RE: wined3d: universal surface convertor function for unsigned integer color formats(2nd attempt)
How many different conversions do the two games need? One of my concerns is that this generic code is way slower than a separate conversion function for each pair of color formats. On the other hand, one function for each pair gives a whole lot more of code, and if we run into the conversion function during rendering we can kiss the framerate goodbye anyway
-----Original Message----- From: wine-patches-bounces@winehq.org [mailto:wine-patches- bounces@winehq.org] On Behalf Of Victor Eremin Sent: Thursday, July 17, 2008 11:02 AM To: wine-patches@winehq.org Subject: wined3d: universal surface convertor function for unsigned integer color formats(2nd attempt)
Supports conversion between most of "unsigned color" argb/xrgb surface formats (D3DFMT_A8R8G8B8, D3DFMT_A8R3G3B2, etc), and "luminosity" color formats (D3DFMT_L8, etc), excluding D3DFMT_A16R16G16B16, D3DFMT_A8P8, D3DFMT_P8 and D3DFMT_A1. luminosity to argb/xrgb (and vice versa) conversions are not supported
Removes "Cannot find coverter" FIXMEs from "Ancient Evil" and "Stranded 2" games.
Fixes water glitches in "Stranded 2" game.
dlls/wined3d/surface_base.c | 203 ++++++++++++++++++++++++++++++++++++++-- dlls/wined3d/utils.c | 126 ++++++++++++------------ dlls/wined3d/wined3d_private.h | 2 +- 3 files changed, 260 insertions(+), 71 deletions(-)
On Thursday 17 July 2008 22:33:34 Stefan Dösinger wrote:
How many different conversions do the two games need?
The games I've mentioned before use simple things like X8R8G8B8 to R5G6B5 or X8R8G8B8 to R8G8B8. By using Google I didn't found much applications with this particular FIXME (simcity3k, stranded2 and "army men" game, which requires conversion from argb to indexed color).
I think that I saw "converter not found" messages some time ago (6-12 months ago) when I've been trying to run things like Sims1, SimCity 2000 rush hour, etc, probably with some other games.
In real DirectX/D3DX conversion code (with similar functionality) might be used with loading texture from different surface formats (like when trying to load A4R4G4B4 from A16R16G16B16 using D3DXCreateTextureFromFile, etc) and when dealing with D3DXFillTexture1D/2D/3D.
The use of this function might be somehow dependand on hardware. In this: http://ubuntuforums.org/showthread.php?t=741465 thread user experience game gui corruption, while on my machine without converter only water is corrupted, and converter isn't called for gui elements at all (I've been setting some channels to zero to check that).
One of my concerns is that this generic code is way slower than a separate conversion function for each pair of color formats.
Ideally, this requires benchmark. Conversion shouldn't be deadly slow when compared with optimized function. Besides there is only one optimized function implemented right now.
An "optimized" replacement for current generic procedure would need up to 240..380 functions, which will be error-prone, and will need either "macros magic" or just a lot of code. It'll be difficult to debug that.
If you are concerned about conversion speed, then conversion function can be easily modified in the way that it'll use generic conversion routine only if optimized conversion is not available. This way it'll be possible to optimize frequently-used conversions, while unusual ones will be still available.
It has been a couple of days since I've submitted patch. Patch still isn't in git. Will it be accepted? If not, what should be changed to make it "acceptable"?
It has been a couple of days since I've submitted patch. Patch still isn't in git. Will it be accepted? If not, what should be changed to make it "acceptable"?
I think the problem was that I forgot to reply to your mail.
I think the idea of using this as a fallback if no special conversion function is needed is ok.
-
Stefan Dösinger -
Victor