Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
intacowetrust

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

Recommended Posts

 

6 hours ago, intacowetrust said:

I believe the N64 version is rendering in a very modern way, using the z-buffer and sorting the sprites back to front - thus does not suffer from this problem. @Erick194can maybe correct me if I'm wrong though, I haven't gone through the code yet in great detail.

 

Doom 64 uses a slightly different method of sorting sprites similar to PsxDoom, as it doesn't use Z-buffer like most n64 games. But it's a bug since Vanilla Doom anyway.

 

https://doomwiki.org/wiki/Sprites_improperly_clipped

 

You can also see it in the following screenshot of the @Immorpher video, of the Doom 64 RE on real hardware. You can tell that the sprites of the dead zombies were clipped through the floor.

 

Screenshot_20201202-091801.jpg.5782c85e2043d72dda2b7317a8288a6e.jpg

 

 

 

Share this post


Link to post
7 hours ago, EtherBot said:

Wow bizarre, do you (or anyone I guess) know if this was a bug with other console ports at the time? Like the n64 version especially, 3do, etc. I never knew the PSX version had this bug, it's fairly significant, I feel like.

The Saturn port does this as well, as is expected since it is ported from the PSX version. However the Saturn port will occasionally draw sprites over level architecture (i.e. drawing a sprite that a corner should obscure, see picture below) and will sometimes even draw a sprite further in distance from the player over one that is closer.

 

Spoiler

1029584232_satdoom.2020-12-0211_02_52.png.e7968620c4e0b379eb62e76821ef7fa4.png

 

Share this post


Link to post
1 hour ago, Erick194 said:

Doom 64 uses a slightly different method of sorting sprites similar to PsxDoom, as it doesn't use Z-buffer like most n64 games. But it's a bug since Vanilla Doom anyway.

 

Oh that's interesting - thanks for confirming @Erick194! From looking very briefly at the code it seemed like it was doing setup for z-buffering but I wasn't sure given how little time I had spent going through it all. I've also read that the cost of a Z-Buffer on the N64 was prohibitive in many cases so perhaps that's why they decided to continue without it.

 

1 hour ago, Mattfrie1 said:

The Saturn port does this as well, as is expected since it is ported from the PSX version. However the Saturn port will occasionally draw sprites over level architecture (i.e. drawing a sprite that a corner should obscure, see picture below) and will sometimes even draw a sprite further in distance from the player over one that is closer.

 

Thanks for sharing, good to know also! Saturn I definitely was not sure about since Jim Bagley did have that fast hardware renderer at one point which got chucked out because of the affine texture warping. What followed that was unclear... Perhaps some day we'll have a fully reverse engineered Saturn codebase to look over as well! 

Share this post


Link to post
39 minutes ago, intacowetrust said:

Thanks for sharing, good to know also! Saturn I definitely was not sure about since Jim Bagley did have that fast hardware renderer at one point which got chucked out because of the affine texture warping. What followed that was unclear... Perhaps some day we'll have a fully reverse engineered Saturn codebase to look over as well! 

Too bad coding up a better renderer for it will be a shitshow.

 

 

Share this post


Link to post
17 hours ago, intacowetrust said:

Thanks for confirming, will grab one on ebay and see what is happening...

 

I was able to confirm that my DualShock 2 controller works via my USB to PS controller adapter.

Share this post


Link to post
10 hours ago, Dark Pulse said:

Too bad coding up a better renderer for it will be a shitshow.

The new renderer will run on PC, not Saturn!

 

By the way, @intacowetrust did you base this port on an existing codebase?

Share this post


Link to post
15 hours ago, seed said:

SaturnDoom when, tacoman 👍?

 

No plans for this I'm afraid! PsyDoom will be keeping me busy for quite some time, then after that I might have another project (not Doom related) in mind...

 

15 hours ago, Dark Pulse said:

Too bad coding up a better renderer for it will be a shitshow.

 

I'm sure someone out there might find it a fun challenge (to do on the actual hardware), just for the sake of it. We'd need the reversed source first though...

 

11 hours ago, fenderc01 said:

I was able to confirm that my DualShock 2 controller works via my USB to PS controller adapter.

 

Great to hear! I wonder what is going on with that PSC controller then? Hope to find out soon, the device is on the way. Will be interesting to play the game with the original controller again :)

 

4 hours ago, VGA said:

By the way, @intacowetrust did you base this port on an existing codebase?

 

The basis was the original machine code in the PSXDOOM.EXE file. I spent time studying the disassembly and identifying all of the functions and a lot of the global variables in the game; from this I built up a database of sorts of those things here:

https://github.com/BodbDearg/PsyDoom/blob/7fc219b60ddf5a006ee03ea1f0e91ee3d0c7956c/doom_disassemble/ProgElems_Doom.cpp

 

Once that was done I wrote a tool to take all of this information and generate C++ functions for every MIPS function identified, where each MIPS instruction would be converted to a C++ function call. I implemented all of those function calls for each type of MIPS instruction and hooked the whole lot up to the Avocado PSX emulator so I could use that as the execution environment, use the registers, stack and memory etc. In certain places I had to stick in code to manually hand over control (temporarily) to the emulator to handle things like interrupts, sound, timers and so on before resuming the 'native' assembly-like C++ code.

 

Here's an example of a file 'r_segs.cpp' in it's initial form, after just being converted from MIPS assembly by my tool:

https://github.com/BodbDearg/PsyDoom/blob/7fc219b60ddf5a006ee03ea1f0e91ee3d0c7956c/game/Doom/Renderer/r_segs.cpp

 

Here's a later version of it with some code converted to C++. R_DrawWallPiece here has a proper C++ function signature also but the body is still in assembly, and I had to marshal the function parameters to the expected MIPS registers while it was in that form. There was a lot of stuff like that and conversion thunks as I was gradually transitioning code over:

https://github.com/BodbDearg/PsyDoom/blob/e4beb43286275220188343a215052dee8dc1fbb3/game/Doom/Renderer/r_segs.cpp

 

And here's the most recent version, with everything in nice readable C++:

https://github.com/BodbDearg/PsyDoom/blob/6ae8e45f3fbeb795dde4c271f88293e8ee679709/game/Doom/Renderer/r_segs.cpp

 

Basically it all started with the original EXE and everything was gradually converted to native while trying to keep a working build at all times. Maintaining a working build allowed me to use the git history to pinpoint problems more easily when they arose. Once @Erick194's reverse engineering efforts became available I also used that as a reference to help accelerate the transition.

 

Share this post


Link to post

The PlayStation Classic controller arrived in the post @fenderc01 and I was finally able to investigate the issue with it. The problem was that the controller was not supported/recognized via SDL's 'game controller' API and thus PsyDoom was not able to use it. I added an alternate codepath to initialize the controller via the more generic 'joystick' API and was able to get it working that way.

 

As part of the fix I also renamed the generic controller inputs to 'joystick' to avoid confusion with the inputs for game controllers recognized by SDL. You can still bind any controller using the 'Joystick xxx' inputs but only certain controllers (known to SDL) can use the standardized Xbox style input names such 'Gamepad A', 'Gamepad Y' etc.

 

Here's the control bindings configuration I used to get the 'PlayStation Classic' controller working more or less the exact same way as the original:

Analog_MoveForwardBack = Gamepad LeftY
Analog_MoveLeftRight = Gamepad LeftX
Analog_Turn = Gamepad RightX

Digital_MoveForward = W, Up, Joystick Axis2-
Digital_MoveBackward = S, Down, Joystick Axis2+
Digital_StrafeLeft = A, Joystick Button7
Digital_StrafeRight = D, Joystick Button8
Digital_TurnLeft = Left, \,, Joystick Axis1-
Digital_TurnRight = Right, ., Joystick Axis1+

Action_Use = Space, Mouse Right, Joystick Button2
Action_Attack = Mouse Left, Joystick Button1, Left Ctrl, Right Ctrl, F
Action_Respawn = Mouse Left, Joystick Button1, Left Ctrl, Right Ctrl, F
Modifier_Run = Left Shift, Right Shift, Joystick Button4
Modifier_Strafe = Left Alt, Right Alt, Joystick Button3
Toggle_Autorun = CapsLock

Toggle_Pause = P, Pause, Return, Joystick Button10
Toggle_Map = Tab, M, Joystick Button9

Weapon_Scroll = Mouse Wheel
Weapon_Previous = PageDown, Q, Joystick Button5
Weapon_Next = PageUp, E, Joystick Button6
Weapon_FistChainsaw = 1
Weapon_Pistol = 2
Weapon_Shotgun = 3
Weapon_SuperShotgun = 4
Weapon_Chaingun = 5
Weapon_RocketLauncher = 6
Weapon_PlasmaRifle = 7
Weapon_BFG = 8

Menu_Up = Up, W, Joystick Axis2-
Menu_Down = Down, S, Joystick Axis2+
Menu_Left = Left, A, Joystick Axis1-
Menu_Right = Right, D, Joystick Axis1+
Menu_Ok = Return, Space, Mouse Left, F, Left Ctrl, Right Ctrl, Joystick Button3
Menu_Back = Escape, Tab, Mouse Right, Joystick Button2, Joystick Button9
Menu_Start = Joystick Button10
Menu_EnterPasswordChar = Return, Space, Mouse Left, Left Ctrl, Right Ctrl, Joystick Button3
Menu_DeletePasswordChar = Delete, Backspace, Mouse Right, Joystick Button4, Joystick Button1

Automap_ZoomIn = E, \=, Joystick Button8
Automap_ZoomOut = Q, -, Joystick Button7
Automap_MoveUp = Up, W, Joystick Axis2-
Automap_MoveDown = Down, S, Joystick Axis2+
Automap_MoveLeft = Left, A, Joystick Axis1-
Automap_MoveRight = Right, D, Joystick Axis1+
Automap_Pan = F, Left Alt, Right Alt, Joystick Button3

PSXCheatCode_Up = Up, W, Joystick Axis2-
PSXCheatCode_Down = Down, S, Joystick Axis2+
PSXCheatCode_Left = Left, Joystick Axis1-
PSXCheatCode_Right = Right, Joystick Axis1+
PSXCheatCode_Triangle = Mouse Left, Left Ctrl, Right Ctrl, Joystick Button1
PSXCheatCode_Circle = Space, Mouse Right, Joystick Button2
PSXCheatCode_Cross = F, Left Alt, Right Alt, Joystick Button3
PSXCheatCode_Square = Left Shift, Right Shift, Joystick Button4
PSXCheatCode_L1 = A, Joystick Button7
PSXCheatCode_R1 = D, Joystick Button8
PSXCheatCode_L2 = PageDown, Q, Joystick Button5
PSXCheatCode_R2 = PageUp, E, Joystick Button6

If you just want to get that particular controller working (and nothing else) then you could just replace your entire controls configuration with the above.

Share this post


Link to post
2 hours ago, fenderc01 said:

Thanks for buying a controller to fix this issue. 

 

No problem! It should hopefully expand PsyDoom's support for other types of joysticks/controllers, and it's always nice to have for emulation anyway :)

Share this post


Link to post

This is really nice. What will happen if I put a bin/cue of the GEC hack of the game? :D

Share this post


Link to post
9 hours ago, VGA said:

This is really nice. What will happen if I put a bin/cue of the GEC hack of the game? :D

 

At the minute you'll get an error saying the disc is not a recognized game since only Doom or Final Doom are supported in any of the PAL or NTSC variants. PsyDoom detects the game type from the startup executable (e.g SLUS_000.77 for NTSC-U Doom) but the GEC disc has an executable of 'SLUS_666.01' which is not on the supported list. You can however supply modded versions of Doom and Final Doom if you wanted to replace levels with new ones or things like that - that can work.

 

The GEC disc is not supported presently because the structure of the disc is very different to the original games and it's sort of partitioned off into multiple separate games with an executable for each. With beta 4 that is likely to change a lot now that the password system can support many more maps and also because the game has been fully reversed, making it easy to add new map slots. Both these changes should make it possible to house all the maps under one executable so the disc will likely look very different in future. I'm waiting on the dust to settle on all of that before adding support to PsyDoom.

 

In the meantime though, it is still possible (but kind of awkward) to play the new GEC levels by using the '-datadir' command and extracting the relevant wads and files to a folder and pointing PsyDoom to that. I've been checking out a lot of the new maps within PsyDoom using that method :)

Share this post


Link to post
6 hours ago, intacowetrust said:

 

At the minute you'll get an error saying the disc is not a recognized game since only Doom or Final Doom are supported in any of the PAL or NTSC variants. PsyDoom detects the game type from the startup executable (e.g SLUS_000.77 for NTSC-U Doom) but the GEC disc has an executable of 'SLUS_666.01' which is not on the supported list. You can however supply modded versions of Doom and Final Doom if you wanted to replace levels with new ones or things like that - that can work.

 

The GEC disc is not supported presently because the structure of the disc is very different to the original games and it's sort of partitioned off into multiple separate games with an executable for each. With beta 4 that is likely to change a lot now that the password system can support many more maps and also because the game has been fully reversed, making it easy to add new map slots. Both these changes should make it possible to house all the maps under one executable so the disc will likely look very different in future. I'm waiting on the dust to settle on all of that before adding support to PsyDoom.

 

In the meantime though, it is still possible (but kind of awkward) to play the new GEC levels by using the '-datadir' command and extracting the relevant wads and files to a folder and pointing PsyDoom to that. I've been checking out a lot of the new maps within PsyDoom using that method :)

Please die in mine, Tacoman. It warms the cockles of my cold, blackened heart.

 

Can't wait until Beta 4 though, then I can finally complete my Romero map and go back and update my older conversions with the new limits in mind. :)

Edited by Dark Pulse

Share this post


Link to post

Hey guys, looks like I managed to get more time and get through the remaining tasks for 0.6.0 quicker than expected. As a result I have an early Christmas present for you all - the 0.6.0 release! You can download it as always from here:

https://github.com/BodbDearg/PsyDoom/releases

 

The main focus of this release is the audio engine and reworking that to remove stutter and improve CD audio handling. This is achieved using a new standalone SPU implementation which is also the basis for the VST plugins shown earlier in the thread. There are also lots of other smaller quality of life improvements too, some bug fixes and a few changes to help modders. Here is the breakdown of what has changed from Github:

 

Feature changes & improvements

  • Greatly improved audio processing and less stutter.
    • Implemented a new standalone emulation of the PlayStation SPU specifically for PsyDoom, based on Avocado's SPU.
      • Eventually (in future) this can also be used to increase SRAM and voice limits, given its increased flexibility.
    • Audio is now fully multi-threaded and can be fed to the sound device on-demand.
      • The audio device doesn't have to wait for the main game thread to respond.
      • This reduces stutter and audio artifacts.
    • CD-DA music handling is much improved and CD-DA music for .cue files with multiple .bin files now works.
  • Implemented a new options menu for turn speed multiplier and auto-run.
  • Added an 'autorun' toggle button (Caps Lock by default).
    • This can also be enabled via the new 'Controls' menu.
  • Implement saving of certain user preferences to 'saved_prefs.ini' in the same folder as all other config.
    • Audio preferences, in-game configurable control settings and last map password are saved.
  • Implement certain well-known PC style cheat key sequences such as 'iddqd' etc.
    • For a full list of cheat key sequences, consult the `cheats_cfg.ini` config file. 
  • No-clip cheat now carries across levels and god/no-clip cheats carry across if using cheat warp.
  • Add a '-nomonsters' command line argument similar to PC Doom
  • Implement support for generic joystick controllers not recognized/supported by SDL.
  • Add more descriptive errors on failure to connect for a network game.
    • If clients or games are mismatched, say so.
  • Improved the precision of the game's music sequencer slightly.
  • Added the ability to configure the audio buffer size, if required, to trade latency for audio stability.
    • The default settings should be good for most systems, however.
  • Allow view bobbing strength to be reduced if required.
  • P_SpawnMapThing: skip things with DoomEd num '0' - not valid things!
    • But warn about bad things on level start.
    • A change to make the engine more resilient/friendly for modders.
  • Allow animated flats and textures to be referred to by animation frames other than the 1st frame in the sequence.
    • This would previously cause crashes, as the engine always expected animated resources to be referred to by the 1st frame in the sequence.
    • If a mapper uses a SLIME02 flat for instance, it now behaves just as if the mapper had used SLIME01.
    • A change to make the engine more resilient/friendly for modders.
  • LCD sound loader: issue a warning if out of sound RAM.
  • P_LoadBlocks: print more info in the case of an unexpected decompressed file size.
    • May be useful for modders to diagnose issues with loading certain map files.
  • Add support for the unused hanging lamp sprite used in the GEC Master Edition (DoomEdNum 90).
  • Implemented (separate) command-line audio tools for manipulating the game's music and sound formats.

Bug fixes

  • Fix gravity being too strong due to the game running at a consistent 30 FPS frame-rate.
    • This is a bug inherited from the original game.
    • This makes the key jump in 'The Mansion' for example now possible, along with other jumps.
  • Fix view bobbing not being as strong as it should be, due to a consistent 30 FPS frame-rate.
    • This is a bug inherited from the original game.
  • Fix an annoying temporary stutter which would sometimes happen on starting a new game.
  • Fix the 'Invalid password' flash overlapping the password.
    • Make the behavior the same as Final Doom - only one or the other shows during the flash.
  • Fixed certain instances of undefined behavior in the code which might affect portability to different CPU architectures.
    • Fixed instances of misaligned data-structures.
    • Fixed reliance on undefined behavior of left/right shift for negative numbers.
  • Fixed a few instances of the renderer overstepping array bounds (potentially a crash issue).

 

After this release my focus next turns to the renderer and improving that beyond it's original limitations. I'll likely be quite a while at that work since it's a big task, so if you see activity going quiet then most likely it's just because I'm busy with that :)

 

Enjoy!

Share this post


Link to post

One more small update (0.6.1) before the year is out, with a bug fix for controls and some improvements/fixes to sound handling:

 

https://github.com/BodbDearg/PsyDoom/releases

 

Feature changes & improvements

  • Audio system: raise the maximum active sequence and track limit to at least 128 (was previously 24) to help prevent issues with sounds not playing.
    • Allows more hardware SPU voices to be used.
    • Note: this change doesn't raise the PSX hardware voice limit, but often tracks and sequences are 'active' without using any voices.
      • Thus more voices can be used if the track/sequence limit is raised.

Bug fixes

  • Fixed the 'Inv Mouse Wheel' control input not working.
  • Fix audio track & sequence slots sometimes being 'leaked' on level end, resulting in some sounds not playing.

Share this post


Link to post

I have doubts about mouselook making its way into PsyDoom without a whole new renderering backend — unless you can live with Duke Nukem 3D's horizon-shifting style of freelook. Higher resolutions though, I'm pretty sure that's been on the wishlist for a while!

Share this post


Link to post
9 hours ago, Lollie said:

I have doubts about mouselook making its way into PsyDoom without a whole new renderering backend — unless you can live with Duke Nukem 3D's horizon-shifting style of freelook. Higher resolutions though, I'm pretty sure that's been on the wishlist for a while!

Isn't PS1 Doom 3d though?

Share this post


Link to post
14 hours ago, marver0PS said:

Isn't PS1 Doom 3d though?

I did hear somewhere that the engine in PS1 Doom is actually polygon-based; it just doesn't feature 3D areas in the level geometry because they were never present in the original maps.

Share this post


Link to post
On 12/18/2020 at 11:02 PM, Marty2Doom said:

Any Chance for "Free Look Mouse" and "Resolution Upscale" ? :)

 

Aside from it looking bad in some situations (with sprites), I won't be doing looking up/down because the original PSX renderer (which PsyDoom will keep for authenticity) relies on the same restrictions as the PC renderer in order to do texturing right and not suffer from the affine texture warping found on many PSX games. It doesn't get texture warping because every floor row and wall column rendered is at a constant depth to the camera, and that is because you cannot look up or down. Fabien Sanglard's excellent article goes into a lot more detail about this and how PSX Doom is rendered:

https://fabiensanglard.net/doom_psx/index.html

 

As far as upscaling goes I won't be doing any of that either since the original renderer has some nasty limitations/glitches, some of which I documented in detail here. I do intend to look at a new Vulkan based renderer however which will allow for high resolution, widescreen support etc. as well as fixing some of the limitations of the original renderer. So if that is what you mean by upscaling, yes - I'm aiming to support that.

 

On 12/19/2020 at 6:47 PM, Lollie said:

unless you can live with Duke Nukem 3D's horizon-shifting style of freelook

 

Yeah I'm not a fan of that effect, feels somewhat pointless to me and doesn't add much value - an attempt to compete with Quake's technology at the time perhaps?

 

16 hours ago, marver0PS said:

Isn't PS1 Doom 3d though?

 

3D is a somewhat ambiguous term and means different things to different people. You'd have to clarify more I'm afraid for such a question to be answered. Some people don't consider games like Doom or Wolfenstein to be '3D' for example... If you want go down that particular rabbit hole, check out this thread: https://www.doomworld.com/forum/topic/92722-game-theorists-doom-wasnt-3d-video-and-my-refutation/

 

1 hour ago, Koff3Katt said:

I did hear somewhere that the engine in PS1 Doom is actually polygon-based; it just doesn't feature 3D areas in the level geometry because they were never present in the original maps.

 

You are technically correct, but perhaps not in the way you might think. PSX Doom actually renders in a manner conceptually similar to the PC version, breaking up walls into individual pixel wide columns and floors into pixel high horizontal spans. Those are submitted to the PlayStation's GPU as extremely thin pixel wide or high polygons. So technically polygons are being used (so the renderer is hardware accelerated) but not in the traditional way that most games use them. It's not breaking up the quadrilateral for a door into two triangles for example, it just renders all of the individual pixel columns in the door/wall in a similar way to the PC version. Again Fabien Sanglard's PSX Doom article goes into more detail about this if you're interested.

Share this post


Link to post
9 hours ago, intacowetrust said:

Aside from it looking bad in some situations (with sprites), I won't be doing looking up/down because the original PSX renderer (which PsyDoom will keep for authenticity) relies on the same restrictions as the PC renderer in order to do texturing right and not suffer from the affine texture warping found on many PSX games. It doesn't get texture warping because every floor row and wall column rendered is at a constant depth to the camera, and that is because you cannot look up or down.

What could be possible, however, would be to implement the same cheat that Heretic, Hexen, and Strife used: Y-shearing to look up or down in place of changing the view pitch.

 

It might be what was referred to as "Duke Nukem 3D's horizon-shifting style of freelook" I realize; but my problem with horizon and Duke 3D is that when looking up and down, the sky moves with your viewpoint, and that's really terrible.

Share this post


Link to post

Ye, Y-shearing is what I was referring to. It's not as widely known as a term, so I opted for the descriptive example instead. (Also yes, Duke's sticky skies are kind of goofy. Although, Doom ports tend to fix this by stretching the sky vertically instead, and that's also inelegant at best.)

 

On 12/21/2020 at 2:50 PM, intacowetrust said:

Yeah I'm not a fan of that effect, feels somewhat pointless to me and doesn't add much value - an attempt to compete with Quake's technology at the time perhaps?

I kinda felt it was a mix of 3D Realms trying to push for that "Wow Cool Expansive 3D World!!" angle, but also: the feature being made necessary by Duke3D's more vertical design and flying enemies. Being shot at by a jetpack alien or a flying pig-cop and being unable to see where it's coming from is super annoying.

 

In Doom however, it doesn't feel quite as important. Levels are generally designed to keep enemies in your view at most times (exceptions going to monsters in pits or lower floors), and even when they are out of view, Doom's vertical autoaim tends to hit the majority of enemies regardless of their vertical position.

Share this post


Link to post

I don't give up hope. Will surely come in time. You just haven't figured out how to implement it technically, even if there is already extensive technical knowledge. Sounds naive but there is always a way. In the past it has also been said that we never have an exact SNES emulation or that we will never see high-resolution SNES rotated chip emulation despite extensive documentation or a native Blood 1 port. :)

Share this post


Link to post

There is nothing to be gained from using vertical aiming in DOOM. I honestly can't think of a more pointless, and unneeded implementation.


That's more a discussion for GZDoom, and its mods that can make use of such a feature.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×