..:: PCSX2 Forums ::..

Oh my gosh !

@shinra358
Could the unaligned texture be linked to anisotropy? OpenGL doesn't support it yet.

(05-01-2015, 11:34 AM)gregory Wrote: [ -> ]@blyss sarania
Sure it is very easy Except for a few details
1/ There is already code to dump PC texture as bmp/dds/(and now png). Note it is awfully slow.
2/ How do you map PC texture number n with "my_sword_in_hd.png". GS handles texture as a byte stream. It receives a "partial" write to an address A with parameters P1/P2...

The slowness of textures dumping shouldn't be a real issue because only the creators of the HD textures need to do it and they have to do it only one time per game.

As for mapping, it should be straightforward. If the GS component can dump a texture A to "my_sword_in_hd.png," it can do reverse mapping as well. And creating a byte stream from a file is also straightforward. I don't know what you mean by a partial write. Could you please explain more?

I dont think so. I set anisotropy to 0 in the ini and in the nvcp, it was already set to application controlled. I turned if off on dx11 and there was no change. It still worked fine in dx11. In opengl, those blocks move around when you rotated the camera. So since it looks correct in dx11 whether aniso is on or off, it may not be aniso's fault.

Quote: I dont think so. I set anisotropy to 0 in the ini and in the nvcp, it was already set to application controlled. I turned if off on dx11 and there was no change. It still worked fine in dx11. In opengl, those blocks move around when you rotated the camera. So since it looks correct in dx11 whether aniso is on or off, it may not be aniso's fault.

Ok. It was to avoid debugging a normal behavior

Quote:The slowness of textures dumping shouldn't be a real issue because only the creators of the HD textures need to do it and they have to do it only one time per game.

As for mapping, it should be straightforward. If the GS component can dump a texture A to "my_sword_in_hd.png," it can do reverse mapping as well. And creating a byte stream from a file is also straightforward. I don't know what you mean by a partial write. Could you please explain more?

No. It doesn't work like that. You ask the GPU to draw with a texture from an address with a format parameter. Next time texture could be in another address, or with different format. Or you can put 2 textures at the same address (yes it is possible, it depends on the format). A single frame is around 100 texture transfers (without GSdx texture cache it will be severals thousands....)

PS2 doesn't have a big GPU memory so it is used as cache. Texture must be power of 2. To use all bytes, games allocate big texture and use it as atlas. So they do partial write of texture. They could also puts 2 textures in memory side by side but uses it as a single texture (half screen bug for example).

It's cool there is already code there, how do you make it work?

Meanwhile as far as the dumping/loading problem - we need to find some way to uniquely identify the textures. E.g. like a hash or something that already exists. You name the dumped texture with that, and as far as loading if outside loading is on, when a texture comes up, you look for a file texture with that name/hash in name.

The problem is how to uniquely identify. I just checked it dolphin and it seems they are using Game Identifier + some type of hash. I dumped some texture from Soul Calibur 2 in Dolphin and got files like:

GRSEAF_eb18c782_6.png

GRSEAF is the game identifier(we could use SLUS/SCUS type code or CRC here), eb18c782 is some sort of hash, and I'm not sure what 6 is.

Edit: Also the GS theoretically shouldn't need to be involved with the loading - we are loading the textures at the PC style point. e.g. GS has already spit out it's texture, it's been converted to PC style. It is at this point we load replacement texture. So the GS will not "know" what is happening. This should also solve issues where textures that are being changed are referenced in some way(e.g. like a shader would, not sure if GS does anything like that though) because the GS would still be processing textures per normal, and would still have access to the PS2 textures it processed. I think.

Would it be possible to look at Dolphin for an idea how theirs works?

Their hashing algorithm changed by the way, it spits out textures like this

tex1_16x32_c6205a75e42cf903_2

or

tex1_30x30_5f7f3ad6ebb4e392_0b88c0bd95b823c6_9

if it's a paletted texture, which is why they needed the rewrite.

Ahh, I'm still using an old version.

In Dolphin texture replacement is strongly tied to texture cache and mipmapping. If you're planning to implement texture replacement then it may be the best moment to rewrite the texture cache because we all know how buggy GSDX's texture cache is. It could be the best idea to create a separate texture cache for OpenGL