Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug in Acorn Doom

65 views
Skip to first unread message

cs9...@gmail.com

unread,
Dec 13, 2012, 7:40:43 PM12/13/12
to
Lately I have been editing an add-on map for Id Software's classic game 'Doom' in Deth. I may be the last masochist using RISC OS both for creating and testing Doom maps, but I thought it worth writing up my findings for posterity here.

After a few hours spent reading about how sound is supposed to propagate from sector to sector, I concluded that there is a bug in the Acorn port of 'Doom' published by R-Comp Interactive. I confirmed this by testing the behavior of two other versions of Doom on Windows: 'Chocolate Doom' (a bug-compatible source port; see http://www.chocolate-doom.org/) and 'Doomsday' (a state-of-the art source port; see http://www.dengine.net/)

The bug is that sound does not cross some two-sided linedefs where the sectors on either side have compatible floor and ceiling heights. This means enemies on the other side of such linedefs are not alerted to the player's presence as they should be if he discharges a weapon in a connected sector that is not separated from the sector containing the monster by at least two linedefs with the 'block sound' flag set (on every possible path between the two sectors).

This changes the game significantly, because it allows the player to ambush monsters that have been behaving as though they were deaf, although they were not intended to be deaf by the map designer. Overall, I would expect it to make the game easier, but it might make some maps impossible! A contrived example is a scenario where the player must pass through a door that he cannot open from the outside, but can be opened from the inside by a monster. A monster on the inside will not try to open the door unless alerted to the player's presence. This may never happen because of the bug.

The minimal test case is three sectors; the first connected to the second, and the second connected to the third (the first and third sectors are unconnected). The linedef connecting the first and second sectors has the 'blocks sounds' flag set. In Acorn Doom, a monster in the third sector cannot hear the player in the first sector; in every other version, the monster is alerted. This is wrong because TWO linedefs with the 'block sound' flag set should be required to block sound. Acorn Doom behaves as though the linedef connecting the second and third sectors also has its 'block sound' flag set, but it does not.

I suspect this is a failed optimization. At first I thought that the Acorn port might pre-compute a table of which sectors are audible from other sectors upon loading a map (which would be a flawed implementation, given that doors can be opened). However, it turns out that no doors are required for the bug to manifest; it just happens that doors are the commonest cause of an extra linedef between a monster that wrongly acts deaf and a linedef with its 'blocks sound' flag set. The simplest example is a door with one of its two-sided linedefs set to block sound. (This is sensible, whereas a door with both two-sided linedefs set to block sound would be stupid because it would prevent monsters on the far side from hearing the player even whilst the door is open.)

cs9...@gmail.com

unread,
Dec 14, 2012, 2:23:21 PM12/14/12
to
In response to massive demand, impassioned pleas, and the incentive of a large cash sum in 50 euro bills left in a black holdall in locker 14 at Munich Central Station, I have now created a Doom II map that is impossible to complete in Acorn Doom but possible to complete in all other versions. You can download it here: http://www.starfighter.acornarcade.com/mysite/doom.htm#acornbug

Have fun, and be sure to let me know what you think of my map design skills. I've been doing it for a while now so I like to think of myself as a bit of an artisan. You'll have plenty of time to admire the alignment of the textures in the first room, because you'll never get the door to the second room open. Just count your blessings that there will be no killing or dying. Take up meditation. Chill out. Crack open a beer.

Cheers!

Christopher Bazley

Martin Bazley

unread,
Dec 14, 2012, 2:57:50 PM12/14/12
to
The following bytes were arranged on 14 Dec 2012 by Christopher:

> I have now created a Doom II map that is impossible to complete in
> Acorn Doom but possible to complete in all other versions. You can
> download it here:
> http://www.starfighter.acornarcade.com/mysite/doom.htm#acornbug

Funnily enough, there is no longer just one "Acorn Doom". I can confirm
that the level is very much completable on Jeff Doggett's port:

https://sites.google.com/site/jeffreyadoggett/

You can even try it out on Chocolate Doom if you like! (Probably not a
good idea on a StrongARM RiscPC though...)

http://www.norisc-nofun.co.uk/Software.html

On an unrelated note, I think I've discovered the perfect soundtrack for
playing Doom to:

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

--
__<^>__
/ _ _ \ You always find something in the last place you look.
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================

cs9...@gmail.com

unread,
Dec 15, 2012, 8:44:27 AM12/15/12
to
On Friday, December 14, 2012 7:57:50 PM UTC, Martin Bazley wrote:
> Funnily enough, there is no longer just one "Acorn Doom". I can confirm
>
> that the level is very much completable on Jeff Doggett's port:
>
>
>
> https://sites.google.com/site/jeffreyadoggett/

I was about to complain that it is slow, but in reality there is almost no perceptible difference in frame rate at equivalent resolutions. It is only a pity that the front-end seems to have been designed by someone who threw Acorn's fascistic and boring Style Guide out of the window. (Sorry, but it's true. How on earth do I guess which buttons are clickable and which fields are editable?!) Also, the graphic detail toggle gives a choice of tiny weapon sprites and correctly-scaled sky or correctly-scaled weapon sprites and horribly magnified sky. Key input seems to be polled rather than buffered, so I have to type I D C L I P I D D Q Q instead of IDCLIPIDDQD.

Apart from that, it's great! Several bugs in the vintage port have been fixed, and I might genuinely find it useful if I could figure out how to change the keys.

> You can even try it out on Chocolate Doom if you like! (Probably not a
>
> good idea on a StrongARM RiscPC though...)
>
>
>
> http://www.norisc-nofun.co.uk/Software.html

Nope, it fails with an illegal instruction (probably BX LR). If it doesn't run on Acorn computers then it's hardly a replacement, is it?

> On an unrelated note, I think I've discovered the perfect soundtrack for
>
> playing Doom to:
>
>
>
> http://www.youtube.com/watch?v=p3G5IXn0K7A

Horrible!

Christopher

Martin Bazley

unread,
Dec 15, 2012, 10:04:54 AM12/15/12
to
The following bytes were arranged on 15 Dec 2012 by Christopher:

> Apart from that, it's great! Several bugs in the vintage port have
> been fixed, and I might genuinely find it useful if I could figure out
> how to change the keys.

That was the main blocker for me as well. It took an email to the
author before I found out it creates a file at Choices:dsg.doomrc, which
contains, among other things, key definitions. There is no front-end to
this section of the file.

The values are lower-case decimal ASCII, with some special
interpretation for arrow keys and the like which I have been completely
unable to fathom.

--
__<^>__ "Your pet, our passion." - Purina
/ _ _ \ "Your potential, our passion." - Microsoft, a few months later

cs9...@gmail.com

unread,
Dec 15, 2012, 2:34:09 PM12/15/12
to
On Friday, 14 December 2012 19:57:50 UTC, Martin Bazley wrote:
> The following bytes were arranged on 14 Dec 2012 by Christopher:
>
>
>
> > I have now created a Doom II map that is impossible to complete in
>
> > Acorn Doom but possible to complete in all other versions. You can
>
> > download it here:
>
> > http://www.starfighter.acornarcade.com/mysite/doom.htm#acornbug
>
>
>
> Funnily enough, there is no longer just one "Acorn Doom". I can confirm
>
> that the level is very much completable on Jeff Doggett's port:
>
>
>
> https://sites.google.com/site/jeffreyadoggett/

It seems to be far too bright, which ruins any sense of atmosphere and makes the game easier. Any shadows are almost invisible due to the lack of contrast and I can see perfectly well in environments that are supposed to be almost pitch black. The light amplification goggles are completely redundant!

Please does anyone have an explanation or solution. I wouldn't even have bothered defining different light levels for sectors if I had been play-testing my maps on this port. Is it too bright on Linux too?

Christopher

jeffrey....@gmail.com

unread,
Dec 15, 2012, 5:02:24 PM12/15/12
to
I've uploaded a darker version for you to try.
I've added a config option to the doomrc file "lightscaleshift" so you can try out different settings.
See the !Help file for more.

Jeff.

cs9...@gmail.com

unread,
Dec 17, 2012, 11:46:44 AM12/17/12
to
Hi Jeff,

What excellent customer service you provide! I couldn't expect more if I paid. :)

I knew that this version was a big improvement as soon as I found myself getting frightened whilst play-testing my own map, and died shortly afterwards upon being attacked by a spectre in a black tunnel!

At first I thought that you had made your port even darker than Chocolate Doom but after doing a comparison of the same map on the same monitor, Chocolate Doom still looks a bit darker:
http://www.starfighter.acornarcade.com/doggett.JPG
http://www.starfighter.acornarcade.com/choc.JPG

I am assuming that Chocolate Doom lives up to its reputation as being the most authentic - I didn't actually try DOS Doom. I linked the monitor in the photographs to a Windows laptop for Chocolate Doom, and my Risc PC for your source port. I don't fully understand the technicalities of 'number lighting levels' and 'light scale shift' but it seems likely to me that some of the differences I observe are due to the former rather than the latter. In many cases your port seems to preserve chrominance better.

One can also see from the screenshots linked to above that Chocolate Doom has the correct aspect ratio. How difficult would this be to fix? The simplest solution might be to provide the option to use screen modes with the correct aspect ratio (320:200, i.e. 16:10). I already have a 640x400 screen mode defined in my MDF specifically for the purpose of playing Acorn Doom.

Lastly, I was unable to test the effect of your changes in high colour (>8 bpp) screen modes because I can no longer persuade the game to use such screen modes! This must be a regression because the previous version certainly allowed high colour rendering on my 2MB VRAM Risc PC.

Cheers,

Christopher

cs9...@gmail.com

unread,
Dec 17, 2012, 11:56:00 AM12/17/12
to
On Monday, December 17, 2012 4:46:44 PM UTC, cs9...@gmail.com wrote:
> Lastly, I was unable to test the effect of your changes in high colour (>8 bpp) screen modes because I can no longer persuade the game to use such screen modes! This must be a regression because the previous version certainly allowed high colour rendering on my 2MB VRAM Risc PC.

Actually, I'm not so sure about this any more. The 24bpp screen modes look distinctly 8bpp even on the previous version. How are the extra colours used, if at all?

Christopher

jeffrey....@gmail.com

unread,
Dec 18, 2012, 3:01:31 AM12/18/12
to
>> I don't fully understand the technicalities of 'number lighting levels' and 'light scale shift'

Neither do I!!! The 'lightscaleshift' is the name of the C variable that the original programmer used.


>> How difficult would this be to fix? The simplest solution might be to provide the option to use screen modes with the correct aspect ratio (320:200, i.e. 16:10). I already have a 640x400 screen mode defined in my MDF specifically for the purpose of playing Acorn Doom.

Ok, I'll look at adding in 320:200 & 640x400. May take a few days....

>> Actually, I'm not so sure about this any more. The 24bpp screen modes look distinctly 8bpp even on the previous version. How are the extra colours used, if at all?

They're not. Doom is very hardwired to 8bpp. The 16bpp & 24bpp modes are only supported in case there is riscos hardware that cannot do 8bpp.
My doom port is basically the original unix X windows source code bodged to work under riscos.

By the way, I downloaded the test level. Bit unfair that the door closes again after you've killed the baddies! I changed it to a "stay open" type of door.

Jeff


cs9...@gmail.com

unread,
Dec 19, 2012, 6:31:44 AM12/19/12
to
On Tuesday, 18 December 2012 08:01:31 UTC, jeffrey....@gmail.com wrote:
> >> How difficult would this be to fix? The simplest solution might be to provide the option to use screen modes with the correct aspect ratio (320:200, i.e. 16:10). I already have a 640x400 screen mode defined in my MDF specifically for the purpose of playing Acorn Doom.
>
>
>
> Ok, I'll look at adding in 320:200 & 640x400. May take a few days....

If I were you, I would simply substitute 320x200 (VGA Mode 13h) for 320x256 and 640x400 for 640x480 because the 8:6 modes are slower than their 16:10 counterparts and make everything look squashed. I can give you the MDF that I use if it would help.

> >> Actually, I'm not so sure about this any more. The 24bpp screen modes look distinctly 8bpp even on the previous version. How are the extra colours used, if at all?
>
>
>
> They're not. Doom is very hardwired to 8bpp. The 16bpp & 24bpp modes are only supported in case there is riscos hardware that cannot do 8bpp.

I see. It might be worth making that explicit in the documentation because R-Comp's version of Doom does true colour 24bpp rendering rather than colour translation (as do versions for many other platforms).

> By the way, I downloaded the test level. Bit unfair that the door closes again after you've killed the baddies! I changed it to a "stay open" type of door.

My original version of the map was as you describe, but I found that the door can't be opened by the troopers if its far linedef has special type 31 so I changed it to 1. According to the Doom Wiki this is not a bug; only types 1 and 4 can be activated by monsters. Also, I observe the same behaviour in your version.

Christopher

jeffrey....@gmail.com

unread,
Dec 19, 2012, 10:49:13 AM12/19/12
to
>> I can give you the MDF that I use if it would help.

It would.


>> R-Comp's version of Doom does true colour 24bpp rendering rather than colour translation (as do versions for many other platforms).

The palette tables in the WAD files are only 256 entries, so not sure how they can actually do that.

>> According to the Doom Wiki this is not a bug; only types 1 and 4 can be activated by monsters. Also, I observe the same behaviour in your version.

Yes, I used a generic linedef type (aka Boom extension).
In Deth there's a config option to allow the use of extensions.

Jeff


cs9...@gmail.com

unread,
Dec 19, 2012, 11:41:33 AM12/19/12
to
On Wednesday, 19 December 2012 15:49:13 UTC, jeffrey....@gmail.com wrote:
> >> I can give you the MDF that I use if it would help.
>
>
>
> It would.

# 640 x 400 (71Hz)
startmode
mode_name:640 x 400
x_res:640
y_res:400
pixel_rate:25175
h_timings:96,46,0,640,0,18
v_timings:2,32,0,400,0,11
sync_pol:3
endmode

I tried and failed to make a 320 x 200 mode which would display satisfactorily on my LCD monitor. I imagine that it is possible to do a letterbox one at least, but I don't have a spare day in which to investigate MakeModes further. The interactive help is extraordinary useless (e.g. "This is the front porch icon.") It makes me cross when people go through the motions of documenting software without thinking about whether what they write will be of any use whatsoever!

> >> R-Comp's version of Doom does true colour 24bpp rendering rather than colour translation (as do versions for many other platforms).
>
>
>
> The palette tables in the WAD files are only 256 entries, so not sure how they can actually do that.

Translate the colour-indexed textures and sprites to a non-indexed additive colour model (e.g. R8G8B8) before applying depth fogging and lighting to obtain the final pixel values to be rendered to the frame buffer. If the translation is done just-in-time then the textures still require less memory than if they were stored in a non-indexed format.

Cheers,

Christopher Bazley

jeffrey....@gmail.com

unread,
Jan 18, 2014, 3:55:46 PM1/18/14
to
On Saturday, 15 December 2012 13:44:27 UTC, cs9...@gmail.com wrote:
> On Friday, December 14, 2012 7:57:50 PM UTC, Martin Bazley wrote:
>
Key input seems to be polled rather than buffered, so I have to type I D C L I P I D D Q Q instead of IDCLIPIDDQD.
>
>
> Christopher

Sorry for resurrecting such an old thread, but I just thought that I'd let you know that I'd finally got around to fixing this terrible oversight.

Update from https://sites.google.com/site/jeffreyadoggett/

Jeff

Martin Bazley

unread,
Jan 19, 2014, 8:41:05 AM1/19/14
to
The following bytes were arranged on 18 Jan 2014 by jeffrey....@gmail.com:

> On Saturday, 15 December 2012 13:44:27 UTC, cs9...@gmail.com wrote:
> >
> > Key input seems to be polled rather than buffered, so I have to type
> > I D C L I P I D D Q Q instead of IDCLIPIDDQD.
>
> Sorry for resurrecting such an old thread, but I just thought that
> I'd let you know that I'd finally got around to fixing this terrible
> oversight.
>
> Update from https://sites.google.com/site/jeffreyadoggett/

The numeric keys seem to be rather alarmingly broken. You don't know
fear until you've picked up your first chainsaw in the middle of a
massive fight and suddenly find yourself completely unable to switch to
any other weapon...

--
__<^>__ Red sky in the morning: Shepherd's warning
/ _ _ \ Red sky at night: Shepherd's delight
( ( |_| ) ) Mince and potatoes: Shepherd's pie

jeffrey....@gmail.com

unread,
Jan 19, 2014, 2:57:15 PM1/19/14
to
On Sunday, 19 January 2014 13:41:05 UTC, Martin Bazley wrote:

> The numeric keys seem to be rather alarmingly broken. You don't know
> fear until you've picked up your first chainsaw in the middle of a
> massive fight and suddenly find yourself completely unable to switch to
> any other weapon...

Sorry Martin, definitely a case of "how hard can it be"!
Try again.

Jeff
0 new messages