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

In article <u894776.718687891@bruny> u894776@bruny.cc.utas.edu.au (James McCoull) writes:
>chrisg@cbmvax.commodore.com (Chris Green) writes:
>
>[some cool ideas... which start to break around here...]
>
>>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.
>
>>	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.
>
>	The way I see it... if you are writing a game you have to provide
>a version for the A500/KS1.2/KS1.3 class of computers - otherwise you don't
>have a market.  This means you have to write two versions of every program -
>one which hits the ECS hardware so hard and direct it almost fries, and one
>which lives nicely under KS3.x/AGA.  Of course if you are using an object
>oriented framework for your game, it is pretty trivial to set up a runtime
>link-loader which will resolve statically the actual rendering methods/code.
>
>	Alternatively, is it possible to boot up a KS1.2 machine, and then
>patch the rest of the KS3.0 graphics.library over it?  It would be quite
>nice if CBM would provide and hurl this patch into the public domain -
>so we could leave the era of hitting the hardware directly, as soon as possible.
>
	The only part of your game which might need to be different under 1.2/1.3 is the
part which did the buffer swap for the double buffering. Under 1.3, you could
either use ScrollVPort, user-copper lists, or custom Views to implement the
double buffering. Under 3.0, of course, you would just call the system double
buffering function on an intuition screen.

	Remember that in a game of this type, the bottleneck is going to be the 
routines that perform the texture mapping, and planar-chunky conversions,
which are all cpu bound, and so not affected by whatever level of hardware
banging you do or not do.

	BTW, don't dismiss the "real" texture mapping approach (UnderWorld)
because it is slower than the "fake" approach (Wolf3d). Sure, Wolf3d runs
faster, but speed is not everything. Wolf3d type of texture mapping will
never allow you to jump on top of a column and crane your head downwards
to look into a chasm filled with animated water in order to fire your
arrow into a monster swimming in the moat.


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