Pages: « 1 2 3 »
  Print  
Author Topic: Phase 1/2 - Help wanted - Please help me test a fix to ENIGMA's font problem  (Read 4420 times)
Offline (Unknown gender) Darkstar2
Reply #15 Posted on: June 03, 2014, 05:44:09 PM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
Works for me too. Geforce 660Ti, Win8.1, driver 337.88.

So we both have the same card and drivers :D Except I have Win7.
Thanks for your feedback, glad to know it works on your end too.

Quote
We need AMD people to test this. Also, we should make sure also no other graphical anomalies appear,

Yes I fully agree, but I don't know anybody personally with an AMD card and all my systems and old gfx cards I have are NVIDIA.  The only thing AMD I used was CPU.   Now I use Intel CPUs.

So far I did not notice any anomaly, I doubt that a 0.01 offset X would cause that much damage.  The rounding vertices thingy I tried had major anomalies with scrolling and other, so that is completely ruled out.

Thanks for your feedback, indeed will make a revision 2, if this revision 1 works for all will add new elements.  BTW, since only X is offset, I assumed it would not affect vertical scrolling.  But just for principles I will add vertical.

Quote
like texture scrolling bug. In the example horizontal scroll looks fine. Is vertical scroll fine as well? And is there no 1 pixel boarder top/bottom of the screen? Because when I tried to fix an off-by-one error in rendering when I fixed one thing, another broke.

Yes I know about the border, with this offset I doubt it will cause borders. I  too tried many offsets and only few specific ranges caused it.

My next revision of this project will add vertical scrolling and change background color to blue and draw a black rectangle filling room area.  Having x and y ortho + GL MODEL VIEW offsets too big caused the border issues, I think we are safe with this range.

Quote
So I ended up not fixing it. Maybe this will fix it as well. Mathematically this fix helps with rounding, but it's weird that only x needs to be changed. Would make more sense if both x and y be 0.01.

Yeah I thought about that too lol, I guess the artifacts I was seeing were "dissolved" by X offsets, and horizontal line artifacts by Y offsets.  But the horizontal artifacts occurred mostly when I played with Y.  But with a tiny 0.01 I guess I could do X and Y.  I will include all this in version 2 :D

Quote
You keep being emotional like a girl on a period. You didn't even mention the d3d_set_projection_ortho(0.01,0,room_width,room_height,0) fix in the previous topic. So when exactly was the place when no one wanted that solution?

Glad you asked :D  Here are some comments I received:

Quote
From Robert:
OGL does not have pixel alignment issues, the issues are in the sampler
for certain cards, I have never once seen blurry text and noone else has.

So if it's not a pixel alignment issue how the hell come this gets resolved with an offset ? or am I missing something?  Be it sampler or alignment or whatever reason is besides the point (no pun intended), what matters is masking this visual anomaly :D  Also I don't know in how many languages I have to keep saying I don't have blurry text, I posted so many screen shots so far.

Also despite Josh merging with lot of reservation he really was against this hack to begin with......this is still an offset, and that is what I was playing it from beginning, except this time I am not touching GL MODEL VIEW, the settings there is what  caused most issues for people it seems.

Then the comments Robert made about / making it clear that offsets would not be used as a fix as everyone complained they have issues and only I have the issues which is utter bullshit!!!  I proved him wrong with my topic, so far everyone who replied has seen the same issue as me and the offset fixes works for everyone so far.  In some cases some people saw no anomaly fix or no fix, which is still good news as it shows that this offset does not have any adverse effects on people who never did have the anomaly in the first place.  So if the results of my 2nd revision project will be positive for all I see no reason why not use this quick fix ..... You've all said you were too busy to fix major things in ENIGMA, that's fine, and unfortunately I don't have the skills to fix ENIGMA myself, so what's left ? A quick fix until eventually an actual ENIGMA developer fixes it or someone new fixes it..........I think this is fair.  But regardless of the decision to be taken, I can do what I want with my projects and I WILL use the offsets.  There is no way I am releasing projects with messed text. :D

Quote
And when did someone said that we won't apply a "band aid" solution? We, just like you, just acknowledge that quick hacks are not the best solutions, but we don't dismiss them. If it works, then it will be applied.

I have not refused any suggestions given to me here, and gladly tested everything suggested to me, and some worked well, but not 100%, some had no effect, some made stuff worse by a mile.  But the only one that works 100% so far is the 0.01., I will make sure once I confirm vertical scrolling works and no border issues.

Quote
ENIGMA has quick fixes in many places in the sourcecode already.

Yeah I know :P  Better a quick fix than no fix and wait till someone has enough time which is unlikely any time soon :D

Quote
So just chill the fuck out. What we DON'T want to apply is a fix that works for you, but breaks shit for others.

LOL why the fuck did you think I started this topic ?  I said from the start I would like a fix that works for all which is why this topic exists.  FFS these are not life or death changes, if something gets discovered eventually it can be removed, we are talking about a quick easy fix a 2 year old can apply, it's not rocket scienece, it's 1 line of code ! :D

Quote
That is what the previous topic was all about. We tried offsets, we tried rounding and both worked for some and not for others.

I don't think anybody did the more extensive tests.
The rounding 1000 worked for me, but later when I tried different fonts and sizes I saw that there were some bits and pieces of lines left.

Quote
We don't test everything. Most of the time only certain examples are tested to see if nothing backwards compatible breaks. In this case it's not even broken, it's just not implemented. The fact that it took 1.5 years for someone to report it kind of shows how little that "feature" was used.

Or how little people were using ENIGMA, some of those flaws were very obvious and so easy to reproduce it's strange that they were not caught.

I only joined ENIGMA since January, and I noticed the DX9 issue not long after I started using ENIGMA and I reported it. along with the many other issues.

Quote
I for one, never use full screen. So I didn't notice. Probably is quite trivial to fix though.

You don't have to use full screen, simply move the window by dragging it, or even clicking on it and the entire display disappears.  :P 

Quote
external resources could be a pain. If someone doesn't know, the reason DX doesn't render anything after fullscreen or after alt+tab, is because it has destroyed the context. Basically it has disconnected the device (GPU) and deleted all resources. Which means you have to reinit the device and reload all resources. Reloading stuff inside the .exe shouldn't be hard, but loading external resources will be harder, as you load them yourself, and we don't store things like paths or anything else.

I agree with you, unless someone used a script to detect in their game to reinit their resources but that would be a pain too.

How come this is a non issue with D3D games I play, going windows to FS, never had this issue, is it because games have their own reinit routines ?

Quote
better. It also explains why sometimes alt+tab outside a game takes freaking 25 seconds. While in OGL games it is instantaneous. That is why you should use GL on Windows as well. Some game engines are becoming exclusively GL, like id Tech engine (Doom3, Rage, Wolfeinsten). Source actually works faster on Windows when running on GL

I agree and this is why I will use GL, now that I have almost stumbled upon a fix that works for all it is more encouraging :D

Would there be any advantages of using DX9 over GL for a game in ENIGMA ?

Logged
Offline (Unknown gender) Darkstar2
Reply #16 Posted on: June 03, 2014, 06:55:12 PM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email

I have an AMD on my other system so I can try this out.

I meant AMD GPU (graphic card).

Quote
That is grounds for a huge flame war and given the maturity level of a couple of the forum members here I am not prepared to enter into that one :)

oh ok then lol.

Logged
Offline (Unknown gender) Darkstar2
Reply #17 Posted on: June 03, 2014, 08:53:36 PM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
Great, please let me know.

@Harri:  Ok I discovered another flaw other than the fonts, vertical scroll indeed is flickering 1px at the seam, that is even without no offset anywhere, so by setting 0.01 on both X and Y it fixes it ! However, since the background scrolling is not in an object event and room itself, the offsets don't work inside my draw event.  So to fix this I hard coded the fixes inside GLMatrix.cpp.  Initial testing worked for me, no more scroll glitch, and text is fine.  So I'll make one final interactive test demo with the changes applied, and if it works for everyone then to me it will be case closed and it will be up to the power that be to apply the changes if they desire.  I even saw that scroll bug in full native 1920x1080, so perhaps this is a scaling issue as it happens in full screen. and it happened without any offset or changes, interesting.  so this 0.01 thing indeed might be helping with rounding, and if it has no adverse effect on AMD (I doubt it will) then this horror story ends well ! lol!

Again I tested all this in D3D window and full screen ( full screen by having the game set it for me when run ) and none of these flaws, so indeed this is only opengl related.


« Last Edit: June 03, 2014, 10:55:08 PM by Darkstar2 » Logged
Offline (Male) Goombert
Reply #18 Posted on: June 04, 2014, 12:39:27 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3107

View Profile
I tested and can confirm whether the fix is enabled or not, it does not make any difference on my end. And I would like to add I am really fucking stumped. Look at the first image, at the top, how come that 1 draws fine but the other 1's below do not?

Also, I have an AMD card.
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.

Offline (Unknown gender) Darkstar2
Reply #19 Posted on: June 04, 2014, 12:51:10 AM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
I tested and can confirm whether the fix is enabled or not, it does not make any difference on my end. And I would like to add I am really fucking stumped. Look at the first image, at the top, how come that 1 draws fine but the other 1's below do not?

Also, I have an AMD card.

Coding wizardry Robert LOL !

I drew the instructions with offsets 0.1 so that they can be readable, and the 1's below with no offset by default. Easy.
In your case are you confirming that all the 1's look like image 2 whether fix is on or off? If you confirm yes then it's good news. BTW don't apply those fixes yet there is something else I discovered, and will work on that tomorrow.  These offsets have to be made in the CPP as I found some other anomalies that needed correction, vertical scrolling.  (I will upload a new demo tomorrow)  The V scrolling glitch occurs even with no offset anywhere, so I found that 0.01, 0.01 (XY) will fix it all but as long as they are in the GLMatrix.cpp.  I would like to upload the 2nd test to make sure it is ok for everyone.
I knew somehow you'd ask about the 1 on top being fine LOL.
Logged
Offline (Male) Goombert
Reply #20 Posted on: June 04, 2014, 12:53:06 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3107

View Profile
I still can't fucking believe this, moving the projection it is acting like you are moving the texture matrix. This just, should not be happening! It makes no sense.
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.

Offline (Unknown gender) Darkstar2
Reply #21 Posted on: June 04, 2014, 01:06:51 AM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
I still can't fucking believe this, moving the projection it is acting like you are moving the texture matrix. This just, should not be happening! It makes no sense.

Anybody want to volunteer testing this with onboard video or non AMD / NVIDIA card ?
Logged
Offline (Male) edsquare
Reply #22 Posted on: June 04, 2014, 01:25:32 AM

Member
Location: The throne of ringworld
Joined: Apr 2014
Posts: 402

View Profile
I still can't fucking believe this, moving the projection it is acting like you are moving the texture matrix. This just, should not be happening! It makes no sense.

Anybody want to volunteer testing this with onboard video or non AMD / NVIDIA card ?

Tomorrow I'll do it, mine is onboard video card, I only hope to be able to do it!  ???
Logged
A child of five would understand this. Send someone to fetch a child of five.
Groucho Marx
Offline (Male) Goombert
Reply #23 Posted on: June 04, 2014, 01:27:55 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3107

View Profile
Darkstar2, I will update my pull request on GitHub with these changes to the source code if you answer some of my questions.

1) This doesn't break anything does it?
2) Please try your changes in the ortho projection function, INSIDE the engine, because that is ultimately where I have to place the fix and I need to know if it works the same there, should be no reason why it wouldn't.
3) Can you confirm this won't break anything else on my hardware?

This is all I really need to know, and you should also get someone to test on Intel, which I see you are doing.

But also, we need to look for finding a real fix to this. I am stumped by this and I don't understand why the issues are horizontal and not vertical.

If I have time I can also test this on my hp laptop, which also has an AMD card.
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.

Offline (Unknown gender) egofree
Reply #24 Posted on: June 04, 2014, 02:17:29 AM
Contributor
Joined: Jun 2013
Posts: 603

View Profile Email
Anybody want to volunteer testing this with onboard video or non AMD / NVIDIA card ?

Yes !

On the laptop Dell Precision M4700, with Windows 8.1 64 bits and Intel HD Graphics 4000, your application works flawlessly before and after the fix.
« Last Edit: June 04, 2014, 02:19:22 AM by egofree » Logged
Offline (Unknown gender) Darkstar2
Reply #25 Posted on: June 04, 2014, 03:01:14 AM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
Darkstar2, I will update my pull request on GitHub with these changes to the source code if you answer some of my questions.

1) This doesn't break anything does it?


Please don't add this fix yet!  Tomorrow I am uploading an updated program for people to test, this will be the final confirmation, there is another issue I discovered, and no it was NOT caused by the fix, as I noticed it without any offsets, but this other thing can be fixed with a slight change to the fix, so far internal tests here show it breaks nothing, so this will fix 2 problems.

Quote
2) Please try your changes in the ortho projection function, INSIDE the engine, because that is ultimately where I have to place the fix and I need to know if it works the same there, should be no reason why it wouldn't.

Agreed 100%. The only reason I included it in my project is for people to be able to dynamically toggle on and off the fix, (much faster that way).  However later on I found out the fix had to be placed in the source so that it is able to handle another issue I will make a full report tomorrow and go into more details. 

Quote
3) Can you confirm this won't break anything else on my hardware?

Yes Robert, it will have your AMD card run into NVIDIA emulation mode  ;D ;D ;D   To answer #3 I will need to confirm one last thing with a new updated program.  I am fairly certain it won't break anything else.  I rather take the time it takes to get this done right.
I will set up a dedicated partition tomorrow and run this through a set of archived older drivers.   But initially when I ran my test in another PC that had an extremely several years old drivers, all was working fine.

Quote
This is all I really need to know, and you should also get someone to test on Intel, which I see you are doing.

Done.   And the result was no text glitch fix or no fix, however I want to expand the test a little further to make sure about 2 things.

Quote
But also, we need to look for finding a real fix to this. I am stumped by this and I don't understand why the issues are horizontal and not vertical.

Finding the real fix solution will be out of my league, as it is something that might require bigger changes to the engine itself.  They are horizontal however when initially you gave me offsets to play with I saw some vertical ones too.  The reason I use 1's is because that is where they are the most obvious.  So far with my fix I tried the entire range of letters, numbers, etc.  However, I want to check something else, the vertical problem occurs if using bigger offsets, more particularly in the GL MODEL VIEW.  The reason maybe this fix is working is because this 1 px artifact is at the complete edge of the glyph so perhaps it's aiding in rounding or something and simply pushes it out of view and into oblivion :D
You mentioned something about padding, won't that use up more VRAM ?

Quote
If I have time I can also test this on my hp laptop, which also has an AMD card.

If everything goes according to plan, INTEL and AMD users should not notice any change between fix and no fix and should not see any side effects.  However if one day something is discovered by accident at least I can't say I did my best to cover all possible scenarios.  Right now the following will be added:

* More text options, sizes, screen res.
* Vertical and Horizontal scrolling
* Testing for border problems (Though really if you are drawing a surface / box or whatever on top of a room you could easily just make it (room_width + 1) and (room_height + 1) but I don't think there should be border problems. There was not when we tested bigger offsets, only a few.
Anything else I should add ? I don't believe a 1/100th offset will cause any harm. While I am confident,I am not 100% yet, but so far getting close

Logged
Offline (Unknown gender) TheExDeus
Reply #26 Posted on: June 04, 2014, 03:55:00 AM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
Quote
Yes I fully agree, but I don't know anybody personally with an AMD card and all my systems and old gfx cards I have are NVIDIA.  The only thing AMD I used was CPU.   Now I use Intel CPUs.
Just tested on laptop's AMD mobility Radeon HD 5000 and it works fine both without and with the fix.

Quote
I agree with you, unless someone used a script to detect in their game to reinit their resources but that would be a pain too.
We can make a function that returns whether you need to reload resource or not. But I would want this to be automatic in some way.

Quote
How come this is a non issue with D3D games I play, going windows to FS, never had this issue, is it because games have their own reinit routines ?
Yes, because they do all this resource reloading. I always wandered playing CS:S in about 2005 why it sometimes take 20 seconds to alt+tab back into the game. I could hear the sound, but the display was black for a while. I turns out DX just deleted all graphics resources from memory. Sound is unaffected, because it's a different system.

Quote
Would there be any advantages of using DX9 over GL for a game in ENIGMA ?
I don't think so. GL is the main system and is the most developed. DX was only made my one person - Robert. I don't think anyone else has ever made a commit in DX. It's possible that DX will be slightly faster than GL1 and maybe GL3, but that's about it. From functionality perspective they are both about equal and GL slightly ahead. From bug perspective GL could have a little less.

Quote
I still can't fucking believe this, moving the projection it is acting like you are moving the texture matrix. This just, should not be happening! It makes no sense.
Quote
But also, we need to look for finding a real fix to this. I am stumped by this and I don't understand why the issues are horizontal and not vertical.
I guess it's not the texture matrix (or more precisely UV coords), but the vertices itself. And they are vertical as well, but they show up only at different situations (vertically scrolling background).

Quote
You mentioned something about padding, won't that use up more VRAM ?
Depends on the font. All textures in ENIGMA are power of two. That means if you have a 72x72 sprite, then in reality it's 128x128 in VRAM. Right now the default font uses about 60 percent of the texture. So if we add 1px padding, then the texture won't become larger and won't take more VRAM. But for larger fonts and more glyphs it would potentially make it roll over to more vram. LGM could maybe show a preview of the texture and show it's size. It would useful.

Also, did you have this issue in GL3 as well? And does this fix it?
« Last Edit: June 04, 2014, 03:57:52 AM by TheExDeus » Logged
Offline (Unknown gender) TheExDeus
Reply #27 Posted on: June 04, 2014, 04:40:37 AM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
Quote
Any chance that the one man ENIGMA team has it wrong and the multi-billion dollar companies aren't selling buggy GFX cards?  :D
It's not about a bug, it's about a differences between the GPU's. So it would be useful to know what they suggest as a fix.
Logged
Offline (Male) Goombert
Reply #28 Posted on: June 04, 2014, 05:01:01 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3107

View Profile
Can you people stop with the sarcastic remarks? Like seriously, if you think you know it so well, then implement the fix. But right now we only know two things.

1) It doesn't occur on AMD, someone with an AMD card prove me wrong if otherwise.
2) It occurs on Nvidia cards, which is nothing tangible to me.

Stop sticking words down my throat, and stop berating my intelligence with dumb fallacies. It's pretty evident multi-billion dollar companies [sic] make mistakes too, otherwise they wouldn't release updates and patches to their own fucking drivers.
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.

Offline (Unknown gender) TheExDeus
Reply #29 Posted on: June 04, 2014, 12:49:20 PM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
Quote
The problem DOES occur on AMD devices HD5570...
But doesn't on several others. And that is why it's not only ENIGMA issue. If it was ENIGMA issue, it would be broken everywhere. All we can do is fix it either as we know how or as more experienced people tells us.

Quote
Geez, I don't know. There is a hell of a lot of wierd issues that ENIGMA has that I have never seen before anywhere else.
Probably because you haven't made an OpenGL engine.
Logged
Pages: « 1 2 3 »
  Print