Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
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) pgppI85eYHBZz.pgp Description: PGP signature
Re: [try 3] wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
Am Montag 12 März 2007 11:54 schrieb Fabian Bieler:
On Monday 12 March 2007 10:39, Stefan Dösinger wrote:
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.
This patch includes the requested changes. I did not implement the
conversions for the new pixel formats, as that would not help anything
without also alterting the fragment shaders.
Almost perfect :-)
+
{WINED3DFMT_X8L8V8U8,0x0,0x0,0x0,0x0,4
,FALSE ,GL_DSDT8_MAG8_INTENSITY8_NV,GL_DSDT_MAG_INTENSITY_NV,GL_BYTE},
Can you align the } with the other lines? (I'm picky because it is very tricky
to fix the formating afterwards)
pgpFJRFbyIqU3.pgp
Description: PGP signature
Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
On Saturday 10 March 2007 23:20, Frank Richter wrote:
On 10.03.2007 15:02, Fabian Bieler wrote:
+static const PixelFormatDesc NV_texture_shader_formats[] = {
+{WINED3DFMT_V8U8,0x0,0x0,0x0,0x0
,2 ,FALSE ,GL_SIGNED_HILO8_NV ,GL_HILO_NV
,GL_BYTE},
Are you sure this is right? From the NV_texture_shader spec it looks to
me like HILO is for high-precision data, and that DSDT (described as
offset data) would be more appropriate for V8U8.
You're probably right about that. While I can't see a visual difference
between using HILO8 and DSDT in hl2 with dx81 (which uses V8U8), I'll resend
a modified patch.
Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
Am Samstag 10 März 2007 15:02 schrieb Fabian Bieler: This patch implements D3DFMT_V8U8 and D3DFMT_Q8W8V8U8 via NV_TEXTURE_SHADER. This fixes some renderissues in Half-Life 2 with the DirectX9 path and the DirectX8 path via GLSL. What do those formats provide that other formats do not provide? Signedness, or something else I missed? Using GL_NV_texture shader and GL_ATI_envmap bumpmap is definitly the way to go, but I am concerned about macos, where neither of those extensions exist. But working around that issue will be tricky because the shaders depend more on the stateblock then, and things get increasingly ugly. Oh, and it seems that you have proven me wrong with my suspicion that sRGB correction is the cause of that :-) pgpobZ0K5igsR.pgp Description: PGP signature
Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
On 10.03.2007 15:02, Fabian Bieler wrote:
+static const PixelFormatDesc NV_texture_shader_formats[] = {
+{WINED3DFMT_V8U8,0x0,0x0,0x0,0x0
,2 ,FALSE ,GL_SIGNED_HILO8_NV ,GL_HILO_NV ,GL_BYTE
},
Are you sure this is right? From the NV_texture_shader spec it looks to
me like HILO is for high-precision data, and that DSDT (described as
offset data) would be more appropriate for V8U8.
-f.r.
Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
Am Samstag 10 März 2007 15:02 schrieb Fabian Bieler: This patch implements D3DFMT_V8U8 and D3DFMT_Q8W8V8U8 via NV_TEXTURE_SHADER. This fixes some renderissues in Half-Life 2 with the DirectX9 path and the DirectX8 path via GLSL. What do those formats provide that other formats do not provide? Signedness, or something else I missed? It' mostely signedness but also from the specification: OpenGL's pixel map, color table, convolution, color matrix, histogram, and min/max are NOT performed on the HILO components or texture offset group pixel groups. (I'm not sure wether these operations are performed when shaders are enabled, though.) Also, even GL_HILO8_NV is internally represented by 16 bits per channel (at least according to the spec). Using GL_NV_texture shader and GL_ATI_envmap bumpmap is definitly the way to go, but I am concerned about macos, where neither of those extensions exist. Perhaps GL_NV_texture_expand_normal can help? -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out
Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
It' mostely signedness but also from the specification: OpenGL's pixel map, color table, convolution, color matrix, histogram, and min/max are NOT performed on the HILO components or texture offset group pixel groups. (I'm not sure wether these operations are performed when shaders are enabled, though.) Also, even GL_HILO8_NV is internally represented by 16 bits per channel (at least according to the spec). Wined3d doesn't use them because direct3d does not support them. So no need to worry about them :-) pgpOz170fHeIj.pgp Description: PGP signature
