Sign in to follow this  

Old DirectDraw code on XP

This topic is 4307 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Quote:
Original post by EasilyConfused
Morning. New member, first post.
Welcome to GDNet [smile]

Quote:
Original post by EasilyConfused
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?
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.

Quote:
Original post by EasilyConfused
Do I need to stop using DirectDraw and upgrade my Direct3D stuff to a higher version or what?
Probably 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...

Quote:
Original post by EasilyConfused
Thought all this stuff was supposed to be backwards compatible.
Well, 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...

hth
Jack

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?



Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
PS: Tried locking the surface before BltFast and doesn't work at all if the surface is locked.

Reckon I'm going to try creating an array of RGBQUAD's, writing my own software routines to put sprites in it then bung the whole lot on the back buffer with StretchDIBits or something then just use DirectDraw to do the flip.

Probably turn out that the flip is what is slowing it down knowing my luck :<

Good weekend, everyone and thanks again.

Share this post


Link to post
Share on other sites

This topic is 4307 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this