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

PsyDoom Multiplayer Tutorial Doom, Final Doom, Doom Forever, Руководство инструкция

17 hours ago, Ruritanian said:

PsyDoom Multiplayer Tutorial Doom, Final Doom, Doom Forever, Руководство инструкция

 

Thanks for sharing this!

7 hours ago, intacowetrust said:

Hey everyone, the time has come again for another release of PsyDoom! (0.7.0)

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

 

This release brings some big new features with the arrival of the Vulkan renderer. PsyDoom can now finally be run at high resolutions and enjoy widescreen support like modern Doom source ports, all while maintaining lighting and shading that is as faithful as possible to the original game. There are a few other improvements also, like the beginning of limit removal in the classic renderer (support for tall rooms!) as well as a few other smaller feature changes and bug fixes.

 

Here is a video of the new release in action:

 

And here are the main changes and fixes for this release:

 

Feature changes & improvements (0.7.0)

• Added an entirely new Vulkan (1.1) based renderer for the game. Its features include:
  • Support for modern resolutions like 1080p, 1440p etc.
  • Widescreen rendering beyond the original aspect ratio.
  • The ability to instantly toggle between the 'Classic' and Vulkan renderers if desired.
  • Emulates the 16-bit lighting & shading of the original game very closely to help preserve the atmosphere.
    • 32-bit shading can also be enabled if desired but is not recommended.
    • Note: some older MacOS hardware may be less accurate with transparency/blending due to the lack of 16-bit framebuffer support.
  • Improved depth sorting for sprites versus the original game.
    • A lot of cases where sprites are 'cut off' by floors and walls have now been fixed.
    • PsyDoom's Vulkan renderer implements a method of splitting up sprites across subsector boundaries proposed by John Carmack, in the 1997 Doom Source release notes.
  • Triangle edge multisample antialiasing (MSAA).
  • Shader MSAA where the hardware supports it, to help remove 'shimmer' and temporal distortions.
  • The ability to render at low resolutions like 240p for an original feel but with some of the old renderer limitations/bugs fixed.
    • Disable MSAA, set 'VulkanRenderHeight' to '240' and 'VulkanPixelStretch' to '1' for an experience close to the PSX renderer.
  • Triple buffering with out-of-date frame discard for lower input latency.
• PsyDoom no longer depends on the Avocado PlayStation emulator.
  • PsyDoom now has its own internal PSX 'GPU' implementation with extended capabilities like 16-bit texture coordinates and new drawing primitives more optimal to Doom.
  • This move also fixes some glitches with pixels flickering and a few other small things.
• MacOS: added native support for the 'arm64' architecture used by M1 Macs.
  •  Note: this is untested/experimental as I do not have access to this hardware currently!
• Added graphics settings to emulate CRT overscan and removed a lot of dead space below the in-game status bar by default.
  • These settings can be tweaked to crop as much of the image as desired.
• Added a 'notarget' cheat that causes monsters to not see the player.
  • By default it can be activated by typing 'idcloak'.
• Upgraded the classic renderer to support room heights greater than 256 units without texture stretching.
  • This fixes texture stretching in a few places in the original maps.
  • This fix is always active; it can only be disabled by compiling a custom version of PsyDoom with 'limit removing' features removed.
  • Note: the Vulkan render has this fix always included too.
• Added a setting to control the output resolution (or window size in windowed mode).
• Provided a new menu option to switch renderers and renamed 'Controls' to 'Extra Options'.
• Added framerate uncapped movement to the automap.
  • Scrolling and moving in the automap should now be smoother.
• Added a new 'fast loading' option useful for speedrunning.
  • This setting skips waiting for sounds to finish and crossfades during loading. It makes loading almost instant on modern hardware.
• Add a '-pistolstart' command line switch that forces pistol starts on all levels.
  • This is similar to the switch found in Chocolate Doom.
• Tweaked/refined some control binding defaults to try and make them more optimal out of the box.
• Implemented an (opt-in) gameplay tweak that reduces the initial firing delay for the Super Shotgun.
  • Makes it feel more like the PC SSG and shifts some of the delay to later in the animation sequence so that damage per second is not affected.
  • This tweak will make it easier to use rapidly, however.
• Added an optional level timer that can be used to measure the time taken to complete a level.
  • This may be useful for speed running.

Bug fixes (0.7.0)

• Fixed rendering bugs where sometimes the ceiling and some walls would 'leak' through the sky from adjacent rooms.
  • The bug would occur where rooms adjacent to a sky had higher ceilings.
  • Not much of an issue with the retail game (avoided largely by design) but can be a limitation for custom maps.
  • The fix is always active for the Vulkan renderer and enabled by default (toggleable) for the Classic renderer.
    • Note: in some situations with the Classic renderer the fix may run into precision problems. It works best with Vulkan.
• Fixed a texture cache overflow error on demos ending.
• Fixed a bug with the view snapping back when pausing while turning.
• Fixed a PsyDoom specific bug in the music system that would cause note pitch to be slightly off sometimes during pitch bend.
• Fixed an original bug in the sequencer system that could cause infinite freezes on level transitions.
• Fixed the 'pause' action sometimes not registering in the finale screens.
• Fixed key up/down events being artificially repeated by the OS if keyboard keys are held down.
• Added a fix to prevent Lost Souls from being occasionally spawned outside of level bounds.
• Fixed an original game bug where sometimes items can't be picked up when overlapping other items that are not possible to pickup.
• Fixed a lack of difference in view bobbing strength between walking and running.
  • View bobbing when walking now should be slightly less intense.
• Fixed broken/stuttering motion when playing back PAL demos with uncapped framerates.

Am getting a black screen.

I tried the latest but it doesn't seem to boot into Vulkan at all? The hotkey to switch doesn't work even though my GPU supports Vulkan 1.2 and I've got the other dependencies installed, thought it might be the reshade Vulkan toggle but that didn't do anything regardless of it being on or off.

8 hours ago, intacowetrust said:

• PsyDoom no longer depends on the Avocado PlayStation emulator.
  • PsyDoom now has its own internal PSX 'GPU' implementation with extended capabilities like 16-bit texture coordinates and new drawing primitives more optimal to Doom.
  • This move also fixes some glitches with pixels flickering and a few other small things.

Now i love to hear more about this! Last we spoke, you mentioned that for the GPU rendering it still relies on Avocado emulation. What does the internal PSX GPU implementation consist of? A translation layer of native PSX calls to the GPU, or a native rendering framework?

Because if i read this correctly, every rendering related trace is now done natively versus being emulated.

This release is huge. PsyDoom has been an amazing journey so far.

3 hours ago, Ruritanian said:

Am getting a black screen.

Sorry to hear that and thanks for sharing your GPU info! A quick question on this: if you press the ` key to toggle renderers do you still see the black screen?

A couple of changes you could also try in graphics_cfg.ini (maybe these might help, let me know if any work):

• Disable MSAA by setting 'AntiAliasingMultisamples' to '1'.
• Disable triple buffering by setting 'VulkanTripleBuffer' to '0'.
• Force a 32-bit framebuffer (more compatible) by setting 'UseVulkan32BitShading' to '1'.
• Force windowed mode by setting 'Fullscreen' to '0'.

Failing all that, if you are still experiencing trouble then the Vulkan renderer can be completely disabled by setting 'DisableVulkanRenderer' to '1'. This should make PsyDoom output like it did in prior releases.

I'm wondering if the issue has something to do with the device being an APU... The memory architecture on such devices can be very different to regular GPUs so perhaps something is being done wrong there. I might look into this tool to see if it can sniff out anything because I only have NV discrete GPUs and to test with unfortunately, apart from an AMD chip in my MacBook Pro: https://vulkan.lunarg.com/doc/view/1.2.131.1/windows/device_simulation_layer.html

40 minutes ago, Tarry said:

I tried the latest but it doesn't seem to boot into Vulkan at all? The hotkey to switch doesn't work even though my GPU supports Vulkan 1.2 and I've got the other dependencies installed, thought it might be the reshade Vulkan toggle but that didn't do anything regardless of it being on or off.

Thanks for reporting! It sounds like PsyDoom is thinking that your device is not capable and making the Vulkan renderer unavailable for some reason. What GPU do you have? I can check its capabilities to see if it should be available.

50 minutes ago, Redneckerz said:

Now i love to hear more about this! Last we spoke, you mentioned that for the GPU rendering it still relies on Avocado emulation. What does the internal PSX GPU implementation consist of?

It's a pretty straightforward software rasterizer that mimics some of the state and drawing capabilities of the original PSX GPU. It's consists of only a single .h and .cpp file and is very minimal:

https://github.com/BodbDearg/PsyDoom/blob/master/simple_gpu/Gpu.h

https://github.com/BodbDearg/PsyDoom/blob/master/simple_gpu/Gpu.cpp

It does rectangles (for sprites), lines and textured triangles like the original GPU. Some PSX features that were not needed for Doom like gouraud shading were removed and a few simplifications made in other areas.

The capabilities of the GPU are also extended in that it can support a bigger VRAM block. It supports 16 bit texture coordinates instead of 8 bit (useful for fixing the room height limitation) and also has newly added 'row' and 'column' drawing primitives to help speed up rendering for Doom; these are faster to rasterize in software than thin triangles.

50 minutes ago, Redneckerz said:

A translation layer of native PSX calls to the GPU, or a native rendering framework?

The original LIBGPU (PS1 SDK) drawing primitives are still used in the old rendering code, like previous versions of PsyDoom. The only exception to this is where I've made changes to use the new row & column draw primitives mentioned above.

In the current version of PsyDoom and prior versions the drawing commands went through an interface (I_AddPrim) which took care of dispatching these instructions to the 'hardware'. Previously they were queued in a buffer and written to the GPU's registers to dispatch the commands. Now however they go directly to a translation layer (no buffering) and are sent immediately to the GPU module:

https://github.com/BodbDearg/PsyDoom/blob/master/game/PcPsx/LIBGPU_CmdDispatch.cpp

Essentially this means you can now step directly in a debugger from where a draw command is being issued and follow the rasterization step by step, there's no emulation or other intermediate layers in the way.

50 minutes ago, Redneckerz said:

Because if i read this correctly, every rendering related trace is now done natively versus being emulated.

 

This release is huge. PsyDoom has been an amazing journey so far.

Thank you! That is correct, rendering is completely native now and PsyDoom no longer relies on the Avocado emulator.

45 minutes ago, intacowetrust said:

Thanks for reporting! It sounds like PsyDoom is thinking that your device is not capable and making the Vulkan renderer unavailable for some reason. What GPU do you have? I can check its capabilities to see if it should be available.

It's an RX560 running the latest drivers

46 minutes ago, Tarry said:

It's an RX560 running the latest drivers

Thanks for sharing! It does seem like that device should be capable, I might have to try the device simulator for that one too to see if it shows up anything. And just for my own reference I'm recording the closest match found for @Ruritanian's GPU in the Vulkan hardware database (device id 130D instead of 130A): https://vulkan.gpuinfo.org/displayreport.php?id=3089#properties

Reporting that I am having a similar issue.  Card is an AMD RX 5700 XT.  Vulkan version is 1.2 and latest drivers as well.

I'm afraid only DisableVulkanRenderer = 1 worked for getting it running.

3 hours ago, Eric Claus said:

Reporting that I am having a similar issue.  Card is an AMD RX 5700 XT.  Vulkan version is 1.2 and latest drivers as well.

Thanks for the report! Definitely starting to see a trend of only AMD hardware being affected. I tested the game on my integrated Intel Graphics (HD 630) as well and there were no issues - everything worked just fine.

2 hours ago, Ruritanian said:

I'm afraid only DisableVulkanRenderer = 1 worked for getting it running.

That's a shame... I think I've found a possible cause in the case of your card; it looks as though some the vertex buffer formats I'm using are not supported on that particular GPU. This might explain the black screen issue - it's creating a display and framebuffer OK but no triangles are actually getting rendered. I think I should be able to workaround and fix this particular issue and use a more compatible data arrangement.

The other AMD devices are still a bit of a mystery to me. The device simulation layer didn't turn up any problems in the case of the RX560 and AMD RX 5700 XT. I'm beginning to wonder if some of the format compatibility checks prior to enabling Vulkan are overly strict and checking for feature flags that aren't necessarily needed. Looking into loosening those up a bit and further refining the checks, perhaps that might solve the issues on these devices.

3 minutes ago, intacowetrust said:

 

Thanks for the report! Definitely starting to see a trend of only AMD hardware being affected. I tested the game on my integrated Intel Graphics (HD 630) as well and there were no issues - everything worked just fine.

 

 

That's a shame... I think I've found a possible cause in the case of your card; it looks as though some the vertex buffer formats I'm using are not supported on that particular GPU. This might explain the black screen issue - it's creating a display and framebuffer OK but no triangles are actually getting rendered. I think I should be able to workaround and fix this particular issue and use a more compatible data arrangement.

 

The other AMD devices are still a bit of a mystery to me. The device simulation layer didn't turn up any problems in the case of the RX560 and AMD RX 5700 XT. I'm beginning to wonder if some of the format compatibility checks prior to enabling Vulkan are overly strict and checking for feature flags that aren't necessarily needed. Looking into loosening those up a bit and further refining the checks, perhaps that might solve the issues on these devices.

Thanks for the response, yeah it does seem odd some AMD cards are unable to toggle on the renderer, doesn't let me do it in the menu either.  I am happy to continue testing updates I have been anticipating these features for awhile and want to help you get them working smoothly!  Thanks for your hard work.

6 hours ago, intacowetrust said:

That's a shame... I think I've found a possible cause in the case of your card; it looks as though some the vertex buffer formats I'm using are not supported on that particular GPU. This might explain the black screen issue - it's creating a display and framebuffer OK but no triangles are actually getting rendered. I think I should be able to workaround and fix this particular issue and use a more compatible data arrangement.

Thanks!!!!!

Hey everyone, I've just put up a 0.7.1 build which I'm hoping might address some of the issues found so far with AMD cards. Since I can't test on real AMD hardware, the changes are purely speculative/guesswork on my part:

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

Here are the release notes for this update:

Feature changes & improvements (0.7.1)

• Issue a descriptive error if a .cue file path is not set.
• MacOS: don't provide a default location for 'Doom.cue' - the path to it must be set explicitly by the user now. Due to OS security restrictions relative paths likely won't work anymore on MacOS.

Bug fixes (0.7.1)

• Speculative fix for the Vulkan renderer not being available on some AMD GPUs.
• Speculative fix for a black screen issue on some AMD GPUs.
• Fix wrong blend modes being used by the Vulkan renderer in some rare circumstances (mostly for newly created user maps).

Fingers crossed this does the trick!

Quote

 

PsyDoom no longer depends on the Avocado PlayStation emulator.

PsyDoom now has its own internal PSX 'GPU' implementation with extended capabilities like 16-bit texture coordinates and new drawing primitives more optimal to Doom.

This move also fixes some glitches with pixels flickering and a few other small things.

 

Wow, that was a nice change! I got to test this port more :D

7 hours ago, intacowetrust said:

Fingers crossed this does the trick!

Tried this one out, sadly it did not fix the issue and it still only boots into the software renderer :(

I can confirm that the Vulkan renderer works on my computers with Nvidia and Intel graphics, but not AMD. 

8 hours ago, intacowetrust said:

Hey everyone, I've just put up a 0.7.1 build which I'm hoping might address some of the issues found so far with AMD cards. Since I can't test on real AMD hardware, the changes are purely speculative/guesswork on my part:

 

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

 

Here are the release notes for this update:

 

Feature changes & improvements (0.7.1)

• Issue a descriptive error if a .cue file path is not set.
• MacOS: don't provide a default location for 'Doom.cue' - the path to it must be set explicitly by the user now. Due to OS security restrictions relative paths likely won't work anymore on MacOS.

Bug fixes (0.7.1)

• Speculative fix for the Vulkan renderer not being available on some AMD GPUs.
• Speculative fix for a black screen issue on some AMD GPUs.
• Fix wrong blend modes being used by the Vulkan renderer in some rare circumstances (mostly for newly created user maps).

 

Fingers crossed this does the trick!

Sorry, still black screen.

AMD just always has to be different on the GPU side of things...

Someone donate a cheap and Vulkan-capable AMD GPU to Tacoman.

Same issue with the AMD stuff others have reported.

Thanks for checking out the build everyone, saddened to hear that it didn't work - had high hopes that it would fix the issue!

I think I might need to look into getting my hands on some cheap Vulkan capable AMD hardware to investigate this more; spotted some GPUs on ebay for less than $50 which could do the job. Might be good to have a low end AMD card anyway for just general development/testing; this way I can check out NV, AMD and Intel all from the same machine :O

Very curious what the problem could be given that it works on NVIDIA, Intel and on MacOS (via Metal/MoltenVK). The problem doesn't seem to be triggering any debug validation layer issues, or any other compatibility layer checks whatever it is. Very strange indeed...

59 minutes ago, intacowetrust said:

Thanks for checking out the build everyone, saddened to hear that it didn't work - had high hopes that it would fix the issue!

 

I think I might need to look into getting my hands on some cheap Vulkan capable AMD hardware to investigate this more; spotted some GPUs on ebay for less than $50 which could do the job. Might be good to have a low end AMD card anyway for just general development/testing; this way I can check out NV, AMD and Intel all from the same machine :O

 

Very curious what the problem could be given that it works on NVIDIA, Intel and on MacOS (via Metal/MoltenVK). The problem doesn't seem to be triggering any debug validation layer issues, or any other compatibility layer checks whatever it is. Very strange indeed...

If you want some cash to help pay for testing hardware I am willing to donate a few bucks.

I built it on my AMD machine, and got this Assert failure raised from here when I tried running it:

The minimum alignment reported from getMinAlignment() on my machine is 4096, but the desired alignment is 65536. Confusing, since that comes out of the vkGetImageMemoryRequirements call.

ed: looking at the code further, the 4096 is a constant on your end. I'm guessing AMD's alignment traits are too much for that. also weird. From further experimentation, they can vary wildly. 65536 is only what the dummy texture created at the start gets, I'm also getting 131072 and the like after bumping up the constant. (yet another edit: I think the alignment traits are to put it on a boundary that's the size of the required image data, rounded to the next power of 2 if it doesn't exactly fall on one, so it can get arbitrarily large... Definitely not a good idea to rely on a fixed alignment here...)

ed2: the results of bumping that constant up to 131072 are certainly exciting and interesting:

But it's fine when the menu is fading in and out? Still confusing. Switching to the classic renderer works fine.

Sorry for the double post, but I'll stick this in a different post because it's a different bug: the idcloak cheat doesn't appear to work properly for AMBUSH monsters, they'll still see you if they hear you shoot.

5 hours ago, Eric Claus said:

If you want some cash to help pay for testing hardware I am willing to donate a few bucks.

Thank you, that's very generous of you to offer! It's no trouble at all though, I'll just pick up something cheap and/or used. Should be useful for other projects in the future also so considering it an investment :)

6 hours ago, SaladBadger said:

built it on my AMD machine, and got this Assert failure raised from here when I tried running it:

The minimum alignment reported from getMinAlignment() on my machine is 4096, but the desired alignment is 65536. Confusing, since that comes out of the vkGetImageMemoryRequirements call.

AHA! Thank you for building the game and testing it out on your device - this is absolutely invaluable info!

Now it suddenly makes sense why the PSX VRAM texture was failing to allocate on the Radeon HD 8790M, which is the reason why I stuck in that workaround to allocate the 'dummy' texture and test that it works before committing to using Vulkan.

This memory management code I wrote maybe 2 years or so ago (for an unrelated side project) and at the time I thought the minimum guaranteed alignment should have been more than enough for any conceivable scenario - it was 16 KiB then rather than 4 KiB now, long story... It appears now in hindsight AMD drivers have very strict requirements for alignment and some adjustments need to be made because of that. The funny thing is that the memory manager probably would have guaranteed the alignment which it wants anyway (just by how it works) but the code is being overly pessimistic and bailing out because it is checking against the minimum guaranteed alignment of the manager, not what the actual alignment would be after allocation.

I think this code might need a rethink and alignment needs to be taken into consideration by the allocator, rounding up the allocation size if necessary to satisfy the alignment requirements. It should be possible to guarantee what the AMD driver wants in almost any scenario because the memory manager works in a way which is very amenable to large alignments; it's basically just taking a large chunk of memory (like 64 MiB, 256 MiB etc.) and further subdividing it by 4 a number of times to create a quad tree like structure.

6 hours ago, SaladBadger said:

ed: looking at the code further, the 4096 is a constant on your end.

Yeah that's the smallest memory unit handled by the memory manager, all allocated memory block sizes are a multiple of this - hence it defines the minimum alignment that the manager can guarantee in all scenarios.

6 hours ago, SaladBadger said:

ed2: the results of bumping that constant up to 131072 are certainly exciting and interesting:

That's pretty crazy looking! I am concerned however... The framebuffers should be allocated as an 'unpooled' allocation directly from the Vulkan API and not go through the sub allocation (inside of an already allocated 64 MiB chunk) that the memory manager normally does for all other requests. I did that because framebuffers typically don't fit nicely into the quad tree structure mentioned above without a lot of waste, and also to support framebuffers larger than 64 MiB for 4K+ rendering etc... Because of this however it seems as though alignment requirements should already be satisfied, which suggests there might be something else going on here - maybe a synchronization issue of some sort.

6 hours ago, SaladBadger said:

But it's fine when the menu is fading in and out? Still confusing. Switching to the classic renderer works fine.

Very strange but if it's a synchronization issue then perhaps that could explain it... The crossfades aren't doing much so maybe the timing works out differently in that case.

3 hours ago, SaladBadger said:

Sorry for the double post, but I'll stick this in a different post because it's a different bug: the idcloak cheat doesn't appear to work properly for AMBUSH monsters, they'll still see you if they hear you shoot.

Thanks for reporting! Yeah that's okay/intended - the cheat just affects monster's sight/visibility checking and nothing else. If you make a noise it will still alert them but they will never fire on you as they can't see you. I mainly added the cheat so I could travel through levels and see them with monsters without being bothered by them; it was useful for testing the new renderer.

Ok just ordered an R5 340X on the cheap, hopefully should be on its way to me in the next week or so. In the meantime I can look into the memory management stuff and try to simulate that issue. I suspect fixing that though might not entirely resolve the problems based on the screenshot above...

Oh my god, as a die hard fan of the PS1 version, PsyDoom has to be the most amazing thing i've ever seen! Great work! Can't wait to test this on my AMD build.

1 hour ago, Muusi said:

Oh my god, as a die hard fan of the PS1 version, PsyDoom has to be the most amazing thing i've ever seen! Great work! Can't wait to test this on my AMD build.

Same here. It really is fucking awesome, isn't it.  60FPS for the Williams Entertainment versions is just fantastic.