I've looked at his code and fixed part of it because I did not have time to check the rest.

Certain semi colons were missing where they were important to be put, also the script sprite make had "var i" in it, that the ENIGMA compiler did not like, so I commented those out.  //update: if I put those back in the compiler complains of the var in that area.

There was a line checking hspeed xor something else, and it had to be put between parenthesis.  The compile errors are due to mostly missing semi colons in critical places, variant type variable declaration and missing parenthesizes. 

Lots have to be gone through and fixed certain parts might have to be redone to
get it working.

I agree about consistency that's my method, that's why I will set up one single template we can all test the same thing.

No, I never complained of blurry text, if you go back from the beginning I made very clear in my posts that the problem is text not displaying properly and I mentioned very specifically the lines next to text.  There were issues before where I posted screenshots that you looked at, remember that alpha image demo where I mentioned the 1 is not drawn properly ? (was displayed like |1 with a dot on top of the 1 ? Never did I mention once text was blurry, and I repeated many times during out testing
What we are doing is a temporary fix to "shift" the anomaly around so it  disappears from view but not actually fixing the problem.
What we are doing now is a band aid solution. Mind you I have nothing to say about that really, YYG has been doing this from day 1. (intentionally).  Right now with ENIGMA since a complete re-write is not realistic, I guess we should focus on a temp fix for now.

As far as external influence....As mentioned, I am not an expert level C++, but when it comes to hardware, software, setting up, troubleshooting, I know my way around. I've troubleshooted the hardest of hardware related and software issues before.  My system is rock solid, well configured, and when testing I usually set up a dedicated area for the OS, clean install, no junk installed aside from all the latest chipset drivers, and hardware drivers and the bare minimum, no other applications installed or stuff that could possibly interfere externally.

I honestly cannot think of something external that may influence my results other than graphic card and graphic card driver.

I have already ruled out defective RAM or VRAM or other issues as those were tested and functioning properly, no defect.
There are no traces or corruption or badly installed drivers or any conflicts.

GMS has a whole set of different problems on their own unrelated.  I have no complaints about the quality render in ENIGMA, the only issues I have seen are the artifacts (refer to screenshots), and the spacing issue is minor really, quite acceptable.  To me BLURRY is unacceptable, and so far I have not seen this with ENIGMA, but the artifacts are also unacceptable.

One thing to understand about blurry and malformed text, most people make games with very low resolution, and nowadays most people have LCD monitor which work quite different than CRT.  So obviously the low resolution material gets upscaled by the monitor or GPU and will look deformed or blurry depending on the screen resolution you have set.  Games at 1:1 with monitor resolution would look better and the best quality would be native resolution obviously. Much the same in your paint program if you upscale the text, if you do a pixel resize you will retain sharp edges but you get the jagged edges, if you use bicubic samping, etc, your edges will blur in this case.

The scaling method in the engine is pixel resize, but if your monitor is not native resolution it is upscaling.  So any slight blur or letters appearing fatter in some areas are the effects of monitor upscaling.  If you switch monitor res to native, in my case 1920x1080, such anomalies go away.

So right now the issue facing is completely different and totally unrelated to any of the above.  The artifacts I see on and around letters are independent of screen resolution, font, font size, etc.

ENIGMA is not 100% compatible, there are certain things that are broken or not working properly and certain things done differently.
Some games might port without modifications, others might require minor adjustments or major depending.

I downloaded it and fixed the code to compile properly without error. Runs now.

The game compile, runs, but obviously
there needs other changes for this to work in ENIGMA.  I can see the intro and world map,
but once in the level mario is unresponsive to movement, somehow it looks like the program is stuck in a loop.  Music is playing
and all, but no movement.  (fixed partially, the missing ;'s where they needed to be placed.  There's more to be fixed, I think I know why mario does not move, collision code will have to be tweaked a little, and other fixes.

I'll let you know later on and send you the working EGM.  Later this evening when I get some time I will look over the thing.
I'm glad you sent this file, I was looking for a more complex, bigger project to test with ENIGMA and LGM, glad to know LGM handled this one quite well, doesn't lag all that much (IDE), fairly stable and fast.
I don't know yet if this can be 100% functional in ENIGMA, from what I gather certain things are not yet fully implemented or finished in the ENIGMA engine itself, but interested in taking a look.

I have another big issue that I am currently testing and want to get resolved too.

(BTW, I am not an ENIGMA developer) but a very interested ENIGMA user,  I came from GM, and using ENIGMA to build from scratch.

Knowing some kind of hack to fix it is not enough, we need to figure out why it is happening. Right now your fix kind of denies logic,

Ok I have reset GLScreen.cpp as it was, and will work with GLMatrix.cpp so we are all on the same level.

More so, I did a change to the modified project.  I simplified the projectchaos, removed sounds and all unnecessary sprites and code to keep only the scrolling screen, and added text.  Also removed my code to dynamically change the d3d projection ortho, as that adds a bias to the offsets already present in the source code.  Now I am working with direct changes to the GLMatrix.   Trust me, that's what I did from the start, I only went those extra steps because all was failing.  So now with new drivers, I am back to playing strictly with the GLMatrix and yes I am modifying the right lines.

but we will check and see what could be the reason. Sadly, neither I or Robert can replicate your problems, so I cannot easily test all of that myself.

If you want my system specs it's posted in that other topic it has not changed.

Windows 7 64bit, 16GB RAM.
(Up to date windows, chipsets and drivers)
EVGA GeForce GTX660 Ti 2GB SC edition
NVIDIA drivers 337.88 (64bit) WHQL (CLEAN install)
P8Z77-V Pro ASUS Motherboard
Intel core i5-3570K (OC: 4Ghz)  Ivy Bridge

But that is why we test a lot of things. I personally think that another good thing to check would be texture coordinates. I think a problem could be precision issues with that, as the position of the glyphs are correct right? It's just that you see lines and malformed letters?

The ONLY problem I ever witnessed so far with ENIGMA is the lines.  Text is crisp and sharp but may have bits of vertical lines next to the text, and bits of horizontal lines top or bottom, and sometimes dots.  No blurriness. Any other anomaly such as certain letters appearing fatter or any other issue would be attributed to monitor scaling or hardware scaling, in which case this issue is completely gone if your monitor resolution 1:1 with the game room.   So this is why doing my tests I will always account for the monitor's native resolution to determine if it is a PASS or a FAIL. I test all other lower resolutions going up, if all pass including native then I mark it as PASS.  Problem with the lines with text occurs in all modes even native and 1:1.

I posted a screen shot above so you'd see what I mean, look closely at the letters, the lines - The letter itself is NOT malformed, it is the added lines surrounding it of different sizes.  I used AA in the examples above, but this occurs no matter if AA is turned on or off....regardless of font used and font size.

As far as Robert's vertical line issue during scroll, I think that is another issue completely.  I was not having this problem at all until I went from 314 to 335, then it disappeared with new drivers 337.  Go look at the code how the scrolling is handled......Whoever wrote projectchaos could have done the scrolling differently using fewer lines of code. 

Also, no need to get emotional. We appreciate your testing and it is slowly getting us on the right track. It's just that we need to properly fix it, and doing it trough "magic" isn't something we want to do. And the fact that we cannot replicate the problem also hurts us.

As said earlier, GLScreen.cpp is reset back to normal, and working on GLMAtrix.cpp now.
Right now without the hacks, all of Robert's ranges do not work, text artifacts.  I am wondering if the problem with text lies elsewhere......all we are doing with the offsets is simply shifting the problem away, sort of like a band aid approach.  I have not seen this issue with GMS, the issues I have seen is elsewhere, they do have a problem with sharpness inconsistency and v position of letters and other issues, that are not present in ENIGMA, however there are workarounds to get perfect display in GMS. The one thing that stands out in ENIGMA is the lines issue (refer to screenshots). 

Right now my work is to determine if there is any relation to the driver I installed, meaning changes in the NVIDIA panel and if so, which one.  Normally I am aware that the changes you can make in the drivers will affect image quality (sharpness) but should not in theory affect the text artifacting, unless NVIDIA uses internal driver settings that affect offsets too?

So we already determined that it's not just the AMD/NVIDIA issue, as I have Nvidia, Robert has ATI and none of us can replicate these problems.

It's called AMD now.  And wrong, Robert did notice the problem with text as this was discussed in previous issues and he acknowledged it.

Maybe later release an exact .egm that has the example you experience the problems in. I will test on an AMD laptop and Nvidia GPU.

I will do so this way we can all this the same thing and be on the same playing field.

We've also been following the suggestions by none other than, that's right, Microsoft who know more about OpenGL and their own graphics API Direct3D than all of us combined.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb219690%28v=vs.85%29.aspx

I don't give a flying crap about their recommendations ! They are not taking into account many variables.  I go with what will work for at least 2 of the most commonly used cards, AMD and NVIDIA, and if possible the most other type of cards.

Right now I am reporting on what I am seeing.

What you are referring as far as rounding, will most likely affect sharpness.  Problem I am experiencing is not blurriness, it's text anomalies such as for example a vertical line next to a 1, dots or other lines surrounding text, these lines are also sharp.  The reason in my screenshot that some lines appeared different shades is because in that example I used AA.....but I also tested AA or non AA, default font or declared font, same issue.  That's what I mean by artifact. 

It does change things depending on what was done previously. Darkstar, did you really change this line?:
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL1/GLmatrix.cpp#L111

I followed EXACTLY to the T what was suggested.  Yes I changed the first,
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL1/GLmatrix.cpp#L111
ONLY that  + the GL MODEL VIEW.  But the values I put there have strange effects and don't behave the same as if I were to do them myself inside the game, meaning  for example set the offset for d3d to 0, and use the D3d_set_projection_ortho function inside game to whatever value I want.  If I were to do 0.1875's within the game with the d3d function, it would not give the same visually if I put it inside the CPP.  AND YES I figured doing 0.1875 on that line + GLScreen would = 0.375 BUT visually if I do 0.375 for d3d + model view in GLMatrix, it did not work....
only worked if I did 0.00/0.00 d3d + 0.375 GL MODEL + 0.375 inside the game through the EDL function !
I hope this is understood I did it over and over and over
.

or did you change this?:
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL1/GLmatrix.cpp#L116

Did not touch this.

Ok well my future games done in ENIGMA will require an NVIDIA card, I already have code to check for that  - problem solved.

This is a pile of horse's manure.

Tomorrow I will make a test project that
has text, scrolling ,etc........ and post a link
to it.  Whoever wants to test it be my guest,
AMD ,Intel, NVIDIA,  I am thrown numbers to play with, they don't work visually well when I plug them in the CPP in the ortho area....  So I'd leave the GL MODEL with the working offset, and manually do the ortho one IN GAME..... this way I won't have to touch GLSCREEN.  If this works for all parties, then to me I will have done my part and will consider it fixed.

Any other suggestions I will listen, but
I will not edit anymore numbers in the GLMatrix.cpp other than the GL MODEL VIEW area..... I've spent HOURS going through all possible numbers in the d3d inside the cpp....won't do that again, I have better things to do.  I am going nowhere and going in circles......I will focus tomorrow on finding what the bloody fucking hell does a driver update make a big difference that has me puzzled too.  NVIDIA back in the very old days had OGL/D3D settings, now they seem to have streamlined quite a bit. I'm sure there are some internal settings that might affect things.  Is this really related to a rounding issue, I don't think so, because the rounding alone or rounding + offset trick as suggested and tried (Yes I did do it and yes as shown) did not have ANY effect on anything.

Cheers

Slow down, you're getting yourself mixed up.

Take a closer look at the clear_view function, do you see anything wrong with what you are suggesting? clear_view only uses x and y one time, when calling the ortho function, so it should make no difference translating it there or in the ortho function.

O RLY ? I knew you'd say that, because to make sure I tried adding both up and putting the equivalent myself in one place, and it didn't bloody work
I already said I tried 0.375, 0.375 and it did not work for me.
ONLY works if I apply it myself INSIDE my game using the d3d function. Again as I stated if I plug those values myself in the CPP they will have a different effect.
I spent much time this evening trying every possibility.

Continuation from post above.

I found out why I am having the issue I explained above., meaning that when I plug the numbers in GLMatrix they don't perform the same as when I plug them in a GML function.  I found a way to fix this. There is another cpp file that must be edit as well.
GLScreen.cpp.

In this example, I am editing GLMatrix.cpp
for d3d projection ortho
I am using x +=0.1875f; y +=0.1875;
and in GL MODEL VIEW.

In addition I also edited GLScreen.cpp
and added the same line as shown below.

Code Select Expand


void clear_view(float x, float y, float w, float h, float angle, bool showcolor)
{
  x+=0.1875f; y+=0.1875f;
  d3d_set_projection_ortho(x, y, w, h, angle);


If this works for us GL3Matrix and GL3Screen will have to be modified as well.

I vote to use 1.875, since both d3d and model view add up to the magic 0.375

Just to make sure this is relevant and I am right I messed up the void clear view function by changing a letter calling it cleaur view instead and when I compiled the game, there was an error, so this function IS called, and the offsets are required to be placed there as well.

Graphics_Systems/OpenGL1/GLscreen.cpp:309:70: error: 'clear_view' was not declared in this scope
     clear_view(0, 0, room_width, room_height, 0, background_showcolor);
                                                                      ^
Graphics_Systems/OpenGL1/GLscreen.cpp:336:132: error: 'clear_view' was not declared in this scope
       clear_view(view_xview[vc], view_yview[vc], view_wview[vc], view_hview[vc], view_angle[vc], background_showcolor && draw_backs);

Renamed it again to clear view, and ran again, works !

Now with GLMatrix, GLScreen modified
with 0.1875 offset + the GL MODEL VIEW in GLMatrix, all works fine. no scrolling glitch, no draw text problems, no borders, all resolutions work fine.

Now again, I am assuming all those numbers you gave me today worked for you, you said it, unless you change your mind again.

Done for today.

One thing I noticed the rounding trick in glmodelstruct.h has no visual effect, I tried everything there.

The ones that have visual impact to me are
the d3d_projection_ortho and GL MODEL VIEW

However I discovered another anomaly.

I have set an interactive code inside the game to allow me to change X and Y offsets and apply them using d3d_set_projection_ortho and the changes apply in real time, I then add code in draw to display those offsets.  Only thing I end up modifying is the GL MODELVIEW inside the CPP.

Whenever I find the right X/Y offsets this way, when I plug them in the CPP file
in the right place, it does not work text goes bad again.
Something is definitely not right !

BTW those scrolling gaps you will always have regardless of offsets.  In last drivers, no matter what offset I used I always had the scrolling gap.
BTW, something is not right.

When using in GLMatrix.cpp
x +=0.1875f; y +=0.1875f;
and GLMODEL VIEW same
I don't get the same visual result, I get bad text.
When using in GLMatrix.cpp
X +=0.00f; y +=0.00f;
OR just // comment that line out and
just use the GL MODEL VIEW 0.1875f
and inside the game apply manually the
d3d projection 0.1875 things work fine.
This defies all logic !

Not to worry, I have good eyes and normally notice things quite well. I know exactly what you mean by the scrolling issue since I experienced it with drivers 335 (Mar2014).
It's a 1 px vertical gap and yes I keep a very close eye and view it long enough to make a call.  In your case probably you had to watch closely, in my case the vertical line was constantly visible and you could clearly see the 1px gap at each tile repeat with previous drivers.

Doing final tests now.  This is one cluster fuck of an issue, I hope we can resolve this shit soon and move on to other things. 

This is what you wrote

...Also please try 0.25,0.25 for the projection and 0.125,0.125 for the model view matrix, and then vice versa. Let me know how each one performs, because all of those work for me.

Also something is very strange here, I have finished testing each new range you gave me, most worked fine, but when I came back to one of them, it did not work, I did not change anything but put back values I already tested.

I gone through all the settings again, this time text is all bad, no scrolling issues, but text bad and visually identical in ALL offsets,
when they worked before - I changed nothing else.
Could it be possible ENIGMA is not properly flushing or clearing buffers or something
I will restart computer and test again.
and yes I tried reinstalling a clean new ENIGMA install same bloody shit!

No those do not work for me and exhibit the scrolling artifacts.

These work for me, please try these ones:
0.375,0.375 and 0.175,0.175
0.175,0.175 and 0.375,0.375
0.1875,0.1875 and 0.1875,0.1875

0.175,0.175 and 0.175,0.175
0.275,0.275 and 0.175,0.175
0.175,0.175 and 0.275,0.275
0.6,0.6 and 0.4,0.4
0.4,0.4 and 0.6,0.6

Off to testing those I mentioned 0.25, 0.25 + 0.125, 0.125 because you said in a previous post that all these worked for you.

No I know enough about it now not to mess anything I shouldn't touch, and I keep backups of the cpp I touch.

BTW, I tried everything suggested even the first time Robert suggested I did try it, even the rounding thing, and yes even what you posted. 

BTW, I just updated the latest drivers 337.88
from NVIDIA, released today.  When updating drivers I do a clean install. I use driver sweeper (driver uninstall) in safe mode and clean all traces of NVIDIA driver / profiles, etc.

Then I use NVIDIA's official installer set to clean mode. 

So far 337.88 works great, and works like version 314 I was using.  The text is buggy, however I am able to find the proper offsets to display text properly in both FS and window, something I could not do in 335.xx from March.  Weird.  By that I mean the d3d projection ortho.  The push vertices settings has absolute no visual effect.

Could this whole problem be caused by incomplete OpenGL textures or something not done right in ENIGMA's code ?

I have more tests to do now to see if I can find working values scrolling glitch.  So far I am trying with 0.375, 0.375 d3d_projection_ortho and tested with many font sizes, down to size 5 full screen and window and all is well. when I get back home later I will try the rest and we can finally agree on what works for all of us.

If so I will have to re-test all the ranges given to me by Robert.  Hopefully we can resolve this steaming pile of shite soon enough and move on to the next pile lol.
These are the 337.88 drivers DEFAULT,
I will try to see somehow if there is a setting in the driver that might cause this.

Also I'm wondering if ENIGMA used OGL1.4 instead of 1.1 would it help matters ?

//update:
Updated: May 27, 2014:  6:35PM ET

I have clean installed recent NVIDIA drivers 337.88 released yesterday and with those I am able to find working ranges.

So after testing, I have found those to work with window, full screen, proper text, and no border problems, no scrolling glitches.

0.25,0.25 for d3d projection ortho

and 0.125, 0.125 for GL MODEL VIEW

Subject to change of course if new issues are discovered with other driver revisions or specific games.

This tested with default font and with declared fonts, anywhere ranging from size 5 to size 50, bold, no bold, AA no AA (all 3 levels). full screen, window, etc.

Tested at different screen and room resolutions from 640x480 up to 1920x1080.

0.375, 0.375 + 0.375, 0375 did not quite work for me Robert.

Oh and the 0.25, 0.25 and 0.125,0.125 combination that works for me now with the latest drivers, I randomly picked to re-test from your list. I did not test the entire ranges you gave me so I stopped at the one that worked and you mentioned works for you.
If you want me to test the other ranges I will do so when I get back later tonight.
but since they both work for us maybe we should stick to those.

I edited post above to add screenshots and more information.  BTW these are results with the push vertex changes.  I really feel this has nothing to do with the above nor the scrolling issue...... I even tried completely commenting out the vertex push lines and adding all kinds of insanely weird values and absolutely no visual change.  I have something else to try.

And Robert, I have tried exactly as suggested with the push vertices that's what I did...... Has no visual effect, anything I put as value changes nothing, the text is still displayed bad.

Code Select Expand


vertices.push_back(round(x+0.5f)); vertices.push_back(round(y+0.5f));


This does not work, whenever I use round
I get compile errors.

Graphics_Systems/OpenGL1/GLModelStruct.h:260:35: error: conversion from 'double' to 'const value_type {aka const VertexElement}' is ambiguous
   vertices.push_back(round(x+0.5f)); vertices.push_back(round(y+0.5f));
                                   ^
Graphics_Systems/OpenGL1/GLModelStruct.h:260:34: note: candidates are:
   vertices.push_back(round(x+0.5f)); vertices.push_back(round(y+0.5f));
                                  ^
In file included from Graphics_Systems/OpenGL1/GLmodel.cpp:17:0:
Graphics_Systems/OpenGL1/GLModelStruct.h:138:2: note: VertexElement::VertexElement(long unsigned int)
  VertexElement(unsigned long v): d(v) {}
  ^
Graphics_Systems/OpenGL1/GLModelStruct.h:137:2: note: VertexElement::VertexElement(gs_scalar)
  VertexElement(gs_scalar v): f(v) {}
  ^
In file included from d:\enigma\enigma\mingw32\include\c++\4.8.2\vector:64:0,
                 from Graphics_Systems/OpenGL1/GLModelStruct.h:41,
                 from Graphics_Systems/OpenGL1/GLmodel.cpp:17:
d:\enigma\enigma\mingw32\include\c++\4.8.2\bits\stl_vector.h:901:7: error:   initializing argument 1 of 'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = VertexElement; _Alloc = std::allocator<VertexElement>; std::vector<_Tp, _Alloc>::value_type = VertexElement]'
       push_back(const value_type& __x)
       ^
In file included from Graphics_Systems/OpenGL1/GLmodel.cpp:17:0:
Graphics_Systems/OpenGL1/GLModelStruct.h:260:70: error: conversion from 'double' to 'const value_type {aka const VertexElement}' is ambiguous
   vertices.push_back(round(x+0.5f)); vertices.push_back(round(y+0.5f));
                                                                      ^
Graphics_Systems/OpenGL1/GLModelStruct.h:260:69: note: candidates are:
   vertices.push_back(round(x+0.5f)); vertices.push_back(round(y+0.5f));
                                                                     ^
In file included from Graphics_Systems/OpenGL1/GLmodel.cpp:17:0:
Graphics_Systems/OpenGL1/GLModelStruct.h:138:2: note: VertexElement::VertexElement(long unsigned int)
  VertexElement(unsigned long v): d(v) {}
  ^
Graphics_Systems/OpenGL1/GLModelStruct.h:137:2: note: VertexElement::VertexElement(gs_scalar)
  VertexElement(gs_scalar v): f(v) {}
  ^
In file included from d:\enigma\enigma\mingw32\include\c++\4.8.2\vector:64:0,
                 from Graphics_Systems/OpenGL1/GLModelStruct.h:41,
                 from Graphics_Systems/OpenGL1/GLmodel.cpp:17:
d:\enigma\enigma\mingw32\include\c++\4.8.2\bits\stl_vector.h:901:7: error:   initializing argument 1 of 'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = VertexElement; _Alloc = std::allocator<VertexElement>; std::vector<_Tp, _Alloc>::value_type = VertexElement]'
       push_back(const value_type& __x)
       ^
mingw32-make.exe[1]: Leaving directory `D:/enigma/ENIGMA/enigma-dev/ENIGMAsystem/SHELL'
mingw32-make.exe: *** [Game] Error 2

I believe I know why this error, so I just
added a line above the code
x=round(x); y=round(y);
and below
vertices.push_back(x+0.5f); vertices.push_back(y+0.5f);

NO changes.  I also removed the 0.5f, I tried other numbers, no visual change.

The only changes I make in the source code
that has any visual effect is the
d3d project ortho, it simply shifts the artifacts, but no range whatsoever eliminates them.
The rest of the tweaks have no visual effect be it on text or scroll glitch.

So we are all on the same page here, I will upload new screenshots to show exactly what I mean. 

There is one easy way to solve the scrolling glitch in FS, is to do 1:1 resolution.

Making a room size a valid screen resolution
then in create event of a controller object
setting:
OscrW=display_get_width();
OscrH=display_get_height();
display_set_size(room_width, room_height);

and in an end game event
display_set_size(OscrW, OscrH);

But for text it's impossible have not found any way.

Will try the rounding thing though this won't have any effect, since I already manually swept all ranges.  I don't see what rounding up or down will do more, it will just fall on some of the same ranges I hit already.

Regarding NVIDIA, indeed, there is a new driver out this morning, it is the 337.88.

Prior to 335 (with 314) I did not have any scrolling glitch, I really don't know what happened. and it worries me that my game would have inconsistent looks based on people's drivers, with functionality so basic!

I intend to use 1:1 and fullscreen for most of my games anyway, in worst case where we cannot resolve the scrolling glitch.  But now text is the harder one to tackle.  There is another way using custom font resources and a custom script but that would increase the size of games and would take time.

Here are the screenshots, I don't need to comment them as they are self explanatory, no complaints with sharpness, the problem is the dots, vertical and sometimes horizontal lines around letters.  Despite sweeping projection ranges they only shift but never disappear.



I zoomed these images for better viewing.
Be it small or large same shit all around.
I tried with other fonts same, so it's not a specific font. but all.

Here is even big text !