[SDL] is true everything must be render inside the event loop?
Author
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?
Author
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?
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?
Author
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.
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.
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.
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.
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.
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.
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]
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]
Author
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)
Author
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
