Contents | < Browse | Browse >

  Steffen Haeuser    


V 0.1  First release
V 0.25 Added some more demos, layout is 80 charachters/line
V 0.26 Added History, layout is 75 characters/line
V 0.3  Added some additional info, added 3d-demo,
       added Albas engine, added Wayne engine, added 
       source section.
V 0.35 Added A1200 smoothness values. Thanks to all the people
       who sent me email, by the way... they help improving
       the FAQ :))) Added some frame rates ...
V 0.4  Added short reviews of TextDemo57 and Alien Breed 3D

Table of contents

I. Introduction

 1. What is Texturemapping ?
 2. What are the problems of Texturemapping on the Amiga ?
 3. How can they be solved ?

II. Short reviews of all demos/games/sources known to me

 1. Demos
 2. Game-Demos
 3. Games
 4. Sources

III. Rumours and other infos department

IV. Doing texturemapping with emulators

 1. Hardware-Emulators
 2. Software-Emulators

V. Algorithms

 1. Terence Russells algorithms used in Wolf3D-2.lha

VI. The Amiga Texturemapping online conference
 1. The invitation
 2. Some hints for people who do not use IRC often

VII. What can YOU do to support this FAQ ?

I. Introduction

1. What is Texturemapping ?

Texturemapping is a method of wrapping bitmapgraphics around
vectors or 3D based graphics in common. For games, texturemapping
is mostly used doing very realistic Dungeons.

In contrary to a dungeon like in Dungeonmaster or Eye of the Beholder,
the player is not limited to some few directions, but he can turn
around in TRUE 360 degrees, like in real life. Often the graphics
is more realistic than the graphics of such block graphics games
and especially the opponents of the player are done very well
(using texturemapping and vector graphics ...)

Texturemapping is used for role playing games and for dungeon action
games (some of them able to handle more than one player at the same time).
The most famous such games are Castle Wolfenstein and DOOM. Castle
Wolfenstein is for PC and Mac, DOOM is for PC (and soon for Mac too).
There are probably more texturemapping action games than texturemapping
role playing games.

The original creators of DOOM did no port to the Amiga and won't do
so in the future. All the talk about "Amiga DOOM" is to do a similar
game on Amiga, not the original DOOM. Most people speak of "Wolfenstein
style" and "DOOM style" graphics engines to describe how GOOD the used
texturemapping in a game is. DOOM engines are superior to Wolfenstein 

2. What are the problems of Texturemapping on the Amiga ?

Texturemapping needs to put single pixels to a screen, not only LINES 
like in vector graphics. So you need both a fast CPU and a fast graphics 
for doing texture mapping.

On PC (and on Mac) the color of each pixel is described by ONE BYTE... 
this is the so-called CHUNKY PIXEL MODE. On Amiga, the color of each pixel 
is described by EIGHT BYTES (for 256 colors). This is the so-called 
BITPLANE GRAPHICS. Easy to understand, Chunky pixel is better for 
texturemapping than bitplane graphics, as bitplane graphics only 
has 12.5% of the speed of chunky graphics. Of course, if you take less
thean 256 colors the speed is better, and i was told, in this way you even
may get a better speed than doing chunky graphics.

Second thing, even if the 68040 is very fast, not everybody has got such 
a thing(i have :)))) ). But on PC most gamers have got a 80486 (Which 
probably is slower than the '040, but much faster than the '020). It is 
probably not possible doing texturemapping with an 68000. In addition, 
texturemapping should have 64 colors AT LEAST (maybe extra halfbrite 
on ECS ...)

Third, a lot of companies let the Amiga alone (Boooooh... :((( ), and in 
special they did not want to risk coding something DIFFICULT on Amiga. 
And some coders simply are moronic DOS-lovers (greetings to ID Software 
(they did DOOM) and to Richard Garriot of Origin at this place... i hope 
they $"&$/&$"/$"/& (censored) !!!)

3. How can they be solved ?

A) Copper Chunky Modes

I told you before, that the Amiga is not capable of doing chunky modes. 
That is not 100% the truth. There is a type of copper cheat (the copper 
is one of the Amiga's graphics coprocessors), that in fact DOES chunky 
modes. The problem with this graphics mode is, it can only handle a 
resolution about 100x100 to 130x120 pixels (i do not know exactly, as i 
am no specialist in coding texturemapping ...) Compared to PC Games with 
320x200 texturemapping this may look ugly ... (but it should be mentioned, 
games on PCs (at least on PCs that are not these absolute high-powered
ones...) often do not use full screen graphics, and so often too use such 
resolutions. Copper chunky can't do 1x1 or 2x1 pixel resolution or
something like that (i do not know exactly what are the limits for that
Copper tricks... maybe an expert inc coding such things could tell me ?)

B) Chunky to Planar Conversion Routines

A Chunky to Planar Conversion Routine is a part of a texturemapping code, 
that takes graphics in chunky (one Byte per pixel) as input, and puts it 
as Bitplane Graphics on the Screen. Of course, this method needs much 
CPU-power. For most demos/games, you should have at least a '030 to get 
it smooth... and a lot of demos using this technique do not have FULL 
texturemapping... that is, they for example have no stairs, and everything 
on screen is on the same height level. Copper Chunky does this better, but
has a low resolution... of course a '040 with a Conversion Routine can 
do fine things...

C) Using a graphics board

Graphics boards for the Amiga do not use Bitplane graphics, but, in fact, 
Chunky graphics. The problem is, not many people have such boards in their 
systems, in difference to the PC, where all graphics is based on such 
boards. But some coders said, they maybe will do an additional "graphics 
board version", that features the fast graphics chips with their chunky 
graphics... there is even a texturemapping demo running on EGS (EGS is
a standard for Amiga graphics boards).

D) Demo-Groups do the Games

As those people who can do texturemapping best (on PC) often are 
DOS-lovers, on Amiga a lot of people of the demo-scene and others, who 
are not employed at software firms, began to code... and as software firms 
want to SELL, they will probably sell the finished products, even if they 
are Amiga-only... And of course there are firms DEDICATED to the Amiga, 
like Team17 ... they are in this texturemapping business, too ...

II. Short reviews of all demos/games known to me

The short reviews are done in a specific format, mentioning Name, Author 
Name (or name of one of the authors), Minimum System, Recommended System, 
Engine style, How smooth the scrolling is and how good the pixelresolution 
is. Then they are followed by a short description of the demo (of course i 
could say more of the most, but there are a lot of demos reviewed...) Then 
i list the E-Mail of the author (if available) and where on Aminet sites to 
find the demo (if possible). I recommend using or or another site with complete Aminet. Some smaller sites 
only have got the latest uploads to Aminet. Wuarchive is a good choice, 
too. And there is another good site called or something 
like that. You could look at, too.

Used abbreviations :

Minimum/Recommended System

All  = All Amigas with 1 MB chip at least
020  = All Amigas with 68020 at least
AGA  = All Amigas with AGA
030  = All Amigas with '030 at least
040  = All Amigas with '040 at least
060  = All Amigas with '060 at least (Joke! :))) )
FPU  = All Amigas with FPU at least
EGS  = All Amigas with EGS graphics boards

Engine style

Low  = Engine worse than Wolfenstein, 
Wolf = Wolfenstein-style engine
:)   = A little Better than Wolfenstein, worse than DOOM
:):) = MUCH better than :), but not DOOM ...
DOOM = DOOM-style engine
Bey  = Engine BEYOND DOOM


VSm  = Graphics very Smooth
Smo  = Graphics smooth
NSm  = Graphics nearly smooth
Not  = Not very smooth graphics

Pixel resolution

Cop  = Probably copper chunky or some other copper cheat, maybe i am 
       wrong. In special CopL says low pixel resolution, CopM medium
       and CopH says high resolution (but i think it is impossible
       of doing a copper display with a pixel resolution you could call
       HIGH). CopM probably is worse than Med. I used the CopL-CopM
       abbreviations only to have SOME METHOD to differentiate
       between different kinds of copper displays.
Low  = Low resolution (probably something around 2x2 or worse...)
Med  = Medium resolution (probably something around 2x1 or 1x2 ...)
High = High resolution (probably 1x1 ...)

Coded by

(P)  = Single Person
(G)  = Demo group
(PO) = listed person is one of those doing the thing... but there are 
(SF) = Software firm

All speed remarks are relative to my own system (hehehe...), an A4000/040 
with 14 MB RAM and a Piccolo SD64 graphics board (not the standard Amiga, 
isn't it ?) If you have an Amiga 1200 without accelator and did some tests 
you may wish to mail your results to me ...

I have to remark too, that the comments are NOT objective... i like some
demos and games, and do not like others... no one should take it as an 
insult, if i give his favourite demo a bad mark... it is only a try done 
by me... if you think the other way round, tell me... maybe you can 
convince me to change the FAQ as to one specific demo :))) I chose to be 
STRICT in the remarks i had to do ... in order to show the differences 
between the tested engines ... but of course i know how much work it is 
even to do a texturemapping demo in LOW resolution with a TM-Engine that 

Sometimes i wrote something like Low/Wolf... then i did not want to say 
Low, and not Wolf... again... everything very subjective ...

Ah... about that "recommended system" things... Just guesses...

Nearly all of the demos are on Aminet and for most of the demos
you will find in the FAQ in which directory. Most of the demos
also are (for the Germans reading this FAQ) available on the
Birdland BBS (number found at the end of this FAQ).

1. Demos

Only Demos with texturemapping parts that could be used in games are 
mentioned... no textured spheres, cubes and such things... all things 
mentioned in the chapter "Demos" will probably never get games ...


Mindflow      Stellar (G)     AGA (4 MB RAM)     AGA (4 MB RAM)
:)            NSmo            Med

One of the effects of this demo is a dungeon that looks nearly like the 
dungeons of the game Ambermoon. The textures of the ceiling and floor 
are MUCH better than in Ambermoon, but Ambermoon is smoother ...

Author : Stellar (One email of a Stellar-Member is , this is Nose/Stellar)
File   : /pub/aminet/demo/aga/mindflow.lha


Motion        Bomb (G)        AGA                AGA
DOOM          Not/NSm         Med

One of the effects of this demo is a FULL texturemapped DOOM engine with 
stairs and all. Bravo, Bomb !!! You should do a game out of this :))) 
This demo did not run on my A4000/040, but i did get a patch from some-
one... i do not think this patch is on Aminet, though ... one last word
to the engine... there are stairs and all included, but the Speed i think
is not that sufficent for a game ... okay for a demo though...

Author : Gengis/Bomb
File   : /pub/aminet/demo/par94/MotionDisk1.dms

Doomed        Pearl (G)       All                All
Low           VSm             CopL

A demo where you can use the joystick to wander around... but i decided
not to do it to the Game-Demos, because the only intention to do this one 
was, to prove it is possible of getting 50 fps on a plain A500. Someone 
of Pearl tried to enhance the engine, but as this did not work, the demo 
died. Talking about resolutions, there are copper chunky demos with 
better resolution.

Author : Netrunner/Pearl (
File   : /pub/aminet/demo/euro/Pearl.Doomed.lha


Phobos        Cydonia (G)     All (???)          All (???)
Low           Smo             CopL

One of the earlier approaches to Amiga texture mapping. It has no floor 
textures and turning around does not look like it SHOULD... but asides 
from that the speed is impressive. You can use your joystick to walk the
dungeon, in contrary to most not-game demos. The resolution is weak.

Author : ???
File   : ???


Fullmoon      Fairlight (G)   AGA                AGA
Low           NSm/Not         Low

Even if Fullmoon is a very nice demo, the texturemapping part is not very 
well done. The scrolling is not smooth, there are no floor and ceiling 
textures and the resolution is low. The not texturemapping related parts 
of the demo are nevertheless great !

Author : ???
File   : ???


HOI-SAGAIII   TEAM HOI (G)    AGA                AGA
Low           NSm/Smo         Low

The texturemapping part of the demo has no ceiling textures, and the floor 
textures are not very well done. The speed is better than that of most 
such "little hacks", but there are better texturemapping demos than this 
one. Aside from this flaw, HOI-SAGA III is (looked upen on it as demo in 
common) okay.

Author : (or was it ???)
File   : ???


Waynes Engine Wayne Mendoza   ???                040
DOOM          ???             ???

This one will be DOOM-like graphics. But sadly Wayne_m said on irc he
would probably not do a game with it. I HOPE he changes his mind about
this :))) I do not know what the final name of the thing will be.

Author :
File   : Not yet available


2. Game-Demos

Game-Demos are Demos that are probably on their best way of getting games. 
Some of them actually will get Games, some not ...


Warp_S        O. Groth (PO)   020+HD             AGA + Fast Ram
:):)          Smo/Vsm         Low/Med

Really a nice engine, the only DOOM style engine on Amiga with monsters 
running around. This one will be a game 100%. Playable demo will be out 
maybe February or March. The resolution and graphics are not the best at 
the moment, but the next Demo out will (according to the beta i saw) be 
much better. They got a new graphician, who is very good (i know this 
one :))) ). Maybe the most promising demo of them all. It will get a 
graphics board version, too, and an extra version that is '040-optimized 
(higher resolution !!!) was promised sometimes... Was in the beginning 
called Texmapp... The release version probably will be faster than the 
demo. Uses not only 90 degree walls. Decompresses monster GFX in real 
time. Just got a new beta from Oliver. Some bugfixes, you can shoot
(but there is no explosion graphics yet) and you have the option of
doing a speedup of the graphics. Maybe the engine is a bit faster

Author :
File   : /pub/aminet/gfx/misc/warp_s.lha
A1200  : Smoothness Smo
Frame  : 19 fps on A4000/040


POOM          Parallax (G)    AGA                030+AGA
:):)          Smo             High

Maybe the most famous Amiga texturemapping demo. But it got very quiet 
around it since October '94. Maybe they dropped it? Or maybe they will 
bring out a complete game from one day to the other? There is a V0.3 on a 
finnish BBS ... the coders did some talk about a "maybe" graphics 
board version. POOM0.2 only has rectangular walls. The phone number of 
the Finnish BBS is +358 18 161 763.
POOM0.2 is on Aminet ... As to V0.3 Beta, it is much smoother, you can
select a resolution from 32x32 up to 320x256 (the latter did not work
on my system, though...), you see the gun and there are some new
textures (a complete floor texture too...). As soon as you quit the
Beta, it crashes. The Beta does not run with 2 MB. Someone said,
the guys of Parallax would be working on something else at the moment,
so the next release of POOM would be some time away.
there somewhere in april.

Author :
File   : /pub/aminet/gfx/aga/poom_02.lha
A1200  : Smoothness Not (V0.2)


BSP           John Fehr (P)   All                040
DOOM          Not             Low/Med

This Demo reads an original DOOM-Wad-File and tries to interpret it. This 
is SLOW, because WAD-Files were made for the PC, not for the Amiga ... 
they are Intel-optimized... the WAD-interpreter BSP has no ceiling or 
floor, but many features (because of the WAD ...) As it is No-Aga and 
not very smooth, i do not think it is more interesting than for example 
POOM or Warp_S. But it was probably VERY MUCH work to make this thing 
reading .wad-Files ... and those multiple textures things probably cost
a lot of speed too... there are AGA versions in the archive too... they
too do not have floor and ceiling, but look better than the
ECS-version ... I was told, it seems, John Fehr now is doing something
further with his engine, but as to now i have no conformation from
himself (so, what about, this, John, if you read this FAQ ? :) )

Author :
File   : /pub/aminet/gfx/misc/bsp1.0.lha


Tmapdemo      C. Green (P)    AGA                AGA
???           NSm             High

This demo comes with complete source... the author allowed doing a game 
with his routine (he probably won't do himself ...) The engine is quite 
cool, but very incomplete... just some blocks with Pics on the walls... 
no collision check... but a floor...

Author : chrisg@commodore.COM (this email of course does not work ...)
File   : /pub/aminet/gfx/aga/tmapdemo.lha


Tmapdemo      S. Boberg (P)   EGS                EGS + EGS board
???           VSmo            High

A Port of Chris Green's texturemapping engine to EGS... according to the 
author a quick hack... probably won't get any further...

Author : ???
File   : ???


Dentaku26     A.J.Amsel (PO)  AGA/CD32           AGA/CD32
Wolf          VSm             CopL/CopM

Dentaku will be a Wolfenstein/DOOM-style game (probably with level editor 
and serial device support). A.J.Amsel said to me, a demo will probably be 
released in April 1995. An older demo (executable from September) is
available on According to the mail information A.J.Amsel gave 
me, he and the others formed now a software company which is called 
Silltunna Software. They are two Coders (one of them A.J. Amsel), one 
artist and Alistair Brimble doing the sound. The game uses a copper display 
for its texture mapping routine. If you are a coder, an artist or a sound
specialist, you may wish to contact Mr. Amsel. Maybe you could join them 
in there project (Mail to A former Demo of 
Dentaku was DentAWolf, but it has not much to do with Dentaku as
it is now. The ratings for DentAWolf are Low/Wolf,VSmo,Low.
The version of Dentaku found at is only optimized for
low end machines (but in my opinion it is good enough on high
end machines... maybe there is even room for an improvement of
the engine :))) And the engine does >20 fps on low end machines
too...) On high end machines you can even do 50 fps. The graphics
is of lower resolution as other games, but looks great anyway.

Author :
File   : /pub/aminet/demo/aga/dentwolf.lha (DentAWolf...)
         /pub/aminet/demo/aga/dentects.lha (Sept. Executable of Dentaku)
A1200  : Smoothness VSm
Frame  : 50 fps on A4000/040


ChunkyMaze    D. Bryson (P)   AGA                AGA
Wolf          VSmo            Med

A little dungeon with flickering torches and some pictures pinned to the 
wall. It has no floor or ceiling textures and in some distance the 
textures do not look nice. But there are worse tries. This project is 
(even if there are better approaches) still alive, but as David Bryson 
told me, the problem is the TIME. Anybody willing to help him, should 
contact him per email. He did not do anything further by himself, but 
Lee Metcalfe did some very nice graphics for the demo, and Paul Heams 
coded a little further. David would like it, if someone with LOTS of time 
picked this demo up. He would help this one with the source, of course.
I found a very similar demo on my harddisk (even the same textures...) 
which is called wolf. I think it is an earlier or later version of 
ChunkyMaze, but i do not have the docs.

Author :
File   : /pub/aminet/gfx/aga/maze.lha
A1200  : Smoothness VSm


TextDemo5     J. Hendricks(P) 020                030                    
:)            VSmo            Med

In Fullscreen probably the fastest engine on Amiga (okay, POOM has floor 
and ceiling textures and is not much slower...). Textdemo has Lightsources, 
not-rectangular walls and the resolution and screen size can be 
customized. The demo has OCS, ECS and AGA versions. It uses some very 
tricky Chunky2Planar code (using even the blitter...). There is a 
TextDemo6 in work, and as i was told this one will probably be one of the 
best texturemapping demos on Amiga.

Author :
File   : /pub/aminet/gfx/misc/TextDemo5.lha
A1200  : Smoothness Not to VSm, according to screen size


TextDemo57    J. Hendricks(P) 020                030+Fast Ram
:):)/DOOM     VSmo            High

A long time, there was nothing new about Textdemo, but now it is on
Aminet !!! And it is probably the BEST texturemapping engine available
on Amiga, striking even Alien Breed 3D, POOM and Warp_S. I hope the
other coders won't take it this harsh and continue their projects
nevertheless :). On a fast '030 or a '040 it FLIES at near full screen.
I did it at 224x168 with 1x1 pixel resolution on my A4000/040 and
that looked ABSOLUT PHANTASTIC. John Hendrikx claimed he will do
a texturemapping engines for high end Amigas that will be AT LEAST
as good as DOOM, if not better...

Some features :

- Realtime movement (smoother on better systems, but not faster
  than acceptable...)
- 128x128 textures (looks MUCH better ...)
- Multiple height walls :)))
- Floor textures (no ceiling textures yet...)
- "Bouncing movement" (I think the bouncing movement of TextDemo
  looks better than that of DOOM !!!)
- Object-mapping-code for monsters included (but no animated
  monsters implemented yet...)
- Textures take 24 Bit as original (so port to graphics board version
  would be easy)
- something that looks like water (and the bouncing movement looks
  like swimming :))) )

There are two teams doing games with this engine, John doing the engine
itself. The first team (the "Shade-Team") are five guys. They intend
to do a game with RPG elements that will be a mixture of DOOM, Dungeon
Master and Magic Carpet. The other Team ("Mystic tank") is doing a
two-person tank game.

Look forward to the next release (that shouldn't be a insult to the other
coders, but TextDemo is really GREAT ... did a long way from Textdemo5).
Maybe with that graphics board talk it would be nice if John did a
Cybergraphics version (if he reads this suggestion ... :) )

TextDemo57 is a sort of pre-release to TextDemo6. (Yeah! It is possible
on the Amiga! :))))))))))) )

Frame: 8-26 fps according to screen and pixel resolution (according 
       to the fps display... sometimes it seems to me better than the
       display says... at the low rates...)


Reality AGA   K.Picone(PO)     ???                ???
???           ???

This project is at present a Wolfenstein type engine that has up to now
not made it to a public release. I got some infos about it :

- Aimed for A1200 and CD 32
- Static and moving objects
- Solid and see through walls
- Floor and ceiling textures (will be done later)
- 1x1, 2x1, 1x2 and 2x2 pixel resolutions
- walls at any angle and of any length
- 64 colour GFX, maybe soon 128 or 256 colour GFX
- external back drop pictures
- simple multi height walls
- graphics board version (will be done later)
- ECS/OCS version (later, with some reduction)
- 320x256 1x2 in 7-8 fps on A1200 with 4 MB Fast
- 320x256 1x1 in 5-6 fps on A1200 with 4 MB Fast

There will probably be a demo release in 2-3 weeks ...

Author: ???
File  : Not yet available
Frame : 8 fps on A1200 with Fast Ram


Albas Engine  alba on irc (P) AGA                ???
DOOM          ???             ???

This one is intended to be a game in June. A DOOM style engine
with 1x1 and 2x2 pixel resolution. It will do 12 fps on 68030 50 MHz
with fullscreen and 1x1. In a small screensize and with 2x2 it
should be even playable on a plain A1200 system. But Fast Ram
is recommended. I did not see it up to now .... I do not have the 
email of the Author. I do not know the final name of the game.

Author: alba on irc
File  : Not yet available
Frame : 12 fps on 50 MHz 68030


Alien Breed3D Team17 (G)      AGA                AGA+Fast Ram
DOOM          NSm/Smo         CopL

The famous Alien Breed 3D Demo is finally there. What do i have to say ?
It is a full Doom engine based on chunky copper. The demo is non playable,
but it seems to me, the game is nearly finished. I think the full game
should show up in 2 months or something like that. The demo does not
run on A4000 properly up to now, but it is said they will fix that
before the release. The graphics resolution is low, but as to nearly
finished games, it is probably the nearest to DOOM available on the
Amiga up to now. I think it will sell fine. :)))


Dogenstien3D  J.D.Doig (P)    AGA                AGA                    
Low/Wolf      VSmo            Low

Texturemapping engine where you can see the gun while walking around. As 
to the graphics, most other engines are better. I don't think this one is 
still around. The first version was called Dog3D.

Author : (it seems, that this is no longer valid)
File   : /pub/aminet/gfx/misc (if it is still there ...)
A1200  : Smoothness VSm


3D-Demo       J.Corigliano(P) 020+2MB+OS2.0      030+2MB+OS2.0
Low/Wolf      Smo/VSmo        Low

The first try of a completely OS-friendly texturemapping engine. Does
9 fps on my A4000/040. As to the Smoothness i HAD to say VSmo, but the
movement is very slow and you can see a bit of the screen refresh when
you turn around. But if this is the first try (the file is not very big),
maybe later versions will get much better. The main problem of the engine
probably is the speed... maybe an updated graphics would enhance it
too... up to now it does not have floor or ceiling textures and the 
other "serious" engines are better... but remember, that is not a
public available demo version, but a frist executable...

Author :
File   : Not yet publicly available ...
Frame  : 9 fps


Wolf23_ish    Chris Colman(P) AGA                AGA                    
Low           VSmo            Low

A "first try" texturemapping demo. In the Readme the author writes he will 
make this one better. It is NO copper chunky. But "as is" it is not very 
good. An older version was wolf2.lha. Maybe another demo i found 
somewhere (but lost the readme...) is an older or newer version of this
demo (it is quite similar). It is called wolf10. But maybe it is only a 
similar demo from another author.

Author :
File   : /pub/aminet/gfx/misc/wolf3.lha 
         (wolf10 is /pub/aminet/gfx/misc/wolf.lha)


Wolf3D        T. Russell (P)  All                All                    
Low           NSm             Low

Another "first try" demo. I do not know anything about what got with it 
after this release.

Author :
File   : /pub/aminet/dev/src/Wolf3D-2.lha (with source)


Rot3D         J. Freund (PO)  FPU+1.5 MB         FPU+1.5 MB             
Wolf          VSmo            Med/High

One of the first, if not THE first texturemapping engine on Amiga 
(now in its latest version). The wood textures of the demo look quite 
well, as do the stone textures, but there are no floor or ceiling 
textures and POOM, TextDemo5 and Warp_S are better. If no one picks this 
one up, it will die. The authors said they would help a potential 
"up-picker". It now seems it is dead.

Author :
File   : /pub/aminet/demo/euro/rot3d.lha


3. Games


TrickOrTreat  D. Stuart (P)   All                All                    
Wolf          Smo             Low

Little texturemapping game, where two players try to shoot each other. The 
graphics is not the best and there is no floor or ceiling texture, but it 
is the first texture mapping action game on Amiga (yes, it is this one, NOT
Fears !!!) Even if the graphics is not comparable to Wolfenstein, the game 
is a lot of FUN. The author wrote he was looking for some work in coding 
the Amiga.

Author : ???
File   : Amiga User International 11/94 (Coverdisk 45)
         Or : Duncan Stuart,10, Bramble Close, The Beeches, Uppingham, 
         Rutland, LE15 9PH


Fears         BOMB (G)        AGA                AGA                    
Low/Wolf      VSmo            Low/Med

This is a Wolfenstein clone for Amiga. The walls are better than nothing, 
the floor textures nearly nothing, the monsters do slide instead of walk, 
but it is a COMPLETE GAME. It is shareware. There is even sound while 
playing. And it is really FAST.

Author : Gengis/Bomb
File   : /pub/aminet/games/demo/fears.lha
A1200  : Smoothness Smo/NSm


Ambermoon     Thalion (SF)    All                030                    
:)            VSmo            Med

Ambermoon (do i have to explain this ?) is probably the best fantasy RPG on 
Amiga. Using a cool texturemapping routine. Okay, the monsters of Ultima 
Underworld on PC are better, but what do you want? This one is LoRes, 32 
colors !!! One minute of silence for Thalion... may they rest in peace... 
OR be back and do something like that in AGA ??? :))) But sure, that won't 
happen... and the programmers for Ambermoon are now at Blue Byte, doing 
Ambermoon's sequel Albion for PC only... BLUE BYTE SUXXXXXXXXXXXXXXX!!! 
Ambermoon is a commercial game.


Legend of valour ???          All                ???                    
Wolf(???)        ???          Low (???)

Legend of Valour is a texturemapping fantasy RPG on Amiga. It is a 
commercial game. I do not own it and only saw it once, so i can't say much 
about this one. But it is not such BIG stuff like Ambermoon.

A1200 : Smoothness NSm (on the biggest screen)


A last remark for this chapter : The game DeathMask is no real 
texturemapping. It is a block graphics game which scrolls around while you 
turn 90 degrees. Better play Hired Guns ...


4. Sources

There are some demos available with sources. Additional you can find
the sources of Chunky2Planar routines on Aminet. My comments to these
will be rather short, as i am not familiar in coding texturemapping.
If you have comments to some of these sources, mail me ...
The format of the short reviews of the sources of course is different
to that of the demo reviews. I will download these sources too and
look them through. Maybe then there is something more i could say
about them.


c2p4.lha          /pub/aminet/dev/src     31KB

Very fast c2p converter using cpu+blitter for the conversion. Needs
68020 at least.


chnky2plnr.lha    /pub/aminet/dev/src     14KB

Various fast c2p conversion algorithms.


fastc2p.lha       /pub/aminet/dev/src     25KB

Two fast c2p converters.


chunky.lha        /pub/aminet/dev/src     54KB

Example of how to create a chunky copper display.


rot3dsrc.lha      /pub/aminet/dev/src    184KB

Complete source of the above reviewed Rot3D texturemapping demo.


wolf3d-2.lha        /pub/aminet/dev/src   56KB

Above reviewed texturemapping demo including source.


tmapdemo.lha        /pub/aminet/gfx/aga  131KB

Above reviewed texturemapping demo including source.


flick-14.lha        /pub/aminet/gfx/show 71KB

FLI/FLC viewer with source including a c2p routine.


III. Rumours and other infos department

1. Maybe DSA 2 (a texturemapping RPG with a really cool engine already 
   released on PC) will come to the Amiga, maybe not. I heard rumours about 
   a spring release (and my software dealer said there would be a good 
   chance for this one to be ported). I do not know if it is AGA, but i 
   think, if they do it, it will be AGA ...
2. There are rumours about ACID Software doing a clone.
3. Some guy on the net wrote there would be a clone from some polnish scene
   member. He could not remember the name, though, and i do not know, if 
   this guy is reliable.
4. According to Amiga Report 233, AGE Entertainment is working at a
   scrolling dungeon game. The game should come out as "Paranoia" and the 
   project began quite a time ago. According to the article in the 
   meanwhile the programmers think of the Amiga as a dead platform (the 
   programmers of Paranoia, not AGE Entertainment !!!), and even if they 
   wanted to finish the ECS version of the game, they wouldn't do the AGA 
   version and the CD 32 version that were planned at the beginning. Nor 
   would they do the planned sequels to the game.
5. Some time ago a group looked for coders for porting the game BOOM that
   they were doing for the Atari Falcon to the PC and Amiga. I do not know, 
   if they found any Amiga programmers for doing the port. The game should 
   be in three parts, and one of the three parts would be a DOOM style 
   action game. I heard, it would be near finished (or finished...) for 
   PC ... (EMail :
6. In the latest add from my software dealer there were announced some
   games for Amiga AND PC that use texture mapping. These games are Body 
   Count, The castle of Dr. Radiak and the sequel of Elder Scrolls, 
   Daggerfall. I do not know, if this is an error or what (as i never 
   heard anything about it before ... and usually such things do not go 
   unnoticed...) And some of these releases were marked as CD and there 
   was NOTHING written about CD 32 ... this looks strange... but maybe at 
   least ONE is TRUE (if so, i hope it is Daggerfall :))) ).
7. It is said Renegade is doing a Wolf/DOOM clone.

IV. Doing Texturemapping with Emulators

1. Hardware-Emulators

Hardware-Emulators, that is ... putting INTEL-PROCESSORS in your poor 
little Amiga. You want to do THIS ? Oh, than you are running PC games, 
not Amiga ones... therefore i do not write ANYTHING about it in my FAQ. 
Because this is nearly no emulation anymore... it is ... gaming on PC ... 
there are quite well emulators of this style called "GoldenGate".

2. Software-Emulators

There are some software PC emulators, but for games like DOOM they are not 
useful. They are slow and only emulate a 8088 or 80286. DOOM needs a 
80386 AT LEAST to run. Maybe on PC Task 3.0 Wolfenstein will run. But the 
speed (espescially the speed of the graphics) surely is a problem. Maybe 
with a graphics board, but probably even this is too slow. So ... wait for 
PC Emplant's CPU transcription mode (this one will not be included in the 
first version of the emulation software, it will come as a free update 
later ...)

Second ... Mac emulation with software... there are two emulators... 
AMaxIV and Emplant... as i heard AMaxIV does not run on AGA ... and it uses 
tricks to be able running with a 128KB ROM ... i doubt games running on 
this one, but maybe i am wrong...

On Emplant (which i own myself) i tested four texturemapping games for Mac:
The demoversions of these games (which i tried...) are on
in /pub/mac/info-mac/game/com. You will need StuffItExpander to decrunch 

Wolfenstein : Runs on my A4000/040 with reasonable speed (even if i do not 
use the graphics board ... with PAL Hires AGA ...), but only with the 
smallest screen. Not very well coded, as it is not very smooth on the 
graphics board either... (okay, with 320x256 it is something near 
smooth ...)

Sensory Overload : Wolfenstein Clone, but i do not like the graphics... 
okay, the screen is bigger than most of these demos for Amiga... but the 
graphics is not much better... i think worse... Sensory Overload does not 
run well without a graphics board.

Pathways into Darkness : Wolfenstein clone from Bungie (, 
i think the graphics is better than Wolfenstein, but Wolfenstein has a 
background music and PID don't ... it is slow, but in LoRes playable 
without graphics board... not much faster with graphics board, though ...

Marathon : The absolute Mega-Game ... rating, if we do it as with the Amiga 
demos above : BEY !!! (Yes, this one is MUCH better than DOOM ...) If you 
are doing EVERYTHING to play DOOM on Amiga, take this one, take the 
smallest screen size, no music, select that the game only displays every 
second line... and run it on at least a 4000/030. But do not show it to 
your PC friends, they will LAUGH at you, if you do not own a graphics 
board... (i did, before i got mine :((( ) On a graphics board, Marathon is 
FANTASTIC, better speed than Amiga graphics demos, maybe even better than 
DOOM on PC (remember, Marathon is 640x480 ...) I use a resolution of 
probably 400x300 in Lores, and it is absolute smooth on the SD 64 ... 
Marathon is the sequel to Pathways into Darkness.

One Last : It is rumoured, at 15th April, DOOM II will be released for 
Mac... 68040 and PowerMac, to be exact...

V. Algorithms

In this chapter i will put algorithms or coding hints sent to me.
Please do not send code (this would be MUCH to specific for this

1. Terence Russells algorithms used in Wolf3D-2.lha

Basic structures and algorithms used to create the Amiga Wolf3D demo.

The techniques I have used do not involve ray-casting for the rendering
or BSP trees for hidden object removal. Instead my style of rendering
has more in common with flat-shaded polygon rendering used in many
older demos.

Sorry for the crappy organization. I'm a fourth year computer science
student and I haven't much time to do this properly.

The Maze and basic objects:

The maze is essentially two dimensional and if looked at from above it
would appear to be a grid whose squares are outlined with walls or are
bisected with doors.

Each square from above is 64 x 64 pixels in dimension. I use pixels as a
unit of measurement since in fact each point is represented by a pixel
column in a bitmap.

The use of the grid analogy is purely conceptual, however, since using a
grid structure would create some complications (which are described under
'collision detection' and 'door movement'). For purposes of discussion I
will refer to the X and Y axis' as being the east-west and north-south
axis' (respectively) of the grid from an above view. The Z axis will
refer to the axis that comes up out of the grid. (This runs contrary to
how I actually programmed the demo as the Y and Z axis are swapped).

Walls and doors are represented by the same basic unit: the block.
A 'block' is from a structural standpoint the canvas onto which wall and
door imagery is 'painted' or 'mapped'. Every wall and every door in
the maze is associated with a block. In fact a block may consist of
up to 4 walls that represent the 'north', 'west', 'south', and 'east'
faces of the block.

 From a programming view a block consists of 256 points plus a center
point. The center point positions the block relative to the bottom-left
corner (0,0,0) of the maze. The remaining 256 are divided into 4 groups
of 64 points, each of which are associated with a particular block face.
All 256 points are relative to the block's center point. (Hence,
only one set of these points need be maintained for all blocks within a
maze). As can be imagined the end-points for each face overlap.

The walls points are given the following offset ranges:

SOUTH: (-32,-32,0) to (31,-32,0)
NORTH: (31,31,0) to (-32,31,0)
EAST: (31,-32,0) to (31,31,0)
WEST: (-32,31,0) to (-32,-32,0)

Notice that for each face the ranges are given in an order which implies
counter-clockwise as viewed from above the grid. This is important for
properly rendering the wall graphics and for backface culling, that is,
removing walls that are facing away from the observer/player.

Each wall/door has an associated 64 x 64 pixel bitmap.  Each 1 pixel wide
column of the bitmap is represented by one of the points found along the
wall/block face. Hence point 0 of the south wall of a block may represent
the 0th column of a 'stone wall' bitmap. From the programmer's view I use
the wall point's ordinal value (it's relative position) to offset/index
into the bitmap image.

Previously I mentioned that blocks are used for BOTH walls and doors.
The attentive reader may have noticed that the offsets for the walls
would create doors that are not located in the center of a block. Since
my aim was to create a near Id wolf-clone I had to specify extra offsets
just for the doors. These new offsets simply have either the X or Y
component zeroed depending on which direction the door is to lie along.
This allows the doors to appear in the center of a block. This also makes
it easy to have sliding doors since all I really need to do is move the
associated block's center point in the direction the door opens. The door
then slides 'into' an adjacent wall block which takes care of hiding the
door. (This is explained later in the next section).

RENDERING - this is just a quick and dirty algorithm

Translate the block centers by an amount equal to the players relative
maze position. Now rotate these centers using the players attitude or
angle of direction, also relative to the 0,0,0 point of the maze.

Next rotate the 256 wall points using the same players direction angle.
For each block center, translate a copy of the 256 wall points to the
block center such that the block center is in the middle of the points.

Now that we have a list of block points that are relative to the player's
position we want to render the blocks. To determine what blocks are
visible I simply sort them by there Y value, (which is now relative to
the player's position). I used this method since at the time I did not
know of the BSP tree method for determining visible polygons.

Once we have a list of sorted blocks, we can immediately discard the
blocks that fall behind the viewer. From this point we render each block
until the player's view is completely filled with graphics.

Since I don't want to draw all of the blocks that are in front of the user,
(just the ones that fill up the view), I use a pre-render loop which
determines what portions of walls/doors are visible. 

To determine what is visible I use the sorted list of blocks and an array
called the xBuffer. This buffer is one dimensional and has an entry for
every vertical column of the user's game display.

The algorithm involves a lot of simple parts that when put together create
a fairly complex program. Hence I will attempt explain it using two similar


I use the following algorithm:

clear the xBuffer

while xBuffer is not full do
    get the block closest to the player

    for each face of the current block do
        if current face is invisible then
            skip face
        else "current face is visible"

            for each of the current face's 64 points do
                perform a perspective calculation on the point to
                  get a screen X1,Y1 point.

                duplicate X1 into X2
                mirror Y1 across the center of the display to get Y2

                the line (X1,Y1)-(X2,Y2) forms a column of screen points
                  onto which a column slice of the wall/door bitmap will
                  be mapped/scaled.

                if X1 lies with in the range of the xBuffer
                   (usually 0-319 for a full screen) then
                    check xBuffer[X1].height to see if a column
                    hasn't already been written there.

                    IF height of current line > xBuffer[X1].height THEN
                        xBuffer[X1] = current column and it's associated
                                      bitmap imagery.
                        discard this column as being invisible.

                    "If all I did was insert just the columns into the
                        xBuffer there would be gaps in-between the columns
                        do to the perspective transformation, hence
                        I need a little loop that makes a copy of the
                        current column back to the previous column of the
                        same wall."


For example suppose my maze viewing area is 320 pixels across the screen.
Then the xBuffer has 320 elements. Each element is a structure that
records: the half-height of the wall/door from the horizon or the equator
of the viewing area; the bitmap identifier; the pixel column offset into
the bitmap

Now using the xBuffer I have a routine take each element and read a column
of pixels from a bitmap and then stretch and clip the bitmap into the
hidden rendering buffer.


while not done do
    check closest wall/door's extents
    (i.e. the starting and ending X locations as project on the view)

    if the extents are outside the viewing area then
        discard the wall/door
        for each of the 64 points/columns of the wall/door
            determine where the column is relative to the view area
            if the column lies in the view area then
                check the corresponding xBuffer element to see if
                   something hasn't already been written there
                if empty then
                        write the columns height and bitmap column offset
                           and bitmap identifier to the xBuffer.
                    if current column's height is greater then
                        write it
                        this part of the wall lies behind some other wall

Starting with the closest block I check each face to determine if it is
visible. Since the faces of the blocks are at angles of 90 and 180 degrees
from each other, at most 2 faces will be visible at any one time.

Once I determine a visible face I use the associated 64 points for that
face to determine visible columns. To each point I add to the Z component
an amount equal to have the height of a wall. Then I run the point
through a simple perspective calculation and I now have a somewhat correct
position for projecting the point onto the player's view.

I next create a duplicate of the point and mirror it across the middle
of the player's view. This gives me two points that represent a line or
column of the wall's bitmap. Since each point of a face is uniquely
associated with a column of pixels in a wall bitmap I can perform some
sort of 'texture' mapping now. Only one thing remains, and that is to
determine the next columns position. Since as you get closer to a wall
the 64 points will be spread out over a greater viewing area, gaps will
start to appear between the columns. These gaps are eliminated by copying
a column up to the next column.

Collision Detection:

Some authors have suggested using a static grid to perform collision
detection with walls. Generally this works very nicely, however, in the
case of Id's Wolf3D there is a slight problem. Id's game supports moving
walls (in other words the secret passage-ways). To perform collision
detection on these moving walls while using the static grid meant that
I would need to either create special case for checking when a wall was
moving, or would have to create a special kind of block: i.e. a moving
wall block. At the time I decided this was unsatisfactory so instead of
using a grid I decided to use the block's center point and a bounding box
around the player. Using this method, collision detection involves
checking each block center to see if it lies within the players bounding
box. This allows me to move blocks at will without worrying about special
cases and is generally pretty quick.

There are many more points to the algorithms I have used, and if you
are interested in understanding them and want to learn a maze rendering
technique that does not involves ray-casting then send some email.

Terence Russell

VI. The Amiga Texturemapping online conference

[This information is dated.  More recent information will be printed when
it is available. -Jason]

1. The invitation

At 7th February (Tuesday) at 22.00 MESZ (16.00 EST or 15.00 Central US 
Daylight Saving Time) there will be a online conference on IRC about Amiga 
Texturemapping. The conference will be on a channel name #amitmap.

Everyone who is interested in Amiga Texturemapping is invited. The talk 
will be about the future of Amiga Texturemapping and as some programmers 
already announced they would be there probably some coding themes. Maybe 
there will be the possibility to find more people for an own project.

2. Some hints for people who do not use IRC often

IRC is the online chat system of the internet. Try out the command irc on 
your site. If this does not work, contact your system administrator and try 
to convince him to install an irc server :))).

As you entered irc, you specify your nick name (the name under which you 
will be known), with /nick Nick-Name. An alternative is starting irc with 
irc Nick-Name. To enter a channel (a channel is a place for people 
discussing a specific theme to meet), you type /join channelname. 
Each channelname starts with a #.

To send someone a private message (that other can't read) you type /msg 
Nick-Name "...", where Nick-Name is the Nick-Name of the user, to whom you 
will send the message. To send a message to all users in this channel, 
simply type what you want to say. Usually you should write it in the 
following way : Name of the user for whom this message is
primarily : Text.

/who * lists all users currently on this channel.

/list * counts the users on this channel.

With /quit you quit irc.

That are only the basics for irc, but with that knowledge you can be with 
us at the conference :))). Irc also has a help-system installed, 
by the way.

VII. What can YOU do to support this FAQ ?

1. Support Amiga
2. Write texturemapping demos/games on Amiga :)))
3. Buy Amiga texturemapping games, if they come to a release
4. If you know of any texturemapping game/demo not mentioned in this FAQ
   (dungeon-related, no texturemapped cubes and spheres),
   or if you have information relevant for me, mail to
   - call Germany 07021/861920 or 862428 or 862429 (Birdland BBS, 
     i am Magic SN on this BBS ...)
   - Phone Germany 07021/51787 and ask for Steffen
   - go in irc and look for MagicSN (that's me :))) )
   - write a letter to Steffen P. Haeuser, Limburgstr.127,
     73265 Dettingen/Teck,Germany
   - Do whatever you want ... :)

5. Do the same, if you want to send me critics or beta-releases of demos
   to test them :)))))))))))))))) (at least i tried it... maybe someone 
   would be in FACT that nice :))) )
   My internet-account is able to handle BIG UUEncoded mail... :))))))))
6. Spread this FAQ on all nets and BBS's.
7. If you are a coder, and you have a lack of time to code, or you have
   a serious problem in coding texture mapping, maybe you find some
   interesting EMail-Adresses all over this FAQ ...
8. Send me texturemapping algorithms you see no need anymore in
   keeping them private (for this new chapter V)

That's it... as soon, as i hear news about some of the mentioned demos 
(or of some new ones ...) i will do a later version of this FAQ. It will be 
found in at least... maybe soon there will be a later 
version of Warp_S or POOM or TextDemo or DentAWolf or... or ...


     Steffen Haeuser
     OR MagicSN (in irc)
     OR (E-Mail, talk ...)