PsyDoom 1.1.1 - PSX Doom port (reverse engineered) for PC

[Dark Pulse]

2 hours ago, intacowetrust said:

 

Challenge accepted! :P

 

PsyDoom also had the same artifact (it has pretty much all the OG rendering artifacts) but I hadn't spent time studying it until now. Here's a fix that I made after investigating the issue:

 

@Erick194 here's the changelist for it if you're interested:

https://github.com/BodbDearg/PsyDoom/commit/2a0250ca6b43d920706849d0d9018cc4656cb1f1

 

One tweak that could be made is maybe unrolling the last loop iteration so that the if() check isn't done inside of the loop each time. Not sure if it's worth the trouble though... I did it this way since it's cleaner and modern compilers might decide do make optimization anyway if it's advantageous.

A god among mere men.

 

I can see some teeny tiny crackles still if I look for them, but they appear for maybe all of one frame at a time and then they're gone. That'll be amazing for PsyDoom at least. And it drove me nuts in this map and Bloodsea Keep (it's REALLY bad there). Either way, it's massively improved, and you have my thanks.

 

The question now becomes is this something that could be ported back to PSXDoom-RE? @Erick194?

 

^{Now please die a couple times in that level to soothe my black heart, since you can't play any of my other ones until Final Doom support is added.}

Edited June 4, 2020 by Dark Pulse

[Erick194]

19 hours ago, intacowetrust said:

@Erick194 here's the changelist for it if you're interested:

Again thank you very much for looking for a solution to that bug, here the commit of the change:

https://github.com/Erick194/PSXDOOM-RE/commit/07375cae6d6ba10a4bdb4c62ef4f9cc1cbfc4a92

[intacowetrust]

On 6/4/2020 at 3:18 AM, Dark Pulse said:

I can see some teeny tiny crackles still if I look for them, but they appear for maybe all of one frame at a time and then they're gone. That'll be amazing for PsyDoom at least. And it drove me nuts in this map and Bloodsea Keep (it's REALLY bad there). Either way, it's massively improved, and you have my thanks.

 

 

Yeah there's still a few other (less severe) precision issues going on that would need to be addressed. The main one I notice is that sometimes columns are skipped at the end of walls or when they are clipped against the sides of the screen. Very distant lower/upper wall pieces also to occasionally not draw, maybe because they are getting too small. Perhaps some more time can be spent investigating these later... 

 

15 hours ago, Erick194 said:

Again thank you very much for looking for a solution to that bug, here the commit of the change:

https://github.com/Erick194/PSXDOOM-RE/commit/07375cae6d6ba10a4bdb4c62ef4f9cc1cbfc4a92

 

You're very welcome, happy to help!

[Dark Pulse]

@intacowetrust Well why the hell not - let's talk about a few more bugs, straight from the Doom Wiki.

• A rocket launcher blast originating from a player's rocket launcher shot does not do any damage to them whenever they are facing a corner where the walls are aligned in an angle of 90 degrees. The player must also be facing slightly off the corner's edge and be as close to it as possible.

Now why is that? My only guess is that it's got something weird to do with the fact that the collision checks are slightly different in PSX Doom than in PC (I remember having to nudge some pickups in order for them to actually be gettable). Could this be because some part of some code, somewhere, assumes the player is partially outside for collision purposes and so the game decides they're not hurt? Or perhaps that's applying to the explosion itself - it thinks the epicenter is outside the linedef, so the linedef clips the explosion blast radius?

• Dramatic memory corruption can be triggered by Lost Souls moving outside the normal boundaries of the levels. Linedefs and sectors in the map will become progressively distorted from their normal layouts until the areas become unrecognizable and eventually the game crashes.

This one, everyone and their grandma knows about. There's some well-known videos.

 

 

The "obvious" solution would be for the game to basically kill any monster (or projectile?) that gets shot into null space. Normally that'd do, however the PLAYER moving far enough outside the bounds also begins triggering the memory corruption (which is the reason that there's not a noclip inside the original game). With PsyDoom readding Noclip back in, this definitely has to be factored for now.

 

How could this be resolved for both PsyDoom and PSXDoom-RE? Maybe something like instituting an invisible barrier a certain amount of units outside the level? An autokill barrier if anything is detected inside it? (Dunno how that'd stop projectiles though, admittedly).

[intacowetrust]

13 hours ago, Dark Pulse said:

@intacowetrust Well why the hell not - let's talk about a few more bugs, straight from the Doom Wiki.

• A rocket launcher blast originating from a player's rocket launcher shot does not do any damage to them whenever they are facing a corner where the walls are aligned in an angle of 90 degrees. The player must also be facing slightly off the corner's edge and be as close to it as possible.

Now why is that? My only guess is that it's got something weird to do with the fact that the collision checks are slightly different in PSX Doom than in PC (I remember having to nudge some pickups in order for them to actually be gettable). Could this be because some part of some code, somewhere, assumes the player is partially outside for collision purposes and so the game decides they're not hurt? Or perhaps that's applying to the explosion itself - it thinks the epicenter is outside the linedef, so the linedef clips the explosion blast radius?

 

It looks like the issue is the rocket spawning on the opposite side of the wall line, and a line of sight check failing from the exploded rocket's position to the player because of that. Because the line of sight check failing, no splash damage is applied - hence the bug.

 

When a rocket is spawned in both PSX and PC Doom it gets 'nudged' forward a little bit immediately. On PC this wasn't as much of a problem because the timestep is smaller, with 1/35 seconds being simulated for every game tick. On PSX it is 1/15 seconds being simulated per game tick so the rocket gets nudged along much further with each step. This little 'nudge' on PSX in some cases pushes the rocket past the wall in front of the player, causing the bug.

 

My fix is to check the original position of the rocket (which is the firer's position) and whether it can be nudged to the new location _before_ the nudge is actually done. If the check fails I explode the rocket immediately. Here is a video showing a before and after of the fix:

 

 

@Erick194 I made a fix for this issue in the following commit, but I am not applying it to PsyDoom by default because it breaks demo compatibility and some of my automated tests: https://github.com/BodbDearg/PsyDoom/commit/624a2807c3302c57c342af19297774d5a4661150

 

I might make this a configurable gameplay option at some point later however.

 

14 hours ago, Dark Pulse said:

This one, everyone and their grandma knows about. There's some well-known videos.

....

 

The "obvious" solution would be for the game to basically kill any monster (or projectile?) that gets shot into null space. Normally that'd do, however the PLAYER moving far enough outside the bounds also begins triggering the memory corruption (which is the reason that there's not a noclip inside the original game). With PsyDoom readding Noclip back in, this definitely has to be factored for now.

 

How could this be resolved for both PsyDoom and PSXDoom-RE? Maybe something like instituting an invisible barrier a certain amount of units outside the level? An autokill barrier if anything is detected inside it? (Dunno how that'd stop projectiles though, admittedly).

 

This issue is actually already fixed for PsyDoom, and I believe @Erick194 has applied the fixes I called out to PSXDOOM-RE also. The problem was that no bounds checks were being done when inserting things into the blockmap, resulting in buffer overflows and memory corruption when things go outside the normal bounds of the map. The fix is to simply not add things into the blockmap when they are out of bounds.

 

[Erick194]

@intacowetrust Oh great, I could add it like in future for psx master edition as a flag in GameInfo maybe.

I take this opportunity to say something important, in a couple of weeks or these days I will have a complete Final Doom Psx, and soon I will release the source code.

[intacowetrust]

16 hours ago, Erick194 said:

I take this opportunity to say something important, in a couple of weeks or these days I will have a complete Final Doom Psx, and soon I will release the source code.

 

That's fantastic news @Erick194! This will help me a lot with adding Final Doom support to PsyDoom - looking forward to the release of that work :)

[Impboy4]

It's happened:

 

[intacowetrust]

2 hours ago, Impboy4 said:

It's happened:

 

 

Woohoo!!

 

Final Doom support in PsyDoom coming...

 

 

:P

[Impboy4]

I have a request to ask: Do you think it will be possible to implement game capture or window capture support for streamers? I have a friend who wants to try it out but he can only use area capture and the sound output isn't as good.

[Woolie Wool]

Is there a chance of either of the current ports spawning something with a more robust UI and PC style controls, or perhaps even supporting GEC Master Edition?

[intacowetrust]

12 hours ago, Impboy4 said:

I have a request to ask: Do you think it will be possible to implement game capture or window capture support for streamers? I have a friend who wants to try it out but he can only use area capture and the sound output isn't as good.

 

Not entirely sure what that is... Does a game need to add explicit support for streaming software? I am adding a proper fullscreen mode very soon also, will that help?

 

10 hours ago, Woolie Wool said:

Is there a chance of either of the current ports spawning something with a more robust UI and PC style controls, or perhaps even supporting GEC Master Edition?

 

I won't be doing any drastic changes of the UI (beyond what is necessary, like a 'quit' option in the menus) but keyboard and mouse will be supported. I also plan to support the GEC Master Edition too.

[Lollie]

8 hours ago, intacowetrust said:

Not entirely sure what that is... Does a game need to add explicit support for streaming software? I am adding a proper fullscreen mode very soon also, will that help?

Basically, OBS Studio requires a game to be using DirectX or OpenGL in order for "Game Capture" sources to function correctly.

https://obsproject.com/wiki/Sources-Guide#game-capture

 

In lieu of that though, Window Capture should be working with PsyDoom just fine. In fact, both Window Capture and Game Capture seem to have no trouble capturing PsyDoom for me in OBS Studio 25.0.8. @Impboy4, your friend might want to try adding an Audio Output Capture source to their scene if they haven't already.

Edited June 15, 2020 by Lollie

[Impboy4]

2 hours ago, Lollie said:

Basically, OBS Studio requires a game to be using DirectX or OpenGL in order for "Game Capture" sources to function correctly.

https://obsproject.com/wiki/Sources-Guide#game-capture

 

In lieu of that though, Window Capture should be working with PsyDoom just fine. In fact, both Window Capture and Game Capture seem to have no trouble capturing PsyDoom for me in OBS Studio 25.0.8. @Impboy4, your friend might want to try adding an Audio Output Capture source to their scene if they haven't already.

The thing is, he doesn't use OBS but this recording software: https://store.steampowered.com/app/228180/Action__Gameplay_Recording_and_Streaming/

[seed]

2 hours ago, Lollie said:

Basically, OBS Studio requires a game to be using DirectX or OpenGL in order for "Game Capture" sources to function correctly.

https://obsproject.com/wiki/Sources-Guide#game-capture

 

25.0.4 also added support for Vulkan game capture.

[intacowetrust]

4 hours ago, Lollie said:

Basically, OBS Studio requires a game to be using DirectX or OpenGL in order for "Game Capture" sources to function correctly.

https://obsproject.com/wiki/Sources-Guide#game-capture

 

In lieu of that though, Window Capture should be working with PsyDoom just fine. In fact, both Window Capture and Game Capture seem to have no trouble capturing PsyDoom for me in OBS Studio 25.0.8. @Impboy4, your friend might want to try adding an Audio Output Capture source to their scene if they haven't already.

 

Awesome, thanks for checking that out! PsyDoom (currently) asks SDL to create an OpenGL window so in theory it should work with any recording software that does GL.

Edited June 15, 2020 by intacowetrust

[Dark Pulse]

@intacowetrust Yet another possible PSX bug I remembered - Barons of Hell/Hell Knights don't have an infighting exception on PSX Doom. As a result, they will fight each other in maps that use both. (Which is, admittedly, unlikely, due to RAM reasons.)

 

Technically this originated in Jaguar Doom, and carried over to PSX/Doom 64. In Doom 64 they've at least got differing projectiles so it's more understandable.

 

The question is, is this a bug or not? I mean it's definitely best left with an optional switch to be sure, but it's definitely different from the PC version.

 

(Then again, so is stuff like the Lost Soul health, which is the same as Doom 64.)

[Impboy4]

I think the Baron/Hell Knight thing is more of a "happy accident" than a bug. Without it would have made some maps harder to deal with when both enemies are present with a PS1 controller.

[seed]

The Baron/HK infighting dilemma sounds like a feature rather than a bug to me honestly, and the fact that this was carried even further into D64 kind of is proof of this, that it is just the way the developers wanted to use the monsters as it made them more interesting that way.

 

I find it unlikely that it was somehow lost during game development.

Edited June 16, 2020 by seed

[Dark Pulse]

1 hour ago, seed said:

The Baron/HK infighting dilemma sounds like a feature rather than a bug to me honestly, and the fact that this was carried even further into D64 kind of is proof of this, that it is just the way the developers wanted to use the monsters as it made them more interesting that way.

 

I find it unlikely that it was somehow lost during game development.

Well, it's well known that Jaguar Doom was based on the 1.2 Codebase, which predates Doom II (obviously).

 

This means it also precedes the Hell Knight even existing though, so when they were added in for PSX Doom (and then Doom 64), basically it means the lack of the exception became an oversight, since obviously Jaguar Doom didn't have Doom II content, but PSX Doom did.

[seed]

1 minute ago, Dark Pulse said:

Well, it's well known that Jaguar Doom was based on the 1.2 Codebase, which predates Doom II (obviously).

 

This means it also precedes the Hell Knight even existing though, so when they were added in for PSX Doom (and then Doom 64), basically it means the lack of the exception became an oversight, since obviously Jaguar Doom didn't have Doom II content, but PSX Doom did.

 

Perhaps, but considering that it was carried into D64 as well makes me suspicious that it was an oversight all the way. I can see that in PSX Doom but not also in D64.

[Dark Pulse]

1 minute ago, seed said:

 

Perhaps, but considering that it was carried into D64 as well makes me suspicious that it was an oversight all the way. I can see that in PSX Doom but not also in D64.

Doom 64 it's likely intentional given the different colored projectiles, yes. Also it's pretty likely that there's no way they wouldn't have noticed it with the higher monster variety densities possible on Doom 64.

[seed]

5 minutes ago, Dark Pulse said:

Doom 64 it's likely intentional given the different colored projectiles, yes. Also it's pretty likely that there's no way they wouldn't have noticed it with the higher monster variety densities possible on Doom 64.

 

Exactly, and considering the way they were used, it's just all too convenient otherwise.

 

But I think PSX Doom was also on purpose because you know, Final Doom also exists and I just find it questionable that no-one at Midway or id ever noticed the 2 can fight each other at all across two different games, and if they did not, surely a player saw it, reported it, and it would've likely been corrected in a future patch or in PSX Final Doom in the worst case.

 

I wonder if @Hyde is still browsing DW, we could perhaps ask him for clarifications.

Edited June 16, 2020 by seed

[intacowetrust]

Looks like the bug (or feature, depending on your POV) is caused by some new logic that was added for Doom II to 'PIT_CheckThing' which was not carried over to the PlayStation's Jaguar/Doom-1 derived codebase. It probably got missed because it wasn't in one of the new Doom 2 functions and wasn't causing very obvious problems in most cases. The logic just adds a special case for Baron and Hell Knight missiles and treats missile hits between the two species as if they were the same species - causing the missile to explode but no damage being applied.

 

I'd wager this was probably an oversight for regular PSX Doom given the rarity of these two enemies being in close proximity at the same time.

 

For D64 however it does sound like they deliberately decided to keep this difference and thought it more confusing if Barons and Hell Knights were treated as the same types of enemy. Only the original team would know for sure however...

[fenderc01]

Another bug that could be fixed for the PC version are that opposite directions don't cancel out when pressed at the same time. Left/Right, Forward/Back, Strafe Left/Strafe Right. This wasn't an issue with the D-pad, but it is when using a keyboard.

[intacowetrust]

3 minutes ago, fenderc01 said:

Another bug that could be fixed for the PC version are that opposite directions don't cancel out when pressed at the same time. Left/Right, Forward/Back, Strafe Left/Strafe Right. This wasn't an issue with the D-pad, but it is when using a keyboard.

 

Good callout!

[Dark Pulse]

Well the proper way to test that would be, of course, to test how it is in the original game. The normal D-pad would, of course, prevent pressing both buttons at once, but it's trivial to see what it does via an emulator.

 

Some games do very strange and unusualy things when "impossible" combinations of directions are pressed all at once.

[fenderc01]

16 hours ago, Dark Pulse said:

Well the proper way to test that would be, of course, to test how it is in the original game. The normal D-pad would, of course, prevent pressing both buttons at once, but it's trivial to see what it does via an emulator.

 

Some games do very strange and unusualy things when "impossible" combinations of directions are pressed all at once.

I have confirmed the same behavior in an emulator.

Edited June 17, 2020 by fenderc01
Clarification

[Dark Pulse]

Interesting. Found out the Williams devs apparently figured out the blockmap bug, fixed it in both PSX Final Doom and Doom 64 by adding checks for Pain Elementals spawning Lost Souls over solid lines, but more importantly, 3DO Doom (of all ports!) actually instituted a more proper bugfix by adding code that was not present in the JagDoom codebase and so the entire problem is something that can simply never occur in that port (versus the presumably more hacky workaround for PSX Final Doom/Doom 64).

 

Dunno if the way it was done on PC is better than whatever way you implemented for PsyDoom, @intacowetrust - it might be, it might not be. I tried doing a quick look for the code (based on the Linux source) and it didn't seem to be found in the PsyDoom repository.

 

Figured I'd heads-up you about it though, just in case. If this actually is what you're doing, sorry; I'll do an offering of pennance and sacrifice on Tuesday.

Edited June 20, 2020 by Dark Pulse

[intacowetrust]

On 6/20/2020 at 5:05 AM, Dark Pulse said:

Interesting. Found out the Williams devs apparently figured out the blockmap bug, fixed it in both PSX Final Doom and Doom 64 by adding checks for Pain Elementals spawning Lost Souls over solid lines

 

Yeah that's a good fix to have. It would still be possible (in theory) however to get the blockmap issue if you (or something else) somehow made its way outside of the level bounds - it wouldn't address the root cause in other words. The ultimate root cause fix is to simply do what the PC version (and 3DO version) do and add bounds checking for blockmap operations.

 

Concerning the Wiki link, I found the following quote interesting in relation to 3DO Doom:

 

Quote

This missing check is restored in the 3DO version of the code, and thus the error does not occur in that version. However, objects moving outside the map still cause various other problems which can slow down and crash the game, for reasons not currently understood.

 

I recall when working on Phoenix Doom making the following division by zero fix in the renderer, which happened sometimes when I got super close to walls or was no-clipping through them: https://github.com/BodbDearg/phoenix_doom/commit/baddc11e9e587afccceca6c10f0cc7f6d594e84a

 

Might be the issue the Wiki is talking about, not sure...

 

On 6/20/2020 at 5:05 AM, Dark Pulse said:

Dunno if the way it was done on PC is better than whatever way you implemented for PsyDoom, @intacowetrust - it might be, it might not be. I tried doing a quick look for the code (based on the Linux source) and it didn't seem to be found in the PsyDoom repository.

 

I'm pretty much doing the same thing as the PC version, just checking the bounds for blockmap operations. Here's one example of where the problem was fixed for comparison:

 

https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_maputl.c#L379

https://github.com/BodbDearg/PsyDoom/blob/a33e7d6ea40464f4a069baf08c2ef52f484ef051/game/Doom/Game/p_maputl.cpp#L165