Robin Sam wrote:
Hi Marc,
It is possible that using some of the SGE calls (I haven’t looked at SDL
Console) is slowing down your code. For example, in your drawUnit function,
you call sge_Circle - I believe that doing a straight blit from a converted
surface would be faster. You might try drawing your circles onto an SDL
surface with transparency and then blitting those surfaces to the screen.
sge_Circle draws a circle using the sqrt function - quick, but still
more expensive than blitting. I don’t know how much your fps suffers from
this, but for 7 circles and 2 filled circles, it’s gotta be slower than
blitting a bitmap.
Unh! sqrt? No Bressenham? I suppose I’ll have to take a bit of time and
code my own. I was hoping to avoid all this, I just want fast
rasterization. It may be of different radius, although I suppose if I
limited it to some finite dozen, I could save the surfaces and blit
them.
Well, my tiles don’t overlap, so that’s okay. It’s units that overlap
terrain, and potentially units that overlap other units (although I
think I’ll implement a kinematic intersection constraint so they never
do so).
You can draw everything to a back buffer, but you will prolly get better
fps if you only update those rectangles that need updating. “If it moves,
blit it; if not, skip it.”
Avoid the painter’s algorithm when blitting back to the screen. For
example, if you have something like:
±-------------------+
| |
| Surface A |
| |
| ±--------±----------+
| | | |
| |eliminate| |
| | this | |
| | area | |
| | | |
| | | |
| | | |
| | | |
| | | |
±---------±--------+ |
| |
| |
| Surface B |
| |
| |
±--------------------+
You can avoid drawing the overlap portion by dividing the areas to blit
into 3 rectangles:
±-------------------+
| |
| Surface A1 |
| |
|----------±--------±----------+
| | |
| | |
| Surface | |
| A2 | |
| | Surface B |
| | |
| | |
| | |
| | |
±---------+ |
| |
| |
| |
| |
| |
±--------------------+
This way, you avoid blitting overlapping areas - which can become
real expensive if you have many overlapping pieces.
That’s similar to the span lists I was asking about. Basically, each
scan line update is stored as a list of updates to perform, like
run-length, and that is easily manipulated. Finally it is drawn once
when everything is calculated. That eliminates overdraw. Of course, in
the absence of overdraw, painter’s algorithm is perfect. With only a
little overdraw, it’s still pretty good.
Keep in mind that blitting to the screen is one of the slower operations
you can perform, so manipulate as much as you can in an off screen buffer
and then blit as little as possible to the screen.
I think for now, I’ll blit each frame in entirety. That’s simple, and in
the worst case (especially scrolling) required. Eventually I may look to
optimize that.–
Marc Lepage
Software Developer
Molecular Mining Corporation
http://www.molecularmining.com/