Sign in to follow this  
Mikle3

SDL Best practices

Recommended Posts

Hello, I've got a few questions about SDL. I hope this is the right place, and not for beginners. First of all, does someone know a best practices or a style guide for SDL developing? Something with conventions and dos and don'ts or a comprehensive FAQ? To be a bit clearer - I know the functions and main structure of a SDL program (mainly from LazyFoo's tutorials) but I need some guidance on the finer things of SDL. A few specific issues I'd like you to address, mainly taking speed and style into consideration: 1. Is there some kind of collision detection function in SDL? I know of such a library, but is it good (I think its name is SDL_Collide)? Is it better to implement "crude" hit tests (which I already did) or is there a better library? 2. If I'm using SDL_HWSURFACE and SDL_DOUBLEBUFF, how do I switch buffers? SDL_Flip()? And generally what's better - maintaining a global dirty rects list and using SDL_UpdateRects or just flipping all of the screen (consider the rect creation overhead)? And why is there a separate SDL_GL_SwapBuffers function? 3. Is there a way to have your sprite move on a long key press without implementing a crude class that starts the movement on a key press and stops the movement on a key release? Also what's better - making the "sprite" class responsible for the blitting and surface management or is it better just to leave it to the main file (performance - wise, function call - wise)? 4. If I'm already on the topic of sprites - is there an implementation of a sprite (similar to the sprite class in PyGame, from which all sprites inherit and which provides some basic stuff like collision detection)? Sorry if this was too long or too noobish, but I just can't find any useful resource on how to write *good* SDL code, not merely SDL code. Thanks, Mikle P.S. I'm programming with CPP on Windows and using SDL 1.2 (Just saw the rules post, and thought some people may misunderstand me). [Edited by - Mikle3 on March 4, 2007 1:25:42 PM]

Share this post


Link to post
Share on other sites
For a rather disorganised SDL FAQ thing, there's this. It's part of the site's "SDL corner" but the site is v. disorganised and hard to navigate (uses frames badly). There's some other useful pages there too, but they're tough to get to. I have yet to find another SDL do's and don'ts type thing though.

1. There's no built in collision detection in SDL. I haven't tried SDL_Collide, so don't know anything about it. I just do my own, there's enough resources around not to make this too hard.

2. SDL_Flip() can be used to switch buffers. You can use it without double buffering as well as it's just equivalent to calling SDL_UpdateRect() on the whole surface. I'd say that it depends on the circumstances whether you want to use UpdateRects or Flip. If lots of the screen stays the same each time (say you have a substantial GUI frame or something and are just updating the central screen) you might just want to update that part as it'll be a lot quicker. If you're changing more though it's probly best to update the whole thing (it's easier anyway).

3. You could try using Uint8 *keys = SDL_GetKeyState(NULL); and then testing the state e.g. if (keys[SDLK_LEFT]) { //do...}.

4. There's nothing in the SDL code. I wrote my own for this kind of thing. There might be some sort of engine around to do this though.

Hope some of that helps. :)

Share this post


Link to post
Share on other sites
1) No. But I've found that a rectangle or circle based collision works quite well, pixel perfect or some other more accurate is rarely required (for my games anyway ).

2) SDL_Flip() will switch buffers on a double-buffered screen surface, otherwise it will just do an SDL_UpdateRect() on the full screen. as for maintaining a list of dirty rects, thats only a good idea if there isn't a lot of moving images. If you find you are redrawing significat portions of the screen every frame then a dirty rect list will probably have more overhead than a straight redraw.

For a detailed explanation for some of the internals of SDL with regard to blitting and flipping read these.

SDL_GL_SwapBuffers() is for when you create a screen surface with the SDL_OPENGL flag. It replaces both SDL_Flip() and SDL_UpdateRect{s}()

3)
Quote:

Is there a way to have your sprite move on a long key press without implementing a crude class that starts the movement on a key press and stops the movement on a key release?

Uint8 *keys = SDL_GetKeyState(NULL); if( keys[SDLK_UP] ){ move_forward(); }
Quote:

Also what's better - making the "sprite" class responsible for the blitting and surface management or is it better just to leave it to the main file (performance - wise, function call - wise)?


Performance wise you the blit will be more expensive than an additional few function calls by a long way, so I would put it wherever makes sense. A simple sprite class could be a good place.

4) No, but its to hard to implement yourself.

Share this post


Link to post
Share on other sites
First of all, thanks for the quick replies and links. The SDL Corner looks very unreadable, but I'll try focusing on it more in the morning, maybe parse the text more clearly.

Also for the SDL_GetKeyState (which is the way I do it in python) I realized now that when I tried it I put it in the wrong place - In the pollevent while loop and not in the main while, which is probably why it didn't work for me (but it made me write everything in classes, and that's good).

Regarding your answers for the collision detection and sprite class - I know I can implement those myself, and I did. But consider this - we three have different implementations, and probably lot's of other people too. Isn't that a waste of time - implement and optimize the same functionality over and over again, instead of focusing on the game logic, we all spend some time maintaining our "help libs". I'm sure you all catch my drift. Well but seeing there isn't any uniform lib for those things, someone probably needs to take it upon himself.

Again, thank you, and I hope I could post my first game (A breakout clone, how original) within the next few days.
Mikle

Share this post


Link to post
Share on other sites
Quote:

First of all, thanks for the quick replies and links. The SDL Corner looks very unreadable, but I'll try focusing on it more in the morning, maybe parse the text more clearly.


Yeah, it's pretty bad. There's some useful info in there, it's just ultra-disorganised.

Quote:

Regarding your answers for the collision detection and sprite class - I know I can implement those myself, and I did. But consider this - we three have different implementations, and probably lot's of other people too. Isn't that a waste of time - implement and optimize the same functionality over and over again, instead of focusing on the game logic, we all spend some time maintaining our "help libs". I'm sure you all catch my drift. Well but seeing there isn't any uniform lib for those things, someone probably needs to take it upon himself.


True. Trouble is there are quite a few ways of doing something like collision detection, which makes sense I guess to have something like SDL_Collide at a lower level, and that can be integrated however someone wanted, rather than trying having a higher level version that would either have to handle it every conceivable way, or people just wouldn't use it anyway. How the collision is actually dealt with would start to come into play, for example, and it would be difficult to try to let people customise that I suspect.

It would be an interesting project though.

Share this post


Link to post
Share on other sites
There are plenty of collision detection libraries around, but they have little to do with SDL, since SDL doesn't handle geometry or game objects. It really is just a wrapper around multimedia functions.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
For 3 you can use SDL_EnableKeyRepeat. http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fEnableKeyRepeat

Share this post


Link to post
Share on other sites

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