Direct Draw Sprite Optimizations

Started by
1 comment, last by Isolier 24 years, 1 month ago
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
Advertisement
Isolier,

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.

Martin
______________Martin EstevaolpSoftware
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

or

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.

NOTE: IDirectDrawSurface4 * == LPDIRECTDRAWSURFACE4
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

surface
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

kosh

'' Target=_Blank>Link
if understanding it made and born with time, then time, is understandings greatest enemy.....

This topic is closed to new replies.

Advertisement