Most efficient drawing with SDL
Author
Hi, im searching the most efficient way to draw to an SDL buffer screen. I only draw pixels, not bmps nor copy surfaces.
What i wnat to know is if i need tu lock the surface, what is the best way to draw pixels, is it better hardware surface than system, is it good idea doing double buffer, etc, etc.
I really need this application to go fast.
Hi,
I played a bit with SDL performances, so I'll try my best as answering you.
If I understand well, you want to directly draw pixels on the screen.
On a general manner, it is often a good idea to use double buffer, since if avoids flickering. For hardware surfaces vs software surfaces, it will partly depend on your OS.
Under Linux with normal configuration, you cannot use acceleration, which means for example that when you swap the buffers, the app will actually copy all the backbuffer on the frontbuffer, which is very time consuming. In this case, the good solution is to refresh only parts that needs it, such as small rectangular zones that contains the parts of the image that changed since the last frame.
If you are under Windows, you should be able to use acceleration (in this case, the swapping of backbuffer to frontbuffer is only a matter of changing a pointer, and is therefore very fast). I believe you have to use hardware surfaces, in this case. So, for each frame, you can lock the surface, do what you want in it, unlock it, and swap buffers. That should be fast enough!
Note that the locking / unlocking of surfaces depend on your system, but you could easily find some generic examples that run on every configuration.
I played a bit with SDL performances, so I'll try my best as answering you.
If I understand well, you want to directly draw pixels on the screen.
On a general manner, it is often a good idea to use double buffer, since if avoids flickering. For hardware surfaces vs software surfaces, it will partly depend on your OS.
Under Linux with normal configuration, you cannot use acceleration, which means for example that when you swap the buffers, the app will actually copy all the backbuffer on the frontbuffer, which is very time consuming. In this case, the good solution is to refresh only parts that needs it, such as small rectangular zones that contains the parts of the image that changed since the last frame.
If you are under Windows, you should be able to use acceleration (in this case, the swapping of backbuffer to frontbuffer is only a matter of changing a pointer, and is therefore very fast). I believe you have to use hardware surfaces, in this case. So, for each frame, you can lock the surface, do what you want in it, unlock it, and swap buffers. That should be fast enough!
Note that the locking / unlocking of surfaces depend on your system, but you could easily find some generic examples that run on every configuration.
Author
Welll, actually im using Windows XP and im using Hardware surfaces, double buffer, and everything you said and i get a veryy slow performance. I can say that because i tried allegro and it was incredible faster than SDL so i supposed tht there was some problem with the routines or the library itself.
I also detected that the colors are drawed bad. I mean in another application the pixels were white and then in the new SDL library(i just redownloaded the same version) y got yellow colors.
So i think maybe the library is mmm bad(compiltion) or something. Is there any way to now that?
I also detected that the colors are drawed bad. I mean in another application the pixels were white and then in the new SDL library(i just redownloaded the same version) y got yellow colors.
So i think maybe the library is mmm bad(compiltion) or something. Is there any way to now that?
I am pretty sure that for pixel manipulation, you want to do as much pixel plotting to a surface in system memmory before copying it to the screen surface. Locking hardware surfaces and reading/writing to them is generally slower than reading/writing to system surfaces when it comes to pixel manipulation. From reading tutorials on SDL I get the impression that the path to take here is to do all of your pixel plotting to a surface in system memmory and then copy that surface all at once (or just the parts that changed) to the screen. I am relatively new to SDL (a few months now) so I could be wrong but do a google on SDL and GetPixel/PutPixel and see what you find. I personally only use bitmasks in system memmory for collision type stuff so I don't really have to deal with this but the topic is talked about a lot in most pixel related SDL tutorials you will find.
Well, you could try the examples provided with the library, see if they work correctly.
About performances, I experienced the framerate not going over 60 fps under SDL. But since the CPU is used in consequence, adding functionnalities to the application does not slow the frame rate more.
About the colors, check your color codes. If you write RGB colors when SDL awaits for RGBA, you can experience this kind of problems.
Check your surfaces parameters.
About performances, I experienced the framerate not going over 60 fps under SDL. But since the CPU is used in consequence, adding functionnalities to the application does not slow the frame rate more.
About the colors, check your color codes. If you write RGB colors when SDL awaits for RGBA, you can experience this kind of problems.
Check your surfaces parameters.
Author
Uff, well, i like the idea of writing pixels to system and blitting to hardware screen. Maybe that could speed up. Thanks for the help,
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
