From: chrisg@cbmvax.commodore.com (Chris Green)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Wolf3D -- programming aspects
Date: 7 Oct 92 12:58:38 GMT
Reply-To: chrisg@cbmvax.commodore.com (Chris Green)
Organization: Commodore, West Chester, PA

In article <leifv.36.718453033@dhhalden.no> leifv@dhhalden.no (LEIF HUGO VARUM) writes:
>>> 
>>> 	I realize that since we don't have byte-addressed graphics like the IBM,
>>> I'll have to do it plane by plane and it'll take a while.  But I'm aiming
>>> for 10+ fps on an 030 w/ 16 colors, lores.  I have no idea if it can be done.
>>> But I've seen cube-o-matic which blazed on my 3000.
>The programmers of the us-gold game said it would run at 8 fps on a standard 
>Amiga, more if you used a smaller output window.
>
>BTW one of the Amiga programmers was Paul Woakes (Mercenary, Damocles).


	For "real" texture mapping (like in Ultima-UnderWorld), I'd recommend
generating your texture mapped polygons into a fake frame buffer, stored
in fast ram at one byte per pixel. After the whole frame has been rendered
into this fake buffer, transfer it to chip ram, converting it from chunky
to planar. This has a lot of advantages over writing your texture map
routines to work in planar modes:

o	Easy coding.

o	Constant overhead, regardless of scene complexity. The overhead of
	planar texture mapping routines would increase as the number of texture-mapped
	pixels increased.

o	The fake frame buffer will be in fast ram, and will be cached
	on the processors with data caches.

o	To change the depth of your screen, say from 16 color to 32 color,
	you only have to have a different transfer routine.

o	You can easily do a table lookup while transferring the pixels to
	chip ram. For instance, you could write your game to do 256 colors
	on AGA, and simply remap the pixels through a lookup table to
	whatever normal amiga mode you use on non-AGA machines. In fact,
	by using two lookup tables (one for even pixels, one for odd),
	you can get a "free" 2x2 dither. This provides a simple way to let
	the user pick between 16, 32, EHB, or 256 colors.

o	You can do neat effects (like transparency, shadows, etc) by having
	shapes which read the pixel out of the fake frame buffer, pass it
	through a lookup table, and put it back.

o	If you beam-synchornize your fake-frame-buffer to chip-ram copy routine,
	you can get away without double-buffering, thus saving chip ram.

o	The copy can take advantage of 32 bit chip ram.

o	If you used (perhaps conditionally) WritePixelArray8 to do the planar
	conversion, then your game would work on any graphics device that
	supports graphics.library.

	For "fake" texture mapping (like in Wolf3d), you the planar nature
of the amiga will not effect you in the slightest:

	Store each column of the texture map at "n" different vertical
magnifications. 

	Step horizontally across the polygon, determining at each
position which vertical scale factor is correct. 

	Use the blitter to copy the appropriate vertical column to the screen.

	Store the scaled texture columns, and the screen memory in "interleaved
fashion". Than one blit can copy all bitplanes of one column to the column
on the screen. You will achieve near perfect processor-blitter overlap
this way (the blitter will be copying the previous column while you are
performing the calculations for the next one).

	Note that for texture mapping games of this nature, there is no reason
that they cannot be completely multi-tasking. In fact, they can run happily
in draggable intution screens.
-- 
*-------------------------------------------*---------------------------*
|Chris Green - Graphics Software Engineer   - chrisg@commodore.COM      f
|                  Commodore-Amiga          - uunet!cbmvax!chrisg       n
|My opinions are my own, and do not         - icantforgettheimpression  o
|necessarily represent those of my employer.- youmadeyouleftaholeinthe  r
|"A screaming comes across the sky..."      - backofmyhead              d
*-------------------------------------------*---------------------------*
Newsgroups: comp.sys.amiga.programmer