Old DirectDraw code on XP
Author
Morning. New member, first post.
Can anyone explain why old DirectDraw7 code and Direct3D code that runs blisteringly fast on my Win98 machine with a 16meg graphics card slows to a crawl on an XP machine with a 32meg card and a 2000 machine with a newer card?
Do I need to stop using DirectDraw and upgrade my Direct3D stuff to a higher version or what? Thought all this stuff was supposed to be backwards compatible. I'm only doing 2D stuff with Direct3D but thought it might solve the problem. Wrong.
Cheers in advance and apologies if this is a stupid first question.
Quote:Original post by EasilyConfusedWelcome to GDNet [smile]
Morning. New member, first post.
Quote:Original post by EasilyConfusedI'm not aware of any software-based reasons for this, but different drivers might behave differently. I don't have any evidence as such, but it is possible that DDraw is being emulated and re-routed through D3D - or some other similar route/emulation.
Can anyone explain why old DirectDraw7 code and Direct3D code that runs blisteringly fast on my Win98 machine with a 16meg graphics card slows to a crawl on an XP machine with a 32meg card and a 2000 machine with a newer card?
Quote:Original post by EasilyConfusedProbably not worth it for old/legacy software unless you still rely on it. The better strategy is to stop using DX7/DX8 for NEW software projects. Go for DX9 or D3D10 from now on...
Do I need to stop using DirectDraw and upgrade my Direct3D stuff to a higher version or what?
Quote:Original post by EasilyConfusedWell, it is technically still working, right? To my knowledge backwards compatability just states it will work - not that it'll work at the same speeds...
Thought all this stuff was supposed to be backwards compatible.
hth
Jack
You might want to provide more details on what you're doing. And if possible, test it on other configurations or have others test it for you.
Author
Wow. That was some quick responses!
Details (trying to be brief as possible)
Wrote a DirectDraw 2D platform game with Borland's free compiler (5.5). Used DirectDraw7 interface. Runs lovely and quick on my 98 machine. Tried on XP machine with better card and ran really (really) slow. Recompiled with same compiler on XP machine. Still ran really slow. Recompiled with DDCREATE_EMULATIONONLY passed to DirectDrawCreateEx on XP machine. Now ran really fast but graphics all shuddery (if that is the technical term) presumabley because all software emulated so (guessing) the flip is a copy rather than a pointer move.
Decided (probably wrongly) that the XP machine card was rubbish for 2D blits and better at spitting out textured polygons so last night created a Direct3D engine for drawing 2D sprites by mapping textures onto 2-triangle strips, usual sort of thing.
Again, ran lovely on my 98 machine with 600 sprites flying around the screen at 1 pixel movement per frame. However, same program still runs really slowly on the XP machine, even after a recompilation.
Using the IDirect3D4 interface for this. Don't know if this is relevant. All above problems on XP machine with 32meg card (98 machine only has a 16meg) and all problems same on a 2000 laptop with a modern graphics card. XP machine is a 1.something Gig and the 2000 is an 800mhz. The 98 machine is a 450mhz P3.
What on earth am I doing wrong?
Details (trying to be brief as possible)
Wrote a DirectDraw 2D platform game with Borland's free compiler (5.5). Used DirectDraw7 interface. Runs lovely and quick on my 98 machine. Tried on XP machine with better card and ran really (really) slow. Recompiled with same compiler on XP machine. Still ran really slow. Recompiled with DDCREATE_EMULATIONONLY passed to DirectDrawCreateEx on XP machine. Now ran really fast but graphics all shuddery (if that is the technical term) presumabley because all software emulated so (guessing) the flip is a copy rather than a pointer move.
Decided (probably wrongly) that the XP machine card was rubbish for 2D blits and better at spitting out textured polygons so last night created a Direct3D engine for drawing 2D sprites by mapping textures onto 2-triangle strips, usual sort of thing.
Again, ran lovely on my 98 machine with 600 sprites flying around the screen at 1 pixel movement per frame. However, same program still runs really slowly on the XP machine, even after a recompilation.
Using the IDirect3D4 interface for this. Don't know if this is relevant. All above problems on XP machine with 32meg card (98 machine only has a 16meg) and all problems same on a 2000 laptop with a modern graphics card. XP machine is a 1.something Gig and the 2000 is an 800mhz. The 98 machine is a 450mhz P3.
What on earth am I doing wrong?
Quote:Original post by jollyjeffers
I'm not aware of any software-based reasons for this, but different drivers might behave differently. I don't have any evidence as such, but it is possible that DDraw is being emulated and re-routed through D3D - or some other similar route/emulation.
hth
Jack
It is still native hardware “accelerated” but you are right about the different driver. It is not the first time I am see that a Win9x driver handle DirectDraw better than newer driver versions for Windows XP. Win9x drivers seems more forgivable if it comes to “bad” program behaviors like locking the front and back buffer multiple times per frame. Another difference I have seen is the batching behavior. Win9x drivers have fewer problems with small batches than Windows XP driver. If you consider the differences in the driver architecture between Win9x and XP this is not a surprise.
EasilyConfused, I believe you run in such a problem were the driver behave different. Do you use an own draw call for every sprite?
Author
Demirug, thanks for your input.
Not sure quite what you mean for an "own draw" call. In the DirectDraw game, each sprite is individually drawn using BltFast, some transparent and some not.
I've often wondered whether this means that for each BltFast the back buffer is being locked then unlocked (I presume it must be) and whether there is a better way to do this.
Would it be better to call Lock first then Unlock at the end or is there some other way that I am not aware of?
Wouldn't have thought this was the issue with the Direct3D one though as every draw operation is between BeginScene and EndScene which I presume does the surface locking and unlocking.
Also, I've quite often heard XP drivers can be a bit naff but not 2000, where I seem to have the same problems.
Ta.
Not sure quite what you mean for an "own draw" call. In the DirectDraw game, each sprite is individually drawn using BltFast, some transparent and some not.
I've often wondered whether this means that for each BltFast the back buffer is being locked then unlocked (I presume it must be) and whether there is a better way to do this.
Would it be better to call Lock first then Unlock at the end or is there some other way that I am not aware of?
Wouldn't have thought this was the issue with the Direct3D one though as every draw operation is between BeginScene and EndScene which I presume does the surface locking and unlocking.
Also, I've quite often heard XP drivers can be a bit naff but not 2000, where I seem to have the same problems.
Ta.
I had this issue with Xp, DirectDraw, and an nVidia card. A quick update of the graphics drivers solved my issue.
Quote:Original post by EasilyConfused
Demirug, thanks for your input.
Not sure quite what you mean for an "own draw" call. In the DirectDraw game, each sprite is individually drawn using BltFast, some transparent and some not.
I've often wondered whether this means that for each BltFast the back buffer is being locked then unlocked (I presume it must be) and whether there is a better way to do this.
Do you call Lock/Unlock for every BltFast? I am a little bit surprised because the blitter does as far as I remember don’t require this. The emulation layer will do this automatically if you use a blit method that your graphic card does not support.
Quote:Original post by EasilyConfused
Would it be better to call Lock first then Unlock at the end or is there some other way that I am not aware of?
As I say before you should only need to Lock a surface if you need direct access to the pixel.
Quote:Original post by EasilyConfusedWouldn't have thought this was the issue with the Direct3D one though as every draw operation is between BeginScene and EndScene which I presume does the surface locking and unlocking.
You should call BeginScene and EndScene only once per frame and all draw calls between. On most cards this two functions do nothing it all but you will generate overhead.
To improve performance you should try to batch your draw calls. This means that you draw as most objects as possible with one single call. But as Jack always recommend if you do something new use Direct3D 9. It will make things easier.
Quote:Original post by EasilyConfusedAlso, I've quite often heard XP drivers can be a bit naff but not 2000, where I seem to have the same problems.
Ta.
Win 2000 and XP drivers are nearly identical. Maybe you have heard less about Win 2000 driver problems because there are fewer persons those uses 2000 for playing games.
Author
No, I'm just calling BltFast on its own. I just wondered if DirectDraw needed to call Lock and Unlock behind the scenes but obviously not.
Looks like I'm still thoroughly stumped, then. Appreciate everyone's input anyway.
Looks like I'm still thoroughly stumped, then. Appreciate everyone's input anyway.
Author
Sorry - forgot to ask on the last one...
How would I go about batching draw operations with DirectDraw7? I read something once about a BltBatch method but Microsoft say it is not implemented in 7.
Re using DirectX9, do all my internet at work so can't really justify downloading the SDK. Also would probably struggle getting it to work with Borland 5.5 or Digital Mars compiler and these are the only two I have. Also feel that since I'm only writing 2D platform games, I don't really want people to need DX9 and a compatible graphics card to run them. Stuff like this worked on Sega Megadrive!
How would I go about batching draw operations with DirectDraw7? I read something once about a BltBatch method but Microsoft say it is not implemented in 7.
Re using DirectX9, do all my internet at work so can't really justify downloading the SDK. Also would probably struggle getting it to work with Borland 5.5 or Digital Mars compiler and these are the only two I have. Also feel that since I'm only writing 2D platform games, I don't really want people to need DX9 and a compatible graphics card to run them. Stuff like this worked on Sega Megadrive!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
