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

[Lollie]

10 hours ago, intacowetrust said:

Yeah I noticed the new issue on the pause menu as well... It might be that the timings were slightly disrupted in this new build, and perhaps an important audio event was missed.

I think you're right that an audio event is being missed. After having a quick listen and comparing to previous versions, it sounds like a "note-off" event isn't being called. I'm assuming that the normal behavior is that upon pausing, the game sends a note-off command to the music engine *and* ramps the music volume down. In this current version though, only the volume ramp down is occurring.

 

Worth noting, this was definitely only recently introduced in 0.1.0 — pause behavior sounds correct up to 0.0.3!

Edited March 2, 2020 by Lollie

[intacowetrust]

On 3/1/2020 at 7:10 PM, Lollie said:

I think you're right that an audio event is being missed. After having a quick listen and comparing to previous versions, it sounds like a "note-off" event isn't being called. I'm assuming that the normal behavior is that upon pausing, the game sends a note-off command to the music engine *and* ramps the music volume down. In this current version though, only the volume ramp down is occurring.

 

Worth noting, this was definitely only recently introduced in 0.1.0 — pause behavior sounds correct up to 0.0.3!

 

Looks like it was caused by a very subtle emulator issue in the end, introduced when I updated Avocado recently. This commit fixes the problem:

https://github.com/BodbDearg/PsyDoom/commit/d8203f6eea1e7b594bfc31b83c0d681f916480ec

 

I might do another build again soon (despite what I said previously) since I have a fix for both this and that nasty freezing issue (on level loads) which have been plaguing the project since I began. That's worth doing another build for alone since it's a big quality of life improvement.

 

The level loading issue went away once I converted the LIBCD PsyQ library to fully native code. This new version is greatly simplified, works synchronously and talks directly to the Avocado 'cdrom':
https://github.com/BodbDearg/PsyDoom/blob/master/game/PsyQ/LIBCD.cpp
https://github.com/BodbDearg/PsyDoom/blob/master/game/PsyQ/LIBCD.h

 

[Gez]

On vendredi 28 février 2020 at 6:35 AM, intacowetrust said:

Add a hack that allows playing the game at 60 Hz instead of the regular 30 Hz max. The hack is enabled by adding the -highfps command line switch. Current issues/limitations:

• View bobbing doesn't work.

• Gravity being far too strong (related to this physics bug, see: https://www.youtube.com/watch?v=7RBycvyZf3I).

• Not as smooth as it could be, occasional stuttering.

• It also doesn't seem to work properly on MacOS.

The proper way would be to keep the gamesim at 30 Hz and add interpolation to the renderer. But until then, perhaps a quick and dirty fix would be to only apply gravity on every odd tic instead of every tic while in highfps mode?

[intacowetrust]

20 hours ago, Gez said:

The proper way would be to keep the gamesim at 30 Hz and add interpolation to the renderer. But until then, perhaps a quick and dirty fix would be to only apply gravity on every odd tic instead of every tic while in highfps mode?

 

Yeah I'm going to have do interpolation for movement in order to be able to support high frame rates without breaking demo compatibility. Unfortunately gravity is still broken even when running at 30 Hz, as this video shows: https://www.youtube.com/watch?v=7RBycvyZf3I

 

I might have to tick the player logic at 15 Hz like the rest of the game in order to fix that one. Will see what I can do once I start looking at that code; hopefully I can make it consistent without making input lag feel bad.

[intacowetrust]

Hey everyone, I've just put up a new build (0.1.1) for Windows 64-bit and MacOS:

 

https://github.com/BodbDearg/PsyDoom/releases/tag/releases%2F0.1.1

 

Changes in this version:

 

• Fixed issues with the game freezing sometimes on level loads.
• Fixed music not stopping fully on game pause.
• The music sequencer is now driven completely by the host machine's clock, not an emulator clock. As a result music timings and playback should be more accurate. The sequencer logic also no longer runs under emulation and can be debugged normally.
• The lowest levels of cdrom and spu handling (via the PsyQ SDK) are now completely native and talk directly to the emulator 'hardware'. Having control over the interactions with the hardware allowed the game freezing issue to be fixed.
• Spu and cdrom advancement have been completely detached from the rest of the emulated PlayStation and now advance at their own pace and as required. Having isolated spu/cd components will eventually allow me to move sound and music to another thread and make it more reliable.

 

[taufan99]

Probably sounds like a bothersome request, but can you implement the Sega Saturn status bar, which, while overall almost the same theme as the PSX status bar, features the original properly scaled status bar face? I found a mod with the Saturn status bar here.

While we're at it, I would like to have an option to switch between two status bar types.

[intacowetrust]

On 3/11/2020 at 4:43 PM, InDOOMnesia said:

Probably sounds like a bothersome request, but can you implement the Sega Saturn status bar, which, while overall almost the same theme as the PSX status bar, features the original properly scaled status bar face? I found a mod with the Saturn status bar here.

While we're at it, I would like to have an option to switch between two status bar types.

 

I did a quick check just to see what might be involved and I think it might be beyond the scope of this project - sorry. If it was just a simple asset swap (enabled by a user supplied WAD) and maybe changing a few texture atlas coordinates for the STATUS image then I might consider adding support but unfortunately that is not the case.

 

The main issue is that the Saturn HUD is much wider than that of the PlayStation, being 320 pixels in width instead of 256. The maximum texture size supported on the PlayStation is 256 pixels and the framebuffer is 256 pixels wide also, so I'd have to make pretty drastic changes with regard to VRAM management, screen resolution etc. in order to support this. PsyDoom is intending to imitate the original PlayStation version fairly faithfully (a chocolate Doom style approach) so I'm keeping a PlayStation style rasterizer in place (most likely I'll continue using the Avocado 'gpu') with similar hardware limitations.

 

Eventually I'm planning to fork PsyDoom and add a hardware renderer, widescreen support etc. so such a change might become more feasible then. But that will not be for quite a while...

[lafoxxx]

I believed this would happen sometime. Happy to see the result so far!

 

Few questions I think you can answer since you've seen how it works:

• When the platform or door moves, why do the pixels of adjacent wall look like they "melt"? Is it some kind of rendering artifact?
• From technical perspective, is the PS1 renderer completely inferior to PC renderer, or is it superior in some ways?
• I remember weapon bobbing being more "complex" in PS version than in original PC release, with varying degree of movement to each side, depending on your speed and direction, etc. What also is taken into account?

Edited March 23, 2020 by lafoxxx

[intacowetrust]

10 hours ago, lafoxxx said:

When the platform or door moves, why do the pixels of adjacent wall look like they "melt"? Is it some kind of rendering artifact?

 

Yeah it's the result of PlayStation hardware limitations. Texture coordinates on the PS1 are specified in terms of whole pixel locations only - there is no fractional component to the numbers. Most of the time that's fine but what happens with doors, plats etc. when they are in motion is that the wall columns end up being not entirely integer sized in terms of their height, due to floor and ceiling heights being in between whole units.

 

When the time comes to submit wall columns to the GPU, rounding must occur (due to the aforementioned hardware limit) and the fractional coordinates are converted to integers. This results in the stepping between pixels shifting slightly and the texture being stretched and squeezed slightly, depending on the current fractional values of the ceiling and floor heights. This causes the 'shimmer' or distortion effect you are observing..

 

This slight glitch can also be found in the original game too, in fact PsyDoom shares pretty much all of the rendering quirks of the original game. Here are a few of the most common ones:

 

Invalid Z Order

Sometimes layering is wrong and sector flats 'cut' into sprites. This is due to the simplified way the renderer handles z-ordering for sprites, it basically emits them as it visits a subsector and relies on the BSP tree to handle Z-Order in relation to everything else - unlike the PC renderer. Most of the time that approach works fine, but occasionally you will see stuff like this:

 

 Texture Drift 

Sometimes depending on the view angle, texture coordinates can 'drift' quite a bit due to various imprecisions. It happens often up close or at seep viewing angles to walls, but sometimes it also happens at very particular view angles as you can see here. This switch texture that isn't displaying as it should:

 

Holes or gaps in walls and floors

This precision issue can occur in most places, but larger levels seem to have the issue more. The yellow pixels are the gaps here where the sky can be seen through:

 

Occluded sector ceilings visible through the sky

The ceiling here shouldn't be showing as it is for a room around the corner. This happens due to the simplified way the PSX renderer handles occlusion and Z sorting.

 

Flats extend beyond their bounds by 1 or 2 px

This is a more subtle issue, but floors and ceilings can sometimes be seen over-extending past where they are supposed to be. I believe it's due to a hack that was trying to prevent cracks in between flats and walls. Sometimes its a little over eager and causes slight visual glitches.

 

 

10 hours ago, lafoxxx said:

• From technical perspective, is the PS1 renderer completely inferior to PC renderer, or is it superior in some ways?

 

In some ways the PS1 renderer is superior, the improvements include:

• 16-bit 'true color' framebuffer instead of the 8-bit palette based display on PC. The PS1 version can display a much greater range of colors because of this.
• Colored lighting.
• Alpha blending effects for transparency and subtractive blending (for 'nightmare' spectres).
• Animated fire skies
• No use of 'visplanes', therefore no more dreaded 'visplane' overflow errors.

Some of the downsides include the bugs discussed above (most of which can probably be fixed, given enough time or CPU power) and also:

• Wall heights are limited to 256 units, due to (again) hardware limitations with PS1 texture coordinates. The coordinates are only a single byte so can only have 256 values. This limit can be worked around to some extent however with some hacks during mapping...
• Texture widths are restricted to 128 units wide, 64 units wide and 16 units wide only to simplify VRAM mangement - you can't have a 48 px texture for instance.
• VRAM is severely limited on the PS1, resulting in a much reduced variety in textures. On some of the busier levels with lots of monsters (like 'The Suburbs'), the 'Texture Cache Overflow' error can be triggered. This error happens when the game runs out of VRAM to display all of the sprites currently visible in the scene.
• The screen resolution is low (only 256x240) and is stretched slightly (horizontally) to fill out the TV display more.
• In some scenes lots of overdraw can occur which can drag down the framerate quite a bit. This is due to the simplified occlusion culling versus the PC engine, which tries to keep overdraw to an absolute minimum. Perhaps this was a deliberate tradeoff however, to shift some of the burden off of the cpu?
• Probably lots of other stuff, feel free everyone to chime in and add to this list...

 

10 hours ago, lafoxxx said:

I remember weapon bobbing being more "complex" in PS version than in original PC release, with varying degree of movement to each side, depending on your speed and direction, etc. What also is taken into account?

 

I believe that should be pretty much it, though I haven't examined that code yet in detail.

 

 

Edited March 24, 2020 by intacowetrust

[Redneckerz]

10 hours ago, intacowetrust said:

In some ways the PS1 renderer is superior, the improvements include:

• 16-bit 'true color' framebuffer instead of the 8-bit palette based display on PC. The PS1 version can display a much greater range of colors because of this.
• Colored lighting.
• Alpha blending effects for transparency and subtractive blending (for 'nightmare' spectres).
• Animated fire skies
• No use of 'visplanes', therefore no more dreaded 'visplane' overflow errors.

Some of the downsides include the bugs discussed above (most of which can probably be fixed, given enough time or CPU power) and also:

• Wall heights are limited to 256 units, due to (again) hardware limitations with PS1 texture coordinates. The coordinates are only a single byte so can only have 256 values. This limit can be worked around to some extent however with some hacks during mapping...
• Texture widths are restricted to 128 units wide, 64 units wide and 16 units wide only to simplify VRAM mangement - you can't have a 48 px texture for instance.
• VRAM is severely limited on the PS1, resulting in a much reduced variety in textures. On some of the busier levels with lots of monsters (like 'The Suburbs'), the 'Texture Cache Overflow' error can be triggered. This error happens when the game runs out of VRAM to display all of the sprites currently visible in the scene.
• The screen resolution is low (only 256x240) and is stretched slightly (horizontally) to fill out the TV display more.
• In some scenes lots of overdraw can occur which can drag down the framerate quite a bit. This is due to the simplified occlusion culling versus the PC engine, which tries to keep overdraw to an absolute minimum. Perhaps this was a deliberate tradeoff however, to shift some of the burden off of the cpu?
• Probably lots of other stuff, feel free everyone to chime in and add to this list...

I believe that should be pretty much it, though I haven't examined that code yet in detail.

I Love this, especially the part where you explain the improvements the PS1 renderer has over the stock Doom engine (and how PsyDoom features this renderer). This is the kind of stuff i am looking for.

 

How does it achieve no visplanes, however?

 

By the way, have you considered making a logo for PsyDoom/Phoenix Doom? I feel PsyDoom definitely deserves one, sadly i am not a graphic artist.

[seed]

He did, although never got to it, yet.

[Chipper35]

This is OTHER DIMENSION STUFF, BROTHER!!

[Redneckerz]

20 minutes ago, seed said:

He did, although never got to it, yet.

Hmm. Either way, what i said in January about making a page, i feel like its close to the time for that :P

 

Just have to figure out if Erick194's PSXDoom reverse engineering has to be included in this. DZDoom not yet so much because the rebrand and release of V3 (When it is to be rebranded in the first place) is not there yet, same with a features list.

[intacowetrust]

9 hours ago, Redneckerz said:

I Love this, especially the part where you explain the improvements the PS1 renderer has over the stock Doom engine (and how PsyDoom features this renderer). This is the kind of stuff i am looking for.

 

How does it achieve no visplanes, however?

 

Glad you found the info helpful! :)

 

As far as no visplanes go, PlayStation Doom achieves this by essentially just rasterizing floor & ceiling polygons through use of the leaf data structure. Each leaf is a complete collection of all the edges in a subsector, which is sadly missing from the regular PC BSP tree. The glBSP Specs intro talks about this problem a little more and why it's an issue for hardware renderers.

 

When the time comes to render a flat plane for a subsector, the PS1 renderer steps through all the pixels in all the screenspace edges to determine the top and bottom screen y values for the polygon, as well as the left and right x values for each horizontal row of pixels. Because the each subsector polygon is convex, all that is needed is a single continuous line for each horizontal row, and a single pair of left and right x values per row.

 

Once it has the screen positions and bounds for each horizontal span/line in the polygon, the renderer can then figure out the floor or ceiling texture coordinates using the view position and direction. Once that is done, all that needs to happen is to submit a single textured line to the GPU for each horizontal row in the polygon, using all of the computed info. This is submitted as an extremely thin polygon that basically rasterizes to a line...

 

That is the happy case... Unfortunately a complication arises for larger polygons due to the previously mentioned 1 byte texture coordinates on the PS1. If the texture wraps too many times the PS1 renderer has to split a horizontal span into many smaller spans to get around the fact that the PS1 can only express texture coords from 0-255. This means that larger open areas can see decreased performance due to more horizontal lines being submitted to the GPU.

 

I've hacked together a quick visualization of this, with each line submitted to the GPU colored randomly so you can see what it is doing. Subsectors here are colored most differently, with slightly less random variance for individual horizontal rows in a polygon:

 

 

Notice how for the larger green subsector by the window there is a slight change in line color midway through the line. This is where the renderer had to split up the horizontal span into multiple smaller spans to workaround PS1 hardware limitations.

 

That is the basic idea of how it all works, but of course there is more detail in the actual implementation. The code is all here and commented for those who want to take a look:

https://github.com/BodbDearg/PsyDoom/blob/master/game/Doom/Renderer/r_plane.cpp

 

10 hours ago, Redneckerz said:

By the way, have you considered making a logo for PsyDoom/Phoenix Doom? I feel PsyDoom definitely deserves one, sadly i am not a graphic artist.

 

Yeah it's definitely on my TODO list, but far down on the list priorities. I'm no artist either but have used Inkscape before in the past so could probably cobble together something. Once all the hard stuff is done I can sort out stuff like that.

[taufan99]

18 minutes ago, intacowetrust said:

Yeah it's definitely on my TODO list, but far down on the list priorities. I'm no artist either but have used Inkscape before in the past so could probably cobble together something. Once all the hard stuff is done I can sort out stuff like that.

Let me see if I can help anytime soon... I'm no artist myself, but some simple logo suggestion would be helpful too, right?

[intacowetrust]

15 minutes ago, InDOOMnesia said:

Let me see if I can help anytime soon... I'm no artist myself, but some simple logo suggestion would be helpful too, right?

 

That would be awesome, thank you! :) Definitely open to help or suggestions on the logo stuff!

[Redneckerz]

5 hours ago, intacowetrust said:

 

Glad you found the info helpful! :)

A summary list of what improvements the PSX renderer has over most other versions of Doom? Well yes, ofcourse! PSX Doom is unique in this approach (Safe for Doom 64) its precisely why PsyDoom is such an important and interesting project: The PSX renderer backported to PC. That's fascinating right there.

5 hours ago, intacowetrust said:

As far as no visplanes go, PlayStation Doom achieves this by essentially just rasterizing floor & ceiling polygons through use of the leaf data structure. Each leaf is a complete collection of all the edges in a subsector, which is sadly missing from the regular PC BSP tree. The glBSP Specs intro talks about this problem a little more and why it's an issue for hardware renderers.

Goes beyond my technical lack of expertise (how this is implemented on a exact level) but it is still very interesting!

 

An out of the box question: The demoscene has worked with PlayStation hardware in the past. Would documentation on the inner workings or perhaps optimized routines be useful for your project? Since PSX Doom essentially talks directly to the CPU and the GTE, this might be a useful thing :)

 

Btw, you may want to contact @Julia Nechaevskaya for logo's. The Woof! logo is her creation :)

 

4 hours ago, InDOOMnesia said:

Let me see if I can help anytime soon... I'm no artist myself, but some simple logo suggestion would be helpful too, right?

Lets strike a deal here for PsyDoom (because its significant enough to warrant an official logo):

 

If a logo is made (by anyone) and adopted as the official logo for PsyDoom, then ill write that article for the Wiki. The way i do articles is to deliver them in one take, as complete as possible - A logo for a project of this magnitude is almost required, i'd say :)

 

Lets get this puppy on the road. PsyDoom needs more attention.

[taufan99]

Based on the Psy-Q logo from this website,

I made several mock-ups for the PsyDoom logo.

I would like to know which of these logos people prefer.

Spoiler

 

[Redneckerz]

1 hour ago, InDOOMnesia said:

Based on the Psy-Q logo from this website,

I made several mock-ups for the PsyDoom logo.

I would like to know which of these logos people prefer.

  Hide contents

 

I would go for the middle one but with the P in capital and with the Playstation buttons either to the side or inbetween Psy and Doom

 

These look great though, well done!

[seed]

I like the one with the controller buttons honestly.

[Gez]

I'd recommend against using the Doom logo wholesale. If I had some graphic talent, I'd do the other way around: PSY in Doom-like font, "doom" in Psy's font.

 

Mockup of what I mean:

 

Quickly done using the AmazDoomLeft and AmazDoomRight fonts (the S is made by a composite of both to get the prong in the center), plain old Arial, and a few GIMP layers.

 

I don't like the "PSY D" logo since the port's name isn't "PsyD".

[intacowetrust]

Thanks for all the cool mockups and suggestions everyone! Some of these concepts have given me a few ideas - I couldn't resist having a pop despite what I said earlier :P

Here's a very rough idea I came up with:

The colors here were inspired by the buttons on the PlayStation controller, and the font chosen for the 'Psy' portion (ZRNIC) somewhat resembles that of the original PlayStation 1 logo. The geometric shapes obviously are inspired by the controller buttons, though I've left out the cross symbol however for future uses. I'm thinking a future fork of PsyDoom might have the 'X' suffix added to it.

 

What do you think?

[Redneckerz]

40 minutes ago, intacowetrust said:

Thanks for all the cool mockups and suggestions everyone! Some of these concepts have given me a few ideas - I couldn't resist having a pop despite what I said earlier :P

Here's a very rough idea I came up with:

The colors here were inspired by the buttons on the PlayStation controller, and the font chosen for the 'Psy' portion (ZRNIC) somewhat resembles that of the original PlayStation 1 logo. The geometric shapes obviously are inspired by the controller buttons, though I've left out the cross symbol however for future uses. I'm thinking a future fork of PsyDoom might have the 'X' suffix added to it.

 

What do you think?

Cute. :)

[taufan99]

2 hours ago, intacowetrust said:

What do you think?

Nice-looking!

[seed]

I like it even more, but the presence of the Doom logo kinda worries me now that I think more about it.

 

Wouldn't that open a can of worms due to being a copyrighted logo?

[fenderc01]

On 3/26/2020 at 3:22 AM, intacowetrust said:

Thanks for all the cool mockups and suggestions everyone! Some of these concepts have given me a few ideas - I couldn't resist having a pop despite what I said earlier :P

Here's a very rough idea I came up with:

The colors here were inspired by the buttons on the PlayStation controller, and the font chosen for the 'Psy' portion (ZRNIC) somewhat resembles that of the original PlayStation 1 logo. The geometric shapes obviously are inspired by the controller buttons, though I've left out the cross symbol however for future uses. I'm thinking a future fork of PsyDoom might have the 'X' suffix added to it.

 

What do you think?

I like the logo. Maybe a little less pastel colored.

[Lollie]

I personally love the pastel-ish colors, they're pleasing to the eye. I'd argue that you could go even further by coloring the "Psy" part to fit in better with the rest of the logo.

 

My only concern is how well the logo elements can be "abbreviated" down into a square icon. I guess it'd just become "PD"?

[The Civ]

How would you feel about something along these lines for a smaller logo that could be used as a square icon?

If you dig the style, I could see what I could do for a larger-form logo of the full name too.

 

Edited March 30, 2020 by The Civ
Re-uploaded pic for small fix

[intacowetrust]

On 3/26/2020 at 3:54 AM, seed said:

I like it even more, but the presence of the Doom logo kinda worries me now that I think more about it.

 

Wouldn't that open a can of worms due to being a copyrighted logo?

 

It's a valid point and entirely possible. I mean it feels like fair (ish) use to me and in 'good faith' given that the project is a fan-made client for an already existing Doom game, and is open source and non commercial. Projects like this serve to promote and preserve interest in Doom games and the Doom universe, which is probably in Bethesda's interest. I'm pretty sure it wouldn't meet the legal definition of fair use though so such a logo could only exist provided Bethesda continued to allow it, and as long as it didn't cause confusion with the official Doom games. I've tried to differentiate the logo enough to make sure that is the case, and this is very much a niche project anyway but perhaps that is not enough... Worst case scenario, if I'm asked to change it then I will and something else can be used instead.

 

There is precedent for this sort of thing already also:

https://doomwiki.org/wiki/Brutal_Doom

 

And also Delphi Doom, which would probably have a similar scale (probably larger!) audience to what PsyDoom should eventually have:

https://sourceforge.net/projects/delphidoom/

 

On 3/28/2020 at 6:18 AM, Lollie said:

My only concern is how well the logo elements can be "abbreviated" down into a square icon. I guess it'd just become "PD"?

 

Yeah that's pretty much what I was thinking, or maybe PS and the 'D'? I can experiment with this in a while. Shortening might also help with the legal aspect, so the logo is more like that of say Chocolate Doom:

 

https://www.chocolate-doom.org/wiki/index.php/Downloads

 

18 hours ago, The Civ said:

How would you feel about something along these lines for a smaller logo that could be used as a square icon?

 If you dig the style, I could see what I could do for a larger-form logo of the full name too.

 

 

I do like your idea, it looks very interesting! :) Going back to the earlier points about legalities however I feel like this one might be flying a little closer (perhaps too close) to the sun given how similar it looks to the present day PlayStation logo (minus coloring). Whatever about using the Doom logo (or aspects of it) for a Doom fan project I think it might be a lot riskier incorporating the Sony logo. Cool idea though!

[lafoxxx]

Came up with an idea of "Simplified version" of the logo by @The Civ, to avoid potential copyright claims

 

Final version

The red triangle looks like 'play' sign, and the two bottom triangles make 'D' letter.

Edited April 4, 2020 by lafoxxx