I've been using and tracking Stefan Dossinger's work re: DDraw over WineD3D and decided try and find out if IWineD3DSurface was far enough along to be able to be used in place of IWineX11Surface for 2d applications (Hopefully to eliminate depth conversion issues). Short answer, no. Long answer, Screen displays blank, trace log shows that glReadPixels at line 615 in wined3d\surface.c (LockRect) is failing with error GL_INVALID_OPERATION. Further investigation reveals that this is because glFormat is GL_COLOR_INDEX, yet the display is an RGB visual (presumably because an indexed colour visual was not available, and this buffer is connected directly to the screen). I figured I'd look to the people already familiar with the WineD3D\DDraw codebase before I tried to figure out my own solution. -- "Most people would rather die than think; in fact, they do so." - Bertrand Russell (1872 - 1970)
Hi,
Long answer, Screen displays blank, trace log shows that glReadPixels at line 615 in wined3d\surface.c (LockRect) is failing with error GL_INVALID_OPERATION. Further investigation reveals that this is because glFormat is GL_COLOR_INDEX, yet the display is an RGB visual (presumably because an indexed colour visual was not available, and this buffer is connected directly to the screen). That is not supported right now. My current priority is to get all previously supported apps working in the way they where working before. Roderic has posted a patch for the current ddraw code to address this, this could be used to extend WineD3D.
At the moment I have problems with LockRect / UnlockRect, described here: http://archives.free.net.ph/message/20060213.220622.51814d8e.en.html (The sf.net archives broke the attachmet). This is needed for DDraw, and it's also a showstopper for many D3D7 games. So what's basically needed for DDraw over opengl: * Indexed colours * Better UnlockRect code * Handling for all Blit cases in BltOverride * A opengl accellerated BltFast override
At the moment I have problems with LockRect / UnlockRect, described here: http://archives.free.net.ph/message/20060213.220622.51814d8e.en.html (The sf.net archives broke the attachmet). This is needed for DDraw, and it's also a showstopper for many D3D7 games.
Hmm, what application are you using to test this? (if you haven't already fixed the issue). -- Not one shred of evidence supports the notion that life is serious.
At the moment I have problems with LockRect / UnlockRect, described here: http://archives.free.net.ph/message/20060213.220622.51814d8e.en.html (The sf.net archives broke the attachmet). This is needed for DDraw, and it's also a showstopper for many D3D7 games.
Hmm, what application are you using to test this? (if you haven't already fixed the issue). I have written a small test app, which I attached to this mail. It works like this: Pressing ESC quits, pressing any other key makes a d3dclear with a color based on the key pressed. This works nice everywhere. On a click with the left mouse button anywhere, the back buffer is locked, filled with 0xff, unlocked and presented. This should fill the screen with a white color, but instead nothing happens.
The app works as it should on nvidia cards, but it fails with mesa software rendering and with the open source radeon driver and fglrx in most cases. Maybe I can take a look at that this weekend, but no promises. Stefan
Hi,
At the moment I have problems with LockRect / UnlockRect, described here: http://archives.free.net.ph/message/20060213.220622.51814d8e.en.html (The sf.net archives broke the attachmet). This is needed for DDraw, and it's also a showstopper for many D3D7 games.
Hmm, what application are you using to test this? (if you haven't already fixed the issue).
I have written a small test app, which I attached to this mail. It works like this: Pressing ESC quits, pressing any other key makes a d3dclear with a color based on the key pressed. This works nice everywhere. On a click with the left mouse button anywhere, the back buffer is locked, filled with 0xff, unlocked and presented. This should fill the screen with a white color, but instead nothing happens.
The app works as it should on nvidia cards, but it fails with mesa software rendering and with the open source radeon driver and fglrx in most cases.
Maybe I can take a look at that this weekend, but no promises.
Stefan
------------------------------------------------------------------------
I have tested your application directly(wine ./main) and it seems to work for me. (note that i can't compile it because i don't have "i486-linux-gnu-gcc") It switch to 640*480 and when i press a key (or left mouse button), all the screen changes to a color (to white for mouse except a little part in the bottom right that shows a tiny code bars). But when i use ESC key, i quit the application but doesn't back to my 1024*768 mode. I must restart my X server (crtl+alt+backspace) and re-login. As you say it appears not to work with open source driver, it works for me who use dri driver. If you have another tests or you need more information on my system, i can help you Christophe
Hi,
I have tested your application directly(wine ./main) and it seems to work for me. (note that i can't compile it because i don't have "i486-linux-gnu-gcc") It switch to 640*480 and when i press a key (or left mouse button), all the screen changes to a color (to white for mouse except a little part in the bottom right that shows a tiny code bars). But when i use ESC key, i quit the application but doesn't back to my 1024*768 mode. I must restart my X server (crtl+alt+backspace) and re-login. As you say it appears not to work with open source driver, it works for me who use dri driver. If you have another tests or you need more information on my system, i can help you Hm. Odd. What card do you have? Can you try with software rendering(take away the users write rights to /dev/dri/card* )
Anyway, the locking code needs some work, and some optimization. Stefan
participants (3)
-
Adam Luchjenbroers -
BONNEL Christophe -
Stefan Dösinger