Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER

[Stefan Dösinger]

Am Montag 12 März 2007 00:30 schrieb Fabian Bieler:
> The same patch as before, but with GL_DSDT_NV instead of GL_HILO8_NV as
> suggested by Frank Richter.
> You seem to add a 2nd table for GL_NV_texture_shader3 formats and try this 
> table first. It is another solution for the static table problem I haven't 
> thought of yet. For now, can you just hardcode the formats in the normal 
> table? It should not cause any issues otherwise, because the function looking 
> for a surface conversion will filter them out anyway.

It is mostly my own fault; When I created that pixel format table almost a 
year ago, we only had static formats which were supported by the gl core, or 
by a max of one extension. Nowadays the table hits the limit with bump map 
formats, and sRGB textures. I think it is time to think about changing the 
design. A few ideas by me:

* Stop making the table static and keep one table per adapter. Then we can 
insert the proper formats depending on the supported extensions at 
initialization time

+: One table to search for a format
-: No solution for sRGB

* Duplicate the tables, create extra tables for sRGB formats and per-extension 
tables
+: Tables stay static
-: Multiple tables look nasty. Can get out of control

* Put one format into the table, select other per-extension formats in 
d3dfmt_get_conv.
+: One table
+: Simmilar to the color keying and palette handling
-: No solution for sRGB
-: Complicated, final format hard to read from pixel format table

* Add extra columns to the table to allow multiple table entries per format:
like a flag sRGB, and a supported extension.
+: One table, stays static
+: Deals with sRGB formats
-: Searching for a format gets more complex, will be more expensive than with 
the many tables approach.

* Replace the table with a function with a huge switch statement.
+: Can deal with all sorts of parameters dynamically
+: Not really more expensive than a lookup table with a linear search
+: If done right should be easy to read
-: We have had that before, it didn't look nice(ok, it used 3 different 
functions)