DOOM on atari st

[ryo]

Hello,
where can I find the game "DOOM" on atari (atari 2600, ste,...)

In advance thank you.

Ryo.

[GroovyBee]

Doom 2600 was a hoax :-
http://www.geocities.com/TimesSquare/Ar ... 00DOOM.HTM

Wolfenstein exists :-
http://freenet-homepage.de/ray.tscc/wolf3d.htm

There are probably other versions of ID games knocking about.

[lotek_style]

...and be sure we WON'T do a DOOM-conversion.... Wolfenstein was already a hard job

[simonsunnyboy]

Doom does exist for highend Ataris running Mint, iirc it is called pmdoom. You have to google for it...

[DarkLord]

Try here:

http://pagesperso-orange.fr/patrice.man ... teurs.html

It says he stopped work in 1998 - but.... I've seen quite a few updates
since then, so I don't think that part is right. The last version I ran on my
CT60'ed Falcon looked and ran great.

[StickHead]

...and of course there is Doom and Wolfenstein 3D on Atari Jaguar.

[yerzmyey]

I suspect to make a DOOM port for ST it would require to make entire engine "from the scratch". Just like they did DOOM on ZX Spectrum 128K. They had to resign from many features just to make the game possible on Spectrum.

[Zamuel_a]

I remember there were a DOOM port for Falcon that came out a few years after DOOM was releasted. A friend had just got an Falcon then and could play it. Must have been around 95 or so. It could run the normal WAD files but had only flatshaded polygons. I wonder what happend to that?

[Desty]

I remember there were a DOOM port for Falcon that came out a few years after DOOM was releasted. A friend had just got an Falcon then and could play it. Must have been around 95 or so. It could run the normal WAD files but had only flatshaded polygons. I wonder what happend to that?

This one?

[Zamuel_a]

Hard to tell since this was about 15 years ago. I have seen that there are many DOOM ports to Falcon, so maybe the one I saw doesn't even exist today.

[Cyprian]

or Bad Mood?

[Zamuel_a]

I tested some DOOM ports on my Falcon but saw that noone were complete games. The best one was DOOM081 which had enemies, even if they didn't move. I wonder why they all are so slow? Around 5fps on a standard Falcon. I used to play it then it came out on a 386 20MHz and it runned fine on that machine. A 16MHz 68030 should be more or less the same as a 386 20MHz I think?
Don't they use the highcolor mode so they get a chunky graphic mode? Even a c2p routine shouldn't be to slow on a Falcon?

I saw a video on youtube with DOOM on an TT030 and it looked even slower than on my Falcon. A 32MHz TT must be able to handle it better?

[Desty]

When Doom came out, it was maybe the most heavily optimised, clever, cheating graphics/3D engine that existed. I think they found some new techniques (or at least, new places to use existing techniques) and optimisations in 3D programming. Maybe not all of these (especially weird tricks done on the x86 that are hard to understand and port) made it into the ports and they're simply less efficient?

http://en.wikipedia.org/wiki/Doom_engin ... rtitioning
http://en.wikipedia.org/wiki/Category:3 ... r_graphics

[Zamuel_a]

The actual game is made in ordinary C code so nothing special there. The graphic routines are in assembler I guess, but the x86 assembler isn't so fun to program in (I did it alot in the past). You don't have so many registers and the ones you have are specified for different things. It's not like the 680x0 there you can do almost anything with any register.
Aren't the ports based on the PC code anyway? I know ID Software released all code several years ago.

[Desty]

The actual game is made in ordinary C code so nothing special there. The graphic routines are in assembler I guess, but the x86 assembler isn't so fun to program in (I did it alot in the past). You don't have so many registers and the ones you have are specified for different things. It's not like the 680x0 there you can do almost anything with any register.
Aren't the ports based on the PC code anyway? I know ID Software released all code several years ago.

The 1997 release code is still upon their website... and Quake is there too, pretty cool.

Actually there's more registers than people consider for the x86, even the 386 has quite a few - six 16-bit segment registers (CS, DS, SS, ES, FS, GS), the pointer registers (ESP, EBP, EIP) and six 32-bit general registers (E{A-D}X, ESI, EDI) which can be used as twelve 16-bit registers (or split up again into 8-bit registers) although I don't think there's a syntax for referencing the upper 16-bits - maybe you have to exchange the halves first. But yeah, there are some very arbitrary-seeming restrictions on which parts of which registers you can use in various addressing modes. And weird conventions like some DOS/BIOS functions expect, say, a string parameter in DS:DX and others want ES:BP

*[edit] On that note, the segment addressing thing is a pile of poo
And as you say, many of the x86 registers are designed and used with specific purposes and restrictions. Which makes it more difficult to design a compiler backend - with more simpler instruction sets and register architecture the compiler can more freely select registers and maybe do more clever optimisation.

On the other hand, afaik most BIOS/TOS/GEMDOS functions on the ST take parameters from the stack which is a little slower?

[wongck]

That because it's written in C.
Ppl optimised it with assembler and you called those Wrap 9, QuickST etc...

[Desty]

That because it's written in C.
Ppl optimised it with assembler and you called those Wrap 9, QuickST etc...

What, you mean the TOS/GEMDOS routines? Sure, but they can't change the calling conventions! Otherwise no existing programs would run under QuickST/etc.

[coze]

if speccy can do it, ST can do it !

http://www.youtube.com/watch?v=3v7cFGneuaw

or even c64 !

http://www.youtube.com/watch?v=X3Oqz5WjDPI

[Zamuel_a]

I did some programming in the late 90th in Borland Pascal on PC and I made some DOOM clones, but Pascal was only 16 bit so the inline assembler didn't support instructions with "eax" for example and the x86 processor is alot slower at 16 bit than with 32 bit instructions so I had to do a "db 66h; mov ax,10h" there 66h was the opcode for 32bit instructions. I remember it was a huge speed difference in the inner loop of a texture mapper to use 32 bit instructions instead of 16. I had done alot of programming on my Atari before I went to a PC and I remember I tought the assembler was crap compared to the 68k And I had to deal with 64k segments. I was used to deal with 4Meg of linear memory, he he.

But I still can't see why DOOM shouldn't be much faster than the ones I saw on a Falcon machine? Are they using the chunky highcolor mode at all or even a c2p routine? Maybe it's done direct with the bitplanes and then I can understand the speed.

[Desty]

I did some programming in the late 90th in Borland Pascal on PC and I made some DOOM clones, but Pascal was only 16 bit so the inline assembler didn't support instructions with "eax" for example and the x86 processor is alot slower at 16 bit than with 32 bit instructions so I had to do a "db 66h; mov ax,10h" there 66h was the opcode for 32bit instructions. I remember it was a huge speed difference in the inner loop of a texture mapper to use 32 bit instructions instead of 16. I had done alot of programming on my Atari before I went to a PC and I remember I tought the assembler was crap compared to the 68k And I had to deal with 64k segments. I was used to deal with 4Meg of linear memory, he he.

I felt the same when I started learning x86 The register setup felt like a big 'smell' compared to the really simple scheme on the 68k. That db 66h (in the code segment, heh!) is a clever little trick, but indicative of the kind of thing that happens on the x86!

But I still can't see why DOOM shouldn't be much faster than the ones I saw on a Falcon machine? Are they using the chunky highcolor mode at all or even a c2p routine? Maybe it's done direct with the bitplanes and then I can understand the speed.

Indeed, there's only one way to solve the mystery... write another Doom clone that is actually fast on a straight Falcon. Let's get going!

[Zamuel_a]

Indeed, there's only one way to solve the mystery... write another Doom clone that is actually fast on a straight Falcon. Let's get going!

He he, yea even if the ones I tested was slow, they were not complete so they were useless even on a 68060 machine so someone should finish a DOOM game for Atari someday. Maybe a ST can do it if you remove floors and ceilings like on the SNES version. It's not much different from wolfenstein then.

[purpleeagle01]

Try Destruction Imminent is a nice Doom like game for a plain ST.
Cheers

[DarkLord]

Try Destruction Imminent is a nice Doom like game for a plain ST.
Cheers

Hmm, got a link? Thanks!

[Zamuel_a]

Yes I tested Destruction Imminent some time ago and it's a fast game, about the same as Substation. Here is a youtube video of it.
http://www.youtube.com/watch?v=b6WEzPgsAus

Substation used shaded walls and here it looks similar but with texturemapping and I have never really figured out how they do it. I got a theory but don't know if it's at all what they do In both substation and in Destruction Imminent, the walls get to a single shaded color then you get close to them and get textured then you see them from a distance. In a real texture mapper the distance doesnt matter so I wonder if they just have alot of "sprites" that they draw? So every angle of a wall is precalced as pictures so they just pic the one they need at a specific angle. Then it's just ordinary flat polygons which is alot faster than textures. Since bitmaps for every angle takes alot of memory they reduce it by not using it on walls close to you. I guess it must be a technic that is something like that?

[Desty]

In both substation and in Destruction Imminent, the walls get to a single shaded color then you get close to them and get textured then you see them from a distance. In a real texture mapper the distance doesnt matter so I wonder if they just have alot of "sprites" that they draw?

Well, real texture mappers usually have mipmapping, maybe this is just a more stripped-down version where instead of lower-detail textures at bigger distances, they just switch to flat shading?