by |>
|>
|> After applying my new True color polygon routines to a 3D app I'm
|> mucking around with. I find that gobs of time are spent drawing
|> the polygons. (1.66 200hz ticks on average)
|>
|> "average" is defined by a C for-next loop generating random points for
|> a 4 sided polygon, and then plotting.
|>
|> I found that using 'towers' in my machine code didn't garner any significant
|> (detectable even) difference over a tiny little loop. I assume the cache
|> is what makes the loop run as fast as the tower.
|>
[example deleted]
|>
|> the point is, I tried loops, I tried towers, my polys are still slow.
|>
|> Can anyone give me some general polygon tips ( pixel packed only please)
|> tips to speed up mine.
|> I'd also like to hear what other people have gotten out of their falcons.
|>
First off, you don't say where you're using RGB or VGA. The problem is one of
memory bandwidth and VGA 320x240xTC uses more than twice the memory bandwidth
of RGB 320x200xTC because of line doubling.
The problem with your linear code (aka towers) is that it is big to fit in
cache. This exacerbates the the memory bandwidth problem since all the
instructions have to be pulled from memory and it makes your linear code
potentially slower than a tight loop. What you really need a loop
with a smaller piece of linear code in it (the exact size will depend
on the surrounding code and whether you are try to fit the Bresenham loop
in cache as well).
Another thing you might try is to use move.l to fill two pixels at once.
This wins for large polygons but loses for small polygons because odd length
run lines need to be detected and an extra move.w done.
You might also try blitting from halftone RAM; but I'm not sure how fast this
is.
There are also some tricks for optimizing the Bresenham calculation. Finally
unless you want to smooth shade or texture map your polygons why do you need
TC? 256 color and movem.l instructions would be much faster.
Steven