Amiga Texturemapping demos/games FAQ V0.1
Steffen P. Haeuser
correct that before the next version of the FAQ ...
Amiga Texturemapped Games FAQ V 0.1
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 known to me
1. Demos
2. Game-Demos
3. Games
III. Rumours and other infos department
IV. Doing texturemapping with emulators
1. Hardware-Emulators
2. Software-Emulators
V. The Amiga Texturemapping online conference
1. The invitation
2. Some hints for people who do not use IRC often
VI. 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 engines.
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.
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 e 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 pixel resolution 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...)
Thent 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
Smoothness
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,
does not say anything, if the resolution is good or bad, read the description
Low = Low resolution
Med = Medium resolution
High = High resolution
Coded by
(P)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 suxx...
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...
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 ...
*****************************************************************************************************
Name Author Min. System Recommended System Engine Smooth Resolution
***************************************************************and all. Bravo, Bomb !!!
You should do a game out of this :))) This demo did not run on my A4000/040.
With luck, i had the possibility to test this demo on a A1200 with '030 50 MHz (but no Fast RAM... this
system was not much faster than a '020-1200, because it had only chip RAM...) Sod. Talking about resolutions, there are copper chunky demos with better resolution.
Author : Th**************
Fullmoon Fairlight (G) AGA AGA n common) okay.
Author : Tea...@SterrBBS.nl (or was it Tea...@SterBBS.nl ???)
File : ???
*************************************************************************** but the
next Demo out will (according to the beta i saw) be much better.
They got a new graphician, who is aybe 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 boaWAD-interpreter BSP has
no ceiling or floor, but many featureommodore crash ...)
File to the mail information he gave me, he and the others formed now a
software company w*********************************************************************************
ChunkyMaze David Bryson (P) AGA AGA Wolf f ChunkyMaze, but i do not have the docs.
Author : ce...@cee.hw.ac.uk
File : /pub/aminet/gfx/aga/maze.lha
*****************************************************************************************************
TextDemo5 John Hendrikx(P) (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 ahis account is no longer valid ...)
File : /pub/aminet/gfx/misc/wolf3.lha
(wolf10 is /pub/aminet/gfx/misc/wolf.lha)
****************************************************************************************tter. If no one picks this one up,
it will die. The authors said they would help a potential "up-picker".
Author : fre...@cis.uab.edu
File : ??? (Source also available on Aminet)
*****************************************************************************************************
DWAGA : A nice little dungeon, i HAD this one once, i THINK it was texturemapping, but not sure.
I don't think the project is still alive. It is AGA, and (if i remember right)
the source was iner International 11/94 (Coverdisk 45)
Or : Duncan Stuart,10, Bramble Close, The Beeches, Uppingham, Rutland, LE15 9PH
*****************************************************************************************************
Fears BOMB (G) AGA AGA Low/Wolf 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.
*****************************************************************************************************
A last remark for this chapter : The game DeathMask is no real texturemapping. It is
a block graphics gam They even said something about cool
water effects in the game. Since December they said they will release
a demo soon... but as far as now, this demo is not released.
3. Simaleth/Pearl told me the best DOOM-Clone-in-progress soon would be
TextDemo6 (Simaleth will probably do some maps for it, an and the CD 32 version that were planned at the beginning. Nor would
they do the planned sequels to the game.
8. 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 fo) ).
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
iwo 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 ftp.hawaii.edu
in /pub/mac/info-mac/game/com. You will need StuffItExpander to decrunch them.
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 ve 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. The Amiga Texturemapping online conference
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 tly 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.
VI. 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
- hae...@minnie.informatik.uni-stuttgart.de
OR
- call Germany 07021/861920 or 862428 or 862429 (Birdland BBS, i am Magic SN on this BBS ...)
OR
- Phone Germany 07021/51787 and ask for Steffen
OR
- go in irc and look for MagicSN (that's me :))) )
OR
- write a letter to Steffen P. Haeuser, Limburgstr.127,73265 Dettingen/Teck,Germany
OR
- 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 ...
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
comp.sys.amiga.games at least... maybe soon there will be a later version of
Warp_S or POOM or TextDemo or DentAWolf or... or ...
ciao,
Steffen Haeuser
OR MagicSN (in irc)
OR hae...@tick.informatik.uni-stuttgart.de (E-Mail, talk ...)
_____________________________________________________________________
Steffen Haeuser
--
Steffen Haeuser - hae...@minnie.informatik.uni-stuttgart.de
Call Germany 07021/861920,862428,862429 BiRDLAND BBS (User Magic SN)
Peter McGavin
>TextDemo5 John Hendrikx(P) (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 ahis account is no longer valid ...)
>File : /pub/aminet/gfx/misc/wolf3.lha
> (wolf10 is /pub/aminet/gfx/misc/wolf.lha)
I think there is a slight mix-up here, wolf3 is not TextDemo5.
TextDemo5 supports high resolution, does not require AGA (as far as I
remember) and it is available on Aminet as gfx/misc/TextDemo5.lha.
In the FAQ it would be nice to have a list of the advantages and
disadvantages of copper chunky versus chunky to planar (c2p)
algorithms, things like:
Copper chunky uses a long, custom copperlist to build a low-resolution
chunky display. Colours are changed by poking directly into the
copperlist. A single poke changes the colour of one (large) pixel.
On the other hand, c2p uses a (not displayed) chunky buffer, which may
be in fastmem, and an ordinary planar display. The image is rendered
to the chunky buffer, then (or simultaneously) the buffer is read back
and converted to planar by rotating bits and writing to the planar
display. There are lots of slow c2p routines out there, and some fast
ones too that can compete comfortably with copper chunky for speed.
Copper chunky requires AGA (unless you very severely limit the
resolution). On the other hand, c2p algorithms can use any number of
bitplanes from 1 to 8, therefore they work with ECS and OCS. Indeed,
reducing the number of bitplanes increases the c2p speed, but reduces
the number of colours.
Copper chunky (usually) provides 4096 colours. C2p algorithms are
(usually) limited to 256 colours.
Full copper chunky screens have limited resolution (about 100x100
large pixels). C2p algorithms have no such limitation.
It is not possible to program AGA copper chunky screens within
Commodore's rules and guidelines. It follows that programs using
(only) copper chunky do not work with mode-promotion, do not work with
high-end non-15kHz monitors, do not work with 3rd-party graphics
cards, are unfriendly to intuition and multitasking, and will not work
on future amiga models (if there ever are any). Programs using c2p
algorithms do not suffer any of these limitations.
Here is a list of some texture-mapping and c2p related Aminet archives
(in no particular order) that it could be useful to mention:
For coders and developers:
c2p4.lha dev/src 31K+v.fast c2p converter (cpu+blitter) 020+
chnky2plnr.lha dev/src 14K various fast chunky2planar conversion algo
fastc2p.lha dev/src 25K+two _fast_ chunky2planar converters
chunky.lha dev/src 54K+Example of how to use chunky AGA copper di
rot3dsrc.lha dev/src 184K+Complete Aztec source to rot3d.lha demo
wolf3d.lha dev/misc 50K+My Wolf3D
wolf3d-2.lha dev/src 56K+Wolf3D clone demo
tmapdemo.lha gfx/aga 133K*AGA Texture-mapping demo by Chris Green, w
flick-1.4.lha gfx/show 71K+OCS/ECS/AGA/EGS FLI/FLC-format anim viewer
For the rest:
TextDemo5.lha gfx/misc 200K+3D Dungeon with shading AGA/ECS (68020+)
Pearl.Doomed.lha demo/euro 348K+New PEARL demo,full scr. wolf on A500!
poom_02.lha gfx/aga 481K+A Doom! style engine with ceiling and floo
bsp1.0.lha gfx/misc 65K+Doom.wad walkthrough demo (ECS | AGA)
dentwolf.lha demo/aga 183K+AGA Wolfenstein Demo for future game
wolf.lha gfx/misc 8K+First attempt at a wolfenstein clone
wolf3.lha gfx/misc 24K+Upgrade to wolfenstein type proggie
fears.lha game/demo 223K+Demo of a Wolfenstein3D-like game !
walls.lha game/demo 26K+FAST interactive (wolf-type) 3D-labyrinth
rotdemo.lha gfx/3d 43K*Wolfenstein3d like demo
rot3d.lha demo/euro 96K+Texture mapping demo, requires math FPU
maze.lha gfx/aga 22K+v1.02 Wolf3D demo (020+ AGA) A4000 fixed
MotionDisk1.dms demo/par94 801K+Motion demo by Bomb - position 3 in the De
MotionDisk2.dms demo/par94 383K+Motion demo by Bomb - position 3 in the De
tapavi12.lha gfx/show 14K+AVI player for AGA/020+/KS2.0
Flip_166.lha gfx/show 22K+Fastest player for FLI/FLC animations. AGA
Harlequin.lzh demo/euro 85K+The definitive texture mapping gfx demo.
warp_s.lha gfx/misc 180K+Texture mapping demo - texmapp 2
I'm sure there are more that I missed. Morten Erikson(sp?)
(mor...@idt.unit.no) posted an OS-friendly replacement for
WritePixelArray8() to alt.sources.amiga. (Where is it now?) There is
an EGS version of tmapdemo on orion.etsu.edu. Lots of Party93 and
Party94 demos include texture-mapping sequences. There are many more
files on Aminet for mucking around with textures.
There is no single, fastest c2p algorithm. There are too many variables,
like:
cpu type and speed
the number of bitplanes
whether fastmem is available
whether the whole display changes with every frame
how many blitter passes are possible while the CPU is tmapping
whether an ECS blitter is available for long blits
whether a "scrambled" chunky buffer is acceptable
how nasty you can be to the OS
whether Akiko is available
how compatible you want to be with 3rd-party gfx cards
etc...
To anyone contemplating writing a c2p routine, I would strongly
suggest that you check out the c2p source code examples on Aminet
first (especially the ones in chnky2plnr.lha, c2p4.lha, fastc2p.lha
and flick-1.4.lha). The Aminet ones are pretty hard to beat from
scratch, but can be improved for specific situations (e.g, skip the
first pass or two and use a scrambled chunky buffer, and/or adjust the
number of async blitter passes to match the chunky rendering time,
and/or use a comparison buffer and update only the parts that
changed). Also, if you want your program to work with 3rd-party gfx
cards then you had better include an option to call WritePixelArray8()
or WriteChunkyPixels() instead of your own routine for the c2p.
Some coders claim that the fastest way to texture map on an Amiga is
to texture map directly to planes, with no c2p or chunky buffer
required. Personally I have not seen hard evidence of this (except
with a small number of bitplanes) and I still think the best way is to
have a full chunky buffer in fastmem. That makes it easier to support
non-planar displays (with WritePixelArray8()) too.
A discussion of raycasting and BSP-trees would be useful in the FAQ
too, along with pointers to where information on these topics can be
found. I don't really know enough about those topics to write about
them myself --- except to mention that just about all amiga
texture-mapping demos so far are based on raycasting, and that
BSP-trees (that DOOM purportedly uses) supposedly are much faster.
--
Peter McGavin. (pet...@maths.grace.cri.nz)
Michael A. Krehan
Quoting the FAQ:
> ***********************************************************************
> Name Author Min. System Recommended System Engine Smooth Res
>
> TextDemo5 John Hendrikx AGA AGA Low/Wolf VSmo Low
Mistake #1: AGA is *NOT* required for TextDemo, but utilized. The old
TextDemo5 consists of three files, Textdemo5-OCS (for systems w/ 512K of
chip mem), -ECS (1MB Chip and up), -AGA (AGA systems only!). (The new
version automatically detects the present system and switches to the
corresponding mode).
The engine is not a Wolfenstein but a Doom-like engine. "Worse than
Wolfenstein" is NOT quite right here: It is BEYOND DOOM as it features
things not even Doom has: For example light sources. The walls are very
non-orthogonal, the newest version now has a floor texture w/ different
floor heights.
> Texturemapping engine where you can see the gun while walking around.
This is not true. There is no gun to be seen right now, and will never be,
because the full game will be set in a Dugeon Master-like scene. Is it
TextDemo you're talking about??
> As to the graphics, most other engines are better.
Nope. The newest version (not out yet) has 24bit graphics (mostly
rendered) that will be rendered for your system (AGA or ECS).
> I don't think this one is still ahis account is no longer valid ...)
Although I didn't quite get this sentence (what means "ahis" ?), John has
changed his server. His new address is:
(I hope I didn't mix anything up - the FAQ was *VERY* strange, I think
there are several passages missing. Maybe I somehow slipped into the next
demo already - but from what it looks everything I quoted was related to
TextDemo).
Now when looking at the FAQ, I see there are MANY passages missing.
Steffen, neat FAQ, but please DO SOMETHING ABOUT THE FORMAT! It is
terrible and a pain to read. And try to find out why there are many parts
just missing. (Just look at the last quoted sentence - there seems to be
one of those breaks between "still a" and "his account".
I was tempted to delete this post as I discovered that the mix-up mentioned
above was due to the FAQ "failure", but then decided to post it anyway in
order to a) warn other people that the FAQ is not quite correct about some
points :) and b) the facts about the new TextDemo mentioned above might be
rather interesting for some people anyway.
--
Michael A. Krehan (mi...@elite.rhein-main.de) - TextDemo dev
"The German who wants to be American"
DISCLAIMER: All of the opinions expressed above are my own, however I am
strongly influenced by other people's opinions.
Alas, I am dying beyond my means.
-- Oscar Wilde, as he sipped champagne on his deathbed
Morten Eriksen
(Peter McGavin) writes:
|>
|> I'm sure there are more that I missed. Morten Erikson(sp?)
|> (mor...@idt.unit.no) posted an OS-friendly replacement for
|> WritePixelArray8() to alt.sources.amiga. (Where is it now?) There is
The name's Morten Eriksen, and my email address is mor...@idt.unit.no.
The sources can be found at the Amiga sources archives at ftp.funet.fi.
Regards,
Morten
Jyrki Saarinen
> Some coders claim that the fastest way to texture map on an Amiga is
> to texture map directly to planes, with no c2p or chunky buffer
> required. Personally I have not seen hard evidence of this (except
> with a small number of bitplanes) and I still think the best way is to
> have a full chunky buffer in fastmem. That makes it easier to support
Yep - when texturemapping 16 colors, it is 2x faster than chunky.
256 color mapping can be achieved, too. Little slower, not much.
With smart techniques, the lack of chunky mode is not a problem
anymore.. I used to think so before.. Not anymore.
I have done this.. Gouraud shading is very fast directly to planes.
> them myself --- except to mention that just about all amiga
> texture-mapping demos so far are based on raycasting, and that
> BSP-trees (that DOOM purportedly uses) supposedly are much faster.
Nope, Mindflow uses a BSP tree in its "DOOM" effect.
> --
> Peter McGavin. (pet...@maths.grace.cri.nz)
--
Jyrki Saarinen - Nose / Stellar - A4000/Warp - jsaa...@kone.fipnet.fi
Maxwell Daymon
: >On Amiga, the color of each pixel is described
: >by EIGHT BYTES (for 256 colors). This is the so-called BITPLANE GRAPHICS.
: 8 bytes per -pixel-? As in 64 bits? Are you sure? :)
: Sounds like more than 256 colours to me..
The Amiga stores each bitplane one after the other in memory. Each byte
refers to eight pixels *across* in any given bitplane.
Except in 256 color mode (where they are equal), planar modes use less
memory if you use less colors, chunky (packed pixel) modes will always
use a multiple of the smallest machine readable segment (in this case,
bytes).
The Amiga can also open screens in an interleaved form where each line of
each bitplane is stored.
In chunky mode, each byte refers to a SINGLE pixel and there's only one
"byteplane" of space. If you open a 64 or 128 color screen in chunky
mode, you "waste" 2 or 1 bits of memory per pixel (respectivly).
If you want to change ONE pixel on a 256 color Amiga planar screen, yes,
you have to read and write 8 BYTES. Not because the pixel takes up the
whole eight bytes, but because each byte of each bitplane contains
information about at eight pixels whether you want it or not.
Now, if you were to read and write EIGHT pixels at a time in 64 or 128
color mode, it would actually be less reads/write than chunky mode. If
you wanted to calculate eight pixels at a time, you'd be even with reads
and writes - but not speed.
------------------
Maxwell Daymon
mda...@rmii.com
------------------
MARC EDWARD FORRESTER
>by EIGHT BYTES (for 256 colors). This is the so-called BITPLANE GRAPHICS.
8 bytes per -pixel-? As in 64 bits? Are you sure? :)
Jyrki Saarinen
> Now, if you were to read and write EIGHT pixels at a time in 64 or 128
> color mode, it would actually be less reads/write than chunky mode. If
> you wanted to calculate eight pixels at a time, you'd be even with reads
> and writes - but not speed.
Gouraud shading can be done to planes faster than chunky if using
<256 colors.
> ------------------
> Maxwell Daymon
> mda...@rmii.com
> ------------------
--
Tim Wendt
>
>In the FAQ it would be nice to have a list of the advantages and
>disadvantages of copper chunky versus chunky to planar (c2p)
>algorithms, things like:
I totally agree!
I appreciate the first attempt at the texture mapping FAQ, however I would like
to see one oriented towards coders such as Peter McGavin describes below. As a
matter of fact, the info in your suggestions was a nice little FAQ in and of
itself! A programmer- oriented TM FAQ would be a great place to start for
ambitious coders who would appreciate a good resource for learning the basics.
I would like to see specific, detailed coding examples or psuedo code written
into the FAQ. Also discussions on related topics like BSP-trees, raycasting,
etc as Peter suggests. So much discussion has occurred on these subjects over
the last year that it would be really nice to see the *facts* documented.
Most excellent suggestions, Peter!
Tim Wendt
tim....@daytonoh.ncr.com
< Aminet listings deleted >
Tim Wendt
The guide format is a natural way to browse this kind of information. Much of
the FAQ-type Windows-based info is in a WinHelp file these days. Lets get up to
speed with the Win world.
You don't you need to be a programmer to create an AmigaGuide document either.
Amiga World recently listed several tools to facilitate the creation of
AmigaGuides.
Hedley v1.0
Text2Guide v3.1
AmigaGuideWriter v1.03
Ag2txt - prints a document from an AmigaGuide
Does anyone know if there is an effort to enhance the AmigaGuide system? (ie, to
keep up with the abilities of WinHelp)
Tim Wendt
tim....@daytonoh.ncr.com
John Pat Corigliano
Tim Wendt <tim....@daytonoh.ncr.com> wrote:
>>In article <PETERM.95...@whio.grace.cri.nz> Peter McGavin writes:
>>
>>In the FAQ it would be nice to have a list of the advantages and
>>disadvantages of copper chunky versus chunky to planar (c2p)
>>algorithms, things like:
>
>I totally agree!
>
>I appreciate the first attempt at the texture mapping FAQ, however I would like
>to see one oriented towards coders such as Peter McGavin describes below. As a
>>
>>too, along with pointers to where information on these topics can be
>>found. I don't really know enough about those topics to write about
>>them myself --- except to mention that just about all amiga
>>texture-mapping demos so far are based on raycasting, and that
>>BSP-trees (that DOOM purportedly uses) supposedly are much faster.
>>--
>>Peter McGavin. (pet...@maths.grace.cri.nz)>
Sorry, I missed the original post - is this FAQ available? From where? I'm doing
a RayCaster right now, but what are BSP-trees? (I never could quite figure out
how DOOM was done!).
I agree that good c2p is critical to creating a playable 3D-game for the Amiga.
My raycaster is very fast but c2p restricts my prog to about 10 fps. Since
I've never programmed the blitter, I'm using a CPU-only c2p algo that's just not
cutting it.
I have an idea to speed things up, but must learn more about the blitter first -
If any master coders out there want to help, here's my plan:
1. Raycast column x; where x is a column of video
2. Texture map column x
3. Let blitter convert texture to planar while prog goes back to step 1 -
assuming the blitter can do this independent of the CPU
4. Hopefully, blitter is done by the time column x-1 is ready.
I think this could, theoretically eliminate the extra time c2p requires - it all
depends on how fast the blitter is.
BTW, is programming the blitter directly considered 'illegal'? So far my prog
is 100% OS friendly and I'm trying to keep it that way.
Later,
--
John Corigliano jco...@strauss.udel.edu
Computer and Information Science University of Delaware
"If you don't like the way I'm driving, call 1-800-B-I-T-E-M-E"
- Tom Servo