How about posting an example here in public so maybe someone else can attempt to help you as well? (leaving the shagging and relieving to Josh and Robert of course!)

What project can't you run ?  There has not been any major revisions to ENIGMA since you left and came back, other than some bug fixings and timeline and this fonts issues etc.  I reckon one of your games did not run due to the non functioning path and path AI finding shit. Can you post a screenshot of the error you are getting ?

Been following this topic and can't help but ask a question, sorry if this might seem slightly O/T, but why do people still rely on INI functions ?  There are many different ways to store settings, some beginner some more advanced.  The easy method by using your own files and using file text reading commands it's more flexible and opens the door for more advanced stuff eventually.

Thanks to everyone who took part in this test the results so far are positive.  It has since been merged.  Robert, are you going to make a new portable zip with the recent changes?

I will keep this topic open for a while in case people want to add anything.

Ok topic locked as this issue was resolved with success, no complaints, and everything so far is working as it should.  Again, thanks for your help.

I've an Alienware X51 with an Geoforce GTX 660 OEM. On Windows 7 64 bits, everything is ok.

Thanks egofree.

A merge will be made soon where the X/Y projection gets rounded first before .01 applied to it, I won't make a new EXE and ask people to test again, because it is not necessary.  There was one test missing which was moving projection using fractional increments, and that was problematic, so rounding fixes everything up.   This rounding thing might have also proactively fixed any potential issues not covered by the test.
At least in theory, but we all know anything is possible beyond belief, with ENIGMA, almost paranormal lol.

@Robert:
https://www.dropbox.com/s/ktliuq5czsp7e8k/DX9Fonts1.png

Who asked me why I removed the 0.25 offset that was present in DX9.  With rounding I don't think this needed, besides I tested and .01 gave identical results to 0.25, no blurriness from not using 0.25 as you can see above the left 1 is 0.25 and right 1 is 0.01

No he has networking systems set to none, meaning the makefile is never even processed for that system, so no. I'm certain the conflict is coming from OpenAL.

There is "connect" (alone) reference in OpenAL includes or source...

Added a pull request
https://github.com/enigma-dev/enigma-dev/pull/750

Fixed OGL1, OGL3 and DX9, rounds first then adds offset to prevent any issues with moving projections or fractional coordinates that may negate the fix and cause the visual anomalies.
Tested all 3 and working.

That is just like saying to use a different variable name. The issue though, is that "connect" should probably be available. It's possible that someone has included some kind of a header in enigma_user namespace.

Using _connect is much closer to the original variable than using a different variable.

BTW, could this be caused by BSnet.h / BSnet.cpp, example
if (!server) { //client
  if (connect(s, sinf->ai_addr, sinf->ai_addrlen) == SOCKET_ERROR)

Alright good I was just going to tell you to patch DX as well. But please leave any FS fixes or anything out of this pull request. Anyway, go ahead and send it and I'll tell Josh or Harri to merge it.

Ok will do this now, and don't worry, the DX9 fixing was just a personal experiment, I'll show you the script I made for it later so you can tell me what you think. I'll integrate that into my own projects using DX9, will wait for the window resizing bug to get fixed first.

want me to patch DX11 too ? lol !

Yeah if you notice I used the delta_time or w/e constant to calculate my scrolling background.

There are many ways to do your own scrolling but majority of people will use traditional methods - When I modified your demo, it looked 1:1 identical yet did not have the gaps anymore.

Anyway, no I said I don't wtf to your code you sent me in a PM because your rounding was mixed with earlier suggestions we made for vertices, not the projection coordinates. Thus my wtf response.

I did try the proper rounding method before but I used X+ instead of x =, so now it all works.  I just finished testing this with DX9, window and full screen and it worked too.
I removed the +0.25 thing that was there, I checked before and after and fonts looked identical, and replaced it with the rounding fix.  So now OpenGL1, OpenGL3 and DX9 are patched with this fix. 

Anyway, wonderful, good thing it works, and yeah I'm certain nobody would ever have a need for a camera at a half pixel would they? When the camera is at half-pixels all you ever notice are artifacts, it looks the same as if it were at the rounded coordinate except shittier.

Exactly, I mean those are little details, what matters is the game, and visually the majority of people playing the games will not dissect the pixel placement on the screen.  With all the movement and concentrating on the game those are details

So am I correct in my assumptions or does someone have evidence to the contrary?

Actually your assumption is logic.

We established at 0.01 works for us all,
and you've guided me to discovering that whenever user x/y + engine offsets = an integer, that the artifacts appear again, and yes half a pixel looks uglier than rounded to the nearest, after looking closely did not see .01 adding any visual effects to the fonts, I mean most people don't care or don't have trained eyes, and besides when playing at your monitor's native resolution 1:1 with your game res, it is never an issue.  Most of the blurriness or other spacing/thickness inconsistencies will be seen due to monitor upscaling and game scaling, as  a lot of people use room sizes < than their monitor res anyway. 

Yeah I like to do things the hard way, plus I don't like using anything built into GM because it's always designed around a fixed time step and not delta timing.

Isn't ENIGMA the same ? Working in steps, for compatibility to GM ?   BTW, nice find, yes too hectic around me and I've been real busy, can't believe I missed that in the testing.

The ortho projection function can be further fixed with the following code.

Code (cpp) Select Expand

x = round(x) + 0.01f; y = round(y) + 0.01f;

Yes Robert, I tried that, and when you said you didn't know what the fuck that was, that was me using a different rounding method because the one I had tried before gave compile error. I realised it was because I used X+=round(x) etc and not x = round.......etc. 

That stops anybody from negating it. We can also fix it in DX the same exact way.

Should have thought of that, and missed it   Thanks for the tip, confirmed working indeed, no matter what coordinates people use, it will always be rounded off and +0.01 added to it, which will prevent negation and allow the stupid artifacts to be out of view.

Will patch the source and submit a new pull.

use a prefix.

_connect works.

example  _connect = 1;
Works fine here.

Here is another example,
room size 640x480

window size 640x480

have a keyboard event: (i.e. vk_right)
window_set_size(720x480);

have another keyboard event: (i.e. vk_left)
window_set_size(640x480);

In this example, window size will change if you press right, BUT if you press left it won't change back to 640x480 and will stick to 720x480.

However, if you were to change the 640 for 641x480, then it would change back to 641x480, but never back to its origin.

Also, example above, if you resize to 720x480, hit F4 to full screen then F4 to window again, then try to go back to 641x480, it will stick to the new 720x480.

You can still keep on dragging the window bigger with your mouse, but never making it smaller as it "sticks"

This is pretty much self explanatory.

I hate to be the bearer of even more bad news, but with the new changes I am still getting the flashing occasional gap in FS with Project Chaos.

I was getting scrolling issues without fix either way, so it's not  caused by the fix.
Without any fix the vertical scrolling in my demo was constantly flickering gap at the seam.

Also the way the scrolling is done in project chaos is kind of odd. Look at the code used,
he is doing it manually ,why the fuck not use the background scrolling - The demo I originally made I re-wrote that code and the scrolling was gone,  he is complicated things for nothing when he could have used scrolling backgrounds

And yes Robert is right, this fix is only a patch, assuming you are on a 0,0 projection view or fixed view that is not negating the +.01 / +.01 fix.  SO, for example if your X/Y projection ortho is set to 0.99/0.99, the result will be an integer and thus negating the fix and the motherfuckers of artifacts will be back!!!  Whatever X/Y you use make sure when added to .01 that it does not = to an integer.

No matter what fix is applied, anything can negate it by game functions and render (no pun intended) them useless.  So there is no real and permanent fix I'm afraid, until ENIGMA gets re-written, or the fonts system re-written or padding is used, and these things won't happen anytime soon.  If this is a serious hardware issue, then a permanent fix would be extremely more complex as conditional offsets would have to be used as the engine would have to "know" the entire bad range and offset dynamically. what a pain in the arse that would be to implement
and I'm sure none of the devs will even want to go there and I can't blame them

So we are in a fucked if you do fucked if you don't scenario, it's a matter of picking the least smelly of 2 feces

So the choice is simple:

Without FIX problem is there all the time with or without projection moving......  Since the FIX is not CAUSING new problems simply moving them

With FIX, problem is gone for no projection movement or projection X/Y + .01 != to an integer.

but stlil present in fractional movements that negate .01 offsets.  So no rounding or offset will fix this shit

So don't use fractional moving projections and you will be fine........

If you use moving projection use a range that does not negate the .01 offsets and you will be fine.

Otherwise you can have wet dreams about ENIGMA being re-written and this problem gone for good because it ain't gonna happen in this lifetime or universe.....not even in our parallel universes, I know, I checked !

Cheers.

BTW I reproduced this problem in DX9, Robert you said all along these issues are not in DX9, they are, just not at 0,0   I tried the moving projection (fractional) and saw the artifacts on fonts, that is with no offsets in the source code for the DX9 graphic system, which is weird because when I ran my test in DX9 initially, everything was fine with no fix, but setting base projection 0.99/0.99 and moving .1 for example and I see the artifacts in DX9 as well.

So the moral of this whole thing, people have to adapt their games to display properly and avoid certain things that could cause issues with other GPUs   A real fix is impossible without an engine re-write or font source re-wrtie / texturing handling re-write.
Meanwhile the current fix will make sure things are displayed correctly based on a projection that is at a .01 offset.

The pull request can now be merged.
https://github.com/enigma-dev/enigma-dev/pull/748

However, I hate to be the bearer of bad news, but we're not out of the woods yet.

We never are and never will be   This is part of the industry, which is why companies are constantly releasing patches, fixes, re-fixes, and re-fix of re-fixes   Let's cross that bridge when we get there, will see if I can come up with a moving projection test check your PM.

Edit: Since his pull request was merged, I have updated the Portable ZIP.
http://enigma-dev.org/docs/Wiki/Install:Windows

Thanks now let's see how long this fix will hold until a new driver revision comes and fucks it up lol!

Indeed this is a cluster fuck of a problem.
This fix just shifts the artifact out of view
it will be seen again if pushed back into range, so yeah, moving project WILL be an issue.     But it is anyways an issue without the fix, only worse