Show Posts
1
Aali's Custom FF7/FF8 Driver / Re: Custom graphics driver for FF7/FF8 [v0.8.1b]
« on: 2014-12-12 12:18:53 »Those animations rely on the field script being able to modify the palette in real-time (changing the actual colors in the palette, not just switching between different palettes). Obviously that cannot work with your upscaled images since there is no palette to speak of. In theory it would be possible to create upscaled images that use the original palettes but that would kind-of defeat the point not to mention be difficult to implement and since there's no hardware from this millenium that supports paletted textures it would run incredibly slow even if you could make it work.Yeah, palettes are dropped, but current GPUs have crazy fill rates and shader performance compared to a few years ago.
I have been thinking long and hard on this one, I figure the best bet would be to somehow analyze the field script to figure out what effect it is trying to accomplish and implement it with a shader. That is unfortunately only slightly more feasible than the above "solution".
What about this:
- bind two textures, one is a I8 texture with the palletised tiles, one is a 256x256 RGBA texture with the palettes. Pass the current palette index as a shader variable or vertex stream.
- set up both samplers to point sample.
- first load the colour index from the first texture, then look up the colour from the second texture with u=colour index, v=palette index, making sure you sample from pixel centres.
Disadvantage:
- You don't get bilinear interpolation, though you can implement that manually in the shader as well. That would mean 8 texture loads instead of 2, but then again, GPUs are much faster nowadays.
For upscaled RGB images it gets complicated. If you have only lighting, and not colour-cycling, you could try to do tone mapping:
- With a matrix, assuming you only have brightness or slight colour tone changes, you need a matrix Ax=b , with x being the old palette and b being the new palette. Then solve for A for example with a least squares fit ( http://eigen.tuxfamily.org/dox-devel/group__LeastSquares.html ). In your shader you can multiply your texture colour by this matrix to get a similar effect as the palette change.
- With a 3D texture, which is more powerful. Basically, for every r,g,b of the old palette you store the r,g,b value of the new palette. As the PSX is only RGBA5551 you should be able to get away with a 32x32x32 cube. It will be a bit tricky to fill in all the colours that are not in the palette, though. Maybe you could use a kD-tree or octree to quickly look up the nearest colours and blend between them, or write a shader to build the 3d texture in a render-to-texture pass. At runtime you would bind both the RGB texture and the 3D texture, and the shader would look up the final colour by using the input colour as u,v,w of a texture lookup into the 3D texture.
