Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

saeZ

fast blitting in SDL

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

Hi, Any of you people using SDL on Linux? I''ve been hearing that SDL is slow on Linux due to XFree86. Is this true? I''m working on a game project and my engine is really slow. I know the lack of speed is caused by slow blitting, but SDL blitters aren''t slow, are they? Well, here''s my real question: How do I force SDL surfaces to stay in system memory? I know system->vidmem calls are slow. I''m using pure 2D. My screen is flagged with SDL_SWSURFACE|SDL_FULLSCREEN. I''m loading images into different surfaces and yes, I''m calling SDL_DisplayFormat on all of them. If someone could help, I would appreaciate it very much! Thank you. saeZ

Share this post


Link to post
Share on other sites
Advertisement
Yes, the standard graphic mode is very slow in X. I do not know much about SDL but probably do it use some other library for the actual blit. I did some stuff a long time ago with Allegro and I think that you can do fast blits in fullscreen using X as root (called DGA-2 mode ?).
In console mode do you have some other options but I guess that the best is FB (?) since it does not requires root access. If you see a penguin at startup is it enabled.

At least I call system->vidmem for blits. Yes, it is slow and not the best way to do it on the PC. OpenGL is the only alternative if you want to use high resolutions and color depths.

Share this post


Link to post
Share on other sites
I''m sorry but I don''t understand why you are complaining. It looks like you are doing anything you can to make the blit really sloooooooow by blitting from system memory to VRAM.
Why do you want your source surface to be in system memory?
Could you please explain? or am I missing something?

Share this post


Link to post
Share on other sites
Well maybe I''m using system->vid because I''m an idiot. What would be the fastest possible way to do things when using software rendering? I do not want to use OGL with my project. 3D is for 3D. I have an OGL 3d engine, but I need fast 2D rendering for my 2D isometric tile engine.

Obelix, what is this dandy DGA mode? How do I enable it? Will it work by just using X as root?
I just want a higher framerate for 2D blitting.. it can''t be so difficult, but I guess it is (for me)!

saeZ

Share this post


Link to post
Share on other sites
I think that DGA (Direct Graphic Access?) mode is available if you run as root. In Allegro can you request for it or let Allegro enumrate the available modes and pick the best.

Allegro also lets you pick different types of memory for your bitmaps but as I remembers it was the difference not big. For that to work under linux do you probably have to be root. The problem with normal X graphics can not be fixed by selecting other types of bitmap memory. I have forgot the details but basicly is a safe and slow layer used to do the rendering.

Depending on your card will you probably get almost similar performance as DirectDraw but OpenGL can do better. Do not forget to put lower resolutions in your X config file so that they can be used.

Share this post


Link to post
Share on other sites
I compiled my kernel with framebuffer support and then configured DGA. It actually works... although I''m still not getting satisfying frame-rate (old: 33, dga: 60-70). Maybe my expectations are unreal. Well, DGA really does give a nice performance boost but I still have some issues to solve.

saeZ

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hi saeZ,

I use SDL and I''m getting about 85-90 fps. This is
the highest frame rate I can reach because of the
Vsync. What I do is to set up a double buffer and
allocate all my surfaces into video memory. In this
way, SDL can make use of the video card blitting
hardware.

This is ok if you don''t need to do any kind of
software rendering (antialiasing, alphablending, and
so...) If you need to do it, you will have to ''lock''
the surface. At this point, SDL maps (copies) the
surface from VRAM to SRAM. Then you can modify it and
after that, you must ''unlock''. When unlocking, SDL
moves the surface again from SRAM to VRAM.

Good Luck !!!

Share this post


Link to post
Share on other sites
The framebuffer (FB) support and DGA is two different things. DGA is a graphic mode that is supported by the X server. As far as I know does all versions of XFree86 has it.
The framebuffer support is used in console mode if no X server is started. If you press ctrl+F1 and run the program will it probably be used. This is great even if you do not need fast graphics because you can set the resolution in text mode.

I did some testing with allegro. It seems like DGA now is DGA-2 and the old version is called DGA-1. Here is some remarks:
- very unstable, the X server was sometimes shut down after the program finished
- can change the color depth of the screen
- some features like video memory -> video memory blits accelerated
- I think that all operations involving reading from the video memory is very slow

As a normal user does it seems impossible to get fast 2D graphics without using OpenGL. I could only allocate video memory, get accelerated vmem->vmem blits and do other stuff as root.


Share this post


Link to post
Share on other sites
I gave up on software rendering and wrote my isometric tile-engine to use OpenGL. It''s not what I really wanted, but I started thinking of my goals and motives, what I want from the game and from its visuals. Well, I came to the conclusion that I want cool''n''smooth lighting effects and so OpenGL was my only choice. I''m not complaining because finally the frame-rate is satisfying even with light effects! And now I can add complex particle effects too. It''s good to be able to add some eye-candy without loosing much fps.

saeZ

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!