• Advertisement

Archived

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

DirectDraw Surfaces... how much vid memory?

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

Lets say I have a 2.74 megabyte bitmap with dimensions of 1600 x 600 pixels. If I create a 2d surface with these dimensions and load the bitmap into the surface, will 2.74 megabytes of video memory (assuming that''s the type of surface I created) be used by this surface, or will it be more (or less)?? I''m making a somewhat tile-based game with direct x. I say somewhat tile-based because I''m using entirely pre-made backgrounds, but plan on blitting from 32x32 rectangles onto my main surfaces. I''m wondering, would it be better to blit an entire 800x600 rectangle onto my backbuffer rather than simulate a tile based design? Any help would be appreciated =) MOV ax, bx asm programming written by Jello

Share this post


Link to post
Share on other sites
Advertisement
The memory the image takes up is mostly based on the image size and the bits per pixel of the display mode. A 1600x600 image (which has 960,000 pixels) in 16-bit mode would theoretically require 1,920,000 bytes (2,880,000 in 24-bit mode, 3,840,000 in 32-bit mode), but DirectDraw often pads the images to align them certain ways if the hardware requires it. That means that usually the video memory the image takes up will be slightly larger than that. My guess is you can multiply the image pitch (not width) by the image height to get the video memory used.

~CGameProgrammer( );

Share this post


Link to post
Share on other sites
Ah, thanks a bunch!

_________________
MOV ax, bx
asm programming
written by Jello

Share this post


Link to post
Share on other sites
Another thing to keep in mind is that not all graphics cards will let you create offscreen surfaces that are wider than the primary display surface. You can check for the capability in the DDCAPS structure (look for "wide surfaces" in the SDK help).

Iain

Share this post


Link to post
Share on other sites
If not all video cards can create surfaces larger than the screen resolution, I''ll have to split up my bitmaps.

256x256 is the fastest blit? As in, largest rectangle without a speed cost?

_________________
MOV ax, bx
asm programming
written by Jello

Share this post


Link to post
Share on other sites
You don''t have to split up your bitmaps - just make them tall instead of wide (e.g. make your page 512 x 1600). It''s best to try to keep your bitmap width to a power of 2 if you can so that the memory addresses are nicely aligned.

AFAIK there''s no reason why blitting from a 256x256 surface would be the fastest. In fact, the narrower the surface the better the performance because you''ll get fewer cache-misses when reading from the source surface.



Iain Hutchison
Programmer, [url=http://www.sdreams.co.uk]Silicon Dreams[/url]
The views expressed here are my own, not those of my employer.

Share this post


Link to post
Share on other sites
A fullscreen Blit should be the fastest. It lets the function handle the largest sections of linear memory and cut down on all the overheads associated with looping.

Of course it''s not much use if your using a tile based system, in that case just use the largest sections you can but remember that the width of the square or rectangle should be the factor that controls the speed. The number of tiles will also add to the Blit speed.

I have noticed a big speed increase between 32x32 tiles and 64x64. Then again i can''t remember whether the code was streamline at that point. Oh and all of the above assumes that your running everything in VRAM.

zipless

Share this post


Link to post
Share on other sites
make a DOS application, but with all the DX headers included. Load your bitmaps into surfaces, such as Surface1, then do:
cout << sizeof(Surface1);


Proceeding on a brutal rampage is the obvious choice.

Share this post


Link to post
Share on other sites
pieman: "In fact, the narrower the surface the better the performance because you''ll get fewer cache-misses "

shouldn''t that be the wider the surface the better? narrow sections have less linear memory requiring more jumping about and less use of the cached memory.

Was that a typo or is there something i''m not aware of at work here?

zipless

/* Ignorance is bliss, then you go and spoil it by learning stuff */

Share this post


Link to post
Share on other sites
I wouldn''t have thought that the width of a surface affected the speed of blits at all. Remember all this is probably taking place in video memory, where there is no cache...

Steve

Share this post


Link to post
Share on other sites
even the video card has a cache when it does stuff. they are pretty complicated now.

Share this post


Link to post
Share on other sites
My comment about cache performance was specific to blitting smaller tiles out of a larger surface. If you're going to be blitting the whole surface then it doesn't matter what width it is. Sorry for the confusion.

Basically, the closer your blitting width is to the surface width the better the performance will be (this is why zipless had better performance with 64x64 tiles than 32x32 tiles). The ideal situation (cache-wise) is to have a surface that is the same width as your tiles and is very tall - that way each tile will be completely linear in memory and will give much better performance.

Iain Hutchison
Programmer, Silicon Dreams
The views expressed here are my own, not those of my employer.

Edited by - pieman on February 6, 2002 6:09:01 AM

Share this post


Link to post
Share on other sites
There is no problems width very wide surfaces unless you put them in video ram...

Share this post


Link to post
Share on other sites
Lots of small blits are slower than a few big ones, even if the big ones take care of the same area.

Share this post


Link to post
Share on other sites
I''m making a game, so I''m gonna try putting the 1600x600 surface into video memory, cuz smooth scrolling is necessary. Since my screen resolution will be 800x600x24, and after reading your replies, I think I''ll blit 800x600 rectangles from the surface to the backbuffer.

So you think this is the best way to go about making a scroll engine with pre-made backgrounds?

_________________
MOV ax, bx
asm programming
written by Jello

Share this post


Link to post
Share on other sites

  • Advertisement