Darkstar2
|
|
Reply #45 Posted on: May 27, 2014, 11:40:42 pm |
|
|
Joined: Jan 2014
Posts: 1238
|
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.
|
|
« Last Edit: May 27, 2014, 11:47:05 pm by Darkstar2 »
|
Logged
|
|
|
|
Goombert
|
|
Reply #46 Posted on: May 27, 2014, 11:56:03 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
For a better understanding of the issue, vector graphics which is what OpenGL and Direct3D are, like things to be half-pixel aligned to be sharp. By offsetting our projection we offset every pixel by that much, it is a cheap way of solving the issue. The driver anomalies come into play because Nvidia drivers may round the pixel up or down, and AMD drivers may do the opposite.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Darkstar2
|
|
Reply #47 Posted on: May 27, 2014, 11:59:12 pm |
|
|
Joined: Jan 2014
Posts: 1238
|
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 !
|
|
« Last Edit: May 28, 2014, 12:11:19 am by Darkstar2 »
|
Logged
|
|
|
|
Darkstar2
|
|
Reply #48 Posted on: May 28, 2014, 12:44:12 am |
|
|
Joined: Jan 2014
Posts: 1238
|
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.
|
|
« Last Edit: May 28, 2014, 12:54:52 am by Darkstar2 »
|
Logged
|
|
|
|
Goombert
|
|
Reply #49 Posted on: May 28, 2014, 03:05:45 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
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.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|
Darkstar2
|
|
Reply #51 Posted on: May 28, 2014, 03:42:31 am |
|
|
Joined: Jan 2014
Posts: 1238
|
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.
|
|
|
Logged
|
|
|
|
Darkstar2
|
|
Reply #52 Posted on: May 28, 2014, 03:50:24 am |
|
|
Joined: Jan 2014
Posts: 1238
|
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#L111ONLY 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
|
|
« Last Edit: May 28, 2014, 04:10:26 am by Darkstar2 »
|
Logged
|
|
|
|
Goombert
|
|
Reply #53 Posted on: May 28, 2014, 04:25:45 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
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. But it was behaving as everyone expected before you updated your drivers. And yes the issue is ultimately rounding to get the pixels to transform to half-pixels, whether you do it in your game or in the source files, it is still a transformation. I think you are fundamentally missing the real problem here. 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
|
|
« Last Edit: May 28, 2014, 04:36:48 am by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
TheExDeus
|
|
Reply #54 Posted on: May 28, 2014, 04:33:34 am |
|
|
Joined: Apr 2008
Posts: 1860
|
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 ! 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, 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. 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. As Robert said, it probably is because of rounding whatever you do. Because rasterization operation on the GPU involved multiplication of floating point matrices with vertex positions. If your vertex positions is something else than 0,0, then you probably will have some kind of round issues regardless. 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? Because then it should be a texture problem. Even gaps between tiled images could technically be a texture problem, but they usually are connected with vertex positions. Ok well my future games done in ENIGMA will require an NVIDIA card, I already have code to check for that - problem solved. 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. 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. 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.
|
|
« Last Edit: May 28, 2014, 04:37:40 am by TheExDeus »
|
Logged
|
|
|
|
Goombert
|
|
Reply #55 Posted on: May 28, 2014, 04:41:06 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Yeah I am getting kind of curious of the texture matrix as well Harri, the only thing is, trying to map those fuckers directly to pixels that are properly rounded. Also, and I can't stress it enough, he's comparing the behavior of ENIGMA after updating his drivers ex post facto to old graphics demos he's run in the past without testing a single other application. Including Studio which has also demonstrated blurry text and odd rendering artifacts for him. 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. 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. Yes, but also, I have AMD, ATI is defunct.
|
|
« Last Edit: May 28, 2014, 04:45:04 am by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Darkstar2
|
|
Reply #56 Posted on: May 28, 2014, 01:39:06 pm |
|
|
Joined: Jan 2014
Posts: 1238
|
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.
|
|
|
Logged
|
|
|
|
Darkstar2
|
|
Reply #57 Posted on: May 28, 2014, 02:11:01 pm |
|
|
Joined: Jan 2014
Posts: 1238
|
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.
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #58 Posted on: May 28, 2014, 04:29:15 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
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. I know but you keep wanting to think half-pixel alignment is not an issue because you have new issues now. It is still an issue, and it sounds as though something external is influencing your results. 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. Ok, but it is important to note, that for testing purposes, it is good to be consistent (the scientific method). For instance, the fonts you used were fonts you drew with before? And it is also important to isolate these new artifacts to the updating of graphics drivers, because it very VERY well could have another OpenGL setting flipped on or off. 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. Wait, so you never had blurry text this entire time we've been testing? I was under the impression you had at least experienced it before. 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. Interpolation can sometimes cause this to happen as well. You had it turned off right? I mean explicitly calling texture_set_interpolation(false) because other texture settings may be overriding the application in your graphics card control panel. 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. If I remove all offsets, guess what, then I don't have those vertical gaps either. In fact, with default OpenGL I have no rendering anomalies, only with Direct3D. The one thing that stands out in ENIGMA is the lines issue (refer to screenshots). You did not have that problem before updating your drivers, again I would encourage you to visit your control panel and ensure that nothing external is influencing the game. Or also to test another application, such as Studio, with your new drivers. 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. No he means we, me and him, notice half pixel issues, but you seem to have all these other problems that none of us have. 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? It's not so much those things, but you may have turned on interpolation or god knows some random OpenGL texture setting. Anyway, yes, I can't encourage you enough to check that panel.
|
|
« Last Edit: May 28, 2014, 04:44:21 pm by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Darkstar2
|
|
Reply #59 Posted on: May 28, 2014, 05:04:19 pm |
|
|
Joined: Jan 2014
Posts: 1238
|
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.
|
|
|
Logged
|
|
|
|
|