Jump to content
  • Advertisement


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


Direct Draw Sprite Optimizations

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

Hello everyone, In every example I have seen that demonstrates sprites, whether it be in books or articles on the net, the author creates a surface for every sprite. Wouldn't it be just as fast and save time to instead load your sprite set into one surfuce, then blit your sprites from there? This method would allow you to load the bitmap containing all the sprites into one surface, rather than creating individual surfaces for each sprite. Also, if you have any sort of game that dynamically creates and destroys sprites, it seams that this way would be faster because you would no longer have to create and destroy surfaces. Any thoughts on this? Please correct me if I am wrong, I will wait for some feed back before implementing any sort of sprite engine in my DX wrapper. Thanks. Edited by - Isolier on 4/9/00 4:17:07 PM

Share this post

Link to post
Share on other sites

I''ve always loaded all my sprite sets from one bitmap, and then created an offscreen surface for all of them, and not for individual ones. I haven''t used the other method, but I think this way is simple enough.


Share this post

Link to post
Share on other sites
hi everyone,

from what I know and what I was told by HAK who does frequent these msg boards, blitting from a small per sprite surface is faster, cause you are not locking a small section, you are locking THE ENTIRE surface, so speed wise, it''s faster to have small bitmaps for each sprites.

but, on the downside, you have a huge memory overhead when you get to having to store quite a few sprites, cause basically, when you store one sprite, which is say 800x600 in size, you only have one copy of the surface data, with lots of surfaces, you lose memory, cause you are using n * surface data size (where n is the number of sprites) which is obviously n-1 times as much surface memory, when talking about the DATA part of the surface, not the surface memory, which doesnt increase the size of the data in the surface, it just is a pointer to the data which is represented by the surface.

understanding me so far ? hopefully I aint made any stupid errors

so, the answer to my knowledge is that yes, it''s faster to use sprite per surface, but it''s also more memory consuming, so what do you wanna do ?

Also, if you have many many many surfaces, you pollute the namespace (the place where you put variables, erm example in a second). But there is a way of getting around this problem, which is also the same as this example.

int a, b, c;
int arrayints[3];

now, if you only have 3 variables, prob not worth the effort of using an array of ints, cause it''s not that much, but what if you have 300 variables ?

int a, b, c, d, e, f, g, h.......yyx, yyy, yyz, zza etc etc


int arrayints[300];

see my point, so if you want to try this, you might want to use an arrayspace solution, which is what I used with my game, I needed a lot of surfaces and didnt know off hand how many I would need until during the programming, so what I did was to create a solution which would work based upon this arrayspace idea. eg

IDirectDrawSurface4 **surfaces;

surfaces = (IDirectDrawSurface4 *)malloc(num_surfaces * sizeof(IDirectDrawSurface4));

that should create an array of IDirectDrawSurface4 * for you to create your surfaces in, hence, this is array based.

I just dont like using that, thats all.

So, when you create the array of pointers, you pass a pointer to a surface like this

Also, you can add and remove elements from this array very easily, but I''ll leave that for another post Can''t have all the answers all of the time you know


'' Target=_Blank>Link

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!