Gliden64: 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.

[gonetz]

@angrylion7 , thanks for the analysis! I'll look at this problem after solving current regressions.

[gonetz]

I found the problem.

Lets consider LLE case.

First texture image:
gDPSetTextureImage( G_IM_FMT_CI, G_IM_SIZ_8b, 704, 0x00121140 );
That is game set 8bit CI texture with origin at address 0x00121140 and width 704.

Then this texture image is loaded to TMEM using LoadTile commands.
LoadTile "copies" rectangular sub-image from large texture image in RDRAM to TMEM.
Tile size is 64x32

This tile is rendered by texrect with size 64x16. Looks strange: why use tile which has doubled height?
The texrect uses dtdy = 2.0, that is each time Y coordinate increased by 1, T coordinate increased by 2, so 16 pixel height of rectangle mapped to 32 texel height of texture. In other words, half of texture texels skipped.

So where the problem? The problem is that actual image width is not 704, it is 1408
How LoadTile works in this case? For example, the very first LoadTile with uls = 0 and ult = 0.
line 0: skip 704 * 0 texels from origin and loads 64 texels of texture image to TMEM
line 1: skip 704 * 1 texels from origin, loads another 64 texels
line 2: skip 704 * 2 texels from origin, loads another 64 texels
and so on.
Each line with odd index in tile is wrong, because after skipping 704 texels we will be still on the same line, not on the next one as it should be.
No problems for software render: it skips lines with odd indices from the tile because of dtdy = 2.
Large problem for hardware render, because it uses continuous texture coordinates from 0 to 1. and thus half pixels get wrong texels. May be implementation of #1603 will allow to fix it without hacks.

[olivieryuyu]

finally the mystery is cracked!!!

May be not solved but at least identified :)

[olivieryuyu]

Would it be possible that #114 is the same issue?

[olivieryuyu]

@gonetz

Do I understand that you need to be able to use non normalized coordinates for texture rectangle?

If so what not using:

https://www.khronos.org/opengl/wiki/Rectangle_Texture

Coud it be?

[gonetz]

Rectangle_Texture is an interesting feature. I did not know about it, thanks!

Use of Rectangle_Texture by itself can't solve the problem. As the description says, "It could certainly be emulated by using the textureSize function to get the size and manually normalize a texture coordinate." That is, we can do the same without Rectangle_Texture. It may help to implement #1603, since non-normalized fetching would be more natural with use of Rectangle_Texture.

In short, this particular issue can be fixed either with a hack (easy way) or with serious modification of texturing code.