   Optimizing SDL game performance
  Unfortunately there's not much you can do. Maybe use 16-bit color, don't use alpha blending, and such.SDL's basic rendering isn't hardware accellerated, it relies entirely on the system resources.   
  If it's an option you can "fake" 2D using the OpenGL API to let you work in 2D terms, but give you the speed and performance (and alpha-blending) of the underlying hardware.If it's not an option, than maybe dig through some of the SDL mailing lists (linkable from the SDL homepage). There might be some software optimization threads in there.What do you mean by "low-end" machine though? :)hth,   ;  SDL is plenty fast enough, so your code must be bugged somewhere. Have you checked for memory leaks? What sort of a system are we talking about here?I recommend you convert all of your loaded images into the display format for much faster and optimised blitting. E.G.SDL_Surface * ImageLoad(char *file){   SDL_Surface *temp1, *temp2; temp1 = SDL_LoadBMP(file);   temp2 = SDL_DisplayFormat(temp1); SDL_FreeSurface(temp1);   return temp2;}Good luck!   ;  I'm afraid I'm not going to read through that code as there's way too much. In future, perhaps consider just posting a snippet of loading or rendering functions. But anyway, the basics are to send as little data as you can and perform as few reads as you can. ie. Smaller resolutions are good (eg. 800x600 is likely to be twice as fast as 1024x768), lower bit depths are good (eg. 16bit will beat 24/32 bit), and avoiding alpha blending is important (as this requires reading from the graphics card - you might get round it with triple buffering but I don't know how practical or efficient that is in SDL). Beyond that, OpenGL (or DirectX) is really the way forward.Other suggestions - don't call TTF_OpenFont over and over again - instead, store it somewhere once you do it the first time. Same for your static text - if you need to render a phrase like 'Inventory System', you do not want to be creating a new surface, rendering a font into it, copying that surface to a display format surface, blitting that surface, then deleting the two text surfaces, every time you do it! Instead, you do the creation/rendering/copying to display format once at the start, and just blit that each time. (Don't forget to free it at the end of the program.) If you ever find yourself doing the same thing over and over again, ask yourself if you could get away with just doing it once at the start.   ;  Thanks very much for all of you who posted here.UndeadInsanity, thanks for your idea I didn´t notice that I could do a function for image loading instead of writing 4 lines for each surface I would load to memory.Kylotan, thanks for your suggestion about the TTF_Font I´ll do that later.TheOther, by low-end I mean slow computers, like a pentium 3-500 and such.I will do these optimizations you guys mentioned here and later when I finish the game I will use OpenGL instead of alpha blending, I really noticed a performance slow down when I used it.My comp is an Athlon 2600+,1024 ram,radeon 8500 64mb, it runs the game fine but in slower computers, like another comp I have, an Athlon 1600+,512ram - the game runs slower, and in a comp with a p3-700 with 384ram in which I also tested my game, it´s just UNPLAYABLE, it runs tooooooo slow. That´s why I got concerned about it. I will do those modifications and I say the results later.Thanks again,Victor Freire   ;  antoher possible speed booster is using SDL_ANYFORMAT as one of the flags when you use SDL_SetVideoMode. this stops a possible slowdown that occurs when SDL cant get you the right bits per pixel and it draws to a memory buffer and then converts the memory buffer to the screens bit depth.    i think this applies more on linux because user programs arent allowed change screen depth though.   ;  Completely off-topic, but it might help you for the future:Your code is hard to work through.  You have a different SDL_Surface* for each image you're creating.  Consider creating a resource manager.  Something where you could say:resourceManager.getImage("./imagename.bmp")and it will return the SDL_Surface*.  What's more, if the image isn't already loaded, it could load the image in there.  You could store all the SDL_Surface* in a stl::vector (or, better yet, a stl::map), making management much easier.It won't help your speed, but it'll help you develop a bit faster.  You could also do the same thing for you sounds (Mix_chunk?), making your code smaller and easier to read.Also, UndeadInsanity's contribution is *vital.*  If you're not using SDL_DisplayFormat, you should be.  I've noticed orders of magnitude difference in performance when I added this.Edit: It appears you are using this... so, um, carry on. :-)Cheers,--Brian   ;  WOW, I after I changed all the SDL_Surface to display format the game has a HUGE performance gain, it became so fast that I had to reduce the frame rate limit.Nairb, excellent idea I'll figure a way to do it soon thanks, right now I'm developing an animation creator system.Thanks very much for your help, I really love this forum, I post and in less than an hour I got at least one reply.Thanks again.   