Skip to main content
gamedev.net
🔒 Locked

DirectDraw 7 optimalization

Started by BigBeginner 3 replies 1.1k views
Original Post
BigBeginner
BigBeginner
I have an half game engine based in DirectDraw7. I started to optimalize it by using hardware capatibilities. I do this by adding the DDSCAPS_VIDEOMEMORY flag when I create the surfaces. So: PRIMARY SURFACE: Desc.dwFlags:= DDSD_CAPS or DDSD_BACKBUFFERCOUNT; Desc.ddsCaps.dwCaps:= DDSCAPS_PRIMARYSURFACE or DDSCAPS_COMPLEX or DDSCAPS_FLIP or DDSCAPS_VIDEOMEMORY; Desc.dwBackBufferCount:= 1; Res:= DDraw.CreateSurface (Desc, Screen, nil); OFFLINE SURFACES: Desc.dwSize:= SizeOf(Desc); Desc.dwFlags:= DDSD_CAPS or DDSD_WIDTH or DDSD_HEIGHT; Desc.ddsCaps.dwCaps:= DDSCAPS_OFFSCREENPLAIN or DDSCAPS_VIDEOMEMORY; Desc.dwWidth:= Picture.Width; Desc.dwHeight:= Picture.Height; Res:= DDraw.CreateSurface (Desc, SURF, nil); It works, but doesn't make it faster at all :(
Dave Hunt
Dave Hunt
By default, surfaces are automatically created in video memory unless there is no video memory available. So specifying DDSCAPS_VIDEOMEMORY is not necessary. The only thing adding that flag does is cause the CreateSurface to fail if there is not enough video memory.
BigBeginner
BigBeginner
Okay, I see. So this flag is useless :)

An other question: is there any way to optimalize directdraw? To put surfaces into the videomemory is one way - is there another?
Dave Hunt
Dave Hunt
The most effective method of optimizing DirectDraw is to limit the number of Lock/Unlock calls on your surfaces. If you will be performing a series of operations on a surface, lock the surface, perform all of your operations, then unlock the surface. For example, if you are plotting pixels, lock the surface, plot all of the pixels, then unlock the surface. If you lock/plot/unlock for each pixel your performance will go down the drain.
lack o comments
lack o comments
To be honest, DirectDraw doesn't really have much in the way of acceleration features. Worse is the fact that it implements very few non-hardware features in software.

The best advice I can give is this: If you ever have need to use software-based rendering, don't use DirectDraw surfaces. Write you own blitter system using system RAM buffers. Collect the final rendered image onto a single system buffer and then perform a single output to the backbuffer.

In general, transfering over the bus, especially read operations, will kill performance.

Quote:

Okay, I see. So this flag is useless :)

Not entirely. As Dave Hunt hinted, the surface creation will fail if this is passed. If not passed, DirectDraw will attempt to use system RAM if there is not enough on-card. It depends on what feature you want.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.