Why is a DOOM port so hard?
Jonathon Gregory
>--
>why is it that DOOM is so hard to port. I agree it is an *awesome* game,
>but
>the graphics are not that spectacular (though the variety of rooms is amazing).
>Why wouldn't a decent 040 machine be able to run this game?
Dooms is relatively easy to port to the Mac, it as hard to make it run fast
(and Dooms speed is a large contribution to it's "play-ability", IMHO)..
(also the full scree and/or almost full screen is a major factor too)
I will run down the reasons why I think that Doom is hard to get onto the
Mac. And it all has to do with the video HARDWARE of the machine..
Not the processor, or the operating system..
The video resolution of DOOM on the IBM as I understand can be 320x200
(or something like that) pixels, and that resolution in VGA mode (please
forgive any ibm naming convention mistakes, I'm not a native ibmer) can
fill the entire screen, while on the Mac a full screen of a 13" monitor (
is 640x400 pixels, so there is four (4) times as many pixels per screen to
move (lets say for simplicities sake, a slowdown factor of 4)..
640x400 pixels equals 256000
320x200 pixels equals 64000
Now the second slow down factor is.. the Mac has one area of memory
dedicated to one monitor (what is in that area is displayed on the screen)
..the ibm can have the portion of memory to be displayed by the video
card specified by a single memory location (i.e., word, register, etyc..)
in other words, with one instruction to the ibms standard type of video
card you call tell the card to display what is in memory section A...
and with the next instruction you call tell the card to display what is
in memory section B. This switch from section A to B occurs in one
clock cycle of the machine (a millionth of a second or less).. for all
practical purposes we can and will say it is instantaneous! Now with this
information in hand let me continue...
The game of DOOM, lets hypothetically say for example purposes, calculates
player movement, monster monement, and player monster environment
interaction. From this information the game then calculates the view
"seen" by the player, draws the view "seen" by the player, and then
displays the view "seen" by the player.. This last sentence is where
the Macs video hardware forces a large slowdown.. you see...
..on the ibm and Mac the calculating the view, and the drawing of the
view, might take roughly the same ammount of time but...
..the ibm draws the new view into memory section B then with one
instruction instantly displays section B, then draws then next view into
memory section A, then with one command instantly displays section A, then
the ibm draws then next view into memory section B then with one
command instantly displays section B, and back and forth and so on..
.. This technique is known as "page-flipping" (because the sections of
memory that is displayed has been/is refered to as a page)...
(because "page-flipping is "instantaneous" it is usally a "clean" transition
from one page to the next)
while the Mac has only memory section X for video display so it's cycle
to display a DOOM like game is draw the next view, then copy that view
pixel by pixel (OK byte by byte) into memory section X, then draw the next
view, then copy that view pixel by pixel into memory section X,then draw
the next view, then copy that view pixel by pixel into memory section X,
etc... for a game with intracate graphics you really can't draw onto
the visible display memory area because the drawing process is slow
enough that the game player will be able to observe the view being
drawn, (i.e., first horizon, then back walls,monsters,front walls,
.. all objects from furthest away to closest) and this would destroy the
smoothness of the gameplay. If there was a home machine (mac or ibm) that
was fast enough to draw the complicated "3-dimensional" view in the
milisecond (one-thousandth of a second) that the electron beam of the
computer monitor (CRT) is blacked out and being "returned" to the top
of the screen then "page-flipping" would not be neccessary..
actually, now that I think about it you have to draw the scene
somewhere in memory in under 1/30th of a second then just have enough
speed to be able to COPY that section of memory into the visible display
memory section during the time the beam is blacked out and being
"returned" to the top of the screen, THEN "page-flipping" would not be
neccessary, so...
to sumarize.. because of pixels on screen the Mac needs to be four (4)
times faster and also, because the Mac must copy pixels to the "screen"
(instead of "page-flipping") there is additional overhead..
So my really really REALLY rough estimate of mac to ibm speed DOOM ratio
is arround 10 ( TEN )..
That is to say if you have an ibm pc with a given "speed" (i.e., specmark,
computational horsepower, numbercrunching capability).. then a Mac
will need to be ten ( 10 ) times as "fast" to get the same frame rate on
a full screen.. (although it will look four times better because of the
higher resolution, IMHO )..
..and all because of the video hardware!
For all you technical people, remember the original question requested a
non-technical answer, and I have tried to keep it as such (with the
risk of loosing some accuracy). If someone has a better/simpler answer
feel free to post it..
..but I felt I had to post something after seeing all the "why don't
we have DOOM on the Mac, the Mac's is just as fast as the ibm, it's not
the video cards speed, etc. postings I've seen here.. perhaps
this will clear some of the questions up...
Arnold Kim
> I don't think double buffering is a standard VGA feature, and Doom may
not
Doom uses triple-buffering, in fact... and it is standard VGA.
> use it. Even if it does, the performance hit for blitting an offscreen
> In fact, there are some major speed problems on the PC with respect to
> video. Ever wonder why so few PC games run at resolutions higher than
> 320x200? It's because 320x200 is the only 256 color resolution which
will
> fit in a single 64K segment of memory. Go any higher, and you have to
> fool around with your video memory residing in different segments.
Memory
> segmentation BITES! Only recently have these problems begun to be
solved
> on the PC.
I don't think this is necessarily true... but I think a more important
reason that PC games don't venture past 320x200x256 is because there is
no (fast) standard way to access video at higher resolutions. You'd have
to write custom for every video card or use the existing (slow) drivers
for it.
arnold
Lincoln A. Kallsen
why is it that DOOM is so hard to port. I agree it is an *awesome* game, but
the graphics are not that spectacular (though the variety of rooms is amazing).
Why wouldn't a decent 040 machine be able to run this game?
-------------------------------------------------------------------------------
"I know this, because I encounter them on the Internet, which is a
giant international network of intelligent, informed computer
enthusiasts, by which I mean, "people without lives." - Dave Barry
-------------------------------------------------------------------------------
Lincoln A. Kallsen College of Education
kall...@maroon.tc.umn.edu University of Minnesota
136-A Burton Hall
178 Pillsbury Dr. SE
Minneapolis, MN 55455-0211
Arnold Kim
> absolutely no sense.
This was discussed endlessly on rec.games.programmer... but I think it
goes something like this:
Say you calc/draw on screen 1, then you calc/draw on screen 2, trigger a
page flip... but you can't start calc/drawing on screen 1 again until
you're sure that the page flip has happened - which is upon the vertical
retrace.
ex: page 1 is being displayed, you finish drawing page 2, and trigger a
page flip - but the scan gun is at pixel line 2 on page 1 at that exact
moment. Since the page-flip happens at vertical retrace, If you start
drawing on page 1 (anywhere below the scan gun), you're going to
accidentally draw stuff that shouldn't be displayed until after page 2 is
completely displayed. So, if you only have 2 buffers you have to wait
until the scan gun makes its way from pixel-line 2 all the way down the
screen to line 200 or so, where it starts the vertical retrace, and where
it'll switch to page 2.
With 3 buffers, you can not worry about that, and keep shuffling through
3 pages of mem. one page will have what was/is on screen, another will
have what will be on the screen, and the last page is what you are
currently drawing/modifing at the moment.
I'm pretty sure this is how Jazz the Jackrabbit also works... basically,
you never have to wait for any sort of video syncing... no wasted time.
arnold
Mark Koesel
Lincoln A. Kallsen <KALL...@maroon.tc.umn.edu> wrote:
>I'm not a programmer, so please give me the layman's (layperson's?) answer --
>why is it that DOOM is so hard to port. I agree it is an *awesome* game, but
>the graphics are not that spectacular (though the variety of rooms is amazing).
>Why wouldn't a decent 040 machine be able to run this game?
An 040 could handle doom, but it would mean two sets of asm routines.
In the interest of time Lion is apparently forgoing the 68k altogether.
__
__/\_\ Mark G. Koesel - koe...@engin.umich.edu
__/\_\/_/ Computer Engineering - University of Michigan, Ann Arbor
/\_\/_/\_\
\/_/\_\/_/ PowerPC - Performance Optimization With Enhanced Reduced
\/_/\_\ Instruction Set <Computer> Personal Computer... err,
\/_/ something like that.
Tim Seufert
greg...@lonexc.admin.rl.af.mil (Jonathon Gregory) wrote:
> I will run down the reasons why I think that Doom is hard to get onto the
> Mac. And it all has to do with the video HARDWARE of the machine..
> Not the processor, or the operating system..
Partially correct, but...
> The video resolution of DOOM on the IBM as I understand can be 320x200
> (or something like that) pixels, and that resolution in VGA mode (please
> forgive any ibm naming convention mistakes, I'm not a native ibmer) can
> fill the entire screen, while on the Mac a full screen of a 13" monitor (
> is 640x400 pixels, so there is four (4) times as many pixels per screen to
> move (lets say for simplicities sake, a slowdown factor of 4)..
> 640x400 pixels equals 256000
> 320x200 pixels equals 64000
Minor nit-pick (because I'm a nit-picking kind of guy, or I wouldn't be
posting this message): the actual Macintosh screen resolution is 640x480.
What is usually done in this case is to use pixel-doubling. That is, you
are rendering at 320x200, and plotting each 320x200 pixel on the screen as
a 2x2 dot, doubling the resolution to 640x400. You simply don't draw to
the remaining 80 lines of the Macintosh screen, or put a status display
there, or something like that.
The slowdown for doing this is typically much lower than the factor of 4
you get if you insist on rendering each pixel, because the time it takes
to render a given pixel (that is, determine what its color should be) is
much more than the time it takes to plot it on-screen as a 2x2 dot.
Note that the IBM version of Doom uses a form of pixel doubling: in "low
detail" mode, used to allow slower machines to run at an acceptable frame
rate, pixels are doubled horizontally (but not vertically - the way the
Doom engine works, pixel doubling vertically does not usually get you any
performance gain). So, in low detail mode, the effective resolution Doom
is running at is 160x200.
So, a Mac version of Doom would probably allow several options: no
doubling (640 pixel resolution), doubling (320 pixel resolution), and
quadrupling (160 pixel resolution). The vertical resolution could
probably remain 400 all the time without any performance hit, because it
is pretty much impossible to improve performance there with pixel doubling
techniques. In fact, they would probably hurt performance. (Why? That
would get into a discussion of how Doom-type rendering engines work.)
You can also run at resolutions other than 640x480 - i.e., not filling the
whole screen, which is a technique Wolfenstein 3D for the Mac uses.
512x384 pixels is an acceptably large image size with relatively little
black border left on a 640x480 screen - and it lets the game run on any
Macintosh color monitor (the 12" RGB monitor uses a resolution of
512x384).
> in other words, with one instruction to the ibms standard type of video
> card you call tell the card to display what is in memory section A...
> and with the next instruction you call tell the card to display what is
> in memory section B. This switch from section A to B occurs in one
> clock cycle of the machine (a millionth of a second or less).. for all
> practical purposes we can and will say it is instantaneous! Now with this
> information in hand let me continue...
I don't think double buffering is a standard VGA feature, and Doom may not
use it. Even if it does, the performance hit for blitting an offscreen
bitmap to the screen is not going to hurt the Mac version that much,
especially on an 040 (which I would consider to be the minimum processor
to run Doom/Mac, except maybe the 030 at 50 MHz). The 040 has this nice
instruction called move16, which moves 16 bytes of memory at once;
properly designed, a copy loop using this instruction should be able to
achieve very fast speeds. Even if QuickDraw is used to move the image to
the screen, speed is possible, because if you set up your offscreen bitmap
right, QuickDraw uses a super-optimized move16 copy loop with very little
overhead.
> So my really really REALLY rough estimate of mac to ibm speed DOOM ratio
> is arround 10 ( TEN )..
And it's way over, IMO.
Remember, the major speed hits in Doom are in the tasks of determining
what polygons to display, and scaling and rotating bitmapped images which
are mapped to the polygons.
In fact, there are some major speed problems on the PC with respect to
video. Ever wonder why so few PC games run at resolutions higher than
320x200? It's because 320x200 is the only 256 color resolution which will
fit in a single 64K segment of memory. Go any higher, and you have to
fool around with your video memory residing in different segments. Memory
segmentation BITES! Only recently have these problems begun to be solved
on the PC.
--
| Tim Seufert, bwa...@cats.ucsc.edu |
| Burn a few penquins when you have the time. It's fun. |
Cpt. Kangarooski
("Lincoln A. Kallsen") wrote:
> I'm not a programmer, so please give me the layman's (layperson's?) answer --
> why is it that DOOM is so hard to port. I agree it is an *awesome* game, but
> the graphics are not that spectacular (though the variety of rooms is
amazing).
> Why wouldn't a decent 040 machine be able to run this game?
I see no reason to port it at all
Once theres a Marathon editor (which runs on non ppc macs- Marathon that
is) just edit marathon to look like DOOM. Think of how fast a good team
effort could kick id's ass for not supporting the mac faster
That would show them (although it might also casue the mac to never get
supported by id, but with fast editing, it would make nary a difference)
-cpt kangarooski
web...@aol.com
("Lincoln A. Kallsen") wrote:
>
> I'm not a programmer, so please give me the layman's (layperson's?) answer --
> why is it that DOOM is so hard to port.
Check out this report from a reliable source. ;-)
===
Dates for Doom ports:
Timex digital wristwatch port: 12/1/94 (In time for Christmas!)
Casio calculators: 1/1/95
Texas Instruments calculators: 3/15/95 (in time for my birthday!)
UMI (Universal Microwave Interface) port: 6/10/95
Sofa port 12/10/95
(The long time frame for the sofa port is due to the complexity of getting
the Doom engine to run on a platform with such limited hardware. Note
that only 3-person + sofas will be supported due to the total lack of
hardware capability on most smaller couches.)
Note: There will be no HP calculator port due to the infamous
Wolf-3D/Hewlett Packard problems experienced by id Software.
Yeah, uh-huh, this is straight from stuff I heard on the Net. Yup.
That's right.
===
--
/ Jeff Schwartz / http://edu-153.sfsu.edu /
/ web...@aol.com / "A friendly little pothole on /
/ :::::::::::::::: / the information superhighway." /
Randy Wood
: >I'm not a programmer, so please give me the layman's (layperson's?) answer
: >--
: >why is it that DOOM is so hard to port. I agree it is an *awesome* game,
: >but
: >the graphics are not that spectacular (though the variety of rooms is amazing).
: >Why wouldn't a decent 040 machine be able to run this game?
Simple answer: id programmers are better than mac game programmers in the
graphics department (id wrote Doom).
I have hope however. I have not seen as much as a screen shot of
Marathon, but all the hype has me hopeful.
I'm growing weary of coming in early to work just to play Doom on my PC
(I have a mac at home). I have to turn the sound off too. I'm very much
looking forward to playing a Doom type game at home where I can crank the
volume and play for hours (after all, I don't have a life).
Tim Seufert
<ah...@columbia.edu> wrote:
> Doom uses triple-buffering, in fact... and it is standard VGA.
Mind telling me why it would use "triple-buffering"? That makes
absolutely no sense.
--
Duncan Anker
: Minor nit-pick (because I'm a nit-picking kind of guy, or I wouldn't be
: posting this message): the actual Macintosh screen resolution is 640x480.
And because I like to nit-pick from time to time too, I've got to say *bzzzt*
What do you mean by "The actual Macintosh screen resolution"?
Classic (more or less defunct, no?) 512x342
Apple 12" 512x384
Apple 13" 640x480
Powerbook 165c 640x400
Not to mention moniters of different sizes. Oops, too late, I just did.
There is no one fixed resolution. Granted, 640x480 is taken as standard
by many people who write games, and it cheeses me off because I can't
use them.
--
s302...@titanic.mpce.mq.edu.au * Duncan Anker * e302...@hardy.ocs.mq.edu.au
I like to reminisce with people I don't know. Granted, it takes longer.
burg...@news.delphi.com
with the VGA hareware that you simply CAN't do on a mac.
1. Page flipping, (Unless you own a Quadra 630). By drawing to an
offscreen buffer that can be shown by hitting a hardware register instead
of a _CopyBits operation, this saves time.
2. Screen memory fits in 64K. Both the 680x0 and PPC have similar
addressing modes to take advantage of such hardware but alas the mac
forces you to use a large screen map (Pixel doubling doesn't work in this
case). Since the art can never go out of a 64K chunk, you can take some
programming shortcuts to gain some speed.
3. VGA pixel registers. A little known fact that the vga chipset can
actually blast a horizontal line of pixels with a SINGLE pixel write. So
in theory you can draw 8 pixels with each pixel write. Doom uses this
when a wall is close to you so instead of drawing 6 vertical lines to
scale a wall line by 6, you preset the vga hardware to expand the line as
you draw it ONCE. This is why the game speeds up so much when something
is in your face.
Burger
Tim Seufert
(BURGE...@DELPHI.COM) wrote:
> 3. VGA pixel registers. A little known fact that the vga chipset can
> actually blast a horizontal line of pixels with a SINGLE pixel write. So
> in theory you can draw 8 pixels with each pixel write. Doom uses this
> when a wall is close to you so instead of drawing 6 vertical lines to
> scale a wall line by 6, you preset the vga hardware to expand the line as
> you draw it ONCE. This is why the game speeds up so much when something
> is in your face.
I don't know that the Doom engine does that, since it is supposed to work
by rendering pixel columns (that is, it doesn't go left to right along a
row - it goes top to bottom along a column).
I would tend to think that the speedup when you are very close to walls is
due to the fact that the engine does not have to worry about rendering as
many objects as it does when you can see a lot of stuff.
Tim Seufert
s302...@titanic.mpce.mq.edu.au (Duncan Anker) wrote:
> : Minor nit-pick (because I'm a nit-picking kind of guy, or I wouldn't be
> : posting this message): the actual Macintosh screen resolution is 640x480.
>
> And because I like to nit-pick from time to time too, I've got to say *bzzzt*
> What do you mean by "The actual Macintosh screen resolution"?
Thank you for nit-picking back. We have to keep the net filled with
mindlessly anal exactness. :)
> Classic (more or less defunct, no?) 512x342
> Apple 12" 512x384
> Apple 13" 640x480
> Powerbook 165c 640x400
>
> Not to mention moniters of different sizes. Oops, too late, I just did.
> There is no one fixed resolution. Granted, 640x480 is taken as standard
> by many people who write games, and it cheeses me off because I can't
> use them.
Yup. I should have said that the actual 13" monitor res is 640x480,
because the original post seemed to imply it was 640x400.
Jon Steinmetz
Brian_A...@helix-online.com (Brian A. Cantin) writes:
> ID Software is 5 guys. With PCs.
Much of Doom was actually done on NeXT machines. There is an article
about ID in a back issue of Computer Gaming World.
// Jon Steinmetz
// stei...@gold.tc.umn.edu
//
// Mac programmer until something better comes along
Tim Smith
>An 040 could handle doom, but it would mean two sets of asm routines.
>In the interest of time Lion is apparently forgoing the 68k altogether.
In an interview with one of the DOOM programmers, he stated that there
are only two assembly routines in DOOM (or maybe three, I forget). First,
the joystick code is in assembly. Second, there is something for copying
textures. (If there was a third, it was some of the code for dealing with
the sound card). Everything else is in C (fairly portable C, in fact,
considering that Id ported DOOM to the R4000 in their spare time very
quickly, and then ported it to Linux and X in a few weeks wall clock time).
--Tim Smith
Mark Koesel
Tim Smith <t...@u.washington.edu> wrote:
>Mark Koesel <koe...@engin.umich.edu> wrote:
>>An 040 could handle doom, but it would mean two sets of asm routines.
>>In the interest of time Lion is apparently forgoing the 68k altogether.
>
>In an interview with one of the DOOM programmers, he stated that there
>are only two assembly routines in DOOM (or maybe three, I forget). First,
>the joystick code is in assembly. Second, there is something for copying
>textures. (If there was a third, it was some of the code for dealing with
>the sound card).
I am aware that Doom is mostly coded in C. And, I believe that the routines
you are thinking of are the two which map a row of texture onto
the screen, and a column of texture onto the screen. There may be others,
but those are the two most significant. These routines are very
optimized, however. My point is two asm routines can equal *lots* of
coding time. (Try it sometime, you'll get the picture :)
> Everything else is in C (fairly portable C, in fact,
>considering that Id ported DOOM to the R4000 in their spare time very
>quickly, and then ported it to Linux and X in a few weeks wall clock time).
Yeah, actually I think Carmack did this essentially by himself. Those guys
are programming geniouses.
Tim Seufert
Steinmetz) wrote:
> Much of Doom was actually done on NeXT machines. There is an article
> about ID in a back issue of Computer Gaming World.
Actually, they develop Doom under the Intel version of NextStep. If they
had originally done the game on 680x0 NeXT machines, a Mac port would have
been fairly simple - the assembly code for the bitmap scaling could have
been reused, and the rest of the game is ANSI C.
Tim Seufert
(Thomas Deweese) wrote:
> uhhh, exactly, if the pixel column is close enough that it will
> be six pixels wide, it sets the VGA hardware to draw six pixels. Then
> draw the column _once_ (which the harware multiplies to six pixels
> wide), then they go to the next pixel column in the texture map. Thus
> they never need to consider a column of the texture map more than
> once.
Except that I've been under the impression, for a long time, that the Doom
engine does raycasting: It considers an individual column of pixels, casts
a ray originating from the column out into the environment, and determines
what object it hits first. The texture for that object is looked up and
the appropriate column of pixels is scaled to adjust for distance, and
then copied to the screen in the appropriate position. If there are still
portions of the entire pixel column unrendered, it continues to look for
the next object, and so on.
Thus, the engine is always rendering one pixel column at a time (or, in
low detail mode, it copies the results of the current column to the next
column as it draws, so that it need only render half the normal number of
pixels).
If they do use a column "fattening" method as you describe, I can't see
how some of the detail that does occur is generated. For example, when a
single pixel in a texture is so close to you that it expands to a 6x6
block or so, the top and bottom edges are not drawn as perfect horizontal
lines - they get drawn as diagonal lines, if you're not facing the wall at
a perfect 90 degree angle.
> >I would tend to think that the speedup when you are very close to
> >walls is due to the fact that the engine does not have to worry about
> >rendering as many objects as it does when you can see a lot of stuff.
>
> Well it still needs to do a complete traversal of the BSP
> tree. And everything behind the wall directly in front of you that is
> facing you probably gets drawn (they can however trivially reject
> everything behind you).
When the engine finds a wall that covers the whole pixel column (as it
usually does when looking at a wall right next to the viewpoint), it can
stop looking for further ray intersections. When you are looking out on a
vast scene, the engine often cannot stop at the first ray intersection,
and thus spends a longer time looking up two or more intersections and
performing scaling for multiple textures.
Brian A. Cantin
--
> why is it that DOOM is so hard to port. I agree it is an *awesome* game,
but
> the graphics are not that spectacular (though the variety of rooms is
amazing).
> Why wouldn't a decent 040 machine be able to run this game?
ID Software is 5 guys. With PCs.
They don't have Macs, and from what I've read are slightly Mac phobic.
Through MacPlay, they've created Wolf 3D, (incidentaly, the game that took 5
people to make took MacPlay about 20 to 30 people).
It's rumored that Doom will next.
So, it is planned, but it won't be a direct port over, so it will have better
graphics, and sound than the PC version, if MacPlay does it.
-Zaphod Beeblebrox.
Thomas Deweese
Tim Seufert <bwa...@cats.ucsc.edu> wrote:
>In article <37l6li$5...@news.delphi.com>, burg...@news.delphi.com
>(BURGE...@DELPHI.COM) wrote:
>
>> 3. VGA pixel registers. A little known fact that the vga chipset can
>> actually blast a horizontal line of pixels with a SINGLE pixel write. So
>> in theory you can draw 8 pixels with each pixel write. Doom uses this
>> when a wall is close to you so instead of drawing 6 vertical lines to
>> scale a wall line by 6, you preset the vga hardware to expand the line as
>> you draw it ONCE.
>I don't know that the Doom engine does that, since it is supposed to work
>by rendering pixel columns (that is, it doesn't go left to right along a
>row - it goes top to bottom along a column).
uhhh, exactly, if the pixel column is close enough that it will
be six pixels wide, it sets the VGA hardware to draw six pixels. Then
draw the column _once_ (which the harware multiplies to six pixels
wide), then they go to the next pixel column in the texture map. Thus
they never need to consider a column of the texture map more than
once.
>I would tend to think that the speedup when you are very close to
>walls is due to the fact that the engine does not have to worry about
>rendering as many objects as it does when you can see a lot of stuff.
Well it still needs to do a complete traversal of the BSP
tree. And everything behind the wall directly in front of you that is
facing you probably gets drawn (they can however trivially reject
everything behind you).
--
Thomas DeWeese
dew...@kodak.com
"The only difference between theory and practice is
that in theory there isn't any." -- unknown
Jeff Hegedus
(Tim Seufert) wrote:
> Actually, they develop Doom under the Intel version of NextStep. If they
> had originally done the game on 680x0 NeXT machines, a Mac port would have
> been fairly simple - the assembly code for the bitmap scaling could have
> been reused, and the rest of the game is ANSI C.
While I have heard both stories, that ID coded Doom on a Next and that ID
created Doom on NextStep equiped PCs, regardless, Doom for the Next has been
available for 6 months now, if having Doom on the Next would make the mac
port so easy, why is it taking this long?
Tim Smith
>In article <37l6li$5...@news.delphi.com>, burg...@news.delphi.com
>> actually blast a horizontal line of pixels with a SINGLE pixel write. So
>> in theory you can draw 8 pixels with each pixel write. Doom uses this
>> when a wall is close to you so instead of drawing 6 vertical lines to
>> scale a wall line by 6, you preset the vga hardware to expand the line as
>> you draw it ONCE. This is why the game speeds up so much when something
>> is in your face.
>
>I don't know that the Doom engine does that, since it is supposed to work
>by rendering pixel columns (that is, it doesn't go left to right along a
>row - it goes top to bottom along a column).
I too doubt that any VGA pixel register manipulation is involved, since
Id has ported DOOM to at least three systems that probably don't allow
direct access to the registers: SGI, NeXT, and Linux. The Linux port uses
X for the display, using standard X calls. From what I've read, it runs
about as fast as the DOS version on the same hardware.
--Tim Smith
Lorne Beaton
>
>>I would tend to think that the speedup when you are very close to
>>walls is due to the fact that the engine does not have to worry about
>>rendering as many objects as it does when you can see a lot of stuff.
>
> Well it still needs to do a complete traversal of the BSP
>tree. And everything behind the wall directly in front of you that is
>facing you probably gets drawn (they can however trivially reject
>everything behind you).
Everything I understand about how the DOOM engine works says that this is
untrue -- i.e., *nothing* is drawn more than once per frame, as this is a very
wasteful method of doing hidden-line removal and kind of negates the benefit of
a BSP. DOOM calculates the correct colour for each pixel in the viewport
independently. The key, I guess, is to find (by searching the BSP) which
linedefs are currently visible, sort them in Z-order and for each pixel down the
column draw the appropriate colour for the nearest non-transparent one.
--
------------------------------------------------------------------------------
: Lorne Beaton -- bea...@server.uwindsor.ca | Grad student, DOOM slave :
: If I had a life, you wouldn't be reading this. | and all-around net addict :
------------------------------------------------------------------------------
Joseph Julicher
> Actually, they develop Doom under the Intel version of NextStep. If they
> had originally done the game on 680x0 NeXT machines, a Mac port would have
> been fairly simple - the assembly code for the bitmap scaling could have
> been reused, and the rest of the game is ANSI C.
>
I have watched DOOM played on a 68040 NeXT here at school. (and not under
SoftPC) so I would image that those assembly code bocks are already done.
Unless of course they made a VGA screen object or something... (right...)
Joseph Julicher