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