wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
stefandoesinger at gmx.at
Mon Mar 12 04:39:17 CDT 2007
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
+: One table to search for a format
-: No solution for sRGB
* Duplicate the tables, create extra tables for sRGB formats and per-extension
+: Tables stay static
-: Multiple tables look nasty. Can get out of control
* Put one format into the table, select other per-extension formats in
+: 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070312/ea022001/attachment.pgp
More information about the wine-devel