Phase 2/2 - Final testing for the fonts and scrolling issues (RESOLVED)

[Darkstar2]

This is a continuation of the other topic:
http://enigma-dev.org/forums/index.php?topic=2000.0

I have been so busy lately that I had to put this on hold for a while.  Today I completed the 2nd and final version of a test project and an update to my fix.  It was established that with the fix applied people with NVIDIA, AMD, INTEL, had no problems viewing fonts in my test project.  However, I discovered an issue on my own when working on v2 of my test project, vertical scrolling had a 1px gap that flickered.  this was not even caused by the fix as I saw it even with all offsets removed, so I updated the fix to address this issue as well.

After rigorous testing on my end with my 2 PCs plus old boards, the results were positive 100%, in theory this will fix all fonts problem, regardless of font and size used and will fix any issues with scrolling.  For those that have graphic cards that had no problems before, the fix will not have any adverse effects and everything should work just fine.

I am submitting a new EXE file for people to try out.  Same drill.  I would please ask you to run the program and follow the instructions.  I've added a menu and it's pretty much self explanatory.  Please go through every menu option.

Here are some guidelines:

For fonts, after a lot of trial/error/testing I have cherry picked the most problematic fonts and combination of letters/numbers/sizes.  You will see 3 sections for fonts, section A which is live render, which is what the engine is currently rendering on your screen.   Section B is a pre-rendered sprite demonstrating what the font should NOT look like, and section C is a pre-rendered sprite showing what the font should look like.  So section A should look like section C, if your section A looks like B, this is not good, so please take note.

Ignore the fact that each line is shifted slightly to the right.  This was done intentionally for testing purposes.  Also ignore any uneven spacing or thickness, again, this is not an issue with ENIGMA but scaling low res fonts on high resolution display + your monitor's upscaling.  The issue to look for here is artifacts, as demonstrated in section B.

-------------------------------------
Scrolling, for this test, the program will switch to full screen mode, and show 2 scrolling backgrounds simultaneously, look closely for at least 30 seconds to a minute, for any 1px or more empty gap at the seams of the horizontal or vertical backgrounds.  If there is a gap you will see a black flickering line at the seam.  In theory this fix should NOT introduce scrolling glitches, but should fix one that was present even without the offsets.
 
-----------------------------------
Border test, this fix should cause any unwanted borders, but I included it just to be sure.  Follow the instructions on screen.

---------------------------------------
Sprites testing, having different instances of sprites scroll in different directions at random positions and alpha settings.  Again, the fix should not have any effect on this, but decided to include it to be sure
If you notice anything unusual such as lines at adges of sprites (such as seen with fonts before the fix) or flickering or you get abducted by aliens, take note

------------------------------------------------

Whether you have any issues or not please report with the following information:

1) As much details as possible as to what IS or IS NOT working for you (FONTS, SCROLLING, BORDERS, etc.)  Please make sure you have understood and followed the instructions first.

2) Your OS, GPU type (NVIDIA, AMD, INTEL, etc) and model if possible along with driver revision (if possible).

3) Your monitor resolution used to run the test project.

If you test on many configurations you can make separate reports or include them in the same one.

I will start first as an example of a valid report:

multi configuration testing:
1) No issues at all with fonts, sprites, borders or scrolling on any setup.
2) Windows 7 64bit SP1
      NVIDIA EVGA GTX 660Ti SC 2GB (337.88 WHQL)
      INTEL HD4000 (iGPU)
       
    Windows XP 32bit SP3
       NVIDIA BFG 8800GTS OC 320MB (306.81)
3) Testing range 640x480 ~ 1920x1080 (Native)
(note that I have extensively tested this, so I am not asking you to test all resolutions).

--------------------------------------
Thanks once again.  Once it is confirmed that people with different setups have successfully run my project and not noticed any anomalies as described herein, then we can go ahead and implement the fix inside ENIGMA.  Test #1 worked for everyone, so I am anticipating #2 will work for everyone as all I have done is add Y offset .01, so now d3d projection ortho X/Y offsets are 0.01/0.01, this is likely helping with rounding issues on some GPUs.   I have compiled this EXE with a modified source where I added my fixes to the source CPP.  It is important that the fixes be included in the CPPs and not done yourself inside your projects as this can be problematic in certain situations.   So I added the fix to GLMatrix.cpp and I can confirm that the fix also works for GL3, so I modified GL3Matrix.cpp as well.

When running this test I highly recommend you have the latest GPU drivers installed.  DISCLAIMER: If you don't feel comfortable updating drivers, don't do it, or do so at your own risk and peril   I am not responsible if your system crashes, fucks up, or anything deemed abnormal caused by updating your GPU drivers or any loss of sleep, alien abduction or otherwise.

Thanks for your help, and hopefully this can be merged and we can move on to other bugs This one was a real pain in the arse!

Current version of enigma contains erronous offsets in the GL matrix, I don't know why these have not been removed as it was established they did not work for everyone Anyhow.

I am including the EXE, zipped.

Now I don't give a shit who's fault it is and who has a better GPU this will not be a debate on who has a bigger penis !  The goal here is to make sure everyone who runs this test is seeing the same good results

Cheers

Download here:
https://www.dropbox.com/s/2i4ff9znwdad6tl/OpenGL1FixTesting-V2-Final.zip


//edit:  Don't run the EXE from the other topic "Phase 1/2"  The revision 2 is more advanced and includes all test, so for those who did not run v1, please don't and skip to this v2. Thanks.

[daz]

Well I didn't run your first round of tests, not sure if that matters to you.

1. Everything is working
2. Windows 8.1, Radeon 7870 HD driver version 14.10-140415a-170730E, Catalyst version 14.4 (release date 4/25/14)
3. 1920x1080

This is a new-ish rig, and while I didn't really expect any problems never hurts in case there's a bug in the OpenGL driver.

[Darkstar2]

Well I didn't run your first round of tests, not sure if that matters to you.

1. Everything is working
2. Windows 8.1, Radeon 7870 HD driver version 14.10-140415a-170730E, Catalyst version 14.4 (release date 4/25/14)
3. 1920x1080

This is a new-ish rig, and while I didn't really expect any problems never hurts in case there's a bug in the OpenGL driver.

I edited my first post to mention that no, it is not necessary to run v1 first.  v2 includes an updated fix and all required tests and is more advanced / has new fixes.

Thanks for your report.  This is encouraging.  First AMD GPU user.  I expect it to work for the others too.

I have already made the changes to GLMatrix.cpp and GL3Matrix.cpp sources on my install.  Once it is confirmed that it works for different configs, I am aiming for AMD, INTEL and NVIDIA GPUs, then changes will be applied to the master source.

//edit: Ok I've gone ahead and made the commits to the GLMatrix.cpp and GL3Matrix.cpp and submitted a pull request which will likely be merged once more people reply to this topic with positive results.

I would appreciate as many people here run the EXE.  Even if you already tested the other EXE (v1) and even if you never had any issues before (this is very important). It is extremely unlikely that this fix will have a negative impact anywhere, but just to be 100% sure. v2 contains an updated fix and changes, discard the v1 in the other locked topic.

Thanks.

[The 11th plague of Egypt]

Please highlight the relevant steps and move them to the top.
No time to read all of that.
Well, I do have some time, but I participated int he first test because it looked much simpler than this 
Oh, and add some screens!

[Goombert]

Everything works fine here, demo was perfect, you also tested the FS border too which was good. As long as everyone else reports the same and you make my suggested changes, this can be merged.
https://github.com/enigma-dev/enigma-dev/pull/748

[TheExDeus]

Every test works fine on my laptop.
Win8.1 64bit
ATI Mobility RadeonHD 5000.

[The 11th plague of Egypt]

Everything looks good on my laptop

Win 7 x64 SP1
ATI Radeon HD 4570 (512 Mb - mobile)
Drivers Catalyst legacy 13.9
Intel Core2 Duo P8600

[Darkstar2]

Great - I'm glad to see many AMD reports, this is where I wanted to make sure things worked - So far I have many confirmations for AMD (old and new), NVIDIA (old and new), and INTEL.

Any more NVIDIA users willing to test V2 ?

Old fix that was working for everyone (v1) had d3d projection ortho X offset by 0.01.
However, found out vertical scrolling had issues for some NVIDIA, even without offsets, so I added a Y offset to make it both X/Y 0.01.  Made the final updates to the source files it is basically ready to be merged, I'd like to get more feedback from NVIDIA as well, and if you have any onboard video or any other card the more feedback the better.

[Goombert]

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. All of these tests were with a stationary projection and the issues may crop up with a moving projection, I believe this can be fixed by rounding the x and y position for the camera and then adding 0.01,0.01

A test should be made to confirm that as well.

Also important to note that Darkstar said that he had the FS border bug with no offsets as well, so this issue is like the projection is offset by default on certain cards, still an extremely odd issue.

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

[Darkstar2]

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

[Goombert]

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.

[Darkstar2]

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.

[Goombert]

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.

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.

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

Code: (cpp) [Select]

x = round(x) + 0.01f; y = round(y) + 0.01f;
That stops anybody from negating it. We can also fix it in DX the same exact way. Because round will guarantee it is a whole number with the offset that works for everybody. Ortho projections should never be at fractional coordinates anyway.

[Darkstar2]

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]

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.

[Goombert]

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

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.

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. So am I correct in my assumptions or does someone have evidence to the contrary?

Also, we don't need to worry about this with the perspective function because it shouldn't be used for 2D rendering.