ENIGMA Development Environment

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.

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.

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

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.

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.

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. 

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.

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.

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.