WineD3D: paletted texture emulation using fragment shaders
hverbeet at gmail.com
Sat Dec 16 22:06:01 CST 2006
On 17/12/06, Chris Robinson <chris.kcat at 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 at gmx.net> wrote:
>+static int use_fragment_program;
>+static unsigned int shader_id;
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 :-)
>+ GL_EXTCALL(glGenProgramsARB(1, &shader_id));
>+ GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, shader_id));
(const GLbyte *)fragment_palette_conversion));
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
You should probably call that through GL_EXTCALL, even though I doubt
there are much pre-1.3 GL setups left.
More information about the wine-devel