Jump to content
  • Advertisement

Archived

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

Jello

DirectDraw Surfaces... how much vid memory?

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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!