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

27 minutes ago, Redneckerz said:

Doom equivalent of Blonde person here, but if a track does not loop like it should, could it be that there is an issue with the audio buffer that is either not working correctly in its native implementation, or still relies on emulated calls?

 

Just a pie in the sky comment, but whenever i hear about tracks that do not loop, i associate that with the audio buffer (especially on PSX).

 

If this is nothing, then i am a blonde, just so we are clear :)

As an actually NATURAL blond, I can say that it does this even on actual hardware, so if there is an issue, it's either because the tracks are set not to loop, or a bug is preventing them from looping. Would have nothing to do with emulation being wrong or PsyDoom getting it wrong.

20 minutes ago, Dark Pulse said:

As an actually NATURAL blond, I can say that it does this even on actual hardware, so if there is an issue, it's either because the tracks are set not to loop, or a bug is preventing them from looping. Would have nothing to do with emulation being wrong or PsyDoom getting it wrong.

Then perhaps its down to the individual model? I do not know which specific model PsyDoom emulates. I do know there were differences in CD-rom drive between the early units and the later units, but whether that has anything to do with this i cannot say for now.

21 minutes ago, Redneckerz said:

Then perhaps its down to the individual model? I do not know which specific model PsyDoom emulates. I do know there were differences in CD-rom drive between the early units and the later units, but whether that has anything to do with this i cannot say for now.

The CD Tray was redesigned because on the older model, the sleds that moved the laser assembly were closer to the power supply on the left side of the unit, and the sleds being plastic meant they eventually deformed due to heat plus wear (remember, no active cooling). Temporary fixes included putting the console on its side or even upside down, but eventually early PS1s became pretty unable to read CDs anymore.

The redesigned model shifted that to the opposite side (towards the right) and turned those sleds into metal rods. Many of them are still working great 20-25 years later.

The actual hardware, though, didn't change for these intents and purposes, so what model it emulates wouldn't matter in the end really.

33 minutes ago, Redneckerz said:

Then perhaps its down to the individual model? I do not know which specific model PsyDoom emulates. I do know there were differences in CD-rom drive between the early units and the later units, but whether that has anything to do with this i cannot say for now.

I've played PSX Final Doom on several different models (SPCH 7000, 9001, and PS one models), plus on a slim PS2 and PS3 and can confirm the music doesn't loop across all models. The sound mixing between music and SFX seemed slightly off to me when I played on PS3 as well compared to original PSX models, but I figured it was because of how the PS3 emulates the PSX hardware.

27 minutes ago, Dark Pulse said:

The CD Tray was redesigned because on the older model, the sleds that moved the laser assembly were closer to the power supply on the left side of the unit, and the sleds being plastic meant they eventually deformed due to heat plus wear (remember, no active cooling). Temporary fixes included putting the console on its side or even upside down, but eventually early PS1s became pretty unable to read CDs anymore.

 

The redesigned model shifted that to the opposite side (towards the right) and turned those sleds into metal rods. Many of them are still working great 20-25 years later.

 

The actual hardware, though, didn't change for these intents and purposes, so what model it emulates wouldn't matter in the end really.

See, that's what i had in my mind. So unlike the later PlayStation (Except for the PSOne, because VRAM at one point employed different memory) models, the sound system remains unchanged.

Thus the Blonde signs off :)

EDIT:

5 minutes ago, Mattfrie1 said:

I've played PSX Final Doom on several different models (SPCH 7000, 9001, and PS one models), plus on a slim PS2 and PS3 and can confirm the music doesn't loop across all models. The sound mixing between music and SFX seemed slightly off to me when I played on PS3 as well compared to original PSX models, but I figured it was because of how the PS3 emulates the PSX hardware.

Oh dear :{ Then there is more to it then i thought.

27 minutes ago, Redneckerz said:

Oh dear :{ Then there is more to it then i thought.

To be fair, PS3 emulation isn't perfect at all, since it depends on the model of the PS3.

Older PS3s had actual PS2 hardware inside them; that, in turn, meant that since some of the hardware components were also part of the PS1 (the controller ports on the PS2 actually were read by pretty much the same hardware that ran as the CPU on the PS1), those ones would, naturally, be more accurate for emulating a PS1 since they had actual hardware to call on.

Later PS3 models eventually stripped down the hardware compatability, first condensing it into a single chip, and then removing it altogether and going with software emulation. Each of these steps, naturally, decreased the emulation accuracy for PS2 games, but that also has a knock-on effect for PS1 emulation as a result.

Basically, older models (CECHA and CECHB) should be the most accurate due to having all PS2 hardware included, slightly later models (CECHC and CECHE) have partial hardware support, and anything later has no PS2 hardware support at all and is purely emulation-driven. Any slim or super-slim PS3 is guaranteed to have no hardware - all the models I mentioned are the older, fat PS3.

If you really want technical minutiae to look through, here you go: https://www.psdevwiki.com/ps3/SKU_Models

@intacowetrust, I come for thee yet again.

@Whiteysnakey pointed out on the GEC discord an old issue that definitely affects several maps (including Bloodsea Keep of my own, until I get around to fixing it) - when outside areas are rendered, any adjoining sectors with heights above that sky sector will have the ceiling "floating" in the air. Here's an example, though it might be hard to see due to color palettes:

Naturally, we can count on you to fix that as an option, yeah? And would it be possible to fix the PSX renderer to work around this issue? Would probably be the last remaining remnant of most of the height limit stuff once subdivision is in.

EDIT: While at it, found this little bug since apparently there's some modding work going on to make PSX Doom run on the GBA Doom engine:

Quote

There is a bug related to item collection, where if the player comes in contact with two or more items at once, neither item will be collected unless the player can pick up all such items. For instance, if a clip and a stimpack are directly adjacent, and if the player has 100% health, he will not be able to collect the clip, regardless of his bullet amount, since he is not allowed to collect the stimpack. This can generally be averted if the player can maneuver to a position where he is not touching multiple items at once, but may be impossible in tight spaces or if the items are very close. This bug was also present in the PlayStation version of Doom, and was inherited from the Atari Jaguar version.

Is this accounted for?

Hmmm... that's actually a little bit of a pickle, that one. You see the problem (or render quirk) you're describing which produces the issue you just posted and also this similar one:

Is also the same quirk that allows for these floating 'faux 3d' effects like this:

So if I fix the problem and make the sky ceiling occlusion behave in a similar way to the PC version, the floating cube is now no longer possible. Basically the walls behind and above the top edge would not be visible, similar to what happens in this screenshot from PC Doom (MAP19: The Citadel):

I think this needs a little more in-depth thought/exploration. If no reasonable solution (which works for both use cases) can be found I think my inclination is to leave this particular render quirk alone, since it allows for effects unique to the PSX version.

7 minutes ago, intacowetrust said:

I think this needs a little more in-depth thought/exploration. If no reasonable solution (which works for both use cases) can be found I think my inclination is to leave this particular render quirk alone, since it allows for effects unique to the PSX version.

If you don't find a way to make it work both ways, a possible compromise would be a new sector type that toggles the PC sky behavior; so it's up to the mapper to make the effect they want work without breaking the original behavior.

1 hour ago, Dark Pulse said:

Is this accounted for?

The item pickup bug is almost certainly still there, or at least if I've been doing a good job being accurate ;-) Do you have a good example of a place where it occurs in Doom or Final Doom? I could check very quickly.

21 minutes ago, Gez said:

If you don't find a way to make it work both ways, a possible compromise would be a new sector type that toggles the PC sky behavior; so it's up to the mapper to make the effect they want work without breaking the original behavior.

Yeah was thinking this might be one way around it. Marking the sky as being a 'blocking/occluding' sky via a special texture name (maybe with some sort of prefix like '#' etc.) might be better though since you may want to assign the sky sector a special itself and not have it consumed just for that purpose.

52 minutes ago, intacowetrust said:

I think this needs a little more in-depth thought/exploration. If no reasonable solution (which works for both use cases) can be found I think my inclination is to leave this particular render quirk alone, since it allows for effects unique to the PSX version.

Hmm really necessary? I like to do 3d effects like Doom64.

But in the work I did in DZDoom (Gzdoom GEC Master Edition), I did the opposite, I added a flag for the lines and sectors that is NO_RENDERSKYHACK, which is to eliminate those lines that render the sky and create that false 3D effect, maybe can something be done in PsxDoom but would be the opposite of what was mentioned above ?.

1 hour ago, intacowetrust said:

The item pickup bug is almost certainly still there, or at least if I've been doing a good job being accurate ;-) Do you have a good example of a place where it occurs in Doom or Final Doom? I could check very quickly.

AFAIK it's not in any of the stock maps, but a quick test map could be thought up - really just make two items nearly overlap to the point it'd be difficult, if not impossible, to pick both of them up when you're full on one of them. So for example, shotgun shell boxes and bullet clips.

Basically if the player is touching both at once, but is full on one of them, the game sounds like it never gets to processing checking for the second since it's breaking out due to the limit being hit on one item.

The way it's worded, if you can approach the other item in such a way that you can touch it WITHOUT colliding with the full item, though, you can pick it up.

Also, good point on the sky hack... that'll need some working-around for sure, then. Setting some kind of special marker or texture might be the way to go.

1 hour ago, Dark Pulse said:

AFAIK it's not in any of the stock maps

Underhalls would like a word with you. That little alleyway with the shotgunner, armor bonuses and medkit.
@intacowetrust go to this map.

8 hours ago, Erick194 said:

But in the work I did in DZDoom (Gzdoom GEC Master Edition), I did the opposite, I added a flag for the lines and sectors that is NO_RENDERSKYHACK, which is to eliminate those lines that render the sky and create that false 3D effect, maybe can something be done in PsxDoom but would be the opposite of what was mentioned above ?.

Yeah that's another possible approach - occluding skies by default like on PC. It might be more mapper friendly too because it 'just works' as you expect in most situations... There are a couple of instances like 'Ballistyx' that would need to be fixed up but maybe PsyDoom can patch certain maps from the original games so the few cases where we want the fake 3d effect work too.

What are your plans for this for the GEC Master Edition? It's probably best if PsyDoom does the same thing, so there is maximum compatibility.

7 hours ago, Dark Pulse said:

Basically if the player is touching both at once, but is full on one of them, the game sounds like it never gets to processing checking for the second since it's breaking out due to the limit being hit on one item.

Yep that's basically what happens. The game basically picks one nearby item when doing the pickup logic, and then checks that to see if it can be picked up. If it can't, well nothing else gets a look in basically. It could be fixed by making a list of things that can be picked up instead.

6 hours ago, Impboy4 said:

Underhalls would like a word with you. That little alleyway with the shotgunner, armor bonuses and medkit.
@intacowetrust go to this map.

Thanks for the example, I will check this one out.

14 hours ago, Dark Pulse said:

AFAIK it's not in any of the stock maps

There's also an area in House of Pain where this occurs too. The corridor with two side by side doors at the end of it in the blue key area has a lot of pickups clustered together behind the right side door.

I've also seen that same floating ceiling render quirk happen in PSX Hexen as well, so the problem still happens with higher ceiling limits.

@intacowetrust this is fantastic.  Amazing job!

Will you consider implementing shaders such as scanlines and bloom to simulate playing it on a CRT TV?

On 7/11/2020 at 6:59 AM, Mattfrie1 said:

I've also seen that same floating ceiling render quirk happen in PSX Hexen as well, so the problem still happens with higher ceiling limits.

Interesting! I wonder did PSX Hexen adopt a similar approach to rendering as Doom then, with leafs and simple back to front rendering etc.? Perhaps John Carmack's input/advice to Aaron Seeler for the PSX engine got passed along somehow? Or maybe they just arrived at the same conclusions independently...

On 7/12/2020 at 7:10 AM, ozy said:

Will you consider implementing shaders such as scanlines and bloom to simulate playing it on a CRT TV?

I hadn't considered it yet, but it's an interesting idea. Perhaps some day that might be a nice feature.

Just gave this a try, and I must say I sure like it.

I have two questions right now:

1.) Will d-pad controls be customizable in the near future? I'm having some problem with my W key on my keyboard, and would like to slightly rearrange it.

2.) The .lcd tracks play fine, but I hear no CD-DA tracks (such as in the start, menu, etc.). Have I done something wrong or is it normal?

Thanks @InDOOMnesia! Glad to hear you are enjoying it :)

4 hours ago, InDOOMnesia said:

Will d-pad controls be customizable in the near future?

They will be eventually. I'm planning to incorporate a similar configuration scheme to Phoenix Doom so you can remap keys etc. however you want.

4 hours ago, InDOOMnesia said:

The .lcd tracks play fine, but I hear no CD-DA tracks (such as in the start, menu, etc.). Have I done something wrong or is it normal?

It's probably because you have a .cue file with .bin files for the individual CD tracks. Unfortunately there's a known issue with this at the minute with Avocado; eventually I will fix or workaround this... See this post for more info:

Speaking of which, did you settle on how key remapping will be handled?

What disappointed me in Phoenix was that you had to configure them all via editing the configuration file. If an in-game menu is a no-go, I was thinking of maybe a mini setuo program a la Chocolate Doom/vanilla Doom.

I guess that once a config file is defined, someone else could contribute a setup tool, too.

Might be a better way to divide effort?

1 hour ago, seed said:

Speaking of which, did you settle on how key remapping will be handled?

  

What disappointed me in Phoenix was that you had to configure them all via editing the configuration file. If an in-game menu is a no-go, I was thinking of maybe a mini setuo program a la Chocolate Doom/vanilla Doom.

It'll be via the .ini files, which will be well documented and hopefully easy enough to understand - similar to Phoenix Doom and also to the approach used by Doom Retro. Cramming a ton of options to the in-game menu would be difficult to navigate at lower resolutions and probably more confusing than an external file. It's always possible an external configuration tool/launcher could be done at some point though.

24 minutes ago, wrkq said:

I guess that once a config file is defined, someone else could contribute a setup tool, too.

Might be a better way to divide effort?

Indeed! The fields in the configs will be changing/volatile for the next while but once that settles down then anyone is more than welcome to give this a go. The challenge also will be making such a thing work on Windows, MacOS and Linux - maybe some sort of simple cross compiling QT based application, or WxWidgets etc.?

Considering it's 2020, both in the "year of troubles" sense and the "look at the insane direction modern tech industry took" sense...

/inb4 someone suggests making it an Electron-based javascript monstrosity.

Because of course bundling 100+MB of Chrome engine is fine for a Doom frontend...

(I wonder how good or horrible are QT bindings for "easier" languages than C++...?)

On 7/21/2020 at 6:42 PM, wrkq said:

Considering it's 2020, both in the "year of troubles" sense and the "look at the insane direction modern tech industry took" sense...

Yeah, it's been quite the year.

Hate to bump but I'm giving this a whirl in trying to test this Wine in Manjaro Linux. I always get an error about "Doom.cue" not being found. I made sure it was the SLUS-00077 version of the game which I believe to be the Greatest Hits NTSC version. I will try this in whatever VMs I can, when I tried VirtualBox it gave me an error about a "renderer" or something so I'm gonna try other VM software and I'll edit my post based upon how it goes.

17 hours ago, Gregory Stephens said:

Hate to bump but I'm giving this a whirl in trying to test this Wine in Manjaro Linux. I always get an error about "Doom.cue" not being found. I made sure it was the SLUS-00077 version of the game which I believe to be the Greatest Hits NTSC version.

Hi @Gregory Stephens thanks for checking out the project. For 0.4.0 and earlier builds PsyDoom looks for "Doom.cue" in the current working directory, which should be the same directory that your .exe is in unless you launched via the command line from some other folder. The easiest way to give PsyDoom what it needs is to simply copy your .cue/.bin files to whatever folder PsyDoom is in and rename the .cue to 'Doom.cue' - that should fix any problems.

17 hours ago, Gregory Stephens said:

I will try this in whatever VMs I can, when I tried VirtualBox it gave me an error about a "renderer" or something so I'm gonna try other VM software and I'll edit my post based upon how it goes.

Interesting, I have not tested it in a VM or via Wine but from your description it sounds like the game is having trouble creating the OpenGL window it needs. I'm not sure what the fix would be for this under a VM but it's probably something to do with hardware acceleration support or drivers. Eventually there should be native Linux build of PsyDoom so you won't need to resort to workarounds on that OS.

Did the super shotgun have a massive delay on the psx too? cant remember. feels like playing with ping 200

59 minutes ago, mankubus said:

Did the super shotgun have a massive delay on the psx too? cant remember. feels like playing with ping 200

PsyDoom is based off PSXDoom-RE, which is a reverse-engineering of PSX Doom's code, so it should be accurate to the PSX version's behavior.

59 minutes ago, Dark Pulse said:

PsyDoom is based off PSXDoom-RE

That's not quite true, PsyDoom began independently using the original MIPS executable & machine code as its starting point (converted to C++) and using the Avocado emulator to handle system specific stuff like the BIOS, SPU & GPU. A little while later Erick released the source code of his reverse engineering efforts with PSXDOOM-RE and this was used to help speed up the conversion to C++ and to cross verify both projects.

Although I referenced Erick's work extensively and it was invaluable source of information to help accelerate my work, at no point was code just carried over verbatim to PsyDoom. Even if I had copied code directly it wouldn't have helped with Sony's PsyQ libraries, which had to be partially reversed and re-implemented for the game to work correctly on PC. My approach with PSXDOOM-RE has been to "trust, but verify" and I actually did point out a few things to Erick along the way that were fed back into PSXDOOM-RE. So in effect part of the work for PsyDoom has to been to peer review Erick's work in RE; I wanted to make sure I could lend an extra pair of eyeballs to help verify/QA that project as it is invaluable to have an accurate recreation of PSX Doom that targets the original hardware and toolchains.

1 hour ago, Dark Pulse said:

so it should be accurate to the PSX version's behavior.

I'm hoping that should be the case! I've now verified PsyDoom's behavior with demos of 4 complete playthroughs recorded against the original games: Doom and Final Doom in both their PAL & NTSC variants: https://github.com/BodbDearg/PsyDoom/tree/master/psxdoom_demos

Demo files in PSX Doom are basically just inputs for every tick, and if the game code does not work in exactly the same way then they very quickly go off the rails. To give you an example a while back I fixed a slight difference in the weapon bobbing for the PAL version of the game (specifically) that caused some demos to de-sync. Where you are in the bobbing phase affects when you can next switch weapons, and that can quickly cause a de-sync if not 100% correct. That's just one example of a minor difference that can cause a demo to go off the rails if not handled correctly.

@intacowetrust  is right, his project (PsyDoom) and mine (PsxDoom-RE) are completely separate, I was really surprised by the work he started with (PsyDoom), and I had not announced anything about a possible release of the rebuilt code for PsxDoom, the only one who knew about my work before it went public was Kaiser when I started a conversation with him on Discord in September 2019 and the first thing I showed him was the rebuilt WESS audio system, really the project of PsyDoom and PsxDoom-RE have been of great help to understand the PlayStation machine, a formidable job in both cases.