Dissecting Sega Saturn Doom

[Dexiaz]

Well, I'm still not sure about dotted teleport fog, but it's not bad, so I'm fine with it. You did a great job here!

[Dark Pulse]

That good old-fashioned faux transparency.

[ludicrous_peridot]

Put that into an updated version of the mod I was talking about before. 

Also made an attempt to "speed up" the weapons, but have no idea how "genuine" that ended up being. 

[Mattfrie1]

I stumbled across another interesting pre-release article of Saturn Doom from the December 1996 issue of EGM. The release date for the game was pegged for November 1996, which of course was delayed by several months until March 1997. Some interesting notes from the write up include how there is "no slowdown during play", yet later mentions that the graphics were "somewhat choppy". This was an issue that they expected would be solved by the time of the final release. It is also mentioned that the music is redbook audio, but that it "matches the music of the PC title". Either the author of the piece wasn't fully familiar with the Bobby Prince PC score and assumed Aubrey Hodges' soundtrack was on the PC, or that it was planned to have the PC music in the game at some point. Definitely an interesting prospect.

[OldDoomer]

I don't know how relevant it is to the discussion at hand, however since the topic of reviews and articles is starting to crop up I thought I would show off material for the Saturn Doom port in Japan.

 

The first image is an ad that first appeared in the January 1997 issue of Saturn Magazine and continued for some months after. Interesting of which is that the ad lists a February 1997 release date, which didn't happen. Also further interesting enough even after the US market Saturn Doom did release the ads continued to use the PSX port's screenshots; there were no updates showing off the US Saturn port's screens. SoftBank handled the Japanese distribution of Saturn Doom.

 

 

The second image is of the first review by Saturn Mag critics later in 1997. The lowest scored critic is lamenting how yet another port of Doom is releasing and that, by this time, Doom was fairly old. Most of the commenters are speaking specifically of the game play aspects, and not necessarily the technicalities of the port; relatively common from these sort of reviews.

 

 

The third image is the final reader's rating for Sega Saturn. Periodically, Saturn Mag would perform a reader's ratings of all current Saturn titles, rating them by position. In 2000 when the Saturn was in it's final days, the magazine compiled all of the prior ratings into the "final" rating of Saturn titles. I put a red box around Doom's rating, which came in at an even 7.0 and number 641 (the box in yellow is the game's previous reader's rating position). One thing to keep in mind however is that Japan's tastes were quite different from the US's, with there being hundreds upon hundreds of visual novels and similar type games on the console that never left Japan. To give an idea what Doom was going up against, the fourth image is the top picks as rated by Japanese gamers, which were mostly visual novels and RPGs. They include Eve Burst Error, Grandia, Langrisser, YU-NO, Machi [City; this was a "sound novel"], and Pia Carrot as the top six.

 

Edited September 14, 2021 by OldDoomer

[Mattfrie1]

Finally found out how to access the hidden credit sequence!

 

 

Enter "jb4jh*****" for Rage Special Credits and "lyjvm*****" for Sega Special Credits at the password screen (The asterisks can be any value). After it flashes "invalid password" just press the start button to display the credits. Pretty sure this has remained undiscovered for all these years.

 

EDIT: Seems like this Easter egg is a bit more difficult to enable than just entering passwords. From what I have discovered so far the credits will only display after Map 02 (Plant) has been loaded into memory. Trying to use the passwords from any other map or from starting up the game after powering the system on will not trigger the hidden screens. I've also discovered that the last 5 characters of the password can be any character, just as long as the first 5 characters are the ones listed above.

 

For those curious, I figured out the password values by examining the hex of 0.bin (aka the main program file). The password values for enabling the screens are stored in plain-text right before SKY20 and SKY21 in the code, and are slightly before what appears to be the code for the password screen.

Edited October 11, 2021 by Mattfrie1

[Roebloz]

The mysterious sky lumps are probably not related to PSX Doom, as the flame skies are procedurally generated.

[ludicrous_peridot]

On 10/11/2021 at 9:31 PM, Mattfrie1 said:

Finally found out how to access the hidden credit sequence!

 

 

That's awesome!

Was looking at those two strings as well, but had lost all hope getting to the secret credits without help of a debugging or disassembling tool, so gave up after trying to input different combinations of those in password screen. I then just imagined how it might have looked, and now I can see I was not quite correct about this :)))

 

 

Spoiler

 

On 9/3/2021 at 2:15 AM, Dark Pulse said:

That good old-fashioned faux transparency.

 

Talking about the "faux" thing - I have been spending more time with DOS stuff then anything else Doom-related this year, so eventually decided to implement the same effect with the renderer itself (as opposed to using shaders as in the pics above), as doing this in DOS port was so much more straight forward, and I was still curious about the whole thing.

A kind of "revelation" came when I tried this effect on a 17" CRT in high resolution (renderer set to 1280x800). The individual pixels "dissolved" completely and "checkers" were no longer seen. Instead I was seeing almost perfect 50% translucency!

Which made me think about Saturn again and that I have personally not experienced Doom Saturn on real hardware...

So a question to those who have - did the specters actually just look translucent on older TVs? I am starting to suspect that may have been the case, and the whole business with the "checkered" effect is just totally wrong on my part!

 

[Dark Pulse]

1 hour ago, ludicrous_peridot said:

A kind of "revelation" came when I tried this effect on a 17" CRT in high resolution (renderer set to 1280x800). The individual pixels "dissolved" completely and "checkers" were no longer seen. Instead I was seeing almost perfect 50% translucency!

Which made me think about Saturn again and that I have personally not experienced Doom Saturn on real hardware...

So a question to those who have - did the specters actually just look translucent on older TVs? I am starting to suspect that may have been the case, and the whole business with the "checkered" effect is just totally wrong on my part!

That's precisely why it was done, yes. The slight fuzziness of an analog video signal (transmitted with something like an RF modulator or Composite cables), along with sufficient distance from the TV, led to patterns like that blending together and essentially abusing the analog nature of the transmission format to fake an actual transparency for free.

 

This sort of thing was very common with 8 and 16-bit hardware, but Sega platforms in general (The Genesis/Megadrive and Saturn) used it a lot.

 

Hence, my comment about it being that good old-fashioned faux transparency - it totally worked, but it wasn't true transparency, so much as abusing the tech of the time to create the effect. Nowadays on an LCD or some sort of RGB modded console, it all falls to pieces, of course - the image output is too good, and so the effect simply fails.

Edited November 6, 2021 by Dark Pulse

[Mattfrie1]

@ludicrous_peridot It was actually your comment back at the beginning of page 5 of this thread that inspired me to go back into the hex and see if I could discover a way to actually access the credits in game, so thanks for the inspiration.

 

As for Saturn transparency, I can also testify that back when I played on a CRT via composite that the effect worked great. The effect still works on modern day LCD monitors if you use composite connections for those that are curious.

[skullbeard27]

I recently acquired a Saturn and this project interests me a lot. I'll poke around with a dev kit and see what I can find.

Edited November 13, 2021 by skullbeard27

[Mattfrie1]

So I've recently decided to analyze the September 30th, 1996 prototype of Saturn Doom and have made a list of things that changed between the prototype and the finalized release:

 

• View bobbing and weapon swing are much more prominent in the prototype compared to the final product.
• Player weight also feels much lighter in the prototype compared to the final builds.
• There are only 2 demos in the prototype compared to the 4 included in the retail editions. These demos are also completely different than the retail versions. The first demo is a complete walkthrough of Map 18: Pandemonium, the second demo is a short incomplete attempt at Map 33: The Gantlet.
• The most noticeable change in the prototype is the inclusion of the PC version's sound effects instead of the PSX sound effects from the final release. The PC sound effects are rather buggy, with the chainsaw sound effects not cutting off properly and the shotgun sound effect causing heavy clipping if too many other sounds are playing at the same time. I've always assumed that the PC sound effects were a leftover from Bagley's original vision for the port, and were switched to the PSX sounds so only one sound designer could be credited on the final version.
• There is only mono sound in the prototype, the buggy stereo sound being added at a later date. The same sound driver is being used in this prototype however.
• For some reason the berserk pack doesn't tint the screen red upon pickup. All other pickups (Invulnerability, Radiation Suit) still function correctly however.
• The CD audio only contains the tracks that were CD audio on PSX Doom. None of Aubrey Hodges' ambient tracks were converted to CD audio yet, so the track that plays for the demo sequence is used as placeholder for all 59 levels.
• The opening sequence includes placeholder text instead of the hi-res screens from the final product. A unique animation of the GT Interactive logo is used here, which goes unused but is still on the disc of the final released editions.
• Special ID Software and Rage Software screens are used during the demo credit sequence which are unused in the final released editions:

Spoiler

 

• All of the glitches present in the released editions of the game are present in the prototype, including the incorrect cityscape sky being used for several levels and the Map 24: Hell Beneath secret area texture not being displayed properly. 
• The overall program file for prototype is smaller (349kb) compared to the final releases (395kb). I haven't noticed any major gameplay changes or crashes compared to the final released versions, although I am still poking around the prototype to see what I can find.

I also took the time to analyze any major differences between the three regional releases of the port which haven't been covered in major detail as of yet:

• The PAL edition of the game is the earliest build dating from 11/20/96. The NTSC-U version is second with a date of 1/29/97 and the NTSC-J version is the last build from 3/24/97.
• There are some extra credits in the PAL version that were removed from the two NTSC editions. As noticed in @ludicrous_peridot's list of strings from a few pages back, a special thanks credit is given to PSX port programmer Aaron Seeler. Also, Rage Software employees Kev Bruce and Steve Lord are credited with Music & SFX in the PAL version, but are only given a "thanks to" in the NTSC versions.

Spoiler

PAL Credits:

 

NTSC credits:

•   The Williams Entertainment logo is still accidentally included outside of Club Doom in both the prototype and PAL versions of the game. It is removed for the NTSC versions.

Spoiler

• The rumor behind the Japanese version running at a slightly higher FPS has been squashed by others in recent years. The other rumor surrounding this edition, that the CD audio tracks have been rearranged, is also false. The only change in the music for this edition is one CD audio track (A Calm Panic Rises, Track 18 on the PAL and NTSC-U discs) was inexplicably removed from the Japanese CD. This pushes up the running order of the track rotation for the remaining levels in the game starting from Map 10. This also makes the size of the disc slightly smaller for the Japanese version as well (528mb vs. 557mb)
• Finally, the program file (0.bin) for all 3 regions vary in size slightly, with the PAL version being 394kb, and the NTSC versions being 395kb. Apart from some obvious changes (Link Cable support in PAL and NTSC-J editions), I have yet to notice any major changes between the regions. This is something I am continuing to look into however.

Edited November 27, 2021 by Mattfrie1

[ludicrous_peridot]

I've been studying 3do Doom sources for some time now, and I guess the main reason for that was that those "fast weapons" have really been bugging me... to the extent I cross referenced DOS sources, 3DO Doom and @Erick194's reverse engineered PSX source of info.c and made a dump of what definitely looks like frame data in the 0.BIN Saturn binary:

 

Spoiler

Frames
239092: [0, 0, 4294967295, 0, 0, 0, 0]
239120: [1, 4, 0, 100768684, 0, 0, 0]
239148: [2, 0, 1, 100766568, 2, 0, 0]
239176: [2, 0, 1, 100766940, 3, 0, 0]
239204: [2, 0, 1, 100767032, 4, 0, 0]
239232: [2, 1, 2, 0, 6, 0, 0]
239260: [2, 2, 2, 100767132, 7, 0, 0]
239288: [2, 3, 2, 0, 8, 0, 0]
239316: [2, 2, 2, 0, 9, 0, 0]
239344: [2, 1, 2, 100766816, 2, 0, 0]
239372: [3, 0, 1, 100766568, 10, 0, 0]
239400: [3, 0, 1, 100766940, 11, 0, 0]
239428: [3, 0, 1, 100767032, 12, 0, 0]
239456: [3, 0, 2, 0, 14, 0, 0]
239484: [3, 1, 3, 100767972, 15, 0, 0]
239512: [3, 2, 3, 0, 16, 0, 0]
239540: [3, 1, 2, 100766816, 10, 0, 0]
239568: [4, 32768, 3, 100768694, 1, 0, 0]
239596: [1, 0, 1, 100766568, 18, 0, 0]
239624: [1, 0, 1, 100766940, 19, 0, 0]
239652: [1, 0, 1, 100767032, 20, 0, 0]
239680: [1, 0, 2, 0, 22, 0, 0]
239708: [1, 0, 2, 100768076, 23, 0, 0]
239736: [1, 1, 3, 0, 24, 0, 0]
239764: [1, 2, 2, 0, 25, 0, 0]
239792: [1, 3, 2, 0, 26, 0, 0]
239820: [1, 2, 2, 0, 27, 0, 0]
239848: [1, 1, 2, 0, 28, 0, 0]
239876: [1, 0, 2, 0, 29, 0, 0]
239904: [1, 0, 3, 100766816, 18, 0, 0]
239932: [5, 32768, 2, 100768694, 31, 0, 0]
239960: [5, 32769, 1, 100768704, 1, 0, 0]
239988: [6, 0, 1, 100766568, 32, 0, 0]
240016: [6, 0, 1, 100766940, 33, 0, 0]
240044: [6, 0, 1, 100767032, 34, 0, 0]
240072: [6, 0, 2, 0, 36, 0, 0]
240100: [6, 0, 3, 100768276, 37, 0, 0]
240128: [6, 1, 3, 0, 38, 0, 0]
240156: [6, 2, 3, 100766920, 39, 0, 0]
240184: [6, 3, 3, 100768912, 40, 0, 0]
240212: [6, 4, 3, 0, 41, 0, 0]
240240: [6, 5, 3, 100768932, 42, 0, 0]
240268: [6, 6, 2, 0, 43, 0, 0]
240296: [6, 7, 2, 100768952, 44, 0, 0]
240324: [6, 0, 2, 100766816, 32, 0, 0]
240352: [6, 1, 3, 0, 46, 0, 0]
240380: [6, 0, 1, 0, 33, 0, 0]
240408: [6, 32776, 2, 100768694, 48, 0, 0]
240436: [6, 32777, 2, 100768704, 1, 0, 0]
240464: [7, 0, 1, 100766568, 49, 0, 0]
240492: [7, 0, 1, 100766940, 50, 0, 0]
240520: [7, 0, 1, 100767032, 51, 0, 0]
240548: [7, 0, 2, 100768540, 53, 0, 0]
240576: [7, 1, 2, 100768540, 54, 0, 0]
240604: [7, 1, 0, 100766816, 49, 0, 0]
240632: [8, 32768, 3, 100768694, 1, 0, 0]
240660: [8, 32769, 2, 100768704, 1, 0, 0]
240688: [9, 0, 1, 100766568, 57, 0, 0]
240716: [9, 0, 1, 100766940, 58, 0, 0]
240744: [9, 0, 1, 100767032, 59, 0, 0]
240772: [9, 1, 4, 100767092, 61, 0, 0]
240800: [9, 1, 6, 100767544, 62, 0, 0]
240828: [9, 1, 0, 100766816, 57, 0, 0]
240856: [10, 32768, 2, 100768694, 64, 0, 0]
240884: [10, 32769, 2, 0, 65, 0, 0]
240912: [10, 32770, 2, 100768704, 66, 0, 0]
240940: [10, 32771, 2, 100768704, 1, 0, 0]
240968: [11, 2, 2, 100766568, 68, 0, 0]
240996: [11, 3, 2, 100766568, 67, 0, 0]
241024: [11, 2, 1, 100766940, 69, 0, 0]
241052: [11, 2, 1, 100767032, 70, 0, 0]
241080: [11, 0, 2, 100767292, 72, 0, 0]
241108: [11, 1, 2, 100767292, 73, 0, 0]
241136: [11, 1, 0, 100766816, 67, 0, 0]
241164: [12, 0, 1, 100766568, 74, 0, 0]
241192: [12, 0, 1, 100766940, 75, 0, 0]
241220: [12, 0, 1, 100767032, 76, 0, 0]
241248: [12, 0, 2, 100767656, 78, 0, 0]
241276: [12, 1, 10, 100766816, 74, 0, 0]
241304: [13, 32768, 2, 100768694, 1, 0, 0]
241332: [13, 32769, 2, 100768694, 1, 0, 0]
241360: [14, 0, 1, 100766568, 81, 0, 0]
241388: [14, 0, 1, 100766940, 82, 0, 0]
241416: [14, 0, 1, 100767032, 83, 0, 0]
241444: [14, 0, 10, 100768892, 85, 0, 0]
241472: [14, 1, 5, 100767092, 86, 0, 0]
241500: [14, 1, 5, 100767600, 87, 0, 0]
241528: [14, 1, 10, 100766816, 81, 0, 0]
241556: [15, 32768, 5, 100768694, 89, 0, 0]
241584: [15, 32769, 3, 100768704, 1, 0, 0]
 

 

One may have expected these actually match what's found in PSX source.

 

What I am wondering about though (and pardon if I'm not using search function to find this out) is what tick rate Saturn version ran at?

Wiki says PSX version ran at 15Hz, while 3DO source has a comment that 60Hz timer is expected and all the tick values in frames section are multiplied by 4 explicitly. I am very much curious about the rate game timer ran at for Saturn.

 

[Dark Pulse]

1 hour ago, ludicrous_peridot said:

What I am wondering about though (and pardon if I'm not using search function to find this out) is what tick rate Saturn version ran at?

Wiki says PSX version ran at 15Hz, while 3DO source has a comment that 60Hz timer is expected and all the tick values in frames section are multiplied by 4 explicitly. I am very much curious about the rate game timer ran at for Saturn.

On PSX, logic/AI was run at 15 Hz, rendering at 30 Hz. Since the Saturn version is literally a port of the PSX version, I'd imagine it's probably the same, but if it's not, it's likely at least in this same vein where the AI/logic is at a different rate from the rendering.

[ludicrous_peridot]

@Dark Pulse thanks for the hint.

 

I've consulted PSX code more and it seems the matter is rather convoluted, so I was wondering if you could validate what I could gather from that:

1. on PSX the unit of time is vertical blank sync period, which I assume is 60Hz (but it could be 50Hz too, right?)

2. PSX Doom waits for at least 2 vbls before running the next loop (so no game code running faster than 30Hz)

3. Game logic actually checks that at least 4 vbls have passed before each next iteration, meaning most Thinkers wouldn't run faster than 15Hz

4. Except that player logic is more specific in what to run when, and weapon sprites updates routine for example is run without waiting for 4 vbls

5. However internally weapon state update explicitly considers frame ticks to be 4 vbls long (logic for which is maintained locally by the code), meaning that weapons change states and sprites at 15Hz   

The above translates to me to 150 pistol shots per minute.

 

Now, appreciate Saturn is port of PSX version straight, there's quite a lot in the above that could go astray while porting... I could imagine, for example, weapon state code to break that local logic, and run state check on every invocation, yielding result of up to 300 pistol shots per minute (that, if waiting for 2 vbls for each loop even holds true for Saturn!).

[Dark Pulse]

9 hours ago, ludicrous_peridot said:

@Dark Pulse thanks for the hint.

 

I've consulted PSX code more and it seems the matter is rather convoluted, so I was wondering if you could validate what I could gather from that:

1. on PSX the unit of time is vertical blank sync period, which I assume is 60Hz (but it could be 50Hz too, right?)

2. PSX Doom waits for at least 2 vbls before running the next loop (so no game code running faster than 30Hz)

3. Game logic actually checks that at least 4 vbls have passed before each next iteration, meaning most Thinkers wouldn't run faster than 15Hz

4. Except that player logic is more specific in what to run when, and weapon sprites updates routine for example is run without waiting for 4 vbls

5. However internally weapon state update explicitly considers frame ticks to be 4 vbls long (logic for which is maintained locally by the code), meaning that weapons change states and sprites at 15Hz   

The above translates to me to 150 pistol shots per minute.

 

Now, appreciate Saturn is port of PSX version straight, there's quite a lot in the above that could go astray while porting... I could imagine, for example, weapon state code to break that local logic, and run state check on every invocation, yielding result of up to 300 pistol shots per minute (that, if waiting for 2 vbls for each loop even holds true for Saturn!).

I'm afraid that I'm not really the type of guy who could answer those questions too well, but I do know two who should be able to. That said, yes, I do know the NTSC version runs at 60 Hz and the PAL version at 50 Hz. Besides that, I'm pretty useless when it comes to the actual technical gubbins of the code.

 

Therefore: @Erick194, @intacowetrust, it's all yours.

Edited January 13, 2022 by Dark Pulse

[Muusi]

On 11/6/2021 at 10:40 PM, Dark Pulse said:

some sort of RGB modded console, it all falls to pieces, of course - the image output is too good, and so the effect simply fails.

Saturn does RGB out of the box though. 

[Dark Pulse]

3 hours ago, Muusi said:

Saturn does RGB out of the box though. 

Only via SCART, which is not a worldwide standard. (It certainly never took off in the US.)

 

And either way, it's still an analog signal, so it'd work there. I should have more clearly explained that a digital signal where there would be no inherent loss of information is where it'd be too crisp (i.e; modern HDMI as opposed to SCART/S-Video/Component/Composite).

Edited January 15, 2022 by Dark Pulse

[Shadow Hog]

Technically JP21 in Japan/East Asia as well. Connector looks the same as SCART, but the pinout is different.

 

But honestly, it'll break down as low as S-Video, so this is splitting hairs. You need composite or RF for the transparency effect to work, otherwise the signal is sufficiently separated enough that the dithered pixels are laid bare.

[intacowetrust]

On 1/13/2022 at 4:19 AM, ludicrous_peridot said:

1. on PSX the unit of time is vertical blank sync period, which I assume is 60Hz (but it could be 50Hz too, right?)

 

Correct: for the PAL version of the game the vblank interval is every 1/50 seconds. The developers did make some adjustments to the frame pacing and timing code however to account for this. Here's a few spots in the PsyDoom codebase that might be of interest (PsyDoom can emulate the PAL timings, if required):

 

https://github.com/BodbDearg/PsyDoom/blob/2cb1613ac754ec93b06294d7bf93977bb0457049/game/Doom/doomdef.h#L89
https://github.com/BodbDearg/PsyDoom/blob/2cb1613ac754ec93b06294d7bf93977bb0457049/game/Doom/Base/i_main.cpp#L550
https://github.com/BodbDearg/PsyDoom/blob/2cb1613ac754ec93b06294d7bf93977bb0457049/game/Doom/d_main.cpp#L710
https://github.com/BodbDearg/PsyDoom/blob/2cb1613ac754ec93b06294d7bf93977bb0457049/game/Doom/Game/p_pspr.cpp#L887

 

On 1/13/2022 at 4:19 AM, ludicrous_peridot said:

I've consulted PSX code more and it seems the matter is rather convoluted, so I was wondering if you could validate what I could gather from that:

1. on PSX the unit of time is vertical blank sync period, which I assume is 60Hz (but it could be 50Hz too, right?)

 2. PSX Doom waits for at least 2 vbls before running the next loop (so no game code running faster than 30Hz)

 3. Game logic actually checks that at least 4 vbls have passed before each next iteration, meaning most Thinkers wouldn't run faster than 15Hz

4. Except that player logic is more specific in what to run when, and weapon sprites updates routine for example is run without waiting for 4 vbls

5. However internally weapon state update explicitly considers frame ticks to be 4 vbls long (logic for which is maintained locally by the code), meaning that weapons change states and sprites at 15Hz   

The above translates to me to 150 pistol shots per minute.

 

The situation is actually even more convoluted than that :) Depending on the frame rate of the game and if it falls low enough, the engine will sometimes switch the player movement/control updates to be every 1/15 seconds (for NTSC) just like the rest of the world logic and the weapon logic.

 

When this situation occurs (what I refer to as a 'long tick') the game tries to adjust some of the physics quantities accordingly for the lower tick rate. It does this however in an incorrect/inconsistent manner which results in noticeably different physics at lower frame rates. When the frame rate is low, gravity is much weaker and it feels like the player is very 'floaty'. Wall sliding can also be affected, walls seem a bit stickier at higher frame rates.

 

I did a video showing the effect of the frame rate on gravity previously:

 

[ludicrous_peridot]

On 11/27/2021 at 9:49 PM, Mattfrie1 said:

The Williams Entertainment logo is still accidentally included outside of Club Doom in both the prototype and PAL versions of the game. It is removed for the NTSC versions.

 

Wanted a bit of a distraction from the news so was watching Doom youtube vids, one had the preview version and that led me to check the assets available on the on the CD the vid had a reference to. On thing I've noticed was that 0.BIN in the preview version was different from the release in that it was lacking a reference to WALL20. Wall20 having a blank black area fitting the removed logo part of the wall, I imagine could be the replacement texture. How that would've overridden pre-baked texture data from the MAPTEX%d.IMG I have no idea. :)

 

 

 

Was also curious about the MAP60TEX/MAP60SPR files on the release disk, my hypothesis those are used for the cast section based on the MAP60SPR.IMG next to BOSSBACK in the 0.BIN.

[Quasar]

24 minutes ago, ludicrous_peridot said:

Was also curious about the MAP60TEX/MAP60SPR files on the release disk, my hypothesis those are used for the cast section based on the MAP60SPR.IMG next to BOSSBACK in the 0.BIN.

That's correct, or at least, that's what they're used for in PSX Doom.

[Mattfrie1]

On 3/3/2022 at 1:21 PM, ludicrous_peridot said:

 

Wanted a bit of a distraction from the news so was watching Doom youtube vids, one had the preview version and that led me to check the assets available on the on the CD the vid had a reference to. On thing I've noticed was that 0.BIN in the preview version was different from the release in that it was lacking a reference to WALL20. Wall20 having a blank black area fitting the removed logo part of the wall, I imagine could be the replacement texture. How that would've overridden pre-baked texture data from the MAPTEX%d.IMG I have no idea. :)

Great find @ludicrous_peridot. Just did a quick check in my emulator and this is indeed the "patch" to override WMSWALL. Deleting this reference then loading up the level shows a blank area where the patch should be.

 

[Mattfrie1]

Messed around with this a little bit more to see if I could determine how the behavior of this works. It seems like replacing the texture name referenced in 0.bin with another one that is elsewhere in the level will have that one display instead. One can also put WMSWALL back into this spot as well, showing that it is loaded into memory but not displayed normally on NTSC versions of the game.

 

Spoiler

 

 

 

[ludicrous_peridot]

Spoiler

Should be doable with Team GEC tools and a hex editor then, I guess.

 

;)

[Whiteysnakey]

_

Edited August 3, 2022 by Whiteysnakey

[Shadow Hog]

BCDFGHJKLMNPQRST-100% runs when

[Jayextee]

Is that not just the string for the password entry letters? It is, after all, lacking the vowels and followed up by 0123456789! and then 'Attack', presumably from the control configuration submenu; leading me to believe they're just all the main menu strings.

[Mattfrie1]

@Whiteysnakey This actually appears to be the character set that the system uses to display passwords, both given at the end of the level and when you enter a password on the password screen. For the screenshots I changed the value of that string to reflect this, since E isn't a character used for passwords. Unfortunately no Nightmare mode it seems... :(

 

 

[Whiteysnakey]

_

Edited August 3, 2022 by Whiteysnakey