Works for me too. Geforce 660Ti, Win8.1, driver 337.88.
So we both have the same card and drivers
Except I have Win7.
Thanks for your feedback, glad to know it works on your end too.
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.
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.
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
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
Here are some comments I received:
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
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.
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.
ENIGMA has quick fixes in many places in the sourcecode already.
Yeah I know
Better a quick fix than no fix and wait till someone has enough time which is unlikely any time soon
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 !
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.
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.
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.
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 ?
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
Would there be any advantages of using DX9 over GL for a game in ENIGMA ?