Page 1 of 1

Doom 0.59.2

Posted: Mon Sep 15, 2014 6:31 pm
by Patrice Mandin
Hello,

I posted this past week in Firebee forum, to announce the coldfire build.

I would like people with TT, or Falcon with accelerators (Centurbo 2 for example) to try this version, as many things have been fixed, both inside SDL, and in Doom code.

As usual, it is available on my website.

Re: Doom 0.59.2

Posted: Thu Sep 18, 2014 2:12 pm
by Dal
Nice one Patrice. I've grabbed it and uploaded it to my NAS. Next time the Falcon is on, I'll try it out and post back to this thread.

Re: Doom 0.59.2

Posted: Thu May 28, 2015 9:33 am
by yerzmyey
Hello,

which link is for Atari TT there?
http://pmandin.atari.org/dotclear/index ... -game-doom
Would it be this one? http://pmandin.atari.org/download/bin/pmdoom-0.60.zip (Binary Atari,68020+ )?

Although I have only 4Mb on my TT. I imagine the game wouldn't work there?

Respect,
Y

Re: Doom 0.59.2

Posted: Thu May 28, 2015 8:58 pm
by Patrice Mandin
Yes it is this archive.
Doom requires approx. 2.5MB free to run, so a machine with 4MB is a minimum.

Re: Doom 0.59.2

Posted: Thu May 28, 2015 11:13 pm
by Atari030
It runs nicely on a CT2b BTW. Runs pretty well on a stock machine too. Thanks Patrice.

Re: Doom 0.59.2

Posted: Fri May 29, 2015 7:01 am
by yerzmyey
[quote="a machine with 4MB is a minimum.[/quote]

An excellent news, thank You very much.
Will be testing it soon. :) :) :)

Re: Doom 0.59.2

Posted: Sat May 30, 2015 8:46 pm
by Eero Tamminen
Patrice Mandin wrote:Yes it is this archive.
Doom requires approx. 2.5MB free to run, so a machine with 4MB is a minimum.


I just tried it in Hatari both with plain TOS and TT & Falcon emulation and it works fine. 4MB of ST-RAM isn't enough though, it requires 4MB of TT-RAM (1 MB of ST-RAM is then enough, at least for Doom I shareware WAD).

Compared to Douglas BadMood, it's of course slower, but on the other hand it doesn't require processing the WADs before play, it works without DSP (on TT) and also in other than 16-bit resolutions. On Hatari's Falcon emulation it's maybe 1 FPS, on TT, maybe few FPS.


Patrice, how you're handling the Doom game tick problem i.e. game using a lot more CPU when rendering falls behind (default 35Hz) game tick? Douglas handled that by reducing the game tick to 12Hz which is about minimum that still works fine (has enough bits for accuracy) and is low enough for BadMood.

Have you used any of Douglas' m68k asm code in your Doom port, e.g. for sound propagation / monster wakeup?

Re: Doom 0.59.2

Posted: Wed Jun 17, 2015 5:43 pm
by Patrice Mandin
Eero Tamminen wrote:Patrice, how you're handling the Doom game tick problem i.e. game using a lot more CPU when rendering falls behind (default 35Hz) game tick? Douglas handled that by reducing the game tick to 12Hz which is about minimum that still works fine (has enough bits for accuracy) and is low enough for BadMood.

Have you used any of Douglas' m68k asm code in your Doom port, e.g. for sound propagation / monster wakeup?

Not sure about the game tick problem, would have to test it myself to understand the issue. Lowering/changing game tick rate could cause problem with demos and/or network play.

I also did not look what Douglas did for sound propagation / monster wakeup.

I just found someone with TT and a nova card, so I'll try to make it work on it (i.e. with nova card resolutions)

Re: Doom 0.59.2

Posted: Sun Jun 21, 2015 8:57 pm
by Eero Tamminen
Patrice Mandin wrote:Not sure about the game tick problem, would have to test it myself to understand the issue. Lowering/changing game tick rate could cause problem with demos and/or network play.


Yes, demo recordings or network play with engines having different tick value (and related other values derived from game tick) are not compatible, but changing that was necessary. Being constantly behind the (35Hz) game tick increases Doom engine CPU overhead significantly.

Most of Douglas' changes to Doom code are behind defines so that one can do builds with original values/code and modified versions. This way optimizations can be easily switched on & off and tested against original version, both for functionality and performance.

Patrice Mandin wrote:I also did not look what Douglas did for sound propagation / monster wakeup.


Doom code for sound -> monster wakeup is recursive. There are some places in Doom maps where this can cause very noticeable delay / skip in frame updates as monsters further and further away are woken up and making noise. Douglas both optimized this code and put limit on recursion. I think this and game tick are only(?) changes to the game play, other optimizations don't have effect on it.

As result, when one enables all optimizations and speedup changes, BadMood is a bit easier than original PC Doom. Lower (4-12) FPS on Falcon compensates this though...

With games using same engine, demo recordings and network play are compatible, so that's not too much of a problem. One would anyway be badly disadvantaged when playing PC Doom against person on a PC with much higher FPS.