New d3d8 code and FFXIBench3 - pretty good!
I just tried the new d3d8 code with FFXiBench3 again tonight and it's pretty good! The textures are mostly there and there are only a handful of recurring glitches. This demo is downloadable from http://www.playonline.com. Some textures had their colors munged up. I assume this is related to earlier discussions about RGB_ v.s. BGR_ formats. Screenshots: http://img238.imageshack.us/img238/9879/screenshot28hh.jpg http://img48.imageshack.us/img48/4135/screenshot35wa.jpg http://img48.imageshack.us/img48/28/screenshot48xx.jpg I got a lot of these two messages: fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking to Rendering surface surf(a)0x7d388550 usage(1) fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces not implemented, returning D3DERR_INVALIDCALL I'll play around with my CopyRects patch a bit and see if I can get it to work properly then submit it. I'm not convinced MSDN is telling the whole truth about how partial copies should work. Keep up the good work! -Al Tobey
Hi,
I got a lot of these two messages: fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking to Rendering surface surf(a)0x7d388550 usage(1) fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces not implemented, returning D3DERR_INVALIDCALL
I'll play around with my CopyRects patch a bit and see if I can get it to work properly then submit it. I'm not convinced MSDN is telling the whole truth about how partial copies should work. This CopyRect functionality could be implemented using IWineD3DSurface::BltFast, once my DirectDraw patches are in.
On Wed, 2006-03-01 at 07:50 +0100, Stefan Dösinger wrote:
Hi,
I got a lot of these two messages: fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking to Rendering surface surf(a)0x7d388550 usage(1) fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces not implemented, returning D3DERR_INVALIDCALL
I'll play around with my CopyRects patch a bit and see if I can get it to work properly then submit it. I'm not convinced MSDN is telling the whole truth about how partial copies should work. This CopyRect functionality could be implemented using IWineD3DSurface::BltFast, once my DirectDraw patches are in.
Hi. I've been dealing with a program that seems to be very slow at Blitting images onto a D3D surface. Unfortunately, this is not my code so I can't fix it. Would the above mentioned BltFast/CopyRect patches deal with code that attempts to provide this feature? -- Coleman Kane IntelliTree Solutions llc.
Hi. I've been dealing with a program that seems to be very slow at Blitting images onto a D3D surface. Unfortunately, this is not my code so I can't fix it. Would the above mentioned BltFast/CopyRect patches deal with code that attempts to provide this feature? Is it ddraw or d3d8/d3d9? Do you have an radeon card? glDrawPixels is pretty slow on that cards. BltFast won't fix that, it needs a better UnlockRect implementation in WineD3D. I tried to do that, but I failed because of a lack of gl knowledge, but I'll make another attempt sooner or later?
Its actually an i865 and "must remain" an i865. Its amazing, the 3D performance (with shadows and all) is pretty fast if I disable the code that results in the screen blits. It looks like it may actually be running them through some "Stretch Blit" function. I don't know if this might translate down to a D3D call or not that does a size transform at the time of Blit. If you'd like, I'd be willing to help out if I can on getting this working better. Sounds like you've gotten a head start on it. -- Coleman Kane IntelliTree Solutions llc. On Wed, 2006-03-01 at 09:05 +0100, Stefan Dösinger wrote:
Hi. I've been dealing with a program that seems to be very slow at Blitting images onto a D3D surface. Unfortunately, this is not my code so I can't fix it. Would the above mentioned BltFast/CopyRect patches deal with code that attempts to provide this feature? Is it ddraw or d3d8/d3d9? Do you have an radeon card? glDrawPixels is pretty slow on that cards. BltFast won't fix that, it needs a better UnlockRect implementation in WineD3D. I tried to do that, but I failed because of a lack of gl knowledge, but I'll make another attempt sooner or later?
Hi,
Its actually an i865 and "must remain" an i865. Its amazing, the 3D performance (with shadows and all) is pretty fast if I disable the code that results in the screen blits. I have never used an Intel chip, so I can't judge about it's speed.
If you'd like, I'd be willing to help out if I can on getting this working better. Sounds like you've gotten a head start on it. I'm quite busy now with finishing my ddraw patch, but when that is in and the regressions are out, I'll ask for apps that aren't working as they should, and then I can look at it. Except, if you desperatly need this blits working, I can have a quick look at it.
Stefan Dösinger <stefandoesinger <at> gmx.at> writes:
Hi. I've been dealing with a program that seems to be very slow at Blitting images onto a D3D surface. Unfortunately, this is not my code so I can't fix it. Would the above mentioned BltFast/CopyRect patches deal with code that attempts to provide this feature? Is it ddraw or d3d8/d3d9? Do you have an radeon card? glDrawPixels is pretty slow on that cards. BltFast won't fix that, it needs a better UnlockRect implementation in WineD3D. I tried to do that, but I failed because of a lack of gl knowledge, but I'll make another attempt sooner or later?
If you want a hand with OpenGL stuff some more Stefan, I'd be glad to help. We could set up a time to chat/irc off-list or if you want I could see if I can get your existing stuff to work (just send me the diffs). Regards, Aric
If you want a hand with OpenGL stuff some more Stefan, I'd be glad to help. We could set up a time to chat/irc off-list or if you want I could see if I can get your existing stuff to work (just send me the diffs). I'll publish a patch in the next days, I just want to fix S3TC decompression and perhaps get my hands on Diablo 2.
The problem I have with GL ATM is UnlockRect. The current code in WineD3DSurface::UnlockRect doesn't work with a lot of cards / drivers(radeon, fglrx and mesa software rendering fail). glReadPixels and glWritePixels is horribly slow on radeons, it takes 1-4 secounds for an 800x600 image. So what I need is an UnlockRect code for render targets that doesn't use glDrawPixels. I have written a code that replaces ReadPixels with copying the render target to a texture and reading back the texture, this works much better. I tried to write an UnlockRect code that loads a temporary texture and Draws a textured quad, but the quad had the solid color of the first pixel. Thanks for your help :) Stefan
Stefan Dösinger <stefandoesinger <at> gmx.at> writes:
If you want a hand with OpenGL stuff some more Stefan, I'd be glad to help. We could set up a time to chat/irc off-list or if you want I could see if I can get your existing stuff to work (just send me the diffs). I'll publish a patch in the next days, I just want to fix S3TC decompression and perhaps get my hands on Diablo 2.
I own Diablo 2... this would be a good reason to dust it off :)
The problem I have with GL ATM is UnlockRect. The current code in WineD3DSurface::UnlockRect doesn't work with a lot of cards / drivers(radeon, fglrx and mesa software rendering fail). glReadPixels and glWritePixels is horribly slow on radeons, it takes 1-4 secounds for an 800x600 image.
I am running fglrx as well, so I could work on getting the performance up on these cards. I also have contacts at ATI, so if there are specific problem I could send feedback directly, and hopefully they can fix things for future releases. Although I'd check glDrawPixels on Windows as well... I suspect it is just as slow there. Also for glDrawPixels you should turn off a lot of the GL state (lighting and stuff that you don't need). That could speed things up a bit.
So what I need is an UnlockRect code for render targets that doesn't use glDrawPixels. I have written a code that replaces ReadPixels with copying the render target to a texture and reading back the texture, this works much better. I tried to write an UnlockRect code that loads a temporary texture and Draws a textured quad, but the quad had the solid color of the first pixel.
Sounds like it shouldn't be too difficult OpenGL problem. There are a lot of commands related to texturing, so it is quite easy to muck things up. I looked at the code a bit that you posted before, but nothing jumped out at me, although it would be easier if I had the full code to play with.
Thanks for your help :)
No problem, anything that will help accelerate the merge of ddraw/d3d7 into wined3d :) Regards, Aric
Hi,
I own Diablo 2... this would be a good reason to dust it off :) I should get it by today :) I ordered it at Amazon for a cheap price. Usually it takes 3 days until I get things. Snail mail that is :).
I am running fglrx as well, so I could work on getting the performance up on these cards. I also have contacts at ATI, so if there are specific problem I could send feedback directly, and hopefully they can fix things for future releases. Although I'd check glDrawPixels on Windows as well... I suspect it is just as slow there. Also for glDrawPixels you should turn off a lot of the GL state (lighting and stuff that you don't need). That could speed things up a bit. The attached program illustrates the problem: It's a d3d9 app and runs with current Wine CVS. On startup, it shows a black screen. If you press any button(except ESC), it will do a Clear with a solid color based on the key you pressed. If you click anywhere with the left mouse button, it locks the backbuffer, fills it with 0xff, unlocks it and flips. On Mesa radeon this has no effect(image doesn't change), with software rendering it's the same, as well with fglrx. If you change the pixel format to D3DFMT_R8G8B8, then it will work for fglrx. I haven't tested this on Windows, but I was told that it works with Nvidia cards in Wine. I just tested it in some old cvscedega version, and there it works, although I have to click twice.
If you change D3DSWAPEFFECT_FLIP to D3DSWAPEFFECT_DISCARD in line 121, the screen will go black on clicks, with a delay of about one secound, so you can see the slowlyness. In some rare cases in games, glDrawPixels writes a dark, solid color, and if it writes to the front buffer, it's possible to see the new color sliding down slowly. I suspect that glDrawPixels isn't really broken, but WineD3D sets up render states which break it. I wanted to do a test with a simple GL app, but I didn't find the time yet. Current DDraw is broken in the same way, but it in the most cases, it draws a textured quad instead of using glDrawPixels, which works fine there.
On Wednesday 01 March 2006 05:48, Al Tobey wrote:
I just tried the new d3d8 code with FFXiBench3 again tonight and it's pretty good! The textures are mostly there and there are only a handful of recurring glitches. This demo is downloadable from http://www.playonline.com.
Some textures had their colors munged up. I assume this is related to earlier discussions about RGB_ v.s. BGR_ formats. Screenshots: http://img238.imageshack.us/img238/9879/screenshot28hh.jpg http://img48.imageshack.us/img48/4135/screenshot35wa.jpg http://img48.imageshack.us/img48/28/screenshot48xx.jpg
I got a lot of these two messages: fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking to Rendering surface surf(a)0x7d388550 usage(1) fixme:d3d:IWineD3DDeviceImpl_CopyRects Wanted to copy partial surfaces not implemented, returning D3DERR_INVALIDCALL
I'll play around with my CopyRects patch a bit and see if I can get it to work properly then submit it. I'm not convinced MSDN is telling the whole truth about how partial copies should work.
Keep up the good work! -Al Tobey
Good news :) Seems working correctly But we must fix all the RGB v.s. BGR problems Best Regards, Raphael
Raphael <fenix <at> club-internet.fr> writes:
But we must fix all the RGB v.s. BGR problems
I'll submit a patch for this when I get home. I verified it with Age of Mythology and the latest CVS (well, from a few days ago). There are just a couple of mistakes in d3d8/utils.c (whoops this file is gone now, great!) and wined3d/utils.c that need fixing, although I don't know if my patch covers all cases, it certainly works for RGB888, RGB565, RGB332 (8bpp rgb). For those intested here is a quick patch against dlls/wined3d/utils.c, I'll submit an "official" one to wine-patches later, in the meantime feedback is appreciated. --- dlls/wined3d/utils.c.orig 2006-03-01 19:09:08.000000000 +0900 +++ dlls/wined3d/utils.c 2006-03-01 19:09:32.000000000 +0900 @@ -1703,9 +1703,9 @@ case WINED3DFMT_Q8W8V8U8: retVal = GL_RGBA; break; case WINED3DFMT_Q16W16V16U16: retVal = GL_COLOR_INDEX; break; /* color buffer */ - case WINED3DFMT_R3G3B2: retVal = GL_BGR; break; - case WINED3DFMT_R5G6B5: retVal = GL_BGR; break; - case WINED3DFMT_R8G8B8: retVal = GL_BGR; break; + case WINED3DFMT_R3G3B2: retVal = GL_RGB; break; + case WINED3DFMT_R5G6B5: retVal = GL_RGB; break; + case WINED3DFMT_R8G8B8: retVal = GL_RGB; break; case WINED3DFMT_A1R5G5B5: retVal = GL_BGRA; break; case WINED3DFMT_X1R5G5B5: retVal = GL_BGRA; break; case WINED3DFMT_A4R4G4B4: retVal = GL_BGRA; break; Regards, Aric
participants (5)
-
Al Tobey -
Aric Cyr -
Coleman Kane -
Raphael -
Stefan Dösinger