How fast are your True color Polygons?

How fast are your True color Polygons?

Post by Steven Ek » Tue, 07 Dec 1993 20:08:15



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

 
 
 

How fast are your True color Polygons?

Post by CHRISTEN,BEAT ALBE » Wed, 08 Dec 1993 00:45:12


Quote:

> You might also try blitting from halftone RAM; but I'm not sure how fast this
> is.

This does NOT speed up things very much. Since the Blitter gains its speed
by addressing pixels in plane-modes. (where the CPU would have to rotate etc.)

For the suggestion with the loop fitting into the 256Byte-Cache, I just can add
that then you should set the Write allocate-Bit in the Cache Register of the
CPU. (Don't ask me right now, what worth is best, I don't know that by
heart...)
This can speed up things like hell!!! (I did it with my old Fractal-routine.
It gained about 70% of speed!!!!
The same thing with Griff's small sphere-demo-routine that was hacked, speeded
up and spread by An Cool (?). After having set that WRITE ALLOCATE Bit, it
worked on VGA-Screens at 60 frames a second...

But do not try this out with the desktop (in Tos 4.0x) it won't work
(only if you do not want to use your disk-drive) Though this has changed in
MultiTOS where they included that Cache On/Off Switch...

Have a nice day
   Beat Christen


 
 
 

How fast are your True color Polygons?

Post by Daniel Hagg - HFB T ep » Wed, 08 Dec 1993 01:10:47



Quote:

>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)

I *think* it's possible to let the BLiTTER do the drawing while the
CPU calculates the next polygon, if you can get the code to fit in
the 68030 instruction cache!

I haven't tried this, coz I haven't got a F030 yet...

 /
/ Daniel

 
 
 

How fast are your True color Polygons?

Post by Timothy Wils » Tue, 07 Dec 1993 18:14:52


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:
d7= pixels to write.
d0= color.

loop:

        dbra d7,loop
end:

** VS ***
        lea _tower,a1

        movew #320,d6
        subw d7,d6
        addal d6,a1
        addal d6,a1 | set up for jump

tower:




        ...

end2:

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.

Thanks. i'll post a summary.

--

Atari Explorer Online: Internet Editor --- GEnie: AEO.8

Quote:>Dark Oak Software<-~-Entertainment and Applications programming in C

^^^^^^^^^^^^^^^^^^^~-~Falcon030, Unix and MS-DOS.
 
 
 

How fast are your True color Polygons?

Post by christian laplaic » Wed, 08 Dec 1993 19:11:30


I am not sure using the BLITTER will be so efficient.
If you let the BLITTER do the points, as long as it runs
the same speed as the 68030, you won't gain time.

If you really want to gain much much time, you could use
the DSP, but it is another problem ...

 
 
 

How fast are your True color Polygons?

Post by Warwick Allis » Sat, 11 Dec 1993 11:40:42


Try using moveml with lots of registers - that's the standard move-as-much-as-
possible solution.  You'll need more special-case code at the start of course
(code to move the residual words).  moveml can be used to move about 56 bytes
per instruction (8 dregs + 6 aregs) * 4 bytes per long.

--
Warwick


 /     * <- Computer Science Department,   ||||||   GEM++ is Free Software
 \_.-._/    University of Queensland,    _// || \\_  C++ is the FUTURE
      v     Brisbane, Australia.        |_/  ||  \_|  Use GNU C++ = FREE

 
 
 

1. TRUE Color vs TRUE B.S.

I've got a question for all of you on the net arguing about how many colors
true color is and how many colors the eye can distinguish and what professor
Phudpucker claimed in his exciting lecture on video color planes...

   WHO CARES???

C'mon people... get a life!
---

___________________________ John "HUTCH" Hutchinson _________________________
_________________ Fair Dinkum Technologies     Member - IAAD  _______________
________________ "No worries, mate... it's from Fair Dinkum!" _______________

2. How to manage FP web locally

3. How Many Colours is true ColoUr?

4. Amstrad 8256

5. Fast Cash It's TRUE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

6. Blocking viruses

7. Atari800 Emulator Programmers show true colors

8. CROSS SECTIONS from CONTOURS - New Product

9. True Color? (Falcon VGA)

10. Apology: True Colour *IS* great for games.

11. True Color Cards

12. The Falcon DOES have true colour

13. The Falcon Does NOT have True Colour