Reply 140 of 341, by Glidos
OK, I'm looking forward to it! 😎 But, I'm not expert in dx9, haven't learnt too much of it yet. 😀
Much appreciated. I have the sourceforge project accepted, but I'll probably try to complete the shaders version of the combine unit before uploading the cvs repository.
Ah, yes, regenerating the texture by hw, it's clever. 😎 There's another method to do it, without pixelshaders: bump mapping. It may sounds weird, but it can be done: using the palette indices as delta u values in the thin palettetexture. Only one extra stage is needed in the pixel pipeline, the bump mapping stage which perturbs the texture coordinates of the next stage.
That's brilliant. I looked for something like that. I'd sussed that interpreting color values as texture coordinates was the trick, but never suspected that bump mapping was a way to implement it. Pixel shaders have a few instructions that are precisely for using color as coords, but its very nice to have a way without relying on pixel shaders.
Of course, there are some optimizations like regenerating texture only in the "last minute", when it's really has to be regenerated (caching the palette changes), and checking if the texture uses the changed palette entries, etc.
Yeah I think I get that right, although there may be a bug. In OpenGlide, I cached several device textures per paletted texture, one for each used palette. Works brilliantly for Blood, but for RB it would run my machine out of virtual memory. 😁
But the most important is to use high performance converting code in a direct 3dfx data->dx texture surface conversion. I'm using self-modifying 😊 mmx code, as I unified and rewrote all format converters in 1.40 to be able to convert from any format->any format.
I'm using a call D3DXLoadSurfaceFromMemory. Does the conversion for you, and - silly me - I'd imagined it would be implemented using all the enhancements available. Guess Microsoft thought speed wasn't too important. 😒 Hmmm, that's a shame. I'm not too fond of , or good at, writing mmx code.