NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/atari/st/18910

Text File | 1992-12-24 | 4.9 KB | 99 lines

Newsgroups: comp.sys.atari.st
Path: sparky!uunet!stanford.edu!nntp.Stanford.EDU!geomorph
From: [e-mail] (Bayard Wenzel)
Subject: Re: Apology:  True Colour *IS* great for games.
Message-ID: <[e-mail]>
Followup-To: Article 32399
Sender: ?@leland.Stanford.EDU
Organization: DSG, Stanford University, CA 94305, USA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 24 Dec 92 21:17:48 GMT
Lines: 86

[e-mail] (Steven Eker) writes in article <[e-mail]>:

>In article <[e-mail]>, [e-mail] (Bayard Wenzel) writes:
>|>[My article on True Color an 3D Graphics deleted]
>
>Not if you choose the positions of your colours in the palette to work for you
>rather than against you - with smart allocation scheme it can be faster.

If you already have the True Color value of the pixel, converting to 256 colors
will require at least 3 divisions (make them shifts if you want and can) and
two ORs when using the 6R 7G 6B color distribution. I think this is one of
the best distributions when using polygon graphics with lots of colors since it
looks to me (I'm not sure about this part) that it's one of the fastest.
But suppose that you found a faster algorythm, and suppose it only
requires one or two extra instructions besides the move to memory. It still is
slower since you can directly move the True Color word to memory. And remember
it takes the same time to move a word and a byte.


>|> [More stuff I wrote deleted]
>
>The good thing about true color is that it is 1word/pixel layout in memory
>rather than interleaved bit planes.Thus you can set the colour of a pixel with
>1 access rather than 16. With flat shading this isn't so important since you
>can write 16 consectutive pixels with the same colour.With gouraud shading the
>value of each pixel is calculated individually and it makes a big difference.
>
>256 colour palette with 1byte/pixel would be much faster for shading and texture
>mapping but unfortunately 256 color modes use interleaved bit planes on the
>falcon.
>
>It _might_ be possible to do real time gouraud shading and even texture mapping
>in true color mode if the bus is fast/smart enough.

Once more I say it takes the same time to write a byte or a word in a bus
bigger than 16 bits so if the bus is not fast enough to do it in True Color
then it can't do it in 256 color mode either. I didn't know the Falcon used
interleaved bits for 256 color. This is rather sad since it may take more time
to draw the screen in some cases(like using 8x8 sprites).

>|> [More stuff I wrote deleted]
>
>The DSP<->main memory bus is unlikely to be fast enough for the DSP to do shading.
>The trick is to have the DSP do all the 3D/lighting calculations/facet
>sorting/clipping at polygon level so that the 68030 can spend ~90% of its
>time rendering polygons
>- ideally with a tight (<=128 byte) inner loop so that it gets most of its
>instructions from cache to avoid bus contention.

That's what I meant when I said "specially with the DSP". The DSP can be used
for vector transformations and ligting calcs. while the 68030 draws the
polygons.

>Suppose 6byte/vertex (16bit x, y, color) and average of 6 vertices/polygon.
>At 30fps with say 500 polygons on screen we need ~540K/s DSP->main memory.
>Assuming the world is stored in DSP RAM the main memory->DSP transfers will
>only contain position updates for moving objects. Just about doable...
>but only just.
>
>Its the speed of the 68030 and the 68030<->main memory bandwidth that worries me.

I think the 68030<-> is fast enough. I imagine it's a lot faster than an ISA
bus on the PC. The latest flight sims on the PC use gouraud shading on some
objects like polygons and stuff. I'm sure that the update is not even 30 frames
per second on those games but it is fast enough to be acceptable.

>Even with the best algorithms and coding tricks I doubt you can render even a
>small gouraud polygon in ~300 instructions... but maybe its possible to find
>a neat way of preprocessing the polygon on the DSP (eg y-sorting verticies,
>precomputing Bresenham increments for each edge) to speed things up; or do
>something clever with the blitter.
>
>Steven

I was thinking somewhat along the same lines you are. The world should be
stored in DSP memory. The DSP should be constantly transforming polygons and
calculating the lighting for them. It can get two requests from a 68030, either
change camera coordinates in which case it clears the buffer and starts
recalculating, or get the next polygon to be rendered (already sorted).
When it returns a polygon it returns the the vertices (4 bytes each, 2 for x &
2 for y) and the plane equation coefficients for calculating the color at each
point in the polygon. The 68030 would then calculate the polygon and the colors
using the standard techniques coded for maximum perf. of course.

Sebastian Ferreyra