home *** CD-ROM | disk | FTP | other *** search
- Path: nntp.teleport.com!sschaem
- From: sschaem@teleport.com (Stephan Schaem)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: TMapping again!
- Date: 16 Feb 1996 05:20:58 GMT
- Organization: Teleport - Portland's Public Access (503) 220-1016
- Distribution: world
- Message-ID: <4g147q$sit@maureen.teleport.com>
- References: <38232371@kone.fipnet.fi> <4fntd3$g56@sunsystem5.informatik.tu-muenchen.de> <38232442@kone.fipnet.fi> <4fvnjb$gdm@oreig.uji.es>
- NNTP-Posting-Host: linda.teleport.com
- X-Newsreader: TIN [version 1.2 PL2]
-
- Jorge Acereda Macia (ii202@rossegat.uji.es) wrote:
- : Jyrki Saarinen (jsaarinen@kone.fipnet.fi) wrote:
-
- : > Btw, I took a new approach in making a Texture/Gouraud
- : > triangle routine; now it fits almost completely in 256b.
- : > Before it was much larger..
-
- : How many special cases do you handle?
-
- The rendering loop is <80 bytes, I think it leave enought room
- to calc the 'slopes'(12 to 15 16bit mul per triangle) in a 256byte
- cache of at least the generic case. (non flat top triangle).
- But then you might want to optimize special cases when any of the slope
- are null (Very often the texture xstep or ystep is null, so the inner
- loop can be 'greatly' optimized... well, its worth an extra 2 byte for
- a beq to the write maping code) and you have no chance to cache all
- the variation in 256bytes then.
- I would unroll the innerloop, you probably can save hundreds of dbra
- and this can defently balance against having the setup in the cache (
- plus it wouldn't anyway if you switch rendering loop depanding on the
- case)
-
- Stephan
-