DOOM on Amiga -- No chunky pixels
Jason Freund
looking for and finding almost every possible speedup for the Amiga, and
because I think I have actually created the best Wolf type engine for
the Amiga so far, I feel qualified to comment here. Besides, I'd hate to
miss out on a great flame war ;)
My roommate and I wrote a Wolf-type enging for the Amiga about 1.5
years ago called rot2. Rot3 was finished a year ago: it has:
* 288 X 175 pixel full-height walls, texture mapped
* 20 fps on 030, 30 fps on 040
* variable size/shape screen
* variable light sourcing, dimming
* each wall is unique texturemap composed of assortment of decorations
* animated walls
* doors/secret doors
I will use rot3 as a measuring tool for what is possible since
I have seen a half dozen slower Wolf-type programs and have a feel for their
algorithms and how fast things can be made to go.
I laugh whenever people compare processor speeds and conclude that
Wolf/DOOM could be done on a Mac or Amiga because the Mac and Amiga (both would
run a DOOM simulation at the same speed, incidentally) don't have the 1
critical thing that makes DOOM INHERENTLY ~8-10 times faster on the IBM than on
the Amiga: chunky pixels. On the Mac/Amiga, for every pixel you need to
do logical operations in each bitplane to read and write the pixel from/to
the appropriate byte in memory. On the IBM, all these operations are done
at once because you can simply pick up a pixel and put it down in 1 move.
So at the innermost level (where 85% of the work is really done), the IBM
is inehrently at least 8 times faster.
The only way that anyone has ever achieved partial success on
the Amiga is to emulate chunky pixel mode. This requires a lot of work and
a lot of careful bit manipulation and pre-computing lots of data. But even
with all this work, you still have to do 3-4 times as much work for each
pixel than you would on the IBM. That is why you need cache, fastram, and
fast processor. Algorithms using the blitter end up slower than
processor-based so any good DOOM wouldn't touch the blitter.
IMHO, rot3 is evidence that wolf can be done on the amiga -- however:
rot3 has no monsters (that would induce a good 20% slowdown). rot3 does
require an 030 WITH fastram because the algorithms are extremely dependant on
a cache, a fast processor, AND fast memory for the Amiga.
IMHO, DOOM is not possible -- not even close -- even on an 040.
Obviously, this will incite a lot of flames on this group, so let me qualify
this: No existing Mac/Amiga will ever run DOOM as fast as a 286. I am very
confident about this. Wolf was barely possible since there were so many
limitations that happened to just barely fit in the Amiga's schemes.
DOOM does lots of things that could never be done using any chunky
pixel emulation scheme on the Amiga. We might be able to pick up a few
tricks from DOOM that weren't in Wolf at very little speed loss, but
some things are actually IMPOSSIBLE (floor, ceiling, outside). Note:
IMPOSSIBLE means: Impossible to implement on Amiga and have it go as fast
as DOOM on 286. And an even longer list of DOOM things would slow down an
Amiga engine to make it intolerably slow.
Jason Freund
(incidentally, look for rot3 with faq and src probably late this month)
--
Bruno Fernandes
Jason Freund wrote a great many factual things.... :)
There is no need for a flame war. This is mainly because everyone else
posting to this discussion have based their completely false opinions on
their warped wishes and total lack of any knowledge about either the
Amiga, PC Systems or graphics in general. I hope I am being harsh enough.
It bothers me extremely when I see empty blanket statements from some of
the 13 year old games players posting to this group.
A friend of mine has also programmed some very fast and efficient routines
in these realms including extremely fast chunky to planar code. There is
just too much to be done just to be able to duplicate what is already a
native feature of VGA cards. Like I told someone else... When we see AAA
then DOOM will be easily possible on our platform (I do hope people will
still develop some games for these higher end systems).
As far as the Macs go... I believe only the earlier Macs used bitplane
displays. Don't at least all the newer Macs use chunky pixels?
Bruno.
Oh, and to stop another thread... No, emulating the Enterprise's HoloDeck
is not possible on an Amiga, PC, Jaguar or 3DO. :)
--
"Also believe that peanut butter | The ideas expressed may very well be my
and bacon have been neglected as | own - or they may be stolen from others.
food groups, particularly when |
eaten together." - D. Cooper | e0f1...@credit.erin.utoronto.ca
Raffaele Lapietra
I just want to preface this with a statement...
"This IS NOT a flame"
Now that you've all put away your incendiary grenades...
<stuff deleted>
> IMHO, DOOM is not possible -- not even close -- even on an 040.
>Obviously, this will incite a lot of flames on this group, so let me qualify
>this: No existing Mac/Amiga will ever run DOOM as fast as a 286. I am very
>confident about this. Wolf was barely possible since there were so many
<more stuff deleted>
I found evrything you wrote very interesting, but I do have a question...
Doom on a 286?? I don't know much about IBM but from what I've heard you
need nothing less than a 486 to have Doom playable at all...
I mean a buddy of mine couldn't play Doom on his system because all he had
was a 486SX with 4 megs of RAM! Guess he needs to juice it up a bit more...
>Jason Freund
>(incidentally, look for rot3 with faq and src probably late this month)
Vin
McGarry T N
: Because I know how Wolf and DOOM are done -- I spent over a year
: looking for and finding almost every possible speedup for the Amiga, and
: because I think I have actually created the best Wolf type engine for
: the Amiga so far, I feel qualified to comment here. Besides, I'd hate to
: miss out on a great flame war ;)
: My roommate and I wrote a Wolf-type enging for the Amiga about 1.5
: years ago called rot2. Rot3 was finished a year ago: it has:
Will this version give proper perspective on the tmaps ?
ROT2 seemed to use a linear mapping which wasnt all that
impressive .
: The only way that anyone has ever achieved partial success on
: the Amiga is to emulate chunky pixel mode. This requires a lot of work and
: a lot of careful bit manipulation and pre-computing lots of data. But even
: with all this work, you still have to do 3-4 times as much work for each
: pixel than you would on the IBM. That is why you need cache, fastram, and
: fast processor. Algorithms using the blitter end up slower than
: processor-based so any good DOOM wouldn't touch the blitter.
I have written routines ( requiring fast ram ) that use the
blitter and are faster than purely processor based , even on
a 4000/40 . The blitter begins converting a frame (in chip) as
processor is drawing the next (in fast) . When the processor
finishes it helps ( or takes over from ) the blitter to finish
conversion . The new frame is then copied from fast to chip
and so on .. Admittedly , the blitter doesnt tend to do all
that much on fast 030s and 040s .
: IMHO, rot3 is evidence that wolf can be done on the amiga -- however:
: rot3 has no monsters (that would induce a good 20% slowdown). rot3 does
: require an 030 WITH fastram because the algorithms are extremely dependant on
: a cache, a fast processor, AND fast memory for the Amiga.
A wolf style game could be done on a 1200 , but faster
machines are definitely necessary for anything other than
wall tmaps.
: IMHO, DOOM is not possible -- not even close -- even on an 040.
: Obviously, this will incite a lot of flames on this group, so let me qualify
: this: No existing Mac/Amiga will ever run DOOM as fast as a 286. I am very
: confident about this. Wolf was barely possible since there were so many
: limitations that happened to just barely fit in the Amiga's schemes.
: DOOM does lots of things that could never be done using any chunky
: pixel emulation scheme on the Amiga. We might be able to pick up a few
: tricks from DOOM that weren't in Wolf at very little speed loss, but
: some things are actually IMPOSSIBLE (floor, ceiling, outside). Note:
: IMPOSSIBLE means: Impossible to implement on Amiga and have it go as fast
: as DOOM on 286. And an even longer list of DOOM things would slow down an
: Amiga engine to make it intolerably slow.
Floors and ceilings are IMPOSSIBLE ? What gave you that idea ?
They're not that difficult . Most stuff can be precalculated
so that you just step through tmaps . What do you mean by
outside ? I've been told Ambermoon has simple floor and
ceiling tmapping .
: Jason Freund
: (incidentally, look for rot3 with faq and src probably late this month)
I cant wait to see it . The previous incarnation had some
great ideas for optimisations .
Tony McGarry
Andor Rauschen
[a lot of stuff deleted]
> IMHO, DOOM is not possible -- not even close -- even on an 040.
>Obviously, this will incite a lot of flames on this group, so let me qualify
>this: No existing Mac/Amiga will ever run DOOM as fast as a 286. very
That is total bullshit. I have seen an AGA-Demo that do 3D moving in
realtime like DOOM. The limits to the frame speed is not caused by
planar or chunky pixels. In terms of speed, both methodes are equivalent.
> Wolf was barely possible since there were so many
>limitations that happened to just barely fit in the Amiga's schemes.
>DOOM does lots of things that could never be done using any chunky
>pixel emulation scheme on the Amiga.
Ambermoon does not emulate chunky pixel (it runs with planar scrolling)
and is very fast on my A4000/30. And I must say that I can't see the
need for emulating chunky pixel.
>Jason Freund
>(incidentally, look for rot3 with faq and src probably late this month)
I will, and than I will check up the source.
Andor
.--------//-------------------------------------------------.
| \X/ | A4000/30 MMU/4/340MB AGA A2000/2/50MB ECS |
| only C= Amiga | E-Mail: ich...@zam001.zam.kfa-juelich.de |
`----------------\ Forschungszentrum Juelich, germany /
The Shift
Mats A Knip
> looking for and finding almost every possible speedup for the Amiga, and
> because I think I have actually created the best Wolf type engine for
> the Amiga so far, I feel qualified to comment here. Besides, I'd hate to
> miss out on a great flame war ;)
I'm in pretty much the same chair, and feel a necessity to comment
some minor things as well. And I'm not all too sure about your routine
being faster than mine ;-)
> The only way that anyone has ever achieved partial success on
> the Amiga is to emulate chunky pixel mode. This requires a lot of work and
> a lot of careful bit manipulation and pre-computing lots of data. But even
> with all this work, you still have to do 3-4 times as much work for each
> pixel than you would on the IBM. That is why you need cache, fastram, and
> fast processor. Algorithms using the blitter end up slower than
> processor-based so any good DOOM wouldn't touch the blitter.
Well, well and well... This could be discussed forever, but just to
get the discussion going, what would you say about...:
What makes texture-mapping so fast on the PC is it's chunkies, yes.
BUT also considering the enormous difference in speeds when
accessing the graphics-memory on a PC without a local-bus and the
Amiga.
Can we agree as far as to the fact that creating the screen in
fastRAM(chunky) on the Amiga can't possibly be any slower than
copying the graphics to a PC graphicscard. A 68040 is every bit as
fast as a 486 running at the same speed (in fact, quite a lot
faster). In other words, since a 33Mhz 486 can do, lets say 20 frames
on a PC (using about 2-3 frames to draw the screen) the same speed,
and probably faster, can be achieved on an Amiga. A chunky-planar
conversion takes how long? (I haven't tried myself) One frame?
So, on an A4000 you should be able to do a DOOM that runs in
about 15 frames (using 2-3 frames to draw and one frame for
c-p conversion). If not, why not?
I, myself, am pretty sure it's fully possible. With akiko (CD32)
even an A1200 should be able to do , if not fullscreen, some
pretty respectable DOOM-graphics. At least full-screen Wolfenstein.
> IMHO, DOOM is not possible -- not even close -- even on an 040.
> Obviously, this will incite a lot of flames on this group, so let me qualify
> this: No existing Mac/Amiga will ever run DOOM as fast as a 286. I am very
> confident about this. Wolf was barely possible since there were so many
> limitations that happened to just barely fit in the Amiga's schemes.
> DOOM does lots of things that could never be done using any chunky
> pixel emulation scheme on the Amiga. We might be able to pick up a few
> tricks from DOOM that weren't in Wolf at very little speed loss, but
> some things are actually IMPOSSIBLE (floor, ceiling, outside). Note:
> IMPOSSIBLE means: Impossible to implement on Amiga and have it go as fast
> as DOOM on 286. And an even longer list of DOOM things would slow down an
> Amiga engine to make it intolerably slow.
No, no, and NO! With all respect, I do not agree on this. Especially
floors and ceiling should be *easy* to implement since such scanline-
routines can be made that makes chunky planes pretty much useless.
Look at the Demo Origin by Complex. Wolf is not just barely possibly
on an A1200. Origin runs fullscreen Wolf-graphics at a respectable
speed on a A1200. And they don't seem to use any of the easy cheats
either, as far as I can tell.
Besides, DOOM won't run on a 286.
--
*=--------------------------------------------------------------------------=*
* E-Mail: mk...@niksula.cs.hut.fi *
* Helsinki University of Technology / department of Computer Science *
*=--------------------------------------------------------------------------=*
Christer Ericson
> I laugh whenever people compare processor speeds and conclude that
>Wolf/DOOM could be done on a Mac or Amiga because the Mac and Amiga (both would
>run a DOOM simulation at the same speed, incidentally) don't have the 1
>critical thing that makes DOOM INHERENTLY ~8-10 times faster on the IBM than on
>the Amiga: chunky pixels. On the Mac/Amiga, for every pixel you need to
>do logical operations in each bitplane to read and write the pixel from/to
>the appropriate byte in memory. On the IBM, all these operations are done
>at once because you can simply pick up a pixel and put it down in 1 move.
>So at the innermost level (where 85% of the work is really done), the IBM
>is inehrently at least 8 times faster.
Well, I know virtually nothing about Amiga, but it is obvious that you
know absolutely nothing about Macintosh. Macintosh has chunky pixels,
has always had chunky pixels, and will always have chunky pixels (at
least in the forseeable future). Does this mean we can laugh at you
as well?
Christer Ericson --- Internet: chri...@cs.umu.se --- tel: +46-90-166794
Department of Computer Science, University of Umea, S-90187 UMEA, SWEDEN
John Shiali
> IMHO, rot3 is evidence that wolf can be done on the amiga -- however:
> rot3 has no monsters (that would induce a good 20% slowdown). rot3 does
> require an 030 WITH fastram because the algorithms are extremely dependant on
> a cache, a fast processor, AND fast memory for the Amiga.
>
> IMHO, DOOM is not possible -- not even close -- even on an 040.
> Obviously, this will incite a lot of flames on this group, so let me qualify
> this: No existing Mac/Amiga will ever run DOOM as fast as a 286. I am very
> confident about this. Wolf was barely possible since there were so many
> limitations that happened to just barely fit in the Amiga's schemes.
> DOOM does lots of things that could never be done using any chunky
> pixel emulation scheme on the Amiga. We might be able to pick up a few
> tricks from DOOM that weren't in Wolf at very little speed loss, but
> some things are actually IMPOSSIBLE (floor, ceiling, outside). Note:
> IMPOSSIBLE means: Impossible to implement on Amiga and have it go as fast
> as DOOM on 286. And an even longer list of DOOM things would slow down an
> Amiga engine to make it intolerably slow.
I bow to your expertise in this area, and I wouldn't be surprised if
Doom is not possible, but surely a Doom-like game is - after all, Core
Design did a pretty good version several years ago (1990) that was reasonable
on a 68000 running kickstart 1.3 ... called "Corporation" I believe...
--
John -
"Nice computer, but I couldn't eat a whole one....."
Eyvind Bernhardsen
Well, I know virtually nothing about Amiga, but it is obvious that you
know absolutely nothing about Macintosh. Macintosh has chunky pixels,
has always had chunky pixels, and will always have chunky pixels (at
least in the forseeable future). Does this mean we can laugh at you
as well?
Bloody hell. Talk about a waste of memory... One byte/pixel for a
b/w screen? SOMEONE should be fired.
--
//| Eyvind Bernhardsen - finger for PGP key - eyv...@lise.unit.no
\X/-| "MS Word is an ugly, clanking, God-awful mess of a program." -DNA
Jason Freund
>some minor things as well. And I'm not all too sure about your routine
>being faster than mine ;-)
to see yours -- will you release a 3000 version ?
>
>floors and ceiling should be *easy* to implement since such scanline-
>routines can be made that makes chunky planes pretty much useless.
>Look at the Demo Origin by Complex. Wolf is not just barely possibly
fast, I think there would be a problem doing walls with it. My c2p
relies on the screen being blank before it Or's a new pixel on the screen.
Having floors and walls would (besides halving the speed) make it so I'd
have to greatly change my inner loop to account for not having a blank
background (and I woudn't even know how to do this fast) Another problem
with DOOM walls is you can have many different walls on the same column.
When I said wolf barely fit into a fast algorithm -- that was because
each column could have 1 wall in it. Having many walls (windows, etc)
means the innermost loop (where 85% of my work is done) is now much,much
bigger. My inner loop is tiny now and every instruction I removed earned
1-2 frames:
iloop:
move.b 0(a1,d0.l),d7 ; get planes for bit
move.l 0(a2,d7.w),d2 ; look up in colortable
or.l d2,(a4)
move.l (a0)+,d0 ; use lookup to calculate row
adda.l d1,a4 ; d1 dplus+=dbrp
dbra.w d5,iloop
Multiple walls/scanline blows this up a lot. That would be bad.
>Besides, DOOM won't run on a 286.
Ya, that was kind of what I meant ;)
I also have to say "oops" about the Mac stuff. My mac knowlege is way out
of date (hmmm :) and they have do have chunky pixels -- and there is even
a good wolf clone out.
Jason
--
Jason W. Nyberg
/ IMHO, DOOM is not possible -- not even close -- even on an 040.
You mean "040 AGA (or less) Amiga", right?
DOOM was developed on a NeXT.
/Obviously, this will incite a lot of flames on this group, so let me qualify
/this: No existing Mac/Amiga will ever run DOOM as fast as a 286. I am very
I thought that Macs had chunky displays. Some, at least.
/confident about this. Wolf was barely possible since there were so many
/limitations that happened to just barely fit in the Amiga's schemes.
/DOOM does lots of things that could never be done using any chunky
/pixel emulation scheme on the Amiga. We might be able to pick up a few
/tricks from DOOM that weren't in Wolf at very little speed loss, but
/some things are actually IMPOSSIBLE (floor, ceiling, outside). Note:
/IMPOSSIBLE means: Impossible to implement on Amiga and have it go as fast
/as DOOM on 286. And an even longer list of DOOM things would slow down an
/Amiga engine to make it intolerably slow.
I agree that we won't see a DOOM clone on the current crop of stock Amigas.
--
These are the thoughts and words of Jason Nyberg (nyb...@ctron.com)
"If this were a fight, they'd stop it." -The Good Life
Borge Noest
>There is no need for a flame war.
Ok all you DOOM sayers (pun intended): How fast would the c2p conversion
have to be before you think it would be possible to do DOOM at an ok rate
(lets say more than 10frames/s)? (Target should be 020, 030, 040 with
fastram.)
--
|/// bor...@stud.cs.uit.no (Boerge Noest) | Amiga B2000 \\\|
|// Box 218, 9001 Tromsoe, Norway | Remember to :-) when needed \\|
|/ The worlds northernmost university | Life is worth living. \|
#Disclaimer: This university does not speak for me.
Zsolt Szabo
>I bow to your expertise in this area, and I wouldn't be surprised if
>Doom is not possible, but surely a Doom-like game is - after all, Core
>Design did a pretty good version several years ago (1990) that was reasonable
>on a 68000 running kickstart 1.3 ... called "Corporation" I believe...
That game did not use texture mapping. It had pre-drawn graphics.
--
R.O.B.O.D.U.D.E.
----------------
Jason Maskell
In a previous article, fre...@cis.uab.edu (Jason Freund) says:
> Because I know how Wolf and DOOM are done -- I spent over a year
>
>Jason Freund
>(incidentally, look for rot3 with faq and src probably late this month)
This may not be representative of your current work, and it
certainly is not meant as a personal attack, but rot2 bit.
Now, I realize this was the 'no-math' version I was running, but
if rot3 is an extension, no wonder it is so slow! Chris Green's tmapdemo
gets at the slowest 50 odd fps on my 1200. It hovers at 230 on my friends
4000/040.
Now, if you have incorporated an integer math algorithim, at least
as efficient as Chris Greens, have done your best optimization job, and
have some hard evidence to back you up, I'll throw in the towel. But I
seriously doubt it.
--
'You see son, if this were Star Trek, we'd be negotiating with this Kobold.'
- Unknown Angband Player
Bruno Fernandes
Andor Rauschen <ICH...@DJUKFA11.BITNET> wrote:
>
>That is total bullshit. I have seen an AGA-Demo that do 3D moving in
>realtime like DOOM. The limits to the frame speed is not caused by
>planar or chunky pixels. In terms of speed, both methodes are equivalent.
>
What can I say? You're an idiot. This is not intended to start a flame
war. By making that statement you only prove without a single doubg that
you have no idea whatsoever about how to program such a game. Also, a
demo is _NOT_ a game. Listen to the original poster - he has made the
best implementation around for the Amiga - I know people with faster
and more optimized routines but they completely agree that it is
completely impossible. DOOM must run at least 30 fps on a 33Mhz 486. If
you want to play a 2-5 fps small-screen version for the Amiga, maybe
someone will make you one.
I can't stand ignorant games players.
Bruno.
Hybrid Developments. Multi-Tasking Entertainment.
Bruno Fernandes
>Well, I know virtually nothing about Amiga, but it is obvious that you
>know absolutely nothing about Macintosh. Macintosh has chunky pixels,
>has always had chunky pixels, and will always have chunky pixels (at
>least in the forseeable future). Does this mean we can laugh at you
>as well?
The original Macs used a bitmap screen.
Bruno
Hybrid Developments.
Bruno Fernandes
Jason Maskell <ao...@FreeNet.Carleton.CA> wrote:
>In a previous article, fre...@cis.uab.edu (Jason Freund) says:
>
>> Because I know how Wolf and DOOM are done -- I spent over a year
>>
>>Jason Freund
>>(incidentally, look for rot3 with faq and src probably late this month)
>
> This may not be representative of your current work, and it
>certainly is not meant as a personal attack, but rot2 bit.
> Now, I realize this was the 'no-math' version I was running, but
>if rot3 is an extension, no wonder it is so slow! Chris Green's tmapdemo
>gets at the slowest 50 odd fps on my 1200. It hovers at 230 on my friends
>4000/040.
> Now, if you have incorporated an integer math algorithim, at least
>as efficient as Chris Greens, have done your best optimization job, and
>have some hard evidence to back you up, I'll throw in the towel. But I
>seriously doubt it.
>
My friend and partner laughed at Chris Green's routines after atempting
the same stuff himself - Green's code was like syrup on a winter morning.
But alas, even with this code, DOOM is in no way possible on an Amiga
(until AAA anyway :)
BTW, even with the proper bugs fixed, an Amiga 4000 is a hell of a lot
slower than an Amiga equiped with a 3rd party 040. What's the fastest 3rd
party device available for the A1200? And what 3rd party additions are
now available for the A4000?
ash...@delphi.com
>I found evrything you wrote very interesting, but I do have a question...
>Doom on a 286?? I don't know much about IBM but from what I've heard you
>need nothing less than a 486 to have Doom playable at all...
>
>I mean a buddy of mine couldn't play Doom on his system because all he had
>was a 486SX with 4 megs of RAM! Guess he needs to juice it up a bit more...
I've played DOOM on a 386DX-33 and it was very enjoyable. So we don't
need comments like...."I played it on a friends Pentium and it was to
choppy." OK?
Another thing.... MOST people have DOOM v1.1. This version is VERY slow
compared to v1.0 (original version)..... but v1.2 (when it's released)
will return DOOM to 'light speed'.
P.S. On my old 386DX-33, I had v1.1 and it was nice.
Jeff Jahr
yet another trendy buzzword that I mannaged to avoid hearing.
-jj
Mark Brophy
: fre...@cis.uab.edu (Jason Freund) writes:
: [a lot of stuff deleted]
: > IMHO, DOOM is not possible -- not even close -- even on an 040.
: >Obviously, this will incite a lot of flames on this group, so let me qualify
: >this: No existing Mac/Amiga will ever run DOOM as fast as a 286. very
: That is total bullshit. I have seen an AGA-Demo that do 3D moving in
: realtime like DOOM. The limits to the frame speed is not caused by
: planar or chunky pixels. In terms of speed, both methodes are equivalent.
Ok Andor, you must now take a gun and blow your inherently useless brains
all over the wall behind you. Of course planar is slower. Why in gods name
do you think C= put the chunky to planar chip in the CD32?? for fun!
: > Wolf was barely possible since there were so many
: >limitations that happened to just barely fit in the Amiga's schemes.
: >DOOM does lots of things that could never be done using any chunky
: >pixel emulation scheme on the Amiga.
: Ambermoon does not emulate chunky pixel (it runs with planar scrolling)
: and is very fast on my A4000/30. And I must say that I can't see the
: need for emulating chunky pixel.
Then you have very little clues about the world in general. The fact
that chunky pixels make this easier is just so blindingly obvious that
I'm surprised even the Braindead WaReZ D00dZ who keep insisting doom
can be done on a 1200 don't realise.
--
Mark Brophy,
The world is like an orange, Sort of!!!!!?????
********************************************************************************
** *** Amiga 1200, ///**
** "News flash!, Vacuum cleaner sucks up budgie." *** "Machine /// **
** -The Clash *** of the \\\/// **
** *** Gods" \/// **
********************************************************************************
** Mail: ins...@aurora.cc.monash.edu.au **
********************************************************************************
Mark Brophy
: In a previous article, fre...@cis.uab.edu (Jason Freund) says:
: > Because I know how Wolf and DOOM are done -- I spent over a year
: >
: >Jason Freund
: >(incidentally, look for rot3 with faq and src probably late this month)
: This may not be representative of your current work, and it
: certainly is not meant as a personal attack, but rot2 bit.
: Now, I realize this was the 'no-math' version I was running, but
: if rot3 is an extension, no wonder it is so slow! Chris Green's tmapdemo
: gets at the slowest 50 odd fps on my 1200. It hovers at 230 on my friends
: 4000/040.
For the benefit of all pple who don't realise thats 5 frames per sec.
When the rotdemo says FRAME RATE = 0070 That is 7.0 fps, Not 70.
: Now, if you have incorporated an integer math algorithim, at least
: as efficient as Chris Greens, have done your best optimization job, and
: have some hard evidence to back you up, I'll throw in the towel. But I
: seriously doubt it.
--
Tomas Hubner
>Can we agree as far as to the fact that creating the screen in
>fastRAM(chunky) on the Amiga can't possibly be any slower than
>copying the graphics to a PC graphicscard. A 68040 is every bit as
>fast as a 486 running at the same speed (in fact, quite a lot
>faster). In other words, since a 33Mhz 486 can do, lets say 20 frames
>on a PC (using about 2-3 frames to draw the screen) the same speed,
>and probably faster, can be achieved on an Amiga. A chunky-planar
>conversion takes how long? (I haven't tried myself) One frame?
>So, on an A4000 you should be able to do a DOOM that runs in
>about 15 frames (using 2-3 frames to draw and one frame for
>c-p conversion). If not, why not?
>I, myself, am pretty sure it's fully possible. With akiko (CD32)
>even an A1200 should be able to do , if not fullscreen, some
>pretty respectable DOOM-graphics. At least full-screen Wolfenstein.
There was a post by Peter McGavin a while ago in some area. He said something
about using the copper for conversion between chunky and planar (not really
convert, rather display chunky graphics). The thought interested me so I had a
look in the RKMs and realised it could probably be done.
What you would have to do is set up an enormous copper program which before
each set of 4 (or was it 8? I guess it depends on AGA or not) pixels writes
color information into the color registers associated with the pixels.
You write the chunky graphics into the copper program itself which could seem
like an easy task forgetting that the color information in the copper program
has to be interleaved by wait and move instructions.
The problem with this is that the copper would probably eat the chip bus while
it is moving color information into registers. This, however, is not a real
problem unless the CPU would wish to access the chip bus. The CPU is totally
free to do whatever it wants with the system bus (that's where the fastram is)
without speed decreases.
So what is needed is a huge copper program in chip memory, a buffer screen
in fast memory which the cpu could write to and a static planar screen with
dummie colors in chip memory. The buffer screen in fast memory could be moved
into chipmem when the copper is waiting for the beam to wrap around the bottom
of the screen.
(The planar screen in chip mem should only contain information that associates
each pixel with a specific color-register. The more pixels the copper writes
color information for each time it stops the more bitplanes are needed. I
figure that 3 or possibly 2 bitplanes would do the trick.)
This method is purely hypothetical at the moment. I haven't been able to do any
test of any kind since I haven't got much time or is very knowledged about
copper programming. So please, spare any harsh comments on this theory.
The disadvantages of this is that the other special chips would have very little
access to the bus. There should be enough pauses between the copper accesses
to be able to play a little sound (I think). Another huge disadvantage is that
it requires fast memory (quite a lot too).
The advantage is that the CPU would not have to do the conversion and that
you'd be able to display an awful lot of colors on the screen at the same time.
(OCS/ECS 4096 and AGA 16.7M theoretically I don't know if the bandwidth of the
chip bus is sufficient for the amount of moves you'd have to make to get 16.7M
colors.)
Now, I write this after very little investigation so it might very well be that
this doesn't work at all. It might also be that this partially works. It might
also work good enough to do some other type of game with a bunch of colors.
I don't know, I just play this keyboard here.
--
Tomas Hybner
Nothing is impossible, it's just that some things are so darned difficult
they can't be done. Yet.
M Richards
>
> I bow to your expertise in this area, and I wouldn't be surprised if
> Doom is not possible, but surely a Doom-like game is - after all, Core
> Design did a pretty good version several years ago (1990) that was reasonable
> on a 68000 running kickstart 1.3 ... called "Corporation" I believe...
Corporation - whilst very good did not use texture mapping (and I
really don't think it needed it). A game that did use TM (which also ran on
the basic 68000 Amiga) was Legends of Valour. It ran very smoothly (albeit
in a small window) - pity the game was so bloody awful.....
I've no idea what happened to the company though.
Mike.
--
You can reach Mike Richards at the following /@\ \|/
address ... (if you're that desperate). `-\ \ ______ - 0 -
\ \/ ` / \ /|\ _
m...@aber.ac.uk \_i / \ |\____//
| |==| |=----/
---- Why not drop me a line ...? -------------------hn/--hn/-----------
Mark Brophy
: Someone want to give an explanation of 'chunky pixels' are? Sounds like
: yet another trendy buzzword that I mannaged to avoid hearing.
: -jj
Ok it goes like this.
b=bit B=Byte.
the Ibm's graphics are stored in memory like this:
BBBBB
BBBBB
BBBBB - This is a 5 by 5 screen.
BBBBB
BBBBB
This would allow a max of 256 colours.
as 1 byte has 256 different values.
The dissadvantage is that even if you only use 2 colours.
You still need the same amount of memory, and you can't do the nice
things you can on the amiga like parallax scrolling as easily.
The reason this is so much better for wolf 3d etc. is say we need
to put up one pixel as being a certain colour, we just
go:
movb #145,xxxxx Where xxxxx is the memory address of that pixel.
ie. set that place to colour 145.
The Amiga on the other hand would have.
bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb
bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb
bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb
bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb
bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb
for a 5*5 256 colour screen.
where each block contains the n'th bit of the byte from
the chunky display.
In this case, to put a pixel up on the screen as having a certain colour,
we need to set one bit in each of the bitpanes.
ie. for the 1st pixel.
or.b #128,xxx1
or.b #128,xxx2
or.b #128,xxx3
where xxx1,2,3 are the bitplanes.
This will set the first pixel to colour 224.
Which is somewhat slower. A LOT slower in fact 8-(
Tomas Hubner
>Can we agree as far as to the fact that creating the screen in
>fastRAM(chunky) on the Amiga can't possibly be any slower than
>copying the graphics to a PC graphicscard. A 68040 is every bit as
>fast as a 486 running at the same speed (in fact, quite a lot
>faster). In other words, since a 33Mhz 486 can do, lets say 20 frames
>on a PC (using about 2-3 frames to draw the screen) the same speed,
>and probably faster, can be achieved on an Amiga. A chunky-planar
>conversion takes how long? (I haven't tried myself) One frame?
>So, on an A4000 you should be able to do a DOOM that runs in
>about 15 frames (using 2-3 frames to draw and one frame for
>c-p conversion). If not, why not?
>I, myself, am pretty sure it's fully possible. With akiko (CD32)
>even an A1200 should be able to do , if not fullscreen, some
>pretty respectable DOOM-graphics. At least full-screen Wolfenstein.
There was a post by Peter McGavin a while ago in some area. He said something
Mats A Knip
> means the innermost loop (where 85% of my work is done) is now much,much
> bigger. My inner loop is tiny now and every instruction I removed earned
> 1-2 frames:
It's true that the texture-draw routine takes more time than any
other part of the routine. Using a copper-chunky (2*2) screen
it should be possible to speed this up like 5-6 times, although the
resolution would suffer. This requires AGA, of course, but you
really should try implementing it. It could look pretty cool.
/ Mats
Teemu Suikki
>Ambermoon does not emulate chunky pixel (it runs with planar scrolling)
>and is very fast on my A4000/30. And I must say that I can't see the
>need for emulating chunky pixel.
Well, you can do texture-mapping in planar, but it's slow. It's much faster
to use chunky buffer in fast ram, and then convert that to planar..
--
PROC main();DEF a,b,c;b:='** email: tsu...@lut.fi **';Vprintf(a:='P'+
'ROC main();DEF a,b,c;b:=%lc%s%lc;Vprintf(a:=%lcP%s%.69s%s%s%lc,%lc[c:'+
'=39,b,c,c,b:=[$%8lx,0],a+1,b,a+70,c,10,^b,10]);ENDPROC/*E .sig!*/%1lc',
[c:=39,b,c,c,b:=[$272B0A27,0],a+1,b,a+70,c,10,^b,10]);ENDPROC/*E .sig!*/
Andor Rauschen
>Andor Rauschen (ICH...@DJUKFA11.BITNET) wrote:
>>fre...@cis.uab.edu (Jason Freund) writes:
>>> IMHO, DOOM is not possible -- not even close -- even on an 040.
>>>Obviously, this will incite a lot of flames on this group, so let me qualify
>>>this: No existing Mac/Amiga will ever run DOOM as fast as a 286. very
>>
>>That is total bullshit. I have seen an AGA-Demo that do 3D moving in
>>realtime like DOOM. The limits to the frame speed is not caused by
>>planar or chunky pixels. In terms of speed, both methodes are equivalent.
>
>Ok Andor, you must now take a gun and blow your inherently useless brains
>all over the wall behind you. Of course planar is slower. Why in gods name
>do you think C= put the chunky to planar chip in the CD32?? for fun!
grmpf, planar is NOT slower as chunky in general. It is slower if you try
to emulate chunky, because you have to move the ram 'bit by bit' and not
in one instruction. But we're talking about DOOM and I say that you can
do the graphics (moving around) without chunky emulation.
But without the emulation Doom can not be ported to the Amiga because you
have to programm absolutely new routines. That is the reason why Commodore
put the chunky to planar chip in the CD32. PC games can easier be ported.
>>> Wolf was barely possible since there were so many
>>>limitations that happened to just barely fit in the Amiga's schemes.
>>>DOOM does lots of things that could never be done using any chunky
>>>pixel emulation scheme on the Amiga.
>>
>>Ambermoon does not emulate chunky pixel (it runs with planar scrolling)
>>and is very fast on my A4000/30. And I must say that I can't see the
>>need for emulating chunky pixel.
>
>Then you have very little clues about the world in general. The fact
>that chunky pixels make this easier is just so blindingly obvious that
>I'm surprised even the Braindead WaReZ D00dZ who keep insisting doom
>can be done on a 1200 don't realise.
I have never saied that it is easier with planar. What's the problem ?
Mats A Knip
> to do any test of any kind since I haven't got much time or is very
> knowledged about copper programming. So please, spare any harsh
> comments on this theory.
Oh, it's not hypothetical at all! It has been done before, and it
should work just fine, only you will need AGA (256 colors) to get any
kind of nice resulution (2*2). This technique was discussed in
amiga.demos some time ago, and according to those that tried it
it doesn't eat very much buss-time at all.
> The advantage is that the CPU would not have to do the conversion and
> you'd be able to display an awful lot of colors on the screen at
> the same time. (OCS/ECS 4096 and AGA 16.7M theoretically I don't know
> if the bandwidth of the chip bus is sufficient for the amount of moves
> you'd have to make to get 16.7M colors.)
I think doing this trick on an ECS-chip would be pretty useless since
the resolution would be so low. And on AGA you would still only
get 4k colors onscreen with any efficiency. But thats still far
from bad ;)
Viljo Viitanen
[the *awesome* copper-chunky-thing]
> I think doing this trick on an ECS-chip would be pretty useless since
> the resolution would be so low. And on AGA you would still only
> get 4k colors onscreen with any efficiency. But thats still far
> from bad ;)
Ha, especially compared to that pitiful 0.25k on the PureCrap :)
Are there any demos which use this effect already ?
-- Viljo, from now on with 1200/4M fast :)
Viljo Viitanen, opiskelee (kun jaksaa) ///fysiikkaa Helsingin Yliopistossa
E-Mail: viljo.v...@helsinki.fi__ /// IRC:#amiga _3V_ Fido:2:220/550.7
depechemodestartrekcalvin&hobbes12\\\///00jarrerunequestfarsidesimpsonsnet
hacktolkiencyberpunkconanelricturbo\XX/rakettimortalkombatv32binteloutside
Jason J. Tucker
>I mean a buddy of mine couldn't play Doom on his system because all he had
>was a 486SX with 4 megs of RAM! Guess he needs to juice it up a bit more...
>Vin
That seems bizarre to me. A friend of mine ran Doom on his 486SX (25
MHz) with 4 MB of RAM and it had no problems whatsoever with speed. Is
the difference between similarly-equipped computers that great or is
there a big difference between people's opinion on speed?
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Jason J. Tucker |Memorial University of Newfoundland| Amiga Owner
jas...@ganymede.cs.mun.ca| St.John's, Newfoundland, Canada |And Darn Proud!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
John Bolton
Mats A Knip <mk...@snakemail.hut.fi> wrote:
:
:...
:Can we agree as far as to the fact that creating the screen in
:fastRAM(chunky) on the Amiga can't possibly be any slower than
:copying the graphics to a PC graphicscard.
: In other words, since a 33Mhz 486 can do, lets say 20 frames
:on a PC (using about 2-3 frames to draw the screen) the same speed,
:and probably faster, can be achieved on an Amiga. A chunky-planar
:conversion takes how long? (I haven't tried myself) One frame?
:So, on an A4000 you should be able to do a DOOM that runs in
:about 15 frames (using 2-3 frames to draw and one frame for
:c-p conversion). If not, why not?
:I, myself, am pretty sure it's fully possible.
Obviously, since you haven't tried it, you don't have a clue.
I was hired to port a Doom-like game to the Amiga and it was a total
flop. The 3000 was only HALF as fast as a 33MHz 386. The killer was
that I was only using 64 colors. If I used 256, like the PC game, it
would be even slower. However, a 4000/40 might have enough horsepower
to produce a playable game.
: With akiko (CD32)
:even an A1200 should be able to do , if not fullscreen, some
:pretty respectable DOOM-graphics. At least full-screen Wolfenstein.
:
Akiko will make a difference.
Hans-Joerg Frieden
>What can I say? You're an idiot. This is not intended to start a flame
>war. By making that statement you only prove without a single doubg that
I don't think that this kind of language is very effective when trying to
avoid a flame war, isn't it.
--
Hans-Joerg Frieden ! EMail: ! //
Schlossstrasse 176 ! in...@uni-trier.de (prefered) ! \\ // Amiga 2000
54293 Trier ! hfri...@treveris.uni-trier.de ! \X/ 25MHz 68030
++49 (0) 651 66410 ! ! Amiga (was sonst)
Hans-Joerg Frieden
>Ok Andor, you must now take a gun and blow your inherently useless brains
>all over the wall behind you. Of course planar is slower. Why in gods name
>do you think C= put the chunky to planar chip in the CD32?? for fun!
>Then you have very little clues about the world in general. The fact
>that chunky pixels make this easier is just so blindingly obvious that
>I'm surprised even the Braindead WaReZ D00dZ who keep insisting doom
>can be done on a 1200 don't realise.
Fact is: To do something like DOOM, you will have to redraw the entire
screen every frame.
Another fact: To draw 8 pixels in a chunky display, you will need 8 byte
access to the graphics memory.
And another fact: To draw 8 pixels in a planar display, you will need -
guess what - 8 byte accesses to graphics memory.
Someone saying 'DOOM requires chunky pixels' is as right as someone
saying 'this problem requires a turing machine'. It is just a question of
HOW something is done.
Hans-Joerg Frieden
>What can I say? You're an idiot. This is not intended to start a flame
>war. By making that statement you only prove without a single doubg that
I don't think that this kind of language is very effective when trying to
avoid a flame war, isn't it.
--
Hans-Joerg Frieden
>Ok Andor, you must now take a gun and blow your inherently useless brains
>all over the wall behind you. Of course planar is slower. Why in gods name
>do you think C= put the chunky to planar chip in the CD32?? for fun!
>Then you have very little clues about the world in general. The fact
>that chunky pixels make this easier is just so blindingly obvious that
>I'm surprised even the Braindead WaReZ D00dZ who keep insisting doom
>can be done on a 1200 don't realise.
Fact is: To do something like DOOM, you will have to redraw the entire
screen every frame.
Another fact: To draw 8 pixels in a chunky display, you will need 8 byte
access to the graphics memory.
And another fact: To draw 8 pixels in a planar display, you will need -
guess what - 8 byte accesses to graphics memory.
Someone saying 'DOOM requires chunky pixels' is as right as someone
saying 'this problem requires a turing machine'. It is just a question of
HOW something is done.
richard.m.brack
>
> Ok it goes like this.
> b=bit B=Byte.
> the Ibm's graphics are stored in memory like this:
>
> BBBBB
> BBBBB
> BBBBB - This is a 5 by 5 screen.
> BBBBB
> BBBBB
>
> The Amiga on the other hand would have.
>
> bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb
> bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb
> bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb
> bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb
> bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb bbbbb
>
> for a 5*5 256 colour screen.
wondering about something. Apparently AmigaOS 3.0 supports an interleaved
bitmap (hope I got the term right) screen. I don't know a lot about it,
but from what I understand it looks something like this:
bbbbb (scanline 1 from plane 1)
bbbbb (scanline 1 from plane 2)
bbbbb (scanline 1 from plane 3)
bbbbb (scanline 1 from plane 4)
bbbbb (scanline 1 from plane 5)
bbbbb (scanline 1 from plane 6)
bbbbb (scanline 1 from plane 7)
bbbbb (scanline 1 from plane 8)
bbbbb (scanline 2 from plane 1)
bbbbb (scanline 2 from plane 2)
bbbbb (scanline 2 from plane 3)
bbbbb (scanline 2 from plane 4)
bbbbb (scanline 2 from plane 5)
bbbbb (scanline 2 from plane 6)
bbbbb (scanline 2 from plane 7)
bbbbb (scanline 2 from plane 8)
etc....
Instead of each whole plane being seporate you have each scanline for each
plane next to each other. Soooooo, would you be able to do one blit to copy
all 8 planes for a pixel? Instead of doing chunck to planer would it be
better to write routines for interleaved bitmaps instead?
I don't have any technical info on the interleaved bitmaps. I've only
heard about it in the amiga groups. If I've misunderstood something
let me know...
Rich...
--
{ the itchman cometh /-/ _ i don't want to be your angel }
{ it...@cbnews.att.com /-/ _|_|_ i want to be your witch! }
{ att!cbnews!itch \-\/-/ ( * )tch -yello }
{ \/\/ /^\ }
Lars Garden
: I was hired to port a Doom-like game to the Amiga and it was a total
: flop. The 3000 was only HALF as fast as a 33MHz 386. The killer was
: that I was only using 64 colors. If I used 256, like the PC game, it
: would be even slower. However, a 4000/40 might have enough horsepower
: to produce a playable game.
Could you explain just how you could have managed 256 colors
on an ECS A3000?
Mark Brophy
: Fact is: To do something like DOOM, you will have to redraw the entire
: screen every frame.
: Another fact: To draw 8 pixels in a chunky display, you will need 8 byte
: access to the graphics memory.
: And another fact: To draw 8 pixels in a planar display, you will need -
: guess what - 8 byte accesses to graphics memory.
hehehehhehe Yeah and you code a routine which maps the graphics and
ever so convieniently spits out the data in interleaved format.
"To code, the impossible code. To blit, the unblittable screen"
: Someone saying 'DOOM requires chunky pixels' is as right as someone
: saying 'this problem requires a turing machine'. It is just a question of
: HOW something is done.
Sorry but I'm not quite sure which side you're arguing for here 8-)
Mark Brophy
: In article <2jvj3m$j...@harbinger.cc.monash.edu.au>, ins...@aurora.cc.monash.edu.au (Mark Brophy) writes:
: Very nice discription of chuncky and planer screens! But I have been
Thanks 8-)
: wondering about something. Apparently AmigaOS 3.0 supports an interleaved
: bitmap (hope I got the term right) screen. I don't know a lot about it,
: but from what I understand it looks something like this:
: (b)bbbb (scanline 1 from plane 1)
: (b)bbbb (scanline 1 from plane 2)
: (b)bbbb (scanline 1 from plane 3)
: (b)bbbb (scanline 1 from plane 4)
: (b)bbbb (scanline 1 from plane 5)
: (b)bbbb (scanline 1 from plane 6)
: (b)bbbb (scanline 1 from plane 7)
: (b)bbbb (scanline 1 from plane 8)
: bbbbb (scanline 2 from plane 1)
: bbbbb (scanline 2 from plane 2)
: bbbbb (scanline 2 from plane 3)
: bbbbb (scanline 2 from plane 4)
: bbbbb (scanline 2 from plane 5)
: bbbbb (scanline 2 from plane 6)
: bbbbb (scanline 2 from plane 7)
: bbbbb (scanline 2 from plane 8)
: etc....
Thats the one, and it is usually how graphics are stored.
from Amigados 1.0 8-)
: Instead of each whole plane being seporate you have each scanline for each
: plane next to each other. Soooooo, would you be able to do one blit to copy
: all 8 planes for a pixel? Instead of doing chunck to planer would it be
Well no you would have to write to the bits which are bracketed (above)
as one pixel. So it wouldn't work. The only way to do something similar
to this would be to use the blitplane modulo. and the blitter modulo.
Basically the blitter writes the blitplane modulo no of bytes
then jumps the blitter modulo before reading the next bit of data.
for your example above we could grab the first bitplane with
a bitplane modulo of 5 bits and a blitter modulo of 35 bits (ie. grab 5 bits
, jump over 35 and grab another five where each 5 bits is a scanline)
So if you had a bitplane modulo of 1 bit and a blitter modulo of 4 bits
(for above) you could grab one pixel or write it with the blitter.
Unfortunately as the blitter and bitplane modulos don't go as low as 1 bit 8-)
it acn't be done. Ahhhhh that was fun wasn't it 8-)
Email me if you don't understand. I wouldn't blame you with that discription.
8-)
Michael Robert Bromery
>John Bolton (jbo...@netcom.com) wrote:
>
>: to produce a playable game.
>
>Could you explain just how you could have managed 256 colors
>on an ECS A3000?
>
He probably didn't but somebody did! Core Design figured out a method to
pull out 256-color displays from even an A500. Their new graphic adventure
"Universe" (Comming out soon) that does it. The technique is called SPAC
for Super Pre-Adjusted Color. Gary Antcliffe is the programmer who designed
this interesting little miracle. Or trick? Whatever it is, the screens look
pretty nice with this blade-runner style graphics and nice detail and fog
effects. I don't know if this style of color scheme can work in anything
outside of graphic adventures though.
-- Mike Bromery.
Email: dave...@wam.umd.edu
Raffaele Lapietra
Mark Brophy
: >>That is total bullshit. I have seen an AGA-Demo that do 3D moving in
: >>realtime like DOOM. The limits to the frame speed is not caused by
Which demo was this? The fastest I've seen was Origin which wasn't that fast.
: grmpf, planar is NOT slower as chunky in general. It is slower if you try
This I know, but it is quicker to emulate chunky and convert to planar
than it is to map the graphics to planar in the first place.
In the case of Doom, this is obvious.
: to emulate chunky, because you have to move the ram 'bit by bit' and not
: in one instruction. But we're talking about DOOM and I say that you can
: do the graphics (moving around) without chunky emulation.
Ok like I said, If you can code a fast graphics mapping routine which spits
out data in interleaved format, I'll kiss your feet.
And again( I love it 8-)
"To code the impossible code, To blit the unblittable screen."
To the tune of "the impossible dream" for the clueless.
: But without the emulation Doom can not be ported to the Amiga because you
: have to programm absolutely new routines. That is the reason why Commodore
: put the chunky to planar chip in the CD32. PC games can easier be ported.
Hmm, I really don't think this is true. Granted in some (very few) cases the
chip would be used for this but I can't see many developers being THAT
lazy (what am I saying! 8-)
: >Then you have very little clues about the world in general. The fact
: >that chunky pixels make this easier is just so blindingly obvious that
: >I'm surprised even the Braindead WaReZ D00dZ who keep insisting doom
: >can be done on a 1200 don't realise.
: I have never saied that it is easier with planar. What's the problem ?
The problem is that your are saying (forgive me if you aren't) that you
can map the graphics onto say a wall in planar mode just a easily as you
can with chunky. This is simply not ture, as the biggest advantage of the
chunky display is that you can take one pixel and place it on the screen.
In planar mode this requires 1 or instruction for each plane and probably
a divide to find out where in a byte the bit you are trying to refer to
is located. With chunky you just copy one byte simple as that.
This is the easiest way I can think of to copy graphics if you only want
parts of it(which is what you want when you resize a piece of graphics).
Ricardo Hernandez
|>
|>
|> In a previous article, fre...@cis.uab.edu (Jason Freund) says:
|>
|> > Because I know how Wolf and DOOM are done -- I spent over a year
|> >
|> >Jason Freund
|> >(incidentally, look for rot3 with faq and src probably late this month)
|>
|> This may not be representative of your current work, and it
|> certainly is not meant as a personal attack, but rot2 bit.
|> Now, I realize this was the 'no-math' version I was running, but
|> if rot3 is an extension, no wonder it is so slow! Chris Green's tmapdemo
|> gets at the slowest 50 odd fps on my 1200. It hovers at 230 on my friends
|> 4000/040.
[stuff deleted]
This is not true. Chris stated that thanks to a bug in his 'fps
measuring code', the fps is not what is written to the screen.
A standard A1200 gives on the order of about 8-10 fps, with fast
ram about 14 fps. My A1200 with the '030 gives near 30fps...
|>
|> --
|> 'You see son, if this were Star Trek, we'd be negotiating with this Kobold.'
|> - Unknown Angband Player
|>
--
------------------------------------------------------------
Raist: "I'm BACK!"----> CSA '12 Gauge, A1200, Bernoulli 150
I LOVE IT!! //Image FX, SCALA MM210, Real 3D V2
\X/Opinions are my own, not of my college campus
Department of Electrical and Computer Engineering
Tomas Hubner
>> This method is purely hypothetical at the moment. I haven't been able
>Oh, it's not hypothetical at all! It has been done before, and it
>should work just fine, only you will need AGA (256 colors) to get any
>kind of nice resulution (2*2). This technique was discussed in
>amiga.demos some time ago, and according to those that tried it
>it doesn't eat very much buss-time at all.
Are you saying that someone has done this and used it as a chunky-display
in a 3D game? Or are you sying someone has used such a copper program?
I know there are demos of copper-screens and such but has it really been
incorporated in something that does a bit more than display cool graphics
and play a bit of music?
>> The advantage is that the CPU would not have to do the conversion and
>> the same time. (OCS/ECS 4096 and AGA 16.7M theoretically I don't know
>I think doing this trick on an ECS-chip would be pretty useless since
>the resolution would be so low. And on AGA you would still only
>get 4k colors onscreen with any efficiency. But thats still far
>from bad ;)
One might say it is sufficient, no?
(There is hardly any need for 16.7M colors since a normal hires-screen (640x500)
can't display more than ~320000 pixels=329k colors. (Lores (320x200) that
would be 64k.)
Hans-Joerg Frieden
>That game did not use texture mapping. It had pre-drawn graphics.
>--
>R.O.B.O.D.U.D.E.
>----------------
The game was only vector graphics. But what do you mean by 'pre-drawn'?
I guess most games have pre-drawn graphics. In the case of Corporation,
it had the enemy sprites being scaled like the baddies in WOLF/DOOM, just
no texture mapping - the dungeon layout was somewhat better than WOLF, and
I did like it better, too (better than WOLF - can't touch DOOM, though).
Tomas Hubner
>> This method is purely hypothetical at the moment. I haven't been able
>Oh, it's not hypothetical at all! It has been done before, and it
>should work just fine, only you will need AGA (256 colors) to get any
>kind of nice resulution (2*2). This technique was discussed in
>amiga.demos some time ago, and according to those that tried it
>it doesn't eat very much buss-time at all.
Are you saying that someone has done this and used it as a chunky-display
in a 3D game? Or are you sying someone has used such a copper program?
I know there are demos of copper-screens and such but has it really been
incorporated in something that does a bit more than display cool graphics
and play a bit of music?
>> The advantage is that the CPU would not have to do the conversion and
>> the same time. (OCS/ECS 4096 and AGA 16.7M theoretically I don't know
>I think doing this trick on an ECS-chip would be pretty useless since
>the resolution would be so low. And on AGA you would still only
>get 4k colors onscreen with any efficiency. But thats still far
>from bad ;)
One might say it is sufficient, no?
(There is hardly any need for 16.7M colors since a normal hires-screen (640x500)
can't display more than ~320000 pixels=329k colors. (Lores (320x200) that
would be 64k.)
--
Hans-Joerg Frieden
RP Needle
> Raffaele Lapietra <lapi...@panix.com> writes:
>
> >I found evrything you wrote very interesting, but I do have a question...
> >Doom on a 286?? I don't know much about IBM but from what I've heard you
> >need nothing less than a 486 to have Doom playable at all...
> >
> >I mean a buddy of mine couldn't play Doom on his system because all he had
> >was a 486SX with 4 megs of RAM! Guess he needs to juice it up a bit more...
>
> I've played DOOM on a 386DX-33 and it was very enjoyable. So we don't
> need comments like...."I played it on a friends Pentium and it was to
> choppy." OK?
> Another thing.... MOST people have DOOM v1.1. This version is VERY slow
> compared to v1.0 (original version)..... but v1.2 (when it's released)
> will return DOOM to 'light speed'.
>
> P.S. On my old 386DX-33, I had v1.1 and it was nice.
I hate to differ with you but i play doom on a 486 with a cyrus logic graphics
card. It uses a local 32bit bus and it still jerks when the screen becomes full.
Moving it down in to low detail helps but it still jerks when you look out over a courtyard. Shrinking the screen also helps as well but then the game begins to
look seriously poor.
I`m not saying that the game becomes unplayable but if a machine with
that sort of power can only just about handle it don`t go moaning about DOOM
not being possible on an Amiga. A1200 and below then your probably right. On
a 4000 it could be done quite convincingly.
Entity
Eyvind Bernhardsen <eyv...@lise.unit.no> wrote:
>In article <CLBoF...@cs.umu.se> chri...@cs.umu.se (Christer Ericson) writes:
>
> Well, I know virtually nothing about Amiga, but it is obvious that you
> know absolutely nothing about Macintosh. Macintosh has chunky pixels,
> has always had chunky pixels, and will always have chunky pixels (at
> least in the forseeable future). Does this mean we can laugh at you
> as well?
>
>Bloody hell. Talk about a waste of memory... One byte/pixel for a
>b/w screen? SOMEONE should be fired.
I'm not a mac guru, but from what I remember, the original macs *DID* have
planar screens. It was only the macII's that had the chunky 8/24 bit screens.
I'm not 100% sure about it being planar, but I remember looking at a friends
code who was writing an assembler version of life for his mac. He was writing
directly to screen memory, and I'm positive he was writing in a planar
fashion.
--
__
__ /// ent...@io.org (NTT@IRC)/[CCCAN!]
\\\ /// becker.gts.org!nsq!entity
HYBRID DEVELOPMENTS ent...@nixie.aus.org ara...@nyx.cs.du.edu
Karsten Weiss
AR> > IMHO, DOOM is not possible -- not even close -- even on an 040.
AR> >Obviously, this will incite a lot of flames on this group, so let me qualify
AR> >this: No existing Mac/Amiga will ever run DOOM as fast as a 286.
AR> very
AR>
AR> That is total bullshit. I have seen an AGA-Demo that do 3D moving in
AR> realtime like DOOM. The limits to the frame speed is not caused by
AR> planar or chunky pixels. In terms of speed, both methodes are equivalent.
It's no bullshit. You maybe saw Wolfenstein3D-like GFX. But *NOT* Doom.
It's a big difference. And the limit is the planar mode! BTW: The gfx
you saw are mostly cheap tricks using the copper or a vertical copper
mirror...
AR> > Wolf was barely possible since there were so many
AR> >limitations that happened to just barely fit in the Amiga's schemes.
AR> >DOOM does lots of things that could never be done using any chunky
AR> >pixel emulation scheme on the Amiga.
AR>
AR> Ambermoon does not emulate chunky pixel (it runs with planar scrolling)
You won't see the chunky pixels as they are in fast mem! However, I
didn't check Ambermoon personally...
AR> and is very fast on my A4000/30. And I must say that I can't see the
AR> need for emulating chunky pixel.
You're no programmer, are you?
So long,
Karsten
+--------------------------------------+----------------------+
| UUCP: kar...@addx.stgt.sub.org | 'Life Is Ours, |
| FIDO: 2:2407/106.10 (Karsten Weiss) | We Live It Our Way' |
| VOICE: +49-(0)7192-8444 | (Metallica) |
+--------------------------------------+----------------------+
| DON'T SEND ME LARGE FILES!!! | PGP key on request! |
+--------------------------------------+----------------------+
A.J.Amsel
Firstly, I apologise for posting this to games again!
> Another fact: To draw 8 pixels in a chunky display, you will need 8 byte
> access to the graphics memory.
True
> And another fact: To draw 8 pixels in a planar display, you will need -
> guess what - 8 byte accesses to graphics memory.
Sort of true. By kepping everything stuck in registers you can do the bit
operations in them. Then 8 byte accesses to memory are needed as you say.
But there are still several(when you consider the loops anyway) extra
instructions needed to set the appropriate bits for each bitplane. In chunky
mode a straight copy can be done. This is impossible to do on the Amiga.
Sad, but true.
> Someone saying 'DOOM requires chunky pixels' is as right as someone
> saying 'this problem requires a turing machine'. It is just a question of
> HOW something is done.
Maybe someone can do Doom without chunky pixels. But it would be very hard to
get the speed faster than with a chunky mode/converter.
Alex
Peter McGavin
>The problem is that your are saying (forgive me if you aren't) that you
>can map the graphics onto say a wall in planar mode just a easily as you
>can with chunky. This is simply not ture, as the biggest advantage of the
>chunky display is that you can take one pixel and place it on the screen.
>In planar mode this requires 1 or instruction for each plane and probably
>a divide to find out where in a byte the bit you are trying to refer to
>is located. With chunky you just copy one byte simple as that.
>This is the easiest way I can think of to copy graphics if you only want
>parts of it(which is what you want when you resize a piece of graphics).
It's true that texture mapping to planar mode is slower/harder than
with chunky. But it's not nearly as slow as you make out, when the
best algorithms are used.
There is certainly no need to write to every plane for every pixel.
It's much better to group pixels and then write to each plane for each
group. The best full-screen c2p routines convert 8 or 32 pixels
simultaneously entirely in CPU-registers. Even then they don't make 8
passes to extract individual bits. Instead they use O(log(N))
divide-and-conquer techniques (so there are 3 phases, not 8). They
convert all the pixels simultaneously in the same time it would take
to convert 1 or 2 pixels alone. They finish up doing exactly the same
number of writes to video RAM as chunky would. There are no divides
involved.
Another approach is to use the blitter for c2p. With fast RAM, the
blitter can run in parallel with the CPU without slowing it down. In
that case the main program runs exactly the same as it would on an
equivalent PC, and at the same speed. Unfortunately the blitter is
limited to less than 9fps for 320x200x8.
--
Peter McGavin. (pet...@maths.grace.cri.nz)
ove...@vax.sbu.ac.uk
In case anybody hasn't considered this (which will probably not be
the case), has anybody considered turning the screen sideways (physically)
then using the normal scanlines to draw the ray-cast texture scaled lines
(as used in W3D & Doom). This would mean you'd write a stream of bytes
in a line, which would be more efficient than moveing down a scan-line for
each texture mapped pixel write ?
Any ideas/comments much appreciated.
regards,
Paul...
--
"...even with an IQ of 6000, it's still brown trousers time."
Rene Rivera
wrote:
>
> In case anybody hasn't considered this (which will probably not be
> the case), has anybody considered turning the screen sideways (physically)
> then using the normal scanlines to draw the ray-cast texture scaled lines
> (as used in W3D & Doom). This would mean you'd write a stream of bytes
> in a line, which would be more efficient than moveing down a scan-line for
> each texture mapped pixel write ?
>
I have. I'm currently working on an algorithm to do the raycasting row
by
row instead of column by column. My present design would surpass DOOM in
some
ways: allow walls of any size and angle, independent of chunky or planar
display. But, don't get your hopes up to high, just like it took ID a long
time
to develope their system, it will also take me some time to do the same.
PS. I will release demos as I finish stages of the system.
_________
| _____ | ! Rene Rivera ! rr rrrrr
| | ___| |___ ! riv...@ils.mwu.edu ! rrrr
| | | _| |_ | ! ! rr rr rrrr
| |_| |_| | | | ! The Institute for the Learning Sciences ! rr rrrr
|___| |___| | | ! Northwestern University ! rrrrr rr
| |_____| | ! 1890 Maple Avenue ! rr
|_________| ! Evanston, IL 60201 ! rrrrr
Hans-Joerg Frieden
>: Fact is: To do something like DOOM, you will have to redraw the entire
>: screen every frame.
>: Another fact: To draw 8 pixels in a chunky display, you will need 8 byte
>: access to the graphics memory.
>: And another fact: To draw 8 pixels in a planar display, you will need -
>: guess what - 8 byte accesses to graphics memory.
>hehehehhehe Yeah and you code a routine which maps the graphics and
>ever so convieniently spits out the data in interleaved format.
I didn't even mention anything about interleaved format. I just stated
that drawing 8 pixels (... well read above). What I mean is that
it is no problem to avoid much poking around in chip ram. You must, of
course, somehow get the 8 planar bytes and write them to chip mem at once.
This is possible, just draw 8 columns at once (or even better, 16, to
do word access to chip ram). I did not say that planar graphics is better
suited for the job, just that it isn't THAT much of a problem (someone
said c->p consts 5 % computational time).
>"To code, the impossible code. To blit, the unblittable screen"
????
>: Someone saying 'DOOM requires chunky pixels' is as right as someone
>: saying 'this problem requires a turing machine'. It is just a question of
>: HOW something is done.
>Sorry but I'm not quite sure which side you're arguing for here 8-)
My own, of course 8-). I am arguing for the Amiga side, of course. What I wanted
to say in the first place is that just having a planar display is no excuse why
it can't be done (which is, in my opinion, false).
Hans-Joerg Frieden
> He probably didn't but somebody did! Core Design figured out a method to
>pull out 256-color displays from even an A500. Their new graphic adventure
>"Universe" (Comming out soon) that does it. The technique is called SPAC
>for Super Pre-Adjusted Color. Gary Antcliffe is the programmer who designed
>this interesting little miracle. Or trick? Whatever it is, the screens look
>pretty nice with this blade-runner style graphics and nice detail and fog
>effects. I don't know if this style of color scheme can work in anything
>outside of graphic adventures though.
not suited for fast moving graphics, but who cares? I like graphic adventures,
and this sounds really interesting. It would be a good way to show Sierra what
stupid ports they did.
Hans-Joerg Frieden
> Floors and ceilings are IMPOSSIBLE ? What gave you that idea ?
> They're not that difficult . Most stuff can be precalculated
> so that you just step through tmaps . What do you mean by
> outside ? I've been told Ambermoon has simple floor and
> ceiling tmapping .
Actually, the tmaped floors and ceilings in Ambermoon are quite good. They
are perspectively drawn, not copper-generated. There are even different types
of tmaps, grass for outside, stone tiles for castles and such, and rock for
caves. They look darn good, and that's all I need. Doom-style floor heights would
be nice, and I don't think that this is that far away.
Marc 'Nepomuk' Heuler
> It's no bullshit. You maybe saw Wolfenstein3D-like GFX. But *NOT* Doom.
> It's a big difference. And the limit is the planar mode! BTW: The gfx
> you saw are mostly cheap tricks using the copper or a vertical copper
> mirror...
A) For fast Amigas the limit is not planar mode, the limit is chip bus
timing.
B) You claim, DOOM does not use cheap tricks?!
--
Fuer manche Leute ist ein Gehirnschlag ein Schlag ins Leere.
// Marc 'Nepomuk' Heuler - Amiga software developer - PGP 2.x key on demand
\X/ UUCP: ma...@aargh.incubus.sub.org ZNetz: marc%aa...@incubus.zer IRC: Nepi
U38...@uicvm.uic.edu
ams made a demo called Full Moon with a chunky pixel room very simalar to Doom.
It can be made, if they really want to make it. But since you need a 486 and a
fast processor for the ibm, the amiga should be able to do it with a amiga 1200
I played it and it is very nice. But IBM is far from being good with games.....
/\/\acho /\/\an
Peter McGavin
>Hans-Joerg Frieden (in...@apollo23.uni-trier.de) wrote:
>: course, somehow get the 8 planar bytes and write them to chip mem at once.
>: This is possible, just draw 8 columns at once (or even better, 16, to
>
>to yank the appropriate bits out before you put the data into chipmem
>which is a major slowdown.
On an A4000/040 with a good c2p routine the c2p introduces no slowdown
at all, because the Chip bus is the bottleneck, not the c2p. That is,
the c2p converts pixels so fast that the CPU has to wait for the Chip
bus. Data are written to graphics memory at the maximum speed the
hardware allows, whether there is a c2p or not.
On slower processors the c2p introduces a slowdown. However one
cannot conclude from this that Wolf/Doom is impossible, only slower
than with chunky hardware. And the speed difference isn't that great,
given the latest c2p algorithms. (Have you tried Aminet:
gfx/show/flick-1.2.lha yet?)
--
Peter McGavin. (pet...@maths.grace.cri.nz)
David Edwards
texture mapping routine yet), but surly isn't this whole thread an issue
of how you look at things?
We are currently discussing how we could convert a game which
runs on a chunky system to a planar system. I would guess that the
routine that does the texture mapping works by calculating the
orientation of the surface, and then calculating the colour of a
particular pixel by rotating and scaling the texture map. The output of
this stage is then presumably dropped into the correct pixel on the
chunky display.
However, if the routine was designed for planar, then instead of
throwing out the graphics pixel by pixel, we could store up the bits in a
few registers, and then output the pixels to the bit-planes in word or
byte sections, thus using the same number of memory writes for 8 pixels
as Chunky (maybe less, in fact, if we are not using 8 bitplanes).
Admitedly this involves a few logical shifts to get the colour
bits in the right places in the registers, but register writing is faster
than memory writing, so it should save some time.
Perhaps I am barking up the wrong tree, so feel free to point out
the flaws in my thoughts....
David
--
_ _
==========////====================================================
/ //// David Edwards: Welcome to the real world... \
|| _ _ //// send mail to: ||
|| \\\\ //// edwards%teaching...@ox.ac.uk ||
\ \\\X/// or u93...@ecs.ox.ac.uk /
====\XXX/=========================================================
A.J.Amsel
If you turn the Cache off on this demo then it runs quite a lot slower.
This means that even on their simple (but nice!) routine they are in trouble
for cpu time.There are a lot of changes that need to be made to convert it
into a game. Trust me, I`m doing it. Hopefully it will no longer need fast
mem thank god.
Alex
.
: Because I know how Wolf and DOOM are done -- I spent over a year
: looking for and finding almost every possible speedup for the Amiga, and
: because I think I have actually created the best Wolf type engine for
: the Amiga so far, I feel qualified to comment here. Besides, I'd hate to
: miss out on a great flame war ;)
: My roommate and I wrote a Wolf-type enging for the Amiga about 1.5
: years ago called rot2. Rot3 was finished a year ago: it has:
: * 288 X 175 pixel full-height walls, texture mapped
: * 20 fps on 030, 30 fps on 040
: * variable size/shape screen
: * variable light sourcing, dimming
: * each wall is unique texturemap composed of assortment of decorations
: * animated walls
: * doors/secret doors
: I will use rot3 as a measuring tool for what is possible since
: I have seen a half dozen slower Wolf-type programs and have a feel for their
: algorithms and how fast things can be made to go.
: I laugh whenever people compare processor speeds and conclude that
: Wolf/DOOM could be done on a Mac or Amiga because the Mac and Amiga (both would
: run a DOOM simulation at the same speed, incidentally) don't have the 1
: critical thing that makes DOOM INHERENTLY ~8-10 times faster on the IBM than on
: the Amiga: chunky pixels. On the Mac/Amiga, for every pixel you need to
: do logical operations in each bitplane to read and write the pixel from/to
: the appropriate byte in memory. On the IBM, all these operations are done
: at once because you can simply pick up a pixel and put it down in 1 move.
: So at the innermost level (where 85% of the work is really done), the IBM
: is inehrently at least 8 times faster.
: The only way that anyone has ever achieved partial success on
: the Amiga is to emulate chunky pixel mode. This requires a lot of work and
: a lot of careful bit manipulation and pre-computing lots of data. But even
: with all this work, you still have to do 3-4 times as much work for each
: pixel than you would on the IBM. That is why you need cache, fastram, and
: fast processor. Algorithms using the blitter end up slower than
: processor-based so any good DOOM wouldn't touch the blitter.
: IMHO, rot3 is evidence that wolf can be done on the amiga -- however:
: rot3 has no monsters (that would induce a good 20% slowdown). rot3 does
: require an 030 WITH fastram because the algorithms are extremely dependant on
: a cache, a fast processor, AND fast memory for the Amiga.
: IMHO, DOOM is not possible -- not even close -- even on an 040.
: Obviously, this will incite a lot of flames on this group, so let me qualify
: this: No existing Mac/Amiga will ever run DOOM as fast as a 286. I am very
: confident about this. Wolf was barely possible since there were so many
: limitations that happened to just barely fit in the Amiga's schemes.
: DOOM does lots of things that could never be done using any chunky
: pixel emulation scheme on the Amiga. We might be able to pick up a few
: tricks from DOOM that weren't in Wolf at very little speed loss, but
: some things are actually IMPOSSIBLE (floor, ceiling, outside). Note:
: IMPOSSIBLE means: Impossible to implement on Amiga and have it go as fast
: as DOOM on 286. And an even longer list of DOOM things would slow down an
: Amiga engine to make it intolerably slow.
: Jason Freund
: (incidentally, look for rot3 with faq and src probably late this month)
: --
What about the possibility of DOOM on an Akiko equiped Amiga? Could
DOOM then run at decent speeds on an CD32 or would you need atleast the power
of an 030 to run at decent speeds ?
Eric Schug
Hans-Joerg Frieden
[stuff deleted]
>Interleaved format is basicaly planar mode just kind of stored in one
>big chunk. Change that to spitting out the data in planar mode, and
>thats what I meant.
Yup, I know what interleaved format is. It is quite usable with the
blitter, but since the blitter won't help very much here, I don't see why
one should bother with this.
>: that drawing 8 pixels (... well read above). What I mean is that
>: it is no problem to avoid much poking around in chip ram. You must, of
>Yeah sure this is true.
>: course, somehow get the 8 planar bytes and write them to chip mem at once.
>: This is possible, just draw 8 columns at once (or even better, 16, to
>Yes and you are essentially doing a c2p routine here. You simply have
>to yank the appropriate bits out before you put the data into chipmem
>which is a major slowdown.
No, I ain't. What I am saying here is only about writing to chip mem.
Lets assume I would use the z-buffered method. I would draw 8 columns of
the buffer at once. My data never was and never will be anywhere near
chunky format (This is hypothetical, of course). I though about a format
to store the bitplanes that would help here, which is quite complicated
to explain. If someone is interested, I could post it, anyway.
>: do word access to chip ram). I did not say that planar graphics is better
>: suited for the job, just that it isn't THAT much of a problem (someone
>: said c->p consts 5 % computational time).
>That someone was lying to you 8-)
That may be. I just said what this guy said. Since I don't have anything
running at the moment, this is merly theoretical.
>: >"To code, the impossible code. To blit, the unblittable screen"
>: ????
>Just my mind going into another dimension, ignore it.
OK, just done.
>8-) Why of course, just because you own an amiga doesn't mean you should
>argue for it. I don't think Doom can be done on a 1200 not because
>I own a PC, which I don't (wish I did, then I could play doom 8-)
>but because I think the c2p overhead is just too high.
To be honest, I always though that the Amiga was far superior to the PC,
in any regard. The fact that Doom exists only on PC's did very little to
spoil that belief. Well, in fact, I also own a PC, but I don't use it much.
>:to say in the first place is that just having a planar display is no excuse why
>:it can't be done (which is, in my opinion, false).
>Yes it is on a 1200. On a 4000/40 I think it could be done, as the 040 has
>the brute power to handle it but an 020 just doesn't cut it.
Something with the size of Doom is obviously not possible on a stock
1200, I agree with you. BUT, I think that a '030 already has enough power
to handle this. In fact, I know of someone who has a DOOM-Like engine
running, and it runs around 15 frames on a A3000, which should be a wee
faster on a 4000/30. It does around 25 fps on a 4000/40, and _that_ is
fast enough. In fact, the PC version only runs reasonable on a 486, or a
386/40 if you switch to lores and/or resize the screen. 'Tis something a
normal 1200 could hardly handle.
>Just out of curiosity, what is the extent of your programming knowledge.
>It's just that you seem so sure that the c2p is not so much of an overhead,
>and either you are arguing blindly or have some evidence of your claims.
I did quite a few programs in the past, although that were mostly
applications and stuff. Somewhere back in the Mists of Time, I did some
three or four demos which never made it to publicity (you know, sinus
scrollers and a bit of vector graphics). My knowledge is generally in
application programming. But I think that I didn't claim anything. I just
said 'it could be done' and such, and I never even said 'I could do it'.
I am currently trying to get a Wolf-Type engine running, but results are
still light years ahead.
>(that sounded nasty but wasn't intended to be, hey it's 2am forgive me 8-)
It did, but I forgive you 8-).
Greetinx, Hans-Joerg.
Hans-Joerg Frieden
>given the latest c2p algorithms. (Have you tried Aminet:
>gfx/show/flick-1.2.lha yet?)
I have tried flick-1.2, and I was amazed by its speed. It did around 25
frames on my brothers 4000/30 in 8 planes, and about the same on my 2000
in 6 planes. It also shows that doing this compare thing (you know,
compare the new frame with the old and draw changes only) does a great
deal of speed gain. However, I fear that this wouldn't help with a
WOLF-Type game, since it would almost always redraw the entire screen,
even more so if the floor and ceiling are tmapped. One would surely gain
speed with non-mapped floor/ceiling, and when the player is standing and
only monsters are moving.
I am now considering to try a Wolf-Engine with a c2p-routine.
McGarry T N
[stuff deleted]
: However, if the routine was designed for planar, then instead of
: throwing out the graphics pixel by pixel, we could store up the bits in a
: few registers, and then output the pixels to the bit-planes in word or
: byte sections, thus using the same number of memory writes for 8 pixels
: as Chunky (maybe less, in fact, if we are not using 8 bitplanes).
: Admitedly this involves a few logical shifts to get the colour
: bits in the right places in the registers, but register writing is faster
: than memory writing, so it should save some time.
To take advantage of planar you really need a routine that
works by scaling rows ( so you can get 8/16 consecutive
pixels ) . Unfortunatley wall tmapping usually involves
scaling columns so planar wouldn't be a good idea .
Out of interest does anyone know the fastest way to rotate
a screen 90 degrees . Then you could scale rows and just
rotate to give the walls , making planar tmapping just about
possible . My method only needs each column to be shifted
vertically , but optimising it is proving difficult .
Basically I think chunky emulation is the easiest ( and
currently most effective ) way to tmap .
Tony
Peter McGavin
> We are currently discussing how we could convert a game which
>runs on a chunky system to a planar system. I would guess that the
>routine that does the texture mapping works by calculating the
>orientation of the surface, and then calculating the colour of a
>particular pixel by rotating and scaling the texture map. The output of
>this stage is then presumably dropped into the correct pixel on the
>chunky display.
>
> However, if the routine was designed for planar, then instead of
>throwing out the graphics pixel by pixel, we could store up the bits in a
>few registers, and then output the pixels to the bit-planes in word or
>byte sections, thus using the same number of memory writes for 8 pixels
>as Chunky (maybe less, in fact, if we are not using 8 bitplanes).
>
> Admitedly this involves a few logical shifts to get the colour
>bits in the right places in the registers, but register writing is faster
>than memory writing, so it should save some time.
What you say could be possible, but personally I can't see how to
reduce the complexity enough (when there are lots of bitplanes). As I
see it, the problem is that this approach has to do something for
every pixel for every bitplane, or O(pixels*bitplanes) complexity.
With a chunky display, you only need to do one thing for each pixel,
or O(pixels) complexity. The fastest c2p algorithms are
O(pixels*log2(bitplanes)/n) complexity, where n is the number of
pixels converted simultaneously.
BTW, keep a lookout for Dominik Tonn's next version of Flip. He just
sent me a beta and it's about twice as fast as Flick 1.2! The bounds
for what is possible keep coming down.
--
Peter McGavin. (pet...@maths.grace.cri.nz)
Hans-Joerg Frieden
> Please correct me if I am wrong (I have not tried to write my own
>texture mapping routine yet), but surly isn't this whole thread an issue
>of how you look at things?
Of course it is, there are many people arguing about doing it chunky or
planar.
> We are currently discussing how we could convert a game which
>runs on a chunky system to a planar system. I would guess that the
>routine that does the texture mapping works by calculating the
>orientation of the surface, and then calculating the colour of a
>particular pixel by rotating and scaling the texture map. The output of
>this stage is then presumably dropped into the correct pixel on the
>chunky display.
Hmmm... I should say that this is too slow. Rotations are very costly, since
they involve trigonometric functions (which can be looked-up) as well as
multiplications. If you are interested, read the file 'notes.txt' in the
archive ACK.zip (or write me - I'll mail it).
> However, if the routine was designed for planar, then instead of
>throwing out the graphics pixel by pixel, we could store up the bits in a
>few registers, and then output the pixels to the bit-planes in word or
>byte sections, thus using the same number of memory writes for 8 pixels
>as Chunky (maybe less, in fact, if we are not using 8 bitplanes).
I have already proposed this once, but many people think this is impossible.
Andreas Schildbach
> : Obviously, this will incite a lot of flames on this group, so let me
> qualify
> : this: No existing Mac/Amiga will ever run DOOM as fast as a 286. I
> am very
> : confident about this.
Doom does not run on 286. It is 386 and up only!
- Andreas
Peter McGavin
>>given the latest c2p algorithms. (Have you tried Aminet:
>>gfx/show/flick-1.2.lha yet?)
>I have tried flick-1.2, and I was amazed by its speed. It did around 25
>frames on my brothers 4000/30 in 8 planes, and about the same on my 2000
>in 6 planes. It also shows that doing this compare thing (you know,
>compare the new frame with the old and draw changes only) does a great
>deal of speed gain. However, I fear that this wouldn't help with a
>WOLF-Type game, since it would almost always redraw the entire screen,
>even more so if the floor and ceiling are tmapped. One would surely gain
>speed with non-mapped floor/ceiling, and when the player is standing and
>only monsters are moving.
Well flick-1.2 is nowhere near the ultimate speed (even with the
NODBUF option turned on). Dominik Tonn sent me a beta of his flip
1.62 which is anything from about 40% faster to 6 times faster than
flick-1.2, depending on the FLI file. Most are about twice as fast.
Flip 1.62beta somehow avoids doing a full-screen compare, yet it
converts only the parts that change. I expect his new version will
turn up on Aminet soon.
Also flick's 8-plane c2p routines are slower than James McCoull's ones
(especially for full-screen), and flick's 4-plane c2p routines are
nowhere near my own fastest (e.g, like the one I posted a few days
ago). And flick still does all the RLE decoding in C, not assembly,
easily consuming 45% cpu time on a full-screen anim when it should
only be 10% or less.
A possible solution to the tmapped floor/ceiling problem has been
mentioned before. That is, use a 4+4 dual-playfield display with the
walls in the top layer and the floor/ceiling showing through from
behind. Then use a table-lookup 4-plane c2p (with frame-compare) for
the walls (which would be extremely fast) and copper effects for the
floor/ceiling texture (as used in the Team Hoi Saga III jetpack-bear
scene, for example), which would also be extremely fast.
>I am now considering to try a Wolf-Engine with a c2p-routine.
That's the way to go, I reckon.
--
Peter McGavin. (pet...@maths.grace.cri.nz)
Hans-Joerg Frieden
IMHO, the chunky display in Full Moon gives a new meaning to the word 'chunky':
It has very large pixels and small bitmaps. I think that the Wolfenstein effect
in this other demo (don't know the name, something with this walker and stuff)
looks much nicer (and much slower). Full Moon seems to use a copper list.
Karsten Weiss
MH> > It's no bullshit. You maybe saw Wolfenstein3D-like GFX. But *NOT* Doom.
MH> > It's a big difference. And the limit is the planar mode! BTW: The gfx
MH> > you saw are mostly cheap tricks using the copper or a vertical copper
MH> > mirror...
MH>
MH> A) For fast Amigas the limit is not planar mode, the limit is chip bus
MH> timing.
Yes, for fast (>=030) Amigas. But there is no market.
MH> B) You claim, DOOM does not use cheap tricks?!
No. I claim that copper planes or vertical copper mirrors are cheap
tricks because you can't make a game like DOOM with them! If you
use copper planes you are very limited by the horizontal resolution
(-> floor and ceiling will look damn ugly) and if you use vertical
copper mirrors you can't have walls that are not symmetrical. Also
with monsters. However, one could solve this by using a dual
playfield screen. But then: You would only get 16 colors on an
old Amiga (OCS/ECS).
I call everything a cheap trick that restricts the (DOOM) engine
elementary (as the upper mentioned trick do). That's why I call
people damn stupid who say that DOOM is possible on the A1200
JUST because they saw Full Moon by Virtual Dreams. WITH THIS
ROUTINE YOU CAN'T MAKE DOOM!
So long,
Karsten
+--------------------------------------+----------------------+
| UUCP: kar...@addx.stgt.sub.org | 'Life Is Ours, |
| FIDO: 2:246/1216.10 (Karsten Weiss) | We Live It Our Way' |
Stefan Boberg
>"Karsten Weiss" <kar...@addx.stgt.sub.org> writes:
>>Yes, for fast (>=030) Amigas. But there is no market.
>Commodore is selling ~40000 A4000 a month. Why is that no market.
Because Commodore are not selling 40000 A4000's a month, that's why. They
hardly even sell that many A1200's. This 40,000 figure is only a figment of
a certain person's imagination.
>Hans-Joerg Frieden ! EMail: ! //
>Schlossstrasse 176 ! in...@uni-trier.de (prefered) ! \\ // Amiga 2000
--
Stefan Boberg, Amiga/SEGA/CD32 programmer - Team 17 Software / LhA Devel.
Applied Physics and Electrical Engineering Student, Linkoping University
InterNet: bob...@lysator.liu.se bob...@team17.adsp.sub.org
========== Disclaimer: I only speak for myself, not Team 17. ============
Zsolt Szabo
>>Yes, for fast (>=030) Amigas. But there is no market.
>Commodore is selling ~40000 A4000 a month. Why is that no market.
I seriously doubt that. I'll bet even Gateway isn't selling that many
PCs, and don't tell me now that C= is outselling Gateway2000, one of the
most popular pc producers here in the US. I would really like to know
where you got that information from.
Michael Saunby
Who are Gateway? Guess they don't sell in the UK. Commodore do :-)
--
Michael Saunby (M.Sa...@reading.ac.uk)
Meteorology Dept, Reading University, UK
Paul Baulch
>Basically, I'd say that the major difference between Wolfenstein and Doom
>is the fact that you will have to trace longer rays in Doom, because a
>wall will not always stop your field of vision. Many people don't seem
>to notice that Doom isn't that much of a difference, and the main problem
>is a fast graphics output, not the tracing or game mechanics.
>
Can you inform me of even one single graphical effect in Doom that requires
the casting of rays? I haven't seen a single moving source of light in what
I have seen of the game (about 4 levels). I have seen no shadows. What makes
you think that the Doom engine can't have simple algorithms to change static
palettes to simulate light levels?
Or has someone who helped write the Doom engine actually SAY that it traced
rays?
And another thing - I have heard many posts on this subject say that you can
render polygons like Doom does with only one division operation per pixel.
Has anyone actually conjectured that it can be done with none? Because that
is what I am conjecturing. Bresenham's algorithm should make it possible.
Any Doom engine for planar which wants to be faster will have to set multiple
horizontal groups of pixels simultaneously, to cut down on the increased
number of memory acesses required to set a pixel.
--
-sh...@zikzak.apana.org.au--------------rec.toys.lego forever!!!-------------
-----Paul Evan Baulch------Reality is by far the most impressive simulation.-
Ron Asbestos Dippold
>the casting of rays? I haven't seen a single moving source of light in what
>I have seen of the game (about 4 levels). I have seen no shadows. What makes
How about Imp fireballs? And yes, there are no shadows.
>And another thing - I have heard many posts on this subject say that you can
>render polygons like Doom does with only one division operation per pixel.
>Has anyone actually conjectured that it can be done with none? Because that
You need to do something to get perspective like the division gives
you, or there will be noticable warping. But you can do a hyperbolic
approximation that looks good enough for something like this. I
believe this requires two or three divisions per line.
--
My kid just beat the snot out of your Honor Student.
Stefan Boberg
>in...@apollo23.uni-trier.de (Hans-Joerg Frieden) writes:
>>Basically, I'd say that the major difference between Wolfenstein and Doom
>>is the fact that you will have to trace longer rays in Doom, because a
>>wall will not always stop your field of vision. Many people don't seem
>>to notice that Doom isn't that much of a difference, and the main problem
>>is a fast graphics output, not the tracing or game mechanics.
>>
>Can you inform me of even one single graphical effect in Doom that requires
>the casting of rays? I haven't seen a single moving source of light in what
>I have seen of the game (about 4 levels). I have seen no shadows. What makes
>you think that the Doom engine can't have simple algorithms to change static
>palettes to simulate light levels?
Paul, you seem to have misunderstood what DOOM uses raycasting for. It
uses *2D* raycasting to determine what wall-segments to display at each
vertical span. I.e. it traces rays from the viewpoint like this:
| |
| |
/----+ +-----\
/ \ Field / \
/ \ of / \
| \visi-/ |
| \on / |
| \ / |
*
This way you don't have to do any 3D calculations or draw polygons. It is
also optimal in that you never draw a pixel twice. (In fact, DOOM isn't 3D,
it's a 2D game with 3D view).
>And another thing - I have heard many posts on this subject say that you can
>render polygons like Doom does with only one division operation per pixel.
>Has anyone actually conjectured that it can be done with none? Because that
>is what I am conjecturing. Bresenham's algorithm should make it possible.
You don't have do perform ANY divisions in a Doom rendering engine.
Certainly not one per *PIXEL*.
>-sh...@zikzak.apana.org.au--------------rec.toys.lego forever!!!-------------
>-----Paul Evan Baulch------Reality is by far the most impressive simulation.-
--
Peter McGavin
>Can you inform me of even one single graphical effect in Doom that requires
>the casting of rays? I haven't seen a single moving source of light in what
>I have seen of the game (about 4 levels). I have seen no shadows. What makes
>you think that the Doom engine can't have simple algorithms to change static
>palettes to simulate light levels?
Certainly DOOM doesn't fully raytrace. I think DOOM programmers talk
about casting rays in the following sense:
For each pixel-column on the screen, one determines which wall is
closest to the eye. To do this, a ray is "cast" from the eye through
a screen pixel into the model. The intersection with each wall is
computed, and the closest one is "it". In a full 3D raytrace you do
this (and a lot more besides) for every pixel. In DOOM (well, Wolf-3D
anyway) you only do it for every column, and the calculation is only
2D (no height).
I remember seeing an article about a way of avoiding a ray cast for
every column, by doing an initial cast and then following walls from
left to right. But right now, I can't see how this would work.
There are some totally different algorithms, which don't involve
ray-casts at all.
Disclaimer: I don't really know how DOOM does it.
--
Peter McGavin. (pet...@maths.grace.cri.nz)
Stefan Boberg
>In article <1994Mar20.1...@ida.liu.se> y91s...@odalix.ida.liu.se (Stefan Boberg) writes:
>: This way you don't have to do any 3D calculations or draw polygons. It is
>: also optimal in that you never draw a pixel twice. (In fact, DOOM isn't 3D,
>: it's a 2D game with 3D view).
> Uh? I wouldn't say that. Doom *is* 3D. you can climb stairs and
> walk in mid-air (with respect to the level of ground where you
> entered), or can climb down a flight of steps, etc...
Yes. But that's just a neat trick. There is never anything else but the
ceiling above any point on the map. I.e. the map is simply a 2D map with
an elevation constant for each `tile'.
> If you still doubt, activate one of the cheat modes that gives
> you your coordinates, and you will see X Y and Z.
Yes, but the map is still only 2D.
>Cedric BEUST, be...@sa.inria.fr, Bull Research Koala project
>click <A HREF="http://zenon.inria.fr:8003/koala/beust.html">here</A>
Cedric Beust
: This way you don't have to do any 3D calculations or draw polygons. It is
: also optimal in that you never draw a pixel twice. (In fact, DOOM isn't 3D,
: it's a 2D game with 3D view).
Uh? I wouldn't say that. Doom *is* 3D. you can climb stairs and
walk in mid-air (with respect to the level of ground where you
entered), or can climb down a flight of steps, etc...
If you still doubt, activate one of the cheat modes that gives
you your coordinates, and you will see X Y and Z.
Wolf3D, Blake Stone, etc... *are* 2D with 3D views.
--
Mark Brophy
>robo...@jhunix12.hcf.jhu.edu (Zsolt Szabo) writes:
>>In article <inf01.763825463@apollo23> in...@apollo23.uni-trier.de (Hans-Joerg Frieden) writes:
>>>>Yes, for fast (>=030) Amigas. But there is no market.
>>>Commodore is selling ~40000 A4000 a month. Why is that no market.
>>I seriously doubt that. I'll bet even Gateway isn't selling that many
>Doubt it if you must, but it IS true. I don't know where I've seen it,
>but I have definetly seen it. I don't know Gateway2000, but if they
>produce PC's, they have much more competition than Commodore.
And I've also seen somewhere that Elvis is still alive. Don't believe
everything you read. There is no way C= are selling that many.
Mark Brophy
Gregory G Greene
'>>Commodore is selling ~40000 A4000 a month. Why is that no market.
'>
'>I seriously doubt that. I'll bet even Gateway isn't selling that many
'>PCs, and don't tell me now that C= is outselling Gateway2000, one of the
'>most popular pc producers here in the US. I would really like to know
'>where you got that information from.
If CBM is selling 40K A4000's a month, there must be a lot of pissed
off Amiga users waiting for them. Because I doubt CBM could produce 40K
A4000's a month. They can barely afford to produce the CD32's and A1200's,
never mind producing A4000's at a rate half that of CD32's (roughly 10K
a week).
Gateway comes close by the way. Computer Shopper or PC Magazine
stated in one of the past issues that they were selling over a 1000 systems
a day (about 30K/month). Pretty awesome considering its one out of >100
PC manufacturers. SPA stated that PC's are selling at a ~25million/year
clip. Thats a tough clip to keep up with if you're a competing computer
maker.
Greg Greene
g...@kepler.unh.edu
Hans-Joerg Frieden
Doubt it if you must, but it IS true. I don't know where I've seen it,
but I have definetly seen it. I don't know Gateway2000, but if they
produce PC's, they have much more competition than Commodore.
--
Hans-Joerg Frieden ! EMail: ! //
Schlossstrasse 176 ! in...@uni-trier.de (prefered) ! \\ // Amiga 2000
Jaime R. Lopez Vazquez
|> sh...@zikzak.apana.org.au (Paul Baulch) writes:
|> >in...@apollo23.uni-trier.de (Hans-Joerg Frieden) writes:
|>
|> >>Basically, I'd say that the major difference between Wolfenstein and Doom
|> >>is the fact that you will have to trace longer rays in Doom, because a
|> >>wall will not always stop your field of vision. Many people don't seem
|> >>to notice that Doom isn't that much of a difference, and the main problem
|> >>is a fast graphics output, not the tracing or game mechanics.
|> >>
|> >Can you inform me of even one single graphical effect in Doom that requires
|> >the casting of rays? I haven't seen a single moving source of light in what
|> >I have seen of the game (about 4 levels). I have seen no shadows. What makes
|> >you think that the Doom engine can't have simple algorithms to change static
|> >palettes to simulate light levels?
|>
|> Paul, you seem to have misunderstood what DOOM uses raycasting for. It
|> uses *2D* raycasting to determine what wall-segments to display at each
|> vertical span. I.e. it traces rays from the viewpoint like this:
|>
|> | |
|> | |
|> /----+ +-----\
|> / \ Field / \
|> / \ of / \
|> | \visi-/ |
|> | \on / |
|> | \ / |
|> *
But then, how the DOOM engine handles the windows at the walls?
|>
|> This way you don't have to do any 3D calculations or draw polygons. It is
|> also optimal in that you never draw a pixel twice. (In fact, DOOM isn't 3D,
|> it's a 2D game with 3D view).
|>
|> >And another thing - I have heard many posts on this subject say that you can
|> >render polygons like Doom does with only one division operation per pixel.
|> >Has anyone actually conjectured that it can be done with none? Because that
|> >is what I am conjecturing. Bresenham's algorithm should make it possible.
|>
|> You don't have do perform ANY divisions in a Doom rendering engine.
|> Certainly not one per *PIXEL*.
Could anyone post a description of the Bresenham's algorithm or other
related one? My friend and I figured it out a (very simple) algorithm but it
involves several divisions.
|>
|> >-sh...@zikzak.apana.org.au--------------rec.toys.lego forever!!!-------------
|> >-----Paul Evan Baulch------Reality is by far the most impressive simulation.-
|>
|> --
|> Stefan Boberg, Amiga/SEGA/CD32 programmer - Team 17 Software / LhA Devel.
|> Applied Physics and Electrical Engineering Student, Linkoping University
|> InterNet: bob...@lysator.liu.se bob...@team17.adsp.sub.org
|> ========== Disclaimer: I only speak for myself, not Team 17. ============
Jaime Lopez
University of Puerto Rico, Mayaguez
mef...@rmece02.upr.clu.edu
Hans-Joerg Frieden
> Uh? I wouldn't say that. Doom *is* 3D. you can climb stairs and
> walk in mid-air (with respect to the level of ground where you
> entered), or can climb down a flight of steps, etc...
> If you still doubt, activate one of the cheat modes that gives
> you your coordinates, and you will see X Y and Z.
> Wolf3D, Blake Stone, etc... *are* 2D with 3D views.
DOOM might look 3D, but in fact is only a 2D map with a 3D view. Take a
look at the map, which is 3d. There are no such things as a bridge. Walls
only come from the ceiling or from the floor, and there is alway only one
"hole" in the ceiling, i.e. at every point of the playing area there is
exactly one surface from the floor, and one from the ceiling. This is
propably the way the map is stored, they store a floor height and a
ceiling height (for polygons). The X and Y coords are relevant for the
calculation of the scene, the Z coordinate "shifts" the screen up or
down, depending on how high you are.
I am not saying I know how DOOM is done (I don't), but I wanted to
express who it can be done without 3D calculation. Hope it became clear
what I meant.
Stefan Boberg
>In article <1994Mar20.1...@ida.liu.se>, y91s...@odalix.ida.liu.se (Stefan Boberg) writes:
>|> Paul, you seem to have misunderstood what DOOM uses raycasting for. It
>|> uses *2D* raycasting to determine what wall-segments to display at each
>|> vertical span. I.e. it traces rays from the viewpoint like this:
>|>
>|> | |
>|> | |
>|> /----+ +-----\
>|> / \ Field / \
>|> / \ of / \
>|> | \visi-/ |
>|> | \on / |
>|> | \ / |
>|> *
> But then, how the DOOM engine handles the windows at the walls?
By drawing the tiles above and below the windows first, and then continue
the ray-trace until it hits the next wall and draw that in the transparent
span.
> Could anyone post a description of the Bresenham's algorithm or other
>related one? My friend and I figured it out a (very simple) algorithm but it
>involves several divisions.
Read any decent book on computer graphics.
James McCoull
>Can you inform me of even one single graphical effect in Doom that requires
>the casting of rays?
You seem a little confused. People are not claiming that ray casting is
required for the pixel level rendering in DOOM, but instead for
determining which subset of the entire map is within the players view.
>And another thing - I have heard many posts on this subject say that you can
>render polygons like Doom does with only one division operation per pixel.
I havent seen these claims so I cant really comment. But for wall like
surfaces no divisions are needed, its merely a matter of shrinking/expanding
columns of pixels. For the floor of course the axis of viewer rotation
means a little more calculation [or more tables] are needed.
--
Shelter me for I am lost in a world | Rescue me for all I can do is try
That lost the will to be free | To escape this reality
Dying age a chronical of forgotten peace | Trip away color the night until the
Replaced by hate | Sun awakes another day
David Tiberio
>in...@apollo23.uni-trier.de (Hans-Joerg Frieden) writes:
>>robo...@jhunix12.hcf.jhu.edu (Zsolt Szabo) writes:
>>>In article <inf01.763825463@apollo23> in...@apollo23.uni-trier.de (Hans-Joerg Frieden) writes:
>>>>>Yes, for fast (>=030) Amigas. But there is no market.
>>>>Commodore is selling ~40000 A4000 a month. Why is that no market.
>>>I seriously doubt that. I'll bet even Gateway isn't selling that many
>And I've also seen somewhere that Elvis is still alive. Don't believe
CBM probably sells about 4000 Amiga 4000's worldwide per month.
I know where he read 40,000. From the same guy that said there
were 10 billion Amiga worldwide. :)
dtiberio
Hans-Joerg Frieden
>in...@apollo23.uni-trier.de (Hans-Joerg Frieden) writes:
>>Basically, I'd say that the major difference between Wolfenstein and Doom
>>is the fact that you will have to trace longer rays in Doom, because a
>>wall will not always stop your field of vision. Many people don't seem
>>to notice that Doom isn't that much of a difference, and the main problem
>>is a fast graphics output, not the tracing or game mechanics.
>>
>Can you inform me of even one single graphical effect in Doom that requires
>the casting of rays? I haven't seen a single moving source of light in what
>I have seen of the game (about 4 levels). I have seen no shadows. What makes
>you think that the Doom engine can't have simple algorithms to change static
>palettes to simulate light levels?
Raycasting is NOT Raytracing. It is similar, but not equal. The
Raycasting I mentioned above means to trace a ray for each column
onscreen on a 2D map. If the ray hits a wall, calculate the distance from
the screen the hit occured, and draw the wall section on the screen,
scaled. Basically Doom does the same as Wolfenstein. This has nothing to
do with lights. It is basically an algoritm to decide what is visible in
a certain column of your viewing window.
>Or has someone who helped write the Doom engine actually SAY that it traced
>rays?
No one said that DOOM does it that way. It is, however, very likely.
>And another thing - I have heard many posts on this subject say that you can
>render polygons like Doom does with only one division operation per pixel.
>Has anyone actually conjectured that it can be done with none? Because that
>is what I am conjecturing. Bresenham's algorithm should make it possible.
DOOM does not render polygons (at least I don't think it does). If it is
done as I imagine it is done, it won't need anything like that. In fact,
it doesn't even do 3D calculations. Note, I'm not sure about this, but it
should be possible to avoid this. You could use a Bresenham to do
incremental ray casting to draw the floor and ceiling texture, but I
guess it would be faster to do it the other way, i.e. for each pixel not
filled with a wall, calculate which pixel of the texture is represented.
>Any Doom engine for planar which wants to be faster will have to set multiple
>horizontal groups of pixels simultaneously, to cut down on the increased
>number of memory acesses required to set a pixel.
Obviously, this would be a lot faster. I think it is best to spread chip
mem accesses as wide as possible, to avoid that the CPU waits for the
chip bus too much. I think word-writes come in handy on ECS, too.
Greetinx, Hans-Joerg.
--
Hans-Joerg Frieden ! EMail: ! The Borg
Schlossstrasse 176 ! in...@uni-trier.de (prefered) ! SpreadSheet:
54293 Trier ! hfri...@treveris.uni-trier.de !
++49 (0) 651 66410 ! fri...@rzbsdi01.uni-trier.de ! Locutus 1-2-3
Hans-Joerg Frieden
>look at the map, which is 3d. There are no such things as a bridge. Walls
OOPS. Damn it. This should read 2D, of course.
Hans-Joerg Frieden
> But then, how the DOOM engine handles the windows at the walls?
Simple. Have you ever seen two windows in a single wall? No, you haven't. Actually,
DOOM has two maps, one for floor, one for ceiling. Windows are just the space between
a wall rising from the floor and another one falling from the ceiling.
> Could anyone post a description of the Bresenham's algorithm or other
>related one? My friend and I figured it out a (very simple) algorithm but it
>involves several divisions.
> mef...@rmece02.upr.clu.edu
You might want to check out the Book GRAPHIC GEMS, by Andrew Glassner. It contains
several opptimized versions of Bresenham line and circle algorithms, along with
some other additional routines you might find useful. I also have a source around
somewhere, mail me if you need it, and I will check out if I still have it.
Greetinx, Hans-Joerg.
Tomas Hubner
>sh...@zikzak.apana.org.au (Paul Baulch) writes:
>>And another thing - I have heard many posts on this subject say that you can
>>render polygons like Doom does with only one division operation per pixel.
>I havent seen these claims so I cant really comment. But for wall like
>surfaces no divisions are needed, its merely a matter of shrinking/expanding
>columns of pixels. For the floor of course the axis of viewer rotation
>means a little more calculation [or more tables] are needed.
The floor isn't much different when you're down at pixel level. There's some
overhead calculations and you render the floor/ceiling horizontally instead
of vertically. (At pixel level I think there is an additional add necessary.)
--
Tomas Hybner
Nothing is impossible, it's just that some things are so darned difficult
they can't be done. Yet.
Hans-Joerg Frieden
>'>I seriously doubt that. I'll bet even Gateway isn't selling that many
>'>PCs, and don't tell me now that C= is outselling Gateway2000, one of the
>'>most popular pc producers here in the US. I would really like to know
>'>where you got that information from.
> If CBM is selling 40K A4000's a month, there must be a lot of pissed
> off Amiga users waiting for them. Because I doubt CBM could produce 40K
> A4000's a month. They can barely afford to produce the CD32's and A1200's,
> never mind producing A4000's at a rate half that of CD32's (roughly 10K
> a week).
OK, forget it. I never said anything. As I stated earlier, I don't work
for C=. I don't buy all the f*cking amigas in the world, so I don't
actually know how much are sold. I can only rely on what I read. Why do
you all think YOU know what is right, eh?