Sign in to follow this  

How to Program SDL More Efficiently?

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

So I wrote my first SDL game (don't ask why I'm still using SDL, it's a programmer's thing), and everything looks good, except...

...

LAG!

...

The lag happens when the background images are blitted. When I reach an area where the background is white and no images are blitted, everything looks smooth. Each image is loaded into a SDL_Surface (once), and blitted every 1 ms inside my draw() loop. The images are jpeg format.

To give you a better picture, this is the regular game scene and this is also where I'm laggy as I move around:

 

LGRpN.jpg

 

 

 

And this is the end of the scene, where the lag magically disappears:

 

KMeg7.jpg

 

 

As I walk back into the regular game scene, the game starts to get laggy again!

 

So, my question in a nutshell: How to make the game more efficient so that it doesn't lag out? (e.g does using bmp images have an effect? Should I not blit them every time in the loop?

 

Also, if you MUST see the code, here it is: http://pastebin.com/0tK4EWeP

Edited by DarrenVortex

Share this post


Link to post
Share on other sites

What happens with a lower framerate ... like 60? 1000 is maybe a little much to shoot for.

Edited by DareDeveloper

Share this post


Link to post
Share on other sites

So I wrote my first SDL game (don't ask why I'm still using SDL, it's a programmer's thing)

 

SDL is in no way outdated or lacks features. I don't quite understand why you brought that up.

 

Also, since your background doesn't have many details, you should go for PNG instead of JPEG.

 

As for the BMP question. When you load an image, SDL will load the pixels from the image file to the surface. A BMP file will load faster because there is no compression, but there won't be any significant difference. BMP files get bigger by the amount of pixels, so they can be used for small icons, but you should use PNG either way to be honest.

JPEG should be used for very detailed backgrounds. (if space is an issue of course)

But beyond loading, there is no performance difference between different image formats. As pixels are pixels.

 

I do not have much experience with SDL surfaces and blitting, so I'll leave it at that.

Share this post


Link to post
Share on other sites

It doesn't appear that you're converting the format of the surface image to the format of the screen. Not doing so will slow down your program since it will have to convert the image to the screen's format every time it's blitted. When you load your image, use SDL_DisplayFormat (SDL_DisplayFormatAlpha for images with a transparency layer) to return a conversion of the image, then free the original image.

 

Something like this:

Surf_Optimized = SDL_DisplayFormat(Surf_Original); //convert the original image to the format of the screen
SDL_FreeSurface(Surf_Original); //free the original image
Edited by Ludus

Share this post


Link to post
Share on other sites

What about blitting onto temporary surfaces that make up the scene, and re-using them, so you're not constantly blitting your tiles over and over every frame. Divide the scene/world up into 8x8 tile patch SDL surfaces, and use them to effectively reduce individual blits when drawing the scene.

Share this post


Link to post
Share on other sites

So I wrote my first SDL game (don't ask why I'm still using SDL, it's a programmer's thing), and everything looks good, except...

...

LAG!

...

 

  1. const int FRAMES_PER_SECOND = 1000;

 

What's the reason for this?

Share this post


Link to post
Share on other sites
I take it your background image is pretty large? I've run into problems blitting very large images every frame on lesser hardware, I wonder if you had smaller tiling images for the background if it would be smoother? Just a guess though I'm still quite new to SDL.

Share this post


Link to post
Share on other sites

This topic is 1654 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this