Jump to content
  • Advertisement
Sign in to follow this  
martinuk

[SDL] is true everything must be render inside the event loop?

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

I am trying to create a GUI with light animations,e.g. shift a picture cross the screen. Is it true that i have to render all the bits that need to animate inside the main loop of the program, i.e. the event loop? and SDL_Flip() only in that loop, so that the animation will look smooth and render properly?

Share this post


Link to post
Share on other sites
Advertisement
ok, if a program needs to be run at a single board computer,and the cpu speed has only 1G or even less, then the rendering will be slowed right?

Share this post


Link to post
Share on other sites
Quote:
Original post by martinuk
ok, if a program needs to be run at a single board computer,and the cpu speed has only 1G or even less, then the rendering will be slowed right?


Unfortunately, that does not make any sense at all.

* single board == single cpu (as compared to a multicore cpu)?
* cpu speed 1G == size of main memory in GiB?

Share this post


Link to post
Share on other sites
sorry, my fault.

what i was trying to say is, what methods can we use ,in SDL, to improve the animation rendering with a low specification machine, i.e. low frequency CPU and integrated graphic card etc.

Share this post


Link to post
Share on other sites
If the amount of moving images on screen is small enough, you might be able to work with a "dirty rectangle" algorithm. SDL supports this through its SDL_UpdateRects() function, but you need to compose the list of dirty rectangles yourself.

The basic idea is simple: when you want to blit a sprite to the screen, first save (blit) the area under the sprite to a hidden SDL_Surface. Then, when you want to move the sprite again, restore the screen using the hidden surface and repeat the process.

If you have scrolling or animated backgrounds or lots of medium to large sprites moving at once this can actually be slower than just redrawing the entire screen from scratch. But if the conditions are right it can be faster.

I believe David Olofson's example-game "Fixed rate pigs" includes an implementation of the above, you might want to check it out.

Share this post


Link to post
Share on other sites
Though I expect in 90% of cases the dirty rectangle approach is unnecessary and difficult to get right anyway.

The original poster would do well to bear in mind that lots of games did just fine at displaying many sprites onscreen when PCs only ran at 4.77MHz rather than a thousand times that today.

Share this post


Link to post
Share on other sites
On very low/old specification machines you can achieve much higher performance by moving to low resolutions like 460x480 or even 320x240 and passing on performance killers like alpha blending(in software).
Integrated graphics chips like Intel GMA 950 can run games like "Word of Goo" well. So if you targeting such chips you can use OpenGL or Direct3D without thinking too much about optimizations.

[Edited by - Kambiz on April 22, 2009 6:21:20 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by rip-off
If the amount of moving images on screen is small enough, you might be able to work with a "dirty rectangle" algorithm. SDL supports this through its SDL_UpdateRects() function, but you need to compose the list of dirty rectangles yourself.
...........>.


cheers. I am using this algorithm just now. But why is it called dirty? is it not the right mechanism to move something on the screen? (i.e. cheat human eyes by restore the background back to the screen then paint the the spite image in a slightly different location,rapidly and repeately)

Share this post


Link to post
Share on other sites
Quote:
Original post by Kambiz
On very low/old specification machines you can achieve much higher performance by moving to low resolutions lik.........

unfortunately, the SBC im using has a VIA Integrated video processors and max shared video memory 128mb.

CPU: on-board VIA CPU C7-eden 1.0GHz
FSB: 800/400MHz
Chipset: VIA CX700M


and I can't even find a proper video driver for it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!