fafling

The lighting informations is indeed present, and loaded in memory. There's even bits of code that are using it, but I have yet to figure out for what exactly. Possibly for the light level calculations as colored lighting can be used to darken rooms. But could also be useless remnants of the PSX code for that. The problem with the colored lighting on Saturn is that Doom uses 8 bpp textures. That color depth prevents using directly the colored lighting information as Gouraud shading parameter. That's because when applied to 8bpp textures, VDP1's Gouraud shading shifts palette indexes instead of colors. When applied to Doom's palette, which isn't engineered for that, you'd get funky colors all around. A possibility to implement colored lighting is to rework all the textures involved to convert them to a format where VDP1's Gouraud applies to pixel's colors instead of palette indexes. But that's a lot of work and those texture formats are either 16 bpp direct color (twice as big as 8 bpp), or 4 bpp color lookup table (only 16 colors). So that would result in memory/performance issues or color downgrade, and I'm definitely not going that way. With 8bpp textures, the only way to get different color shades is to use different palettes. The radiation suit palette is an example of that. The thing is that the color palettes are stored in VDP2 color ram which is 4 KB. So that limits to 8 different 256 color palettes simultaneously on screen, one of which must be the base color palette. So you have maximum 7 other palettes to play with, one for each colored lighting on screen, supposing the whole color ram can be used for that. The PSX version has 256 different possible colored lighting, and I don't think there's a restriction on the number of different colored lighting used simultaneously other than the max number of sectors that can be on screen. And it's definitely not 7. Another hurdle is that currently 2 palettes other than the base one are present at all time in VDP2 color ram : the radiation suit palette and the invincibility one. Those 2 could be evicted, the radiation one by using a VDP2 color offset effect instead, and the invincibility one could be stored externally and only swapped in color ram when needed. So on Saturn, only a very simple approximation of the colored lighting is possible with the 8 bpp textures. And that will require a quite extensive hack and a better knowledge of the rendering part of Doom than I currently have. So if I ever get around to do that, it's not anytime soon.

There's a function only called when loading level 59 Club Doom that replaces the texture name WMSWALL by WALL20 in the sidedefs that have just been loaded. WMSWALL is hard coded in the function's character comparison instructions, that's why you can't find it as a string in the binary. The fix patch will restore it by skipping that function calls. The Williams logo deserves to be in the game since it uses a good part of the PSX version's code.

Some stuff related to the startup optimization : I intend to make the logos skippable which would gain a lot of time. If they can be skipped, I'll add the unused ID Software high res logo (https://www.doomworld.com/forum/post/2190091). I've also eliminated a function that unnecessarily ramped the CD audio volume down for several frames and paused the CD drive before certain loadings and menus (including levels and intermission screen). I've also made the D-pad right button skip to the next step of the demo loop. That will allow me to check faster any change on the demos, which I record to measure performance gain.

Yes I am working on the next version. I'm currently trying to reduce the startup time.

I didn't intend to release any more Action Replay codes for fixes, but there's a bunch of Saturn games that output CD audio in mono instead of stereo like Doom does, and it's possible to use the same codes to fix almost all of them including Doom : https://segaxtreme.net/threads/generic-action-replay-codes-to-force-stereo-and-volume-on-cdda-tracks.25543/ Of course, this isn't needed if you can use the fix patch.

You did an impressive video ! There's no official competition showreel yet, but there's an unofficial one that showed the patch (though it had a contrast issue that makes the game overly dark) :

Honestly I had gotten used to these grunts and I didn't noticed them anymore ! So it's possible to fix that, but it's more complicated than just setting a height, because it's at the same time a bug and a symptom that the gameplay has been optimized for low framerate. Like in the PSX version (I've spotted the P_PlayerZMovement function on Saturn), the gravity depends of the framerate, because a constant amount is applied once per game frame contrary to the PC where it's applied once per tick. It means that the lower the framerate, the lower the gravity, the further you can jump. Since the framerate is much lower in the Saturn version than on PSX, the amount of gravity applied each frame after the 1st during a jump has been sharply increased to keep it about consistent with the PSX : it's GRAVITY*2 instead of GRAVITY/2 (4 times as much !). What causes the player's grunt each time he even takes a small step down is that the threshold of accumulated gravity where this grunt is emitted has been left unchanged (GRAVITY*2), while gravity accumulated much faster. So a fall during just 2 frames is enough to trigger it. The easy way out is to increase the threshold, but it's like continuing to optimize for low framerate which I'd rather not. Instead, I'll try to make gravity accumulation independent of the framerate and roughly align it on the PC values, which should match the PSX behavior at 15 fps. Hopefully this won't break the demo playback, since there's very little height change during them.

Do you have an example of a sound effect with with higher pitch than on PSX ? Those that I checked were correct. You may be mistaking a pitch difference with the metallic tone of certain sound effects on Saturn that is due to the lower sampling rate / lower bit depth. That metallic tone can be more perceptible now that the sound effects are less muffled. I think the gain in clarity obtained by the pitch fix greatly offsets that downside. The info on the unused sounds for the zombies is interesting, I didn't know that. I see a difference in A_Look and A_Scream functions between PSX and PC versions. When choosing pseudo-randomly between the 3 possible sounds : PC does "P_Random() % 3", which gives 0, 1 or 2 that is added to the base sound number, allowing to alternate between the 3 sounds. PSX does "P_Random() & 1", which gives 0 or 1 that is added to the base sound number, alternating only between the first 2 sounds. I've found a match for that PSX code in the Saturn version, so it has the same problem. The fix isn't going to be easy as I'll have to make room to add a few instructions that would allow to alternate between the 3 sounds. I confirm that I haven't changed the sound effects data itself, and I don't intend to do that.

Submitted a fix patch for the Japanese version of Doom for the Segaxtreme Saturn annual game competition. It includes a number of fixes for sound, a palette change for the nightmare spectres, and a small performance improvement. The submission : https://segaxtreme.net/threads/sega-saturn-29th-anniversary-game-competition.25411/post-185179 The ressource that goes in greater details about the patch, with links to a memory map and to the patch changes : https://segaxtreme.net/resources/doom-fix-patch.287/ Have to keep the myth alive that the Japanese release is the better Saturn version ;-) @ludicrous_peridot The sampling frequency of the sound effects is hardcoded with a MIDI note value of 0x17 in the program, which translate to 5203 Hz. I am 100% sure that this value is one tone too low and that, to match the PSX version pitch, the sound effects are meant to be played back with a sampling frequency of 5512 Hz (corresponds to MIDI note 0x18), exactly half that of the PSX version samples. That's one of the fixes in the patch.

@ludicrous_peridotThe link to download your tool for SCR and CHR file conversion gives an error : "We could not locate the item you are trying to view. Error code: 2S328/1". Internet archive has a snapshot of it from earlier this year : https://web.archive.org/web/20230614191102/https://www.doomworld.com/applications/core/interface/file/attachment.php?id=100754 Also the last 2 command lines listed in your post to convert PNG to game formats are using chrtools.png and scrtools.png instead of chrtools.py and scrtools.py.

Fixed a bug in the US master code : https://segaxtreme.net/threads/action-replay-codes-for-nightmare-difficulty-in-saturn-doom.25268/post-184042

Reworked the nightmare difficulty AR code : https://segaxtreme.net/threads/action-replay-codes-for-nightmare-difficulty-in-saturn-doom.25268/post-184029

Here's an Action replay code that swaps in the inferno sky without touching the city levels : https://segaxtreme.net/threads/action-replay-code-for-unused-sky-in-saturn-doom.25309/ Also includes elements that make me think that the use of the city sky instead of the inferno sky was intentional.

That's the correct frequency as computation from the SCSP registry values yields the same result. In the SCSP debug screen of Kronos emulator, Doom sound effects are all played with octave (OCT) value 12 and frequency number switch (FNS) value 909. Octave is a 4 bit two's complement value, so 12 is certainly an unsigned value and the actual octave is in fact -4. There's a formula to compute the playback frequency Fs of a sample from these 2 parameters : Fs = (FNS + 1024) * 44100 / (2^-OCT * 1024) Which gives precisely 5202,96 Hz.

Yes I know about the story of the Saturn port. It's sheer luck that the code for the nightmare mode was left in place instead of being cleaned off.