Passing A Large Sdl_surface* Between Functions

[Alex.]

Guess who -

In the game I'm making, I have this big sprite sheet (1000x500). It's loaded as a SDL_Surface, and is a local variable that's passed from function to function. Due to its size, it slowed my game down by 75%, so I split it into two pieces and periodically loaded needed parts of them. This solved the speed problem, but I feel that it's still slowing it down, even if only by a little bit.

Should I make the spritesheet a global variable in order not to have it passed around by functions? What about the screen itself (I have that declared as a local and passed around as well). Would that improve speed, and would it be good coding practice?

Thanks a bunch!

- Alex

 

[mrsnature]

Just pass the pointer to the surface to your functions. But if the data needs to be there for the whole life of your program, a global variable is not a bad idea.

 

[Parkydr]

I presume the SDL_Surface* in the title is referring to a pointer, the size of the surface should not matter, the pointer will only be 4 bytes.

 

[dwelch]

Local variables are bad anyway, in particular large ones like this you really dont want the local variables to take up too much space, it all has to live on the stack and your heap will hit your stack and game over. Fewer functions, fewer local variables, few if any mallocs makes for a rubust, reliable system. Not to mention how slow it is to pass things around by value instead of by reference (or not even having to pass things around everyone knows where it is, its global). Just make a global, dont think twice about it.

David

 

[Alex.]

Global it'll be. Thanks for the help fellas

- Alex

 

[Alex.]

I made the screen and the sprite sheet global variables, but unfortunately the framerate takes the same hit. It seems that blitting from a spritesheet that large (1000x500) is too much.

- Alex

 

[gfoot]

The actual speed of the blit hasn't got much to do with whether your pointer is a global or a function argument though - except for really small blits, the cost of copying the image data is going to far outweigh the cost of passing an additional parameter (and note that SDL's blit function will be using exactly such a parameter anyway). Before worrying too much about this though you ought to profile it, so you know excatly what is costing you, and how much.

If it's actually copying the data that's slow (likely, given the size!) then, if you can, use the hardware accelerated SDL, flag relevant surfaces to be hardware-blitter-friendly, and let the hardware blitter do its job - note that it can do this in the background, so provided you don't need to use the target surface for a while, you can go off and do something else in the meantime.

 

[YakumoFuji]

the best way to speed it up is once you have your sprite sheet in an SDL surface, conver it from its initial state to the native screen surface state (eg: to 16bit), this will speed up the blit since it wont be doing a pixel conversion continously.

the size of the sprite sheet should not make any differencce either.

ignore the global / local bullshit too. your passing pointers around, its got nothing to do with local + global variables as far as speed goes.