Open olivieryuyu opened 9 years ago
This is still actual
I know. Angrylion's solution need to be implemented.
Angrylion: I solved the problem, in a very logical way. The thing is, if texel1 is used in the 2nd cycle of the combiner, it is in fact texel0 (what Ziggy called 'texel swapping'), BUT for the next pixel (s + ds, t + dt), not for the current pixel.
Can I get any confirmation that this is how it should work?
@gonetz How does the texel swapping happen currently?
I wrote some proof of concept code on how this can be implemented. However, I believe that combiner code could be modified so that this idea fits in more naturally, but I'm not sure how.
Can I get any confirmation that this is how it should work?
Correct.
How does the texel swapping happen currently?
I wrote some proof of concept code on how this can be implemented. However, I believe that combiner code could be modified so that this idea fits in more naturally, but I'm not sure how.
Interesting approach. It works, but only in native resolution. And the title screen with copyrights text has issues with texture mapping even in native res. I also took several attempts in the past to implement that bias to texel one, but result was the same: it either works for title screen or for in-game text and only in native res.
Interesting approach. It works, but only in native resolution. And the title screen with copyrights text has issues with texture mapping even in native res.
You're right, non native resolutions still have artifacts and even native resolution has artifacts in certain places.
I added a hack to the use_screen_coords branch to check the behaviour there and got correct picture in both menus and in-game text (but only in native). So I'm guessing there are actually two issues with this game: a general bias also present in other games (like the one in Ogre Battle) and the texel swapping bias described in this issue.
The text on the game menu seems to be wrapped or overlapped by another one
Angrylion: I solved the problem, in a very logical way. The thing is, if texel1 is used in the 2nd cycle of the combiner, it is in fact texel0 (what Ziggy called 'texel swapping'), BUT for the next pixel (s + ds, t + dt), not for the current pixel.