OpenGL-Accelerated DirectDraw: Experiances and expectations

Stefan Dösinger stefan at codeweaves.com
Sat May 6 03:37:54 CDT 2006


Hi,
Now that the new ddraw code in my tree is almost feature-complete, I decided 
to take a look at opengl-accelerated DirectDraw. I have implemented Blts from 
and to rendertargets already for Direct3D games like Tomb Raider 3 and Swat3, 
so I thought it would work. Palettized surfaces(d3d demos) and color 
keying(moto racer 2) are also in place.

Well, I started Anno 1602 with opengl surfaces, got a black screen and looked 
at the logs. The basic problem is that directdraw games tend to do a lot of 
'nasty' things(The same applied to d3d games which do ddraw-rendering)

One of these nasty things is GetDC on the render target. Age of Empires 2 and 
Settlers 3 to that to draw text. This is going to be unplayably slow I'm 
afraid. Wine will need a dib engine for that to work.

Another issue is 'stupid' rendering. I tested Tibia 3(d3d with a ddraw main 
menu). It creates a single-buffered, non-d3d primary, and a offscreen d3d 
surface. Now it blts to the offscreen device(which is the wined3d back 
buffer, no problem), reads everything to an non-d3d offscreen surface and 
blts the result to the front buffer. This can work, but it needs some pretty 
good opengl magic to work at a usable speed(At the moment it just produces a 
black screen).

Swat3 showed another problem: It renders the main menu, mouse pointer and the 
in-game hud with ddraw blts, which works just great basically. In opengl the 
main menu renders at ~500 fps, instead of ~40 fps with the old gdi code. But 
whenever I move the mouse pointer over a control, it starts locking all it's 
surfaces in read-write mode, which requires them to be reloaded to gl and 
takes performance down(2-3 fps). This is made worse by the surface convertion 
for color keying emulation.

I expect opengl-accelerated directdraw to take some more time, and there will 
be some games(GetDC) which are unlikely to work well at all. I will make some 
modifications to the WineD3D texture loading code to only upload changed 
areas, which should improve the problems a bit.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060506/c5476a40/attachment.pgp


More information about the wine-devel mailing list