Archived

This topic is now archived and is closed to further replies.

Optomizing ddraw 7

This topic is 6014 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

What are some common ways to optomize a program using ddraw 7 ie: are there any special flags I should use in the Flip() command; Does triple buffering speed the program up by much; How much does the screen resolution affect the speed (is 800x600x32 a lot faster than 640x480x16); etc......

Share this post


Link to post
Share on other sites
A few things...

Triple buffering may improve your animation but it eats up video memory - so it might help performence if you just use 1 buffer.

Also the screen resolution eats more memory as it increases... a mode like 320 X 200 X 8 takes almost nothing at all... but a resolution like 1240 X 780 X 32 eats up a lot of memory...

Then again most of this stuff can be handled by today''s computers and they''re video cards - but if you aim to run stuff on some "crappier" computers then I would stick to using only double buffering and lower resolutions...

Hoped that helped,

Destroyer

Share this post


Link to post
Share on other sites
I guess I''ll throw in few things since you didn''t mention it:

While back I figured that avoiding rendering between system RAM and VRAM is a good idea if you want speed... so try store all your graphics resources like animation frames in video memory, so that all blitting is done between VRAM and VRAM. If you have so much resources that they don''t all fit in video memory, store the ones you most frequently use in VRAM. And less frequently used ones in system RAM. Or i guess you could also load it from HD appropriately if you are running out of memory.

Another thing I can think of is, accessing video surfaces manually slows things down a lot. So avoid Locking video surfaces for accessing them manually if/where possible.

I guess you could also use DDFLIP_NOVSYNC (or something like that) in flip()... but then you might get tearing, which can get annoying.

Share this post


Link to post
Share on other sites
Its a good idea to stick to 640x480 since many cheap (popular 4MB OEM) cards drastically fall behind when using 800x600 for games.

Use 16Bit as the default BPP and have 24 or 32Bit as an option.
Depending on the video card, sometimes copying the backbuffer to the primary surface is quicker than using flip(), and make sure when you copy to or from the primary surface use ->Blt() instead of ->BltFast() unless you dig 4FPS.

  Game Download  ZeroOne Realm

Share this post


Link to post
Share on other sites
Only Clean Dirty Rectangles.(That is, instead of blting everything all over each frame, just modify only what has changed).

I "heard" DirectX 6 was faster then 7? As most info on the net is pretty much opinion I was wondering if this is true?.I was thinking of writing one of my programs with options to use

DirectX 3.0(DirectDraw2) for Windows NT Compatibility
(PS would anybody know where I can get the DirectX 3.0 SDK Documents?)
DirectX 6.0(DirectDraw4)
DirectX 7.0(DirectDraw7)

Thanks, and excuse me for cutting in

Share this post


Link to post
Share on other sites
Heya,

I am just wondering why Blt should be faster than BltFast on the primary surface??

Also, if you do more than just blitting. For example you are texturing or alphablending, keep the textures in system ram, because you have to load them in system anyway to perform the operations.
Also in my recent project I load the texture in a short array (16BPP) instead of a surface. Makes the code faster and more portable/reusable!!

Also if you lock your surface and are going to copy data from/to it, use DWORD pointers! If you for example have 8 bits per pixel and you load a DWORD form the surface, you get 4 pixels at once.

Gr,
BoRReL

Share this post


Link to post
Share on other sites
quote:
Original post by BoRReL
Also if you lock your surface and are going to copy data from/to it, use DWORD pointers! If you for example have 8 bits per pixel and you load a DWORD form the surface, you get 4 pixels at once.



Sorry for cutting in, but given that you''re programming in 32 bit platform, is it ALWAYS faster to use 32 bit pointer to access memory? Under every circumstance? For instance, as you say 32 bit pointer would acess 4 pixels at once in 8 bit, 2 pixels in 16 bit and so on. Say, using a 16 bit pointer to acess it for a pixel at a time (in 16BPP) is always always slower?

Share this post


Link to post
Share on other sites
Heya,

Copying 32bits instead of two times 16 is ALWAYS faster!
But since you have to shift the pixels out of the DWORD when accessing them, you still have some overhead. Still I guess that a shift is faster than a memoryread (especially from videomem)

When (just) copying a lot of data the asm operation for bytes would be (8BPP):

mov ecx, howmanybytes
rep stosb

for dwords:
mov ecx, howmanybytes/4
rep stosd

So less instructions, less cycles, more speed!

Gr,
BoRReL

Share this post


Link to post
Share on other sites