Hello boys !!,(I’m new on this mailing list ,so
don’t be too severe if I
make mistakes … :))
I’m looking for the best(The more efficient ,the
fastest) way to design a
main loop ,…,especially,
about what should be drawn,and what shouldn’t be !
On of the main problem I face is :
Every time the games ‘loops’ :
-1 Should I redraw the entire background and then
draw the sprites on it.
-2 Or,should I try to “erase” all the sprites(This
implies the redraw of the
piece of background that was under them) ,and then
draw them in their new
positions …
-3 Should I try to find only the sprites that
changed their position before
erasing ,(This implies handling the case where a
sprite is moving above the
other).
-4 Other suggetstions ???
Of course it is assumed that the background is a
static,if I want a
scrolling background I’ll create a huge
sprite covering all the screen…
Just remember,I’m looking for the most efficient
method ,(not the easiest).
Thanks in advence !!!
Welcome!
The method that will draw the least amount necessary
would be the fastest…
If your background is static, and a good many sprites
don’t move, or even if a good many sprites don’t move
relative to a moving background, then you’ll want to
only erase animated or moving sprites, and redraw the
aforementioned sprites… plus any sprites that have
an overlapping bounding box with them (in case they
have been partially erased).
The exact value of ‘good many’ will probably depend on
the system… benchmarking would be the way to go if
you really are worried about efficency.
To have a moving background with a selective erasure
scheme like above, you’d need to re-blit the screen
content to an offset location… if it’s a hardware
surface one of SDL’s blit functions may be able to
transfer directly from hardware memory to hardware
memory. Chances are it’ll actually be faster as a
software surface, in which case you might be able to
write a faster move/blit function than the generic
one… assuming your screen dosn’t move too much (how
much will again depend on the system) you could write
a single for loop that would do an extra draw in the
new ‘uncovered’ area, but wouldn’t have as many
comparisons. If you’re interested in an example of
what I’m talking about let me know. (It might only be
worth it for 1 or 2 pixels shift left/right)
For an ANIMATED background (aka not just moving side
to side) you’ll need to redraw at least part of the
background for the animation. Any sprites overlapping
animated areas will need to be redrawn. If it’s coming
from a file, you could pre-compute areas that need
redrawing (boxed out somewhat for fast blits) and
compare all sprites against this as well.
Also, as a final note: most systems today are fast
enough that you may want to postpone optimization
until you are fairly close to ‘finished’ with the game
(and by cloes to finished I mean close to
releasing/going beta/going past beta). This has the
advantage of being able to know how everything is
layed out, and hence where exactly you should start
optimizing :).
Geeze I reply too long too much… 
-Mike__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
