[Patch] Textures

[HarryTuttle]

PATCH for r680.

All 10 texture mips (11 lods in total) are now uploaded to texture memory.

Not very much to say, besides that 2x2 mips are usually solid color texels averaging the color of the next bigger lod. Also for 1x1, 2x1, 1x2 mips the original hw seems to re-fetch color info from 2x2 mip, that was tested for correctness in many cases like, for example, the distant texture of the road in Daytona2.

Finally it seems evident that Real3D was capable of maximum lod clamping or lod biasing, like some fence textures in Harley, LA Machineguns and Scud. Without it, the lower solid colored lod will show up too early.

[Ian]

excellent work Harry

[HarryTuttle]

Thanks Ian!

Inspired by your solution using glTexSubImage2D I'm speculating that texture dimensions stored at polygon level are just for computing mapping coordinates and replicating factor; I think we should upload into host GPU the original dimensions, those used when populating the texture RAM. I'm currently working on that to confirm this theory.

Please note:
in my last patch I increment texDataOffset inside the function StoreTexture. My real intention was to directly increment texData pointer argument and, at every iteration, continue from the last value. I'm lacking the c++ knowledge to do that... if you want to contribute

Also: you can see I used different decode offsets for specific tile horizontal sizes. It could be possible to do the same using a more complex algorithm on the same decode8x8 constant array, but I didn't have the time. In fact if you pay attention to the offsets sequence used for, i.e. the 8x4 version, it follows a "saw tooth" pattern in respect of the 8x8 version. The same principle is used for the smaller ones in respect of the bigger version. This way we can save some branching using lots of "if-then-else".

If it sounds confusing I'll post a quick draft.

[Ian]

Code: Select all

I'm speculating that texture dimensions stored at polygon level are just for computing mapping coordinates and replicating factor;

yes basically The problem is some games are mixing adjacent textures together. It makes texture invalidation quite complex because you have to walk back in memory and check for overlapping tiles

[HarryTuttle]

It makes texture invalidation quite complex because you have to walk back in memory and check for overlapping tiles

Yes, that's where my brain exploded. Basically all that stuff that happens in TextureSheet::Invalidate.

[Ian]

If you want to better understand how it works take a look at how it used to look before i added the crazy overlapping tile check

https://sourceforge.net/p/model3emu/cod ... et.cpp#l76

The hash value for the texture entry is its x/y position in the sheet. (It's a multimap so we can actually have different texture types at the same x/y position). And we know the min texture size is 32 pixels, so the code simply loops over the area and every 32 pixels asking is there a texture there, if so delete :p

Texture invalidation is a bit brute forcy, but look up is cheap.

[YoYo09]

Ian , Harry

R682 test

von2 , von2 5.4g all
Can not play while freezing from the stage start screen after character setting

[Ian]

I should mention save states might look a bit broken because the memory sheet is missing all the lower mipmaps. You have to start from the beginning

[YoYo09]

I should mention save states might look a bit broken because the memory sheet is missing all the lower mipmaps. You have to start from the beginning

Ian

Delete the nv file
From the first boot to the intro
Likewise, simultaneous freezing of stage 1 image output
A popup window pops up saying that the supermodel has stopped.

[Ian]

Sounds like it crashed
can you make a save state just before it crashes?