WCW Nitro: the mysterious wrong textures

[olivieryuyu]

HLE and LLE has the same issue. Only software plugins (HLE/LLE) have not this issue.

It must be a framebuffer/TMEM issue then (CI framebuffer index?)

[olivieryuyu]

Those are CI textures.

[olivieryuyu]

render framebuffer as texture improves the situation, without solving it

[oddMLan]

Native res x1 helps but textures are still messed up heavily

[olivieryuyu]

second screen is now only garbage, regression!

[olivieryuyu]

Btw only jabo software solve the issue, both in lle and hle

[olivieryuyu]

why software plugin solve the case in both LLE and HLE?

[gonetz]

Would be nice to get sources and find why. May be it uses a hack, like Glide64 does.

[olivieryuyu]

a hack only on software HLE but not hardware HLE? that would be odd. You can switch Jabo mode from hardware to software. The correct image appears and then goes black.

still a mystery :)

[olivieryuyu]

actually you are right, it works simply with copy fb to rdram with jabo. in HLE hardware as well.

Damn!

[olivieryuyu]

reading some docs, I have now an idea... :)

Are the letters 4 bits textures please?

[gonetz]

Yes, text uses 4bit CI textures.

[olivieryuyu]

It should be a loading texture issue. Z64 LLE doesn't work with this game. As well the ucode is standard.

I believed for a while it was a kind of framebuffer issue (as Yoshi). But libreto LLE implementation doesn't have the issue and it is based on angrylion plugin. It is hardware with the same capacity in terms of framebuffer than GlideN64.

So it must be a RDP issue. My feeling is that it relates to 4 bits textures.

[olivieryuyu]

would it be possible to check the logs between angrylion and your plugin to see the difference in LLE? That would be useful no?

[angrylion7]

The contents of the TMEM match perfectly between GlideN64 and an older version of my plugin, which could handle this scene, so Load* commands in GlideN64 should be good enough, and they also match my older plugin very well code-wise.
This scene also doesn't use any frame buffer effects. I also excluded many other possibilities during my testing, by tweaking various othermodes bits, by making the two tile indices used non-neighbours in their 0...7 index space, by using just one tile instead of two for all operations (which is possible in this particular display list), by inserting a bogus SetMaskImage command, which is absent in this DL, because it doesn't use z-buffering.
So I went on and created a testrom which only renders the very first texrect of this scene, it was wrong in GlideN64 too. The only notable thing about this CI-8 texrect is that dsdx = 1.0 (0x400), while dtdy = 2.0 (0x800). So I lowered its dtdy to 1.0 and 0.5 and increased YL accordingly, and the divergence from my plugin was gone! Then I increased dtdy to 3.0 and decreased YL accordingly, and the bug was there but less pronounced. So it should be an issue with the "rendering" stage.
Since the LSB of integer parts and whole fractional parts of T coordinates are always zero in this scene while dtdy is always 0x800, in my plugin this not only effectively suppresses triangular filtering (turning it into nearest-neighbour filtering, because S coordinates also cooperate to achieve this), it also means that "dword interleave" when fetching texels from the TMEM never ever happens.
So maybe it's just a bug in how GlideN64 renders CI-4 and CI-8 textures when dtdy >= 2.0 (or even simply > 1.0), or it may be somehow connected with this "dword interleave", which is somehow not emulated well for textures of the above mentioned formats and for big dtdy's.