Re: WineD3D: paletted texture emulation using fragment shaders
On Saturday 16 December 2006 13:24, Roderick Colenbrander wrote:
Hi,
This patch adds 8-bit paletted texture emulation support using a fragment shader.
Won't this break for programs that attempt to use paletted textures and fragment shaders itself? If you need to emulate paletted textures, IMHO, a better option would be to hold the palette and 8-bit image in RAM, and just convert it to RGB(A) when either's changed. Though hardware has dropped native support for paletted textures, so, also IMHO, that should be done on the ddraw side, instead of making all d3d apps think paletted textures are available.
On 17/12/06, Chris Robinson <chris.kcat(a)gmail.com> wrote:
Won't this break for programs that attempt to use paletted textures and fragment shaders itself? For ddraw that won't be an issue, but in case of d3d I think it will, even if the game isn't using fragment shaders itself. Calls to DrawPrimitive will (re)bind the proper vertex / fragment shaders, which would effectively disable the surface conversion.
AFAIK this patch is aimed at ddraw blits with 8-bit paletted surfaces, where this would of course work just fine, but code that gets called from LoadTexture probably isn't the right place. A few other points: On 16/12/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote:
+static int use_fragment_program; +static unsigned int shader_id; ... + "END"; + These are only used inside d3dfmt_p8_upload_palette(), so they probably shouldn't be global. Also, use_fragment_program is assigned, but never read.
- extensions like ARB_fragment_program and ATI_fragment_shaders will be added as well. + extensions like ARB_fragment_program and ATI_fragment_shaders will be added aswell. "as well" is actually the proper spelling :-)
+ if(!have_fragment_program) + { + glEnable(GL_FRAGMENT_PROGRAM_ARB); + GL_EXTCALL(glGenProgramsARB(1, &shader_id)); + GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, shader_id)); + GL_EXTCALL(glProgramStringARB(GL_FRAGMENT_PROGRAM_ARB, GL_PROGRAM_FORMAT_ASCII_ARB, strlen(fragment_palette_conversion), (const GLbyte *)fragment_palette_conversion)); + glDisable(GL_FRAGMENT_PROGRAM_ARB); + have_fragment_program=1; + } I don't think the glEnable()/glDisable() is required there. If it is though, you can kill the glDisable(), and move the glEnable() above the if-block, to save a few redundant state changes. Also, it probably makes sense to just check if shader_id is non-zero, rather than introducing another variable to check if the program is already created.
+ glActiveTexture(GL_TEXTURE1); You should probably call that through GL_EXTCALL, even though I doubt there are much pre-1.3 GL setups left.
Am Sonntag 17 Dezember 2006 05:06 schrieb H. Verbeet:
On 17/12/06, Chris Robinson <chris.kcat(a)gmail.com> wrote:
Won't this break for programs that attempt to use paletted textures and fragment shaders itself?
For ddraw that won't be an issue, but in case of d3d I think it will, even if the game isn't using fragment shaders itself. Calls to DrawPrimitive will (re)bind the proper vertex / fragment shaders, which would effectively disable the surface conversion.
AFAIK this patch is aimed at ddraw blits with 8-bit paletted surfaces, where this would of course work just fine, but code that gets called Yeah, this will only work for 2D Blits, not for 3D drawing. Even if the app doesn't use pixel shaders we would need a full fragment pipeline replacement I think.
Games that use fragment shaders and 8 bit textures at the same time should be pretty rare, as directx drivers dropped 8 bit support long ago. I think we should remove the advertisement for WINED3DFMT_P8 if the texture palette extension isn't available for directx8 and directx9, even though we support those formats. Even though the emulation via manual unpacking works, it needs 4 times the video memory, and CPU time for unpacking. Games will fall back to a 16 bit texture usually. They have to deal with a lack of that format on windows too. We should keep advertising it for DirectX7 and below games. Afaik all cards that were out when these games were written had support for P8 (well, the ddraw format that represents D3DFMT_P8). And if a dx8/9 game tries to use P8, then this should succeed, with just beeing inefficient in terms of vidmem usage.
Am Sonntag 17 Dezember 2006 04:03 schrieb Chris Robinson:
On Saturday 16 December 2006 13:24, Roderick Colenbrander wrote:
Hi,
This patch adds 8-bit paletted texture emulation support using a fragment shader.
Won't this break for programs that attempt to use paletted textures and fragment shaders itself? If you need to emulate paletted textures, IMHO, a better option would be to hold the palette and 8-bit image in RAM, and just convert it to RGB(A) when either's changed.
Though hardware has dropped native support for paletted textures, so, also IMHO, that should be done on the ddraw side, instead of making all d3d apps think paletted textures are available. If you look at dlls/wined3d/surface.c, d3dfmt_get_conv() and d3dfmt_convert_surface() then you'll see that we do exactly that :-) The problem is that unpacking a 8 bit palettized texture to a 32 bit ARGB texture eats a lot of video memory and cpu time. The idea behind the blitting shader is to have unpacking done in the gpu and avoid eating video memory. But as you've correctly seen, this won't work for 3D rendering, only for 2D blitting.
participants (3)
-
Chris Robinson -
H. Verbeet -
Stefan Dösinger