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

[Impboy4]

3 hours ago, intacowetrust said:

Hey everyone, these are fun to look at so I thought I'd share. Just a small sneak peek at the upcoming Vulkan renderer, with a before and after comparison comparing against the original renderer:

Sadly, this laptop I'm using doesn't support Vulkan. :(

[Rymante]

10 hours ago, intacowetrust said:

Hey everyone, these are fun to look at so I thought I'd share. Just a small sneak peek at the upcoming Vulkan renderer, with a before and after comparison comparing against the original renderer

 

Oooo!  I'm liking those crisp, high resolution Vulkan shots!  Looking forward to it  ^_^

[Gez]

6 hours ago, Impboy4 said:

Sadly, this laptop I'm using doesn't support Vulkan. :(

I'm in the same boat.

[seed]

This is epic, Vulkan is already coming, wow.

 

*hype intensifies*

[intacowetrust]

15 hours ago, Impboy4 said:

Sadly, this laptop I'm using doesn't support Vulkan. :(

 

8 hours ago, Gez said:

I'm in the same boat.

 

Not to worry! The classic PSX renderer will still be available for systems that don't support Vulkan - same as previous releases. If you're a Linux user then software Vulkan (via MESA) could eventually be an option as well once PsyDoom is ported to that platform. This would probably be very slow but it might still be fast enough to do Crispy Doom levels of resolution, which would still be an improvement.

[lafoxxx]

Decided to finally check out the port -- here are some differences from the PS1 version (and from my expectations) I found in latest version 0.6.1 (sorry if it's already known -- just decided to post it here anyway):

 

• Some people I have shown the game to experience Texture Cache Overflow crash after the credits roll in Final Doom (I don't).
  UPD: Just encountered this error. Guess you should launch the game, play a little bit (warp to a few levels), then go to main menu, let the demo start, then stop it and let it launch again. The error will show after the first demo is played.
• Sequenced music sounds a bit off-pitch sometimes in Final DOOM (level 1: attack) -- not sure about DOOM.
• Floor gap fix doesn't work 100% (level 3: canyon, second floor of the starting room):
  
• Sound is distorted when there are multiple sound sources playing same sound with reverb (like the lowering columns in the room with hell knight and red skull key on level 2: virgil):
  
• Uncapped FPS option doesn't affect platforms, doors and weapon bobbing -- they still seem to work in 15 FPS mode.
• Player position has PS1 precision even in uncapped FPS mode -- resulting in 'jerky' movement when you release directional keys sometimes.

• Weapon bobbing works like if you're playing regular PC version -- not affected by player speed. It should be subtle when you're walking and "normal" when you're running. You can check in ZDoom using 'movebob 0.125' command -- then try moving with different speed and look at the weapon sprite. Checked in the emulator using SLUS-00331 (NTSC) disc. UsePalTimings also doesn't seem to affect this (but I think it should because in PAL version weapon bobbing also wasn't affected by player speed).

• Some cheats (like invulnerability and noclip) keep working after you warp to other level via cheat -- though I'm not sure if it's a 'psydoom bug' or a 'ps1 feature'

• Weapon scroll is bound to 'Mousewheel" by default, but "next weapon" is selected when you scroll mouse wheel up -- not down. I know it's fixed by use of 'invmousewheel', just can't seem to remember any game with similar configuration -- in games like DOOM3 of HL2 next weapon was selected when you scrolled mouse wheel down.
• I think it'd be great to enter password using keyboard keys.

 

Otherwise it feels just right.

I was also wondering if it'll be possible to compile the exe in x86 (32-bit) someday. 

 

Also I've decided to create an icon in .ICO format -- feel free to use it if you like it. It's same design as seen in the 4th page of this thread. 

 

psydoom.ico.zip

Edited January 24, 2021 by lafoxxx

[Ruritanian]

 

I love the fact PsyDoom now has speedrunners.

[intacowetrust]

On 1/23/2021 at 12:28 PM, lafoxxx said:

Some people I have shown the game to experience Texture Cache Overflow crash after the credits roll in Final Doom (I don't).
UPD: Just encountered this error. Guess you should launch the game, play a little bit (warp to a few levels), then go to main menu, let the demo start, then stop it and let it launch again. The error will show after the first demo is played.

 

Thanks for reporting this issue will check it out!

 

On 1/23/2021 at 12:28 PM, lafoxxx said:

• Sequenced music sounds a bit off-pitch sometimes in Final DOOM (level 1: attack) -- not sure about DOOM.

 

Hmmm... not sure I noticed this. Are you comparing the music to Aubrey's versions on bandcamp? I noticed there is a slight quirk in the Williams music sequencer system (also present in the PSX original) whereby if you pitch shift downwards then it will add an additional semitone of downwards shift. Aubrey's tracks might not have this additional pitch shift if he rendered them outside of the engine (most likely considering they are HQ), so perhaps this might be how you are perceiving the difference?

 

On 1/23/2021 at 12:28 PM, lafoxxx said:

 Floor gap fix doesn't work 100% (level 3: canyon, second floor of the starting room):

 

Yeah there are certain types of issues the fix won't address and which might be very complex to fix without an entirely new renderer. The fix mainly stretches out horizontal floor spans so there's no gaps between them and the walls at the side. The Vulkan renderer won't have any of these strange artifacts, except for maybe one or two tiny slivers or cracks in the floor that I've noticed in some maps - probably due to errors in the map building process. Possible this instance could be one of those too.

 

On 1/23/2021 at 12:28 PM, lafoxxx said:

• Player position has PS1 precision even in uncapped FPS mode -- resulting in 'jerky' movement when you release directional keys sometimes.

 

This might be a bug that I noticed where the uncapped turning sometimes snaps backwards when pausing. Need to look into that issue... Where you pausing by any chance when this happened?

 

On 1/23/2021 at 12:28 PM, lafoxxx said:

 Weapon bobbing works like if you're playing regular PC version -- not affected by player speed. It should be subtle when you're walking and "normal" when you're running. You can check in ZDoom using 'movebob 0.125' command -- then try moving with different speed and look at the weapon sprite. Checked in the emulator using SLUS-00331 (NTSC) disc. UsePalTimings also doesn't seem to affect this (but I think it should because in PAL version weapon bobbing also wasn't affected by player speed).

 

It is affected by movement speed but looking at it again it does seem like the difference between move/run is not as great as it should be. I could have sworn I had this working previously, I might need to take a look at it again. Thanks for bringing up.

 

On 1/23/2021 at 12:28 PM, lafoxxx said:

Some cheats (like invulnerability and noclip) keep working after you warp to other level via cheat -- though I'm not sure if it's a 'psydoom bug' or a 'ps1 feature'

 

Yeah this is an intentional change to make testing faster & easier. It lets you zip through the levels quickly in cheats mode rather than having to keep re-enabling them every time you enter a level.

 

On 1/23/2021 at 12:28 PM, lafoxxx said:

Weapon scroll is bound to 'Mousewheel" by default, but "next weapon" is selected when you scroll mouse wheel up -- not down. I know it's fixed by use of 'invmousewheel', just can't seem to remember any game with similar configuration -- in games like DOOM3 of HL2 next weapon was selected when you scrolled mouse wheel down.

 

It's a matter of personal preference for sure, I'm used to it the opposite way around and find it weird when it works as you describe. I would be open to changing the default direction though if there was evidence to suggest the opposite way would make things easier for the majority users. Anyone know of any sources for or against this, polls etc.?

 

On 1/23/2021 at 12:28 PM, lafoxxx said:

• I think it'd be great to enter password using keyboard keys.

 

Good suggestion, will make a note.

 

On 1/23/2021 at 12:28 PM, lafoxxx said:

I was also wondering if it'll be possible to compile the exe in x86 (32-bit) someday. 

 

PsyDoom can be built in 32-bit mode, but it's not very well supported or tested and may come with some performance deficits. Perhaps I can put up a 32-bit binary for the next release, if people feel strongly enough about it.

 

On 1/23/2021 at 12:28 PM, lafoxxx said:

Also I've decided to create an icon in .ICO format -- feel free to use it if you like it. It's same design as seen in the 4th page of this thread. 

 

Thanks! The whole logo/iconography thing is still something I need to revisit at some point. Right now I'm still heads down on getting the main features done.

[intacowetrust]

On 1/23/2021 at 5:50 PM, Ruritanian said:

I love the fact PsyDoom now has speedrunners.

 

That's awesome! Nice to see people enjoying the port :)

[lafoxxx]

22 hours ago, intacowetrust said:

Are you comparing the music to Aubrey's versions on bandcamp? I noticed there is a slight quirk in the Williams music sequencer system (also present in the PSX original) whereby if you pitch shift downwards then it will add an additional semitone of downwards shift. Aubrey's tracks might not have this additional pitch shift if he rendered them outside of the engine (most likely considering they are HQ), so perhaps this might be how you are perceiving the difference?

I'm comparing it to the way it sounded wien I played the game on the actual console and/or the emulator... Just listen to the music in Level 1: Attack -- you'll notice that sometimes the note of the melody gets changed -- like if the dude who would have been playing this music constantly touches the pitch bend wheel on their synth. You can hear it even in the first part -- before the "bass" appears in this music (about 40 second). I'm not sure if I have explained it good enough -- I think I can record it if needed.

 

22 hours ago, intacowetrust said:

This might be a bug that I noticed where the uncapped turning sometimes snaps backwards when pausing. Need to look into that issue... Where you pausing by any chance when this happened?

No -- this issue was there since the original PS1 version was released. Just thought it'll be fixed in this port by this very option.

I'll attempt to describe: When you, for example, walk forward and then stop, your speed decelerates -- it happens in all DOOMs. In PS1 Doom, when your angle is, say, 130 degrees, while you decelerate, your movement is visibly jagged -- like if you're not walking on 1x1 pixel grid (almost straight line), but like 8x8 (resulting in more "zigzag" movement and screen shaking sideways when your speed almost reaches zero).  In PC DOOM, on the other hand, this "deceleration" is very smooth (your screen doesn't shake sideways) even if you're not facing North/South or East/West (not 0, 90, 180 or 270 degrees precicely).

While almost unseen in 256x240, this issue will become very noticeable when you will play in high resolution.

 

 

22 hours ago, intacowetrust said:

PsyDoom can be built in 32-bit mode, but it's not very well supported or tested and may come with some performance deficits. Perhaps I can put up a 32-bit binary for the next release, if people feel strongly enough about it.

 

I thought of it being more like a "nice to have" feature for those who like to use older computers (like WinXP or Win98). I think it'd be interesting to see how the engine would run in relatively "period-correct" setup, considering it doesn't look and feel really demanding (unlike Minecraft, Unity DOOM or some re-releases of classic games which might no longer run on Pentium 3 despide being developed for it). I mean really, this port doesn't really feel as demanding as as PrBoom or even DOOM Legacy. I'd play GZdoom+PSXTC on that computer, but modern GZDOOM requires at least Pentium 4 or Athlon 64 -- just like DOOM 3!

 

By the way, will it be possible for the game to support just the directory (for example -- device letter) in addition to the .CUE? For those who still has the original discs it will be great way to keep using them "legally" -- unlike N64 cartridges where you have to buy some device to dump them to your computer to play Doom 64 EX

Edited January 26, 2021 by lafoxxx

[intacowetrust]

5 hours ago, lafoxxx said:

I'm comparing it to the way it sounded wien I played the game on the actual console and/or the emulator... Just listen to the music in Level 1: Attack -- you'll notice that sometimes the note of the melody gets changed -- like if the dude who would have been playing this music constantly touches the pitch bend wheel on their synth. You can hear it even in the first part -- before the "bass" appears in this music (about 40 second). I'm not sure if I have explained it good enough -- I think I can record it if needed.

 

I see, thanks for confirming. I will make a recording in a PSX emulator and compare the outputs.

 

5 hours ago, lafoxxx said:

No -- this issue was there since the original PS1 version was released. Just thought it'll be fixed in this port by this very option.

I'll attempt to describe: When you, for example, walk forward and then stop, your speed decelerates -- it happens in all DOOMs. In PS1 Doom, when your angle is, say, 130 degrees, while you decelerate, your movement is visibly jagged -- like if you're not walking on 1x1 pixel grid (almost straight line), but like 8x8 (resulting in more "zigzag" movement and screen shaking sideways when your speed almost reaches zero).  In PC DOOM, on the other hand, this "deceleration" is very smooth (your screen doesn't shake sideways) even if you're not facing North/South or East/West (not 0, 90, 180 or 270 degrees precicely).

 

Ah... what you're experiencing is actually imprecision in the renderer, which causes the walls to shake and wobble a lot. A lot of this imprecision stems from using the PlayStation's GTE (Geometry Transform Engine) to do the rotations for the 3D view (which PsyDoom emulates), but there are other sources too in the various fixed point calculations used. You can see a lot of this in other PSX titles too... The Vulkan renderer of course will fix all of this and provide very stable and precise rendering.

 

5 hours ago, lafoxxx said:

I thought of it being more like a "nice to have" feature for those who like to use older computers (like WinXP or Win98). I think it'd be interesting to see how the engine would run in relatively "period-correct" setup, considering it doesn't look and feel really demanding (unlike Minecraft, Unity DOOM or some re-releases of classic games which might no longer run on Pentium 3 despide being developed for it).

 

The main goal of PsyDoom is to bring the game onto modern platforms that are in use today, not to try and support older ones which are dead and no longer alive outside of vintage computing circles. As such Windows 98 will never be supported, and XP support is hanging on by a thread; as soon as it becomes no longer possible to target XP in modern Visual Studio then support will be dropped completely. 32-bit is kind of falling into the vintage category at this point, that's why I don't want to invest time and energy into supporting it if I don't have to.

 

5 hours ago, lafoxxx said:

I mean really, this port doesn't really feel as demanding as as PrBoom or even DOOM Legacy. I'd play GZdoom+PSXTC on that computer, but modern GZDOOM requires at least Pentium 4 or Athlon 64 -- just like DOOM 3!

 

You'd be surprised actually - the GPU emulation for the classic PSX renderer does consume quite a bit of CPU time. When I run the game at 144 Hz it will consume approximately 25% of one core on my i7 7700k. The game is mostly single threaded (apart from SPU emulation) so this is still quite a large chunk of CPU time for the one core that it runs on. If you go back as far as a Pentium 4 with the significantly lower IPC, cache size etc. then the game would definitely become a lot more strenuous.

 

5 hours ago, lafoxxx said:

By the way, will it be possible for the game to support just the directory (for example -- device letter) in addition to the .CUE? For those who still has the original discs it will be great way to keep using them "legally" -- unlike N64 cartridges where you have to buy some device to dump them to your computer to play Doom 64 EX

 

I had considered this previously but decided against it. Mainly because streaming CD audio and so on from real media is a lot more complicated but also because I want to discourage people from using the real game media and instead back up and use an image. At this point with bit rot etc. these discs are becoming increasingly precious and should be taken care of.

[lafoxxx]

20 hours ago, intacowetrust said:

The Vulkan renderer of course will fix all of this and provide very stable and precise rendering.

That's great. Looking forward to checking it out!

20 hours ago, intacowetrust said:

You'd be surprised actually - the GPU emulation for the classic PSX renderer does consume quite a bit of CPU time. When I run the game at 144 Hz it will consume approximately 25% of one core on my i7 7700k. The game is mostly single threaded (apart from SPU emulation) so this is still quite a large chunk of CPU time for the one core that it runs on. If you go back as far as a Pentium 4 with the significantly lower IPC, cache size etc. then the game would definitely become a lot more strenuous.

 

Ok, I see.

Regarding the renderer -- it's great you're adding Vulcan, but what about OpenGL -- is there any chance we (mostly -- those of us who don't have a compliant gpu) will see it , or it's already decided that the project is developed with latest technologies in mind?

Will the port ultimately be completely free of components of PS1 emulator on _all_ levels (in addition to PS1 GPU emulation for rendering and PS1 BIOS which is now also not needed)?

20 hours ago, intacowetrust said:

I had considered this previously but decided against it. Mainly because streaming CD audio and so on from real media is a lot more complicated but also because I want to discourage people from using the real game media and instead back up and use an image. At this point with bit rot etc. these discs are becoming increasingly precious and should be taken care of.

Makes sense. But what about the other formats (like .ISO, for example)?

Edited January 27, 2021 by lafoxxx

[intacowetrust]

On 1/27/2021 at 6:38 AM, lafoxxx said:

Ok, I see.

Regarding the renderer -- it's great you're adding Vulcan, but what about OpenGL -- is there any chance we (mostly -- those of us who don't have a compliant gpu) will see it , or it's already decided that the project is developed with latest technologies in mind?

 

I likely won't be adding OpenGL support, there are a couple of reasons for this:

• Even if I did it's not clear if some of the older (non-Vulkan capable) devices would support some of the data formats and features needed by PsyDoom. The list of new devices supported might not be worth the effort. The cut-off point for Vulkan support is generally GPUs released in 2012 or afterwards (GCN 1.0 and Kepler) and it seems like GPUs before that might start to get a bit sketchy and be lacking some of the features that PsyDoom needs.
• I've started taking advantage of certain Vulkan specific features that might require painful or sub-optimal workarounds in GL. This wouldn't help matters on lower end GPUs. The renderer is architected with newer APIs in mind.
• Personal preference: I find OpenGL a pain in the neck to work with compared to Vulkan, and a headache to try and debug. Vulkan is actually surprisingly pleasant to work with once you get a lot of the boilerplate out of the way.

The main reason for going with Vulkan however is that it cleanly lets me target the 3 major platforms of Windows, MacOS (via MoltenVk) and Linux with one API and it looks like it has a much longer shelf life ahead of it compared to OpenGL. GL is basically dead on MacOS and will likely wither on the vine on Windows/Linux due to diminishing interest in it from developers and driver teams alike. Thus Vulkan was chosen for longer term compatibility and portability reasons.

 

On 1/27/2021 at 6:38 AM, lafoxxx said:

Will the port ultimately be completely free of components of PS1 emulator on _all_ levels (in addition to PS1 GPU emulation for rendering and PS1 BIOS which is now also not needed)?

 

As of right now (in the latest code on the 'develop' branch) PsyDoom no longer uses the Avocado PlayStation emulator - I've removed it completely from the project. The last dependency on Avocado was the GPU emulation, and that has now been replaced with PsyDoom's own internal GPU module. This move was done to fix a few bugs & issues with the Avocado GPU and also to allow for future limit removing/reduction and extended features. For example this new GPU can support 16-bit texture coordinates instead of 8-bit, which in turn enables tall walls of > 256 units to be supported more easily. It will also be easy to increase the amount of VRAM and so on...

 

On 1/27/2021 at 6:38 AM, lafoxxx said:

Makes sense. But what about the other formats (like .ISO, for example)?

 

ISO unfortunately doesn't support CD audio, so that is a no-go for PsyDoom. CHD could be an option but because of the compression it might make random disc access a pain and much slower. Not 100% sold on the merits of supporting that format yet, but I haven't looked into it much. The standard bin/cue combos seem to be the most popular in PS1 emulation.

Edited January 28, 2021 by intacowetrust

[lafoxxx]

On 6/9/2020 at 7:50 AM, intacowetrust said:

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.

Sorry for replying to such an old message -- but I feel like the initial position of the rocket is not the root cause of this issue. To me, the issue appears because it seems like the player gets "deeper" into the wall when you get into the corner:

Watch that video from your comment closely -- you'll see that on the 5th second the player gets "sucked in" to the corner after performing left strafe.

Otherwise the bug would have been reproducible without having to get into the corner, but just by shooting into the wall right in front of you.

Edited January 30, 2021 by lafoxxx

[intacowetrust]

On 1/29/2021 at 3:47 PM, lafoxxx said:

Sorry for replying to such an old message -- but I feel like the initial position of the rocket is not the root cause of this issue. To me, the issue appears because it seems like the player gets "deeper" into the wall when you get into the corner:

 

Yeah that's the cause of the rocket's initial position being bad. It starts off at the player's position and then is nudged a fixed amount forward, away from the player. Previously after performing this nudge the code would check whether the rocket penetrated a wall, and then explode the rocket if that was found to be the case. The explosion causes splash damage and splash damage checks whether there is a line of sight (via a raycast) from the explosion point to the player (and other nearby things).

 

This worked great in most situations, except when the player position got really close to the wall (thanks to slightly iffy collision code). In the failure cases with the bug the rocket would be nudged so deep into the wall that the raycast from its spawn point to the player would be obscured and hence the player would not receive splash damage. My fix was to simply add an additional collision check against the wall before the nudge and explode the rocket then if it was already penetrating.

[xvertigox]

I saw this mentioned in a different thread and wow, PsyDoom works great out of the box. I was able to immediately start up Doom 1/2 and Final Doom and get to playing. I haven't played much at all but the controls are tight and the lighting looks great. I'm surprised at how mature this looks already, great job!

[Eric Claus]

Loving this port, and the Vulkan rendering looks sick! Smooths things out a bit but in a good way and makes it much easier to look at.  Can't wait!

[intacowetrust]

6 hours ago, Eric Claus said:

Smooths things out a bit but in a good way and makes it much easier to look at.  Can't wait!

 

Yeah those screenshots have 8x MSAA active, which does tend to smooth out stuff in the distance a bit. It can be turned off though if a sharper look is preferred.

 

One thing that's not possible to see from those screenshots - the MSAA will also help with temporal aliasing and shimmer artifacts when moving about. This was the main motivation for me to implement it. Doom doesn't suffer from jaggies too much because the geometry is so simple but the shimmer of course does catch the eye and tends to stick out even more at higher resolutions.

[taufan99]

Just a bit of curious, how will PsyDoom handle recognition of both PSX DOOM and Final DOOM as separate games, so as to clear the need to rename CD rip file(s)?

[intacowetrust]

9 hours ago, InDOOMnesia said:

Just a bit of curious, how will PsyDoom handle recognition of both PSX DOOM and Final DOOM as separate games, so as to clear the need to rename CD rip file(s)?

 

Haven't thought about it much yet but that sort of thing would probably be handled best via a separate launcher which incorporates disc selection, like what was mentioned earlier in the thread.

 

For now though the easiest workaround is to simply have separate folders for each game and duplicate the PsyDoom .exe - it's only ~2MB so won't take up much space. Alternatively you can create shortcuts or launch scripts and use the '-cue <CUE_FILE_PATH>' command line argument to specify which disk you want to use.

[Warden]

This is a great port, and I love being able to play the game in its native res with proper M+KB support. It's beautiful.

 

I have two suggestions/requests, though I'm not sure if they're outside your project's scope:

• A -pistolstart command line option ala Crispy Doom. Simple but much appreciated QoL feature.
• DEHACKED-esque cheat to unnerf the revenant's A_Chase speed and restore his random tracers—it just feels a bit sad to fight this guy with a keyboard now. Let us return him to glory.

Edited February 17, 2021 by Warden

[intacowetrust]

15 hours ago, Warden said:

• A -pistolstart command line option ala Crispy Doom. Simple but much appreciated QoL feature.

 

This would be a relatively simple addition, I'll make a note of it - thanks! In the meantime using the level warp cheat is one way to ensure a pistol start, or one of the pistol start passwords available here.

 

15 hours ago, Warden said:

DEHACKED-esque cheat to unnerf the revenant's A_Chase speed and restore his random tracers—it just feels a bit sad to fight this guy with a keyboard now. Let us return him to glory.

 

DEHACKED support is definitely beyond the scope of the project but I'm still considering whether to support a limited set of optional & disabled by default gameplay tweaks. There have also been complaints about the delay of the Super Shotgun compared to PC, for example. Tweaking gameplay is a bit of a slippery slope that I don't want to go too far down but perhaps a few basic quality of life accommodations can be made.

[Warden]

The good news is that unlike Doom 64 EX I can actually get this thing to compile, so I don't mind too much if you want to lean in a conservative direction. It's been a lot of fun to tinker with the past couple of days and most of the things I wanted to mod in are fairly simple.

 

I'm curious about the software renderer. I know you've said upscaling would look ugly but is there any possibility of extending the viewport for "widescreen 240p" (I'm not sure what the right term for this would actually be)?

Edited February 28, 2021 by Warden

[DoomedFox]

Im glad the sound distortion/crackle issues have been fixed as those kept me from really diving further into this port. Cause I am LOVING this port already and its shaping up to be the one way to play PSX doom without a emulator. Only issue is how do i get to the config file for keymapping? I tried going into my AppData folder and it seems like windows 8.1 really wants to bury it far into the system. Is there a possiblity that the config file could just generate in the folder\directory PsyDoom.exe resides in for easy access? or is there a planned expansion to the controls\video\compatibilty settngs in the future? 

[intacowetrust]

1 hour ago, Warden said:

I'm curious about the software renderer. I know you've said upscaling would look ugly but is there any possibility of extending the viewport for "widescreen 240p" (I'm not sure what the right term for this would actually be)?

 

It's possible but it would be very awkward and require a lot of changes to how the original renderer worked. The assumption of a 90 degree field of view is baked into a lot of places in the classic renderer and used to simplify a lot of math and various clipping operations. Trickier than that is the issue of framebuffer management and where the classic framebuffer lives. There are fixed parts of PSX VRAM that are used to house the front and back buffers and those can't accommodate anything wider than 256 pixels; the entire framebuffer management would need to be re-done to bypass PSX VRAM, much like how the Vulkan renderer itself works. In the end the classic renderer would end up becoming something more like the Vulkan renderer, which in some ways would also make it redundant.

 

Having that said however, what you are looking to achieve should be largely possible within the new Vulkan renderer. I plan on supporting a 'render scale' setting for the new renderer so you can control the pixel density and make things chunkier if desired. If you turn off anti-aliasing and render at a scale similar to the PSX then what you should end up with is something that looks very close to the PSX, but with widescreen support and various other renderer glitches fixed. 

 

Here is a quick test I did of that, ignore some slight pixel stretching issues for the VK screenshot - I haven't really looked at this feature yet:

 

[intacowetrust]

1 hour ago, DoomedFox said:

Im glad the sound distortion/crackle issues have been fixed as those kept me from really diving further into this port. Cause I am LOVING this port already and its shaping up to be the one way to play PSX doom without a emulator. Only issue is how do i get to the config file for keymapping? I tried going into my AppData folder and it seems like windows 8.1 really wants to bury it far into the system.

 

Hey @DoomedFox try putting the following location into the Windows Explorer address bar, or by pressing Windows + R and inputting this path into the 'open' field:

%APPDATA%\com.codelobster\PsyDoom

The configuration folder should open up for you then. The file you are looking for in particular is called 'control_bindings.ini'. Please note you also need to launch PsyDoom first in order for these files to be generated, first time around.

 

1 hour ago, DoomedFox said:

Is there a possiblity that the config file could just generate in the folder\directory PsyDoom.exe resides in for easy access?

 

By default PsyDoom will follow modern OS practices of separating the program from it's user data and write to the AppData location because it should always be somewhere that's more or less guaranteed to be writable; the folder which PsyDoom is placed in which might not be. It's also a location that's exposed in a portable manner by SDL, which maps neatly to similar locations in other operating systems, like MacOS and Linux etc.

 

Having that said however, if you want your config files to reside in the same folder as PsyDoom then you can just copy them all out to that folder. If PsyDoom detects these config files in its own folder/working-directory, then they will take precedence over the ones in AppData and be used instead.

 

1 hour ago, DoomedFox said:

or is there a planned expansion to the controls\video\compatibilty settngs in the future? 

 

Yes there will likely be at least 1 new setting added to each major release of PsyDoom, depending on what needs to be made configurable. For future settings added they will be appended to your current configuration files and PsyDoom will inform you if there is new stuff that you might want to change.

Edited February 18, 2021 by intacowetrust

[intacowetrust]

Just a quick note to record some of my findings with regards to seams on the floors (and ceilings) in some levels. I was hoping the Vulkan renderer would be able to eliminate this sort of thing entirely:

 

Spoiler

 

And while the issue is vastly improved, there are still tiny sky specks visible now and then where there are minute gaps between floor polygons. I've shaded floors solid grey so you can see things more clearly here:

 

Spoiler

 

I attempted to implement a vertex welding algorithm (for extremely close vertices) in the hope that it might help but unfortunately it turned out to be a wash. The real issue is that the level geometry is full of t-junctions and these are causing the occasional seams. For a discussion on why that is a problem, see:
https://computergraphics.stackexchange.com/questions/1461/why-do-t-junctions-in-meshes-result-in-cracks/1464

 

One other thing I noticed too when I tried getting more aggressive with the vertex welding, cracks like the following started occurring:

 

Spoiler

 

This one is in the original level data, but I wound up with similar artifacts with this experiment. Wherever you see these cracks then in original maps, it may have been due to the vertex welding done at map build time, where t-junctions are nearby. Unfortunately the only true fix for all these issues to rebuild the map data to try and avoid these t-junctions in the first place.

 

Thankfully the good news is that if you turn on MSAA then many of these miniscule seams become virtually un-noticeable for the most part, especially at higher sample counts. So if you can run the game with that enabled, then it should literally paper over the cracks for you :)

 

[Marty2Doom]

On 2/18/2021 at 11:17 PM, intacowetrust said:

 

Hey @DoomedFox try putting the following location into the Windows Explorer address bar, or by pressing Windows + R and inputting this path into the 'open' field:

%APPDATA%\com.codelobster\PsyDoom

The configuration folder should open up for you then. The file you are looking for in particular is called 'control_bindings.ini'. Please note you also need to launch PsyDoom first in order for these files to be generated, first time around.

 

 

By default PsyDoom will follow modern OS practices of separating the program from it's user data and write to the AppData location because it should always be somewhere that's more or less guaranteed to be writable; the folder which PsyDoom is placed in which might not be. It's also a location that's exposed in a portable manner by SDL, which maps neatly to similar locations in other operating systems, like MacOS and Linux etc.

 

Having that said however, if you want your config files to reside in the same folder as PsyDoom then you can just copy them all out to that folder. If PsyDoom detects these config files in its own folder/working-directory, then they will take precedence over the ones in AppData and be used instead.

 

 

Yes there will likely be at least 1 new setting added to each major release of PsyDoom, depending on what needs to be made configurable. For future settings added they will be appended to your current configuration files and PsyDoom will inform you if there is new stuff that you might want to change.

I have to contradict that.

I replaced that as standard in your last version and recompiled the Psydoom not in Appdata searches but in the directory where it is located.

 

Wiki entry:
Unfortunately, it is a convention that is often overlooked by programmers that the special directory should only be used for data relating to the computer on which the directory of the application itself is located. Whereas the "application data" should contain the information that is related to the logged in user and his / her settings. This is particularly disregarded by the fact that other virtual directories are used and added to Windows Explorer.

 

Many just don't understand the special directory concept that Microsoft is introducing. It has nothing to do with "modern". It is actually just laziness because the given API has already given the special directory as the global configuration directory. So you don't have to program anything except insert CSIDL and you're done. But not everything can be crammed into Appdata. The directory is not used well by many other programs anyway and it is becoming more and more confusing. The best negative example are mods from games that have to stay with appdata. They didn't understand anything anymore. One of the big ones is Unity, Unreal who didn't hear the shot.

 

Unless the configuration is user-dependent. Sensitive data and so on. The configuration has nothing to do with Appdata. But 90% of programmers don't understand that. I have to recompile most of the open source programs. i don't want to search through appdata. 

[SaladBadger]

ok, but if things are "supposed" to write data to their working directory, how do you handle things on unix-y platforms, where normal users can't write to /bin/ or /usr/bin/? or are you saying that applications should never, ever be installed to a location where they can't write to their own working directory?

[intacowetrust]

On 3/16/2021 at 5:09 AM, Marty2Doom said:

Wiki entry:
Unfortunately, it is a convention that is often overlooked by programmers that the special directory should only be used for data relating to the computer on which the directory of the application itself is located. Whereas the "application data" should contain the information that is related to the logged in user and his / her settings. This is particularly disregarded by the fact that other virtual directories are used and added to Windows Explorer.

 

@Marty2Doom not sure I'm understanding the argument you are making - do you have any other sources or articles supporting what you are saying? I don't speak German and I'm sure that might be a poor auto-translation (I don't see this paragraph on the English page) so I'm probably not getting the full context. The way I see it however is that the config files are user settings; a combination of PsyDoom generated values, plus possible user modifications to those values to be exact. So that does seem fit in with the intended use of AppData quoted above... If that is the case what would be the issue?

 

On 3/16/2021 at 5:09 AM, Marty2Doom said:

I replaced that as standard in your last version and recompiled the Psydoom not in Appdata searches but in the directory where it is located.

 

You are of course welcome to make changes if you disagree with any decisions - that's one of the benefits of open source. I will add in this instance though you don't need to modify the code to achieve what you are looking for. Just copy the config files to PsyDoom's working directory and it'll use those instead of the ones in %APPDATA%.

 

On 3/16/2021 at 5:09 AM, Marty2Doom said:

The directory is not used well by many other programs anyway and it is becoming more and more confusing. The best negative example are mods from games that have to stay with appdata. They didn't understand anything anymore. One of the big ones is Unity, Unreal who didn't hear the shot.

 

Unless the configuration is user-dependent. Sensitive data and so on. The configuration has nothing to do with Appdata. But 90% of programmers don't understand that. I have to recompile most of the open source programs. i don't want to search through appdata. 

 

Personal preferences aside, if everyone is doing it this way might that not suggest that this is in fact the accepted/standard method nowadays? It seems quite a stretch to say that 90% of devs are doing it wrong... I didn't just decide this unilaterally either, its cross platform 'get me a save folder' functionality provided by SDL which of course has been around for a long time now and used by many projects. On Windows the SDL functionality happens to be implemented this particular way, using the AppData folder.

 

On 3/16/2021 at 10:30 AM, SaladBadger said:

ok, but if things are "supposed" to write data to their working directory, how do you handle things on unix-y platforms, where normal users can't write to /bin/ or /usr/bin/? or are you saying that applications should never, ever be installed to a location where they can't write to their own working directory?

 

Adding to that point, you normally can't write to your .app bundle on MacOS either. If you house the .app in the 'Applications' folder then that will be typically off limits as well. On MacOS you are kind of forced to use the 'AppData' equivalent (~/Library/Application Support).