Optomizing ddraw 7
Author
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......
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
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
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.
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.
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.
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
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
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
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
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
I think that the Visual Studio 5 CDs come with DirectX 3 docs... I don''t know how you can access those without installing the application though, so good luck if you have 6 installed
MatrixCubed
http://MatrixCubed.org
MatrixCubed
http://MatrixCubed.org
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?
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
