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

[intacowetrust]

Update - latest Release (0.8.3 - October 16th, 2021):

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

 

Most recently recorded video of the project:

 

Feature changes & improvements (0.8.0)

• Expanded the available VRAM for the game from 1 MiB to a maximum of 128 MiB (the default).
• Greatly expanded the amount of main RAM available to the engine; it's now 64 MiB by default (up from around 1.3 MiB).
  • This can also be increased further via config settings, if needed.
• Added support for any power of two texture size for walls and flats from 2x2 up to a maximum of 1024x512.
  • Previously only wall textures with pixel widths 16, 64 and 128 were possible.
  • Previously only 64x64 pixel flats were allowed.
• Classic renderer: now allowing up to 8192 sprites (instead of 64) to be drawn per subsector.
• Removed all limits on:
  • The maximum map lump size (was 64 KiB).
  • The maximum number of flats in a map (was 16).
  • Classic renderer: the number of draw subsectors (was 192).
  • Classic renderer: the amount of geometry that can be clipped (was 20 edges and 32 vertices max).
  • The number of scrollable lines (was 32).
  • The number of moving floors (was 30).
  • The number of moving ceilings (was 30).
  • The number of specials that can be triggered in one frame by crossing lines (was 8).
  • The number of switches that can be activated at once (was 16).
  • The maximum size of the music sequencer's .WMD file (was around 70 KiB in previous builds).
• Implemented Doom 64 style dual colored lighting.
  • Due to the need for binary map format compatibility, the feature is slightly more limited than D64.
  • However it does have additional tweaks & controls available that aren't found in the D64 engine.
• Implemented the ability to have floor skies.
• Implemented a new 'invisible/ghost' platform flag for sectors.
  • This makes the sector render as if it's floor height is the same as the lowest sector floor height around it.
  • Can be used to make invisible platforms, like the 'self-referencing sector' technique for the PC engine.
• Implemented support for a new 'MAPINFO' lump to allow user maps and episodes to be named etc.
  • See PsyDoom's modding docs for more details.
• Implemented the ability to add custom animated textures and flats via the 'PSYFANIM' and 'PSYTANIM' lumps.
• Added the ability to define new switch types via the 'PSYSWTEX' lump.
• Implemented a simple 'DECORATE' style lump for adding new (non-interactive) decor sprites.
• Implemented the ability to use Lua for scripted line and sector specials.
  • Scripts allow more control over specials and for elaborate sequences of events to be scheduled.
  • See PsyDoom's modding docs for more details.
• Implemented the ability to adjust floor and ceiling texture offsets via scripting.
  • Can be used to do scrolling effects.
• Reimplemented the following missing enemies/things from PC Doom II:
  • Arch-vile (now DoomEd number '91' for PSX).
  • Wolf-SS.
  • Commander Keen.
  • All 'Icon Of Sin' related things.
• Reimplemented the following missing line specials from PC:
  • 131 & 132: 'raise floor turbo' switch, once and repeatable.
  • 130 & 129: 'raise floor turbo' line cross trigger, once and repeatable.
  • 128: repeatable 'raise floor to nearest' line cross trigger.
• Reimplemented the following sector specials missing from PC:
  • 11: E1M8 style 'death' exit
• Made the 'Texture Cache Overflow' error a non-fatal warning.
  • Graphical corruption may still happen when this situation arises, but using a warning allows the game to recover.
• Implemented an optional on-screen stat counter that can show kills, secrets and item stats.
  • This can be toggled in the 'Extra Options' menu.
• Added logic to de-duplicate and merge identical sounds played at the exact same time to keep audio levels under control.
• Removed the use of the 'TEXTURE1' and 'SPRITE1' lumps by the engine.
  • This makes adding new textures and sprites much easier.
  • Instead use the size and offset info in the texture header.
• Now generating the list of sprites in the game based on main WAD contents rather than hardcoding.
  • Allows new lumps to be added to main game IWADS without breaking the lump numbers in the sprite list.
  • Also allows new sprites to be more easily defined.
• Lua: add the ability to have an external camera viewing something for a brief period.
  • Useful for showing the result of using a switch etc.
• Define new hint flags to specify whether a sky wall should be drawn above a 2-sided linedef.
  • Allows the mapper to control the behavior and fix certain problem cases if required.
• Vulkan renderer: allow lower and upper walls to extend past sector floors and ceilings.
  • Allows certain special effects to be achieved when used in conjunction with sky floors or ceilings.
    • In order to support this change renderer batching must be broken in some (rare) situations.
  • This change also makes the renderer behavior/results more consistent with the classic renderer.
• Added PsyDoom specific generic marker things, intended for use in scripting.
• Overhauled WAD management to allow for more than one main IWAD.
  • PsyDoom will now load 'PSXDOOM_EXT.WAD' and 'PSX_MISSING_ENEMIES.WAD' from the mod directory specified via the '-datadir <MY_DIRECTORY_PATH>' command line argument.
  • The user can also manually add extra IWADs via the '-file <WAD_FILE_PATH>' program argument.
  • For more on all this, see PsyDoom's modding documentation.
• Limit removing: allow sprites with odd widths to be used (normally these would display corrupt).
• Level loading: now handling missing textures more gracefully.
  • Missing textures are replaced with a default and a warning is issued after level startup.
• Tweaked audio compression further to reduce the amount of compression.
  • Should now only activate when sounds get really loud.
• Vulkan renderer: add a (default enabled) tweak that brightens automap lines to compensate for them appearing perceptually darker, due to their thinness at high resolutions.
  • This tweak is required due to a correction made to the automap line colors for both renderers.
  • Previously they were over bright for both renderers due to a bug, so dimness not an issue.
• File overrides mechanism: make file name matching case insensitive.
• Add a developer cheat to automatically re-load a map 'in-place' when it has changed.
  • This reloads the map but preserves player position and view angle. Useful for quickly previewing changes.

 

Feature changes & improvements (0.8.1)

• Implement the option to extend the player shoot range (on by default).
  • If enabled, extends the following player attack limits:
    • Max shoot/hitscan distance, from '2048' to '8192'.
    • Max auto-aim distance, from '1024' to '8192'.
    • Max BFG spray/tracer distance, from '1024' to '2048'.
• Robustness: gracefully handle orphaned lines with no sectors in the map data instead of crashing.
• MAPINFO: add the ability to disable multiplayer for a user mod.
  • May be required if the mod uses tricks that are incompatible with a multiplayer environment.
• Improve the behavior of the Final Doom 'no repeat' mid wall flag.
  • Instead of forcing the mid wall to be 128 units in height the flag now forces the wall height to be the same height as the texture.
  • This allows fence textures smaller than 128 pixels in height to be used.
  • The change doesn't affect original maps, but will be useful for modding.
• Implement sector special '32' (strobe hurt) which behaves the same as special '4' on PC.
  • The PSX version of special '4' is missing the strobe, and this behavior must be preserved for map compatibility reasons.
  • For a PC style 'strobe hurt' special '32' can now be used, if desired.
• Sector special 11 (Damage 10/20% and End level): don't play the player's death sound (silent death).
  • This makes the behavior more like PC.

 

Bug fixes (0.8.0)

• Fix a bug where sometimes sound would not work on startup.
• Original bug: fix bullet puffs not appearing sometimes when shooting certain walls outdoors.
• Original bug: LCD Loader: fix a bug that could sometimes cause sounds to be cut short.
  • This bug can be observed on Final Doom MAP28 (Baron's Lair) with the Revenant's pain sound being cut short.
• Automap: fix some colors being slightly incorrect versus how they appear in the original PSX game.
• Windows: fix the game (unintentionally) running at lower resolutions when the Windows display scale is not at 100% (thanks @aybe!)
• Original bug: fix the 'House Of Pain' hidden door bug by applying a map patch.
• Fix music in Doom MAP04 having notes that are slightly off; fix a slight difference in pitch calculations versus the original game.
• Fix lights in a room not going fully out in Final Doom MAP08, Minos, after collecting the Super Shotgun.
• Final Doom MAP23 (Ballistyx): fix the altar ceiling hole not being see through and fix some outer walls dissapeering in the yellow key cage area.
• MAP47 The Citadel: fix not being able to see over the small starting hut even though it is lower than other buildings.
• Original bug: fix numeric overflows in the line-of-sight calculations that would sometimes cause enemies to not see the player.
  • These overflows occurred when sector floor and ceiling heights differed greatly.
• Fix a strange sound playing when returning from the finale to the main menu.
• Fix the item bounding box display in the VRAM viewer.
• Fix view height interpolation being broken when a platform underneath the player is moving but the player is not touching it.
• Fix the engine crashing without explanation if certain required/non-optional textures are not found.
  • Instead issue an error explaining what is wrong.
• Tweak the rocket blast fix to the correct forces applied in some situations and to try and ensure the explosion is always rendered.
• Original bug: fix certain 'raise platform' actions not fully finishing when the target floor height was reached.
  • This bug would prevent further specials from being executed on sectors, because movers were still regarded as 'active'.
• Classic renderer: fix invalid handling of textures that are uncompressed for wall segment rendering (resulted in crashes).
• Classic renderer: fix numerical overflows in sky wall rendering in some cases when really close to sky walls that are very high overhead.
• Classic renderer: fix numeric overflows in extremely tall maps with far offscreen walls.
• Vulkan renderer: fix flickering when sprites are placed at exactly the same location.
• Vulkan renderer: fix a slight error in setting up texture wrapping for the sky (could affect custom skies).
• Final Doom: fix the revenant missile fire sound sometimes playing upon reaching the MAP30 finale.
• Audio tools fixes and error handling tweaks:
  • LcdTool: show more info when there is a sample size mismatch with the WMD when building the LCD file.
  • Fix the handling of implicit blocks in the VAG file. Need to be aware of the file size and zero any blocks that are not in the file.

 

Bug fixes (0.8.1)

• Classic renderer: fix tall sprites like tech pillars sometimes vanishing up close.
  • These pillars can be found in 'MAP01: Attack' of Final Doom.
• Doom MAP04 (Command Control): fix some steps appearing black.
• Doom MAP22 (Limbo): fix a step/lower-wall not rendering.
• Fix flats and textures in PSXDOOM_EXT.WAD not overriding those in PSXDOOM.WAD.
• Fix an original bug where sometimes sound propagates through closed doors that should block it.
  • This bug can be observed with the small window into the secret room, in MAP03 of Doom.
  • It allows sound to pass through it even though it is closed.
• Fix an original bug where the 'lower and change texture' special doesn't work sometimes.
  • The bug can happen if the sector being lowered is surrounded by another sector that isn't at the destination height.
  • Without this fix a series of lowering floor segments like E3M1 in PC Doom will not work.
• Final Doom: fix incorrect default palette selection for SKY02-SKY06 if a user map with the .WAD extension is loaded.
  • Palette selection logic was incorrectly using DOOM palette selection logic instead of Final DOOM logic.
  • The fix makes the palette selection method vary depending on the base game loaded rather than the map file extension.
• Fix being able to use again scripted 'once only' switches.
• Fix overflows in shooting logic near the minimum & maximum possible map coordinates.
  • Helps prevent strange behavior for larger maps that have areas close to these coordinates.

 

Bug fixes (0.8.2)

• Arch-vile: fix resurrected monsters not having their blending mode preserved.
• Classic renderer: fix occasional numerical overflow when using dual colored lighting.
  • The bug would result in strange wall colors in some situations.
• Cheats: add a message for when the 'X-Ray Vision' cheat is enabled and disabled.
  • Helps explain what is happening to avoid confusion.    
• MAPINFO: fix the 'multiplayer disabled' sound unintentionally playing when moving up and down the main menu.
  • The sound should only play when the user attempts to switch to multiplayer.

 

Bug fixes (0.8.3)

• Fix a crash when activating god mode after death, deactivating and then firing.
• Fix original demos potentially de-syncing if MAPINFO specifies Doom vs Final Doom game rules.
• Big font: fix the uppercase letter 'C' being slightly cut off.
• MAPINFO: fix a bug where setting the 'Text' field in 'Cluster' would not clear unused lines.
  • The bug would result in unwanted text from the base game's finale displaying - now fixed.

 

---------------------------------------------------------------------------------

 

Original Post:

Hey everyone,

 

Just a quick post to let you all know about a project that I'm busy working on - a reverse engineered source port of PlayStation DOOM for PC. The project is currently at a very early stage and there is a *HUGE* amount of work to be done before my objectives are met, however as of right now the game is pretty much up and running. 

 

Check out this brief video demonstration:

 

This gives a nice platform for experimenting with the game and gradually converting over source code, piece by piece. Eventually my goal is to convert all of the game code over to easily readable/changeable C++, from it's current assembly-like form, and remove PSX bios and .exe dependencies etc.

 

In the spirit of openness and knowledge sharing (and also as a contingency, in case I get hit by a bus :P) I've also made the github repo public if you want to poke around and experiment:

https://github.com/BodbDearg/PsyDoom

 

As of right now I'm not doing any pre-made builds because this is at such an early stage and far from ready. If anyone is desperate to try though, let me know and I can put a build up on github - it's kind of a pain in the ass to run at the minute and not configurable at all.

 

Happy to answer any questions you might have about this, I can update this post also as new progress/developments are made.

Thanks!

Edited October 17, 2021 by intacowetrust

[intacowetrust]

@Erick194 if you are reading this and want to collaborate on some of this reverse engineering stuff, let me know! As I understand it you've already done quite a bit of work on the PSX code and your objectives are similar (though you are targeting the original hardware), so perhaps we can help each other out. I would be very interested to know what you have deciphered so far! :)

[Redneckerz]

This is amazing on two levels:

• 1: You attempt a port of the PSX stuff to PC.
• 2: Recently i have been discussing with a few PSXDoom prominents how to name their GZDoom port properly.

So in that case, i am going to tag

@Gerardo194,

@Dark Pulse.

 

EDIT: Well you tagged Erick already :P

[Gez]

If we're tagging people, @Kaiser and @Quasar should be there too.

[Redneckerz]

15 minutes ago, Gez said:

If we're tagging people, @Kaiser and @Quasar should be there too.

Obviously you know this, but for everyone else:

• Prior work by the OP includes Phoenix Doom, a source port of the 3DO codebase to PC and extended. Whereas most ports use Linux Doom as a base, OP used 3DO Doom and then extended it for the PC. Impressive stuff indeed. 

[seed]

Holy shit man, this is SO AWESOME <3 .

 

It looks like solid progress has been made so far, after all there's even modding possibilities in place (more or less proof-of-concept at the moment, but it works). It also seems to be running pretty well.

 

Which is what I was about to get to: I hope performance at high resolutions will be good, as well as mouse support be at least on par with PD. I seem to recall reading that PD did not run very well at high resolutions and the performance issues were more apparent there. I ran it in 320x200 so it wasn't a problem, but still.

 

Also, apart from the wrong speed, do demos stay in sync til the end at the moment, or do they desync? What are your objectives by the way? Is it aiming for accuracy + lots of quality-of-life improvements (a la PrBoom, for example), or is it going to be more like a remaster, similar to how PD was, with tons of bugs fixed (which would make demo compatibility impossible)?

 

Overall, I am SO looking forward to playing this. I noticed music playback is wrong in some parts - the end level music sounded pretty different from how it should have at the end of E1M1.

Edited December 29, 2019 by seed

[Quasar]

A lot of the game sim code will be virtually identical to Jag Doom so be sure to check out Calico, or the vanilla Jag source. Should help enormously to verify your results when transforming it to structured programming. There are also some things shared with Doom 64 so that might also be likewise useful.

[Redneckerz]

I take it the name StationDoom is a placeholder? Because Phoenix Doom sounded awesome, but StationDoom, whilst a good reference, does sound a bit generic in my ears.

 

Something like Eclipse Doom sounds cool.

 

Also, during searching, i came across a recently released homebrew Doom title for PSX for which i have made a seperate thread: Doom 2D for PSX

[seed]

1 hour ago, Quasar said:

Calico

 

Speaking of which, any progress on mouse support :) ?

[Gerardo194]

@intacowetrust I'm interested in this project.

[Erick194]

@intacowetrust 

Hello, first of all, good job with rendering and I viewed your code from github and I see that much of it is in MIPS code.
I am really interested, I wanted to compile it but it fail, it must be that I use VS2015.

 

I currently have the complete code in C, and I am recompiling it for psyq I am still on my way to finish and it is really interesting to fuction the codes.

 

Everything that has to do with the Williams Entertainment Sound System (WESS) is complete and works 100% in recompiled psx.

 

Here is an example of compilation for PSXDoom with rotating enemies.

 

 

@Redneckerz

By the way for the Gzdoom [GEC] ME, it will change its name which will be Dzdoom (DarkZdoom).

Edited December 29, 2019 by Erick194

[Redneckerz]

1 hour ago, Erick194 said:

 

@Redneckerz

By the way for the Gzdoom [GEC] ME, it will change its name which will be Dzdoom (DarkZdoom). 

DZDoom is a perfect name and would well with the QZ/GZ/LZ naming scheme that is currently at the ZDoom page.

[intacowetrust]

10 hours ago, seed said:

Which is what I was about to get to: I hope performance at high resolutions will be good, as well as mouse support be at least on par with PD. I seem to recall reading that PD did not run very well at high resolutions and the performance issues were more apparent there. I ran it in 320x200 so it wasn't a problem, but still.

 

Yeah Phoenix Doom is using a software renderer at the minute, which means performance at higher resolutions can be an issue. I might revisit that decision at some point in the future, and and re-implement with Vulkan or OpenGL.

 

For this project though I'll probably keep it at the original resolution and do higher resolution support via a fork/offshoot project instead; so something like Chocolate vs Crispy Doom basically... I figure since we don't have the original source at hand there's value in maintaining a codebase that is as 'vanilla' as possible for historical reference and also to serve as a starting point for new modifications. Plus higher resolution support might not look great without rewriting a lot of the way the renderer works due to the 'shakiness' of the PSX renderer and some of the imprecision involved - that stuff would really get exposed at higher resolution.

 

Quote

Also, apart from the wrong speed, do demos stay in sync til the end at the moment, or do they desync?

 

Playback speed aside, both demos included with the game play correctly at the moment and the aim is to keep it that way. I wish there were more of them to be honest because they are quite valuable tools for verifying work!

 

Quote

What are your objectives by the way? Is it aiming for accuracy + lots of quality-of-life improvements (a la PrBoom, for example), or is it going to be more like a remaster, similar to how PD was, with tons of bugs fixed (which would make demo compatibility impossible)?

 

Primarily to reverse and convert the game code entirely to C++, remove dependencies on the PSX bios and the original .EXE, and where possible to strip away and simplify as many of the layers of emulation as possible. At the minute I use the 'Avocado' emulator to handle emulation of the PSX GPU, SPU, as well as some bios calls.

 

I'm aiming for this project to be a 'Chocolate Doom' for PSX DOOM basically, which will serve for as a basis for more advanced ports later. I'm considering doing limit removal stuff in this port however (so we can do stuff like PSX SIGIL), but if the changes for that are too big then perhaps we'd be better off doing that in a fork instead. Still TBD on that one.

 

As far as bugs go, I'm aiming to leave most of them in except for bugs that would cause undefined behavior and/or crashes. Those bugs are not of much value and will only cause annoyance on a modern operating system (which has less tolerance for such things) so I will probably be fixing things like the lost soul out of bounds issue mentioned in this thread: 

 

 

Quote

 I noticed music playback is wrong in some parts - the end level music sounded pretty different from how it should have at the end of E1M1.

 

Yeah there's issues with sound emulation sometimes being advanced too much at the moment. I'm in this tricky spot where I have to advance the emulation sometimes in order for certain hardware events to occur that native C++ code is waiting on (which would be stuck forever otherwise), so sometimes the sound does get out of whack in places. Eventually this issue should be resolved once dependencies on the PSX hardware (via emulation) are removed and the rate of sound advancement is tied to actual real time much more closely. That will be a bit down the road however...

 

 

[Job]

[intacowetrust]

9 hours ago, Quasar said:

A lot of the game sim code will be virtually identical to Jag Doom so be sure to check out Calico, or the vanilla Jag source. Should help enormously to verify your results when transforming it to structured programming. There are also some things shared with Doom 64 so that might also be likewise useful.

 

Indeed, you are very much correct. From what I've seen so far while studying the disassembly and cross referencing with other DOOM sources, it definitely bears the closest resemblance to Jag Doom. Having that said however, there are places where DOOM II stuff has been pulled in (for obvious reasons) or where PSX DOOM just does its own unique thing.

 

Excellent point on checking out Doom 64 though! I've been mostly focusing on studying the ancestors of PSX DOOM but had not considered studying it's descendants also. Perhaps Doom64 EX might yield some important clues about certain systems...

[intacowetrust]

9 hours ago, Redneckerz said:

I take it the name StationDoom is a placeholder? Because Phoenix Doom sounded awesome, but StationDoom, whilst a good reference, does sound a bit generic in my ears. Something like Eclipse Doom sounds cool.

 

Yeah the name is by no means final - if anyone has any better ideas then I'm definitely open to suggestions! That goes for logo ideas too... (Phoenix DOOM needs a logo too). I was basically trying to think of a name that conveyed that it is a port of PlayStation Doom, but without invoking the word 'PlayStation' or any other trademarked stuff that might cause possible issues - hence the 'Station' abbreviation.

 

Quote

Also, during searching, i came across a recently released homebrew Doom title for PSX for which i have made a seperate thread: Doom 2D for PSX

 

Interesting find, I was not aware of this! :)

[intacowetrust]

On 12/29/2019 at 11:56 AM, Erick194 said:

@intacowetrust 

Hello, first of all, good job with rendering and I viewed your code from github and I see that much of it is in MIPS code.

 

Thanks @Erick194! You are quite right, there is much work to be done on this project to produce code that is more than just assembly-like C++. What you see so far is mostly derived from the original machine code... So far I have only converted over only a very small portion of the game and mostly focused on setup/loading related code. That being said however the entire program structure (in terms of functions) is already there as well as some helpful auto-generated comments documenting where loads and stores are going to. The entire conversion process will take a lot of time and effort but I'm confident that it can be done eventually given enough persistence.

 

The hardest part was getting to this point and TBH I wasn't entirely sure if the strange mix of running most of the code natively and jumping into the emulator whenever something hardware specific was required would work. Somehow it all does however, occasional sound sync issues aside... I was partially inspired by this project to take that approach:

https://github.com/ughman/c2c

 

The nice thing about this setup as well is that it is very easy to do a small bit of reversing, test how it works with all of the existing code and then move on. If need be I can also run the original function through the emulator if there is a problem, to compare behavior. This can be quite a useful tool indeed!

 

Quote

I am really interested, I wanted to compile it but it fail, it must be that I use VS2015.

 

Yeah sorry, there might be occasional use of C++ 17 features in there that would require at least VS2017. Not that I intend to do object oriented DOOM or anything but some of the quality of life things in C++ 17 can be useful. I have also tested against Xcode 11 if you have that either... XC 10 might work too.

 

Quote

I currently have the complete code in C, and I am recompiling it for psyq I am still on my way to finish and it is really interesting to fuction the codes.

 

Yeah it's strangely alluring, gradually uncovering some of the mysteries inside of this game... For example I was puzzled for a long time why there two 'malloc' functions until I reversed the extra one and discovered that it was trying to allocate at the end of the heap rather than the start. I don't recall seeing this in other versions of DOOM. See the function I'm calling 'Z_EndMalloc' for that particular code:
https://github.com/BodbDearg/PsyDoom/blob/master/game/Doom/Base/z_zone.cpp

 

Quote

Everything that has to do with the Williams Entertainment Sound System (WESS) is complete and works 100% in recompiled psx.

 

Here is an example of compilation for PSXDoom with rotating enemies.

 

That's awesome man, nice work! :) Definitely cool to see it running in the original environment too. If you'd like to contribute to this project as well, I'd definitely be interested in seeing some of that deciphered WESS code and incorporating your findings. That might free me up to look at other stuff which hopefully might be of use to your own project.

Edited January 25, 2020 by intacowetrust : Github URL change

[Erick194]

1 hour ago, intacowetrust said:

Yeah sorry, there might be occasional use of C++ 17 features in there that would require at least VS2017. Not that I intend to do object oriented DOOM or anything but some of the quality of life things in C++ 17 can be useful. I have also tested against Xcode 11 if you have that either... XC 10 might work too.

I will have to try that Xcode 11. From what I see I can't, it's for mac :P

 

1 hour ago, intacowetrust said:

Yeah it's strangely alluring, gradually uncovering some of the mysteries inside of this game... For example I was puzzled for a long time why there two 'malloc' functions until I reversed the extra one and discovered that it was trying to allocate at the end of the heap rather than the start. I don't recall seeing this in other versions of DOOM. See the function I'm calling 'Z_EndMalloc' for that particular code:

It is correct both PsxDoom and Doom64 have that function, but it is called Z_Alloc, here the decompilation of z_zone of both games.

 

PSXDOOM z_zone.c

DOOM64 z_zone.c

Edited December 30, 2019 by Erick194

[seed]

8 hours ago, intacowetrust said:

Yeah Phoenix Doom is using a software renderer at the minute, which means performance at higher resolutions can be an issue. I might revisit that decision at some point in the future, and and re-implement with Vulkan or OpenGL.

 

NOICE, it would be an absolute blast to have such renderers in place, although I seem to recall the reason why PD runs worse at higher resolutions was due to some fancy feature that was added I think that was added, which wasn't an issue at lower res but became one once it was cranked up.

 

So there's not going to be much else apart from QOL improvements, that's fine. I agree that initially it would be best to have the whole game reverse-engineered, the code cleaned up, and in C++ since there original code was never released. This will probably make it easier for forking as there won't be any worries about removing unwanted features, and also perfect for historicity and preservation, making sure it never gets lost again.

 

8 hours ago, intacowetrust said:

Playback speed aside, both demos included with the game play correctly at the moment and the aim is to keep it that way. I wish there were more of them to be honest because they are quite valuable tools for verifying work!

 

Yea, shame there's only 2-3 internal demos, but hey, that's better than nothing, at least those can be used for reference in the beginning, and later on, when the game stabilizes we could start making demos and playing them back on the real hardware to see if they desync. That is, unless I'm dreaming - is it even possible to do this?

 

8 hours ago, intacowetrust said:

As far as bugs go, I'm aiming to leave most of them in except for bugs that would cause undefined behavior and/or crashes. Those bugs are not of much value and will only cause annoyance on a modern operating system (which has less tolerance for such things) so I will probably be fixing things like the lost soul out of bounds issue mentioned in this thread

 

Falls under QOL improvements, which is a good thing, no one wants crashes and bugs :) .

 

7 hours ago, intacowetrust said:

That goes for logo ideas too... (Phoenix DOOM needs a logo too).

 

That would be neat, pretty ugly to have default exe icons on the desktop (well at least they're not as ugly as they are in older versions of Windows :p ).

[Gez]

9 hours ago, intacowetrust said:

Primarily to reverse and convert the game code entirely to C++, remove dependencies on the PSX bios and the original .EXE, and where possible to strip away and simplify as many of the layers of emulation as possible. At the minute I use the 'Avocado' emulator to handle emulation of the PSX GPU, SPU, as well as some bios calls. 

Ideally, everything could be turned into portable code with no need for integrating an emulator anymore.

 

8 hours ago, intacowetrust said:

Yeah the name is by no means final - if anyone has any better ideas then I'm definitely open to suggestions! That goes for logo ideas too... (Phoenix DOOM needs a logo too). I was basically trying to think of a name that conveyed that it is a port of PlayStation Doom, but without invoking the word 'PlayStation' or any other trademarked stuff that might cause possible issues - hence the 'Station' abbreviation. 

I think "Station Doom" is perfectly cromulent. I could suggest something like Psych Doom (PSX -> Psych). Or "Loco Doom" since this port allows the game to leave the station. Or, same idea, "Dynamite Doom", since station is static, and the opposite of static is dynamic.

[Gerardo194]

On 12/29/2019 at 11:44 AM, Redneckerz said:

 

Also, during searching, i came across a recently released homebrew Doom title for PSX for which i have made a seperate thread: Doom 2D for PSX

 

15 hours ago, intacowetrust said:

Interesting find, I was not aware of this! :)

Me neither, I think it looks interesting!!

[Redneckerz]

18 hours ago, intacowetrust said:

 

Yeah the name is by no means final - if anyone has any better ideas then I'm definitely open to suggestions! That goes for logo ideas too... (Phoenix DOOM needs a logo too). I was basically trying to think of a name that conveyed that it is a port of PlayStation Doom, but without invoking the word 'PlayStation' or any other trademarked stuff that might cause possible issues - hence the 'Station' abbreviation.

 

 

Interesting find, I was not aware of this! :)

What do you think of the names put forward so far?

2 hours ago, Gerardo194 said:

 

Me neither, I think it looks interesting!!

Its not ultra polished, but hey, its a Doom platformer on PSX.

[intacowetrust]

16 hours ago, Erick194 said:

It is correct both PsxDoom and Doom64 have that function, but it is called Z_Alloc, here the decompilation of z_zone of both games.

 

PSXDOOM z_zone.c

DOOM64 z_zone.c

 

Interesting, thanks for sharing!

 

12 hours ago, seed said:

 

Yea, shame there's only 2-3 internal demos, but hey, that's better than nothing, at least those can be used for reference in the beginning, and later on, when the game stabilizes we could start making demos and playing them back on the real hardware to see if they desync. That is, unless I'm dreaming - is it even possible to do this?

 

That's actually a really neat idea - I might end up doing that! (though perhaps in reverse, playing back real demos in the new build and verifying that way)

 

I've definitely seen code in there relating to demo recording and storing inputs in a 16 KiB demo buffer so it seems doable. It might be difficult to record on the real hardware, but perhaps it's possible using a PC, an old serial connection and a cheat cartridge; I have not had such a setup since the 90s though... Basically I would need to patch the game code or data somehow to activate demo recording, then grab the data from that buffer and save to a file. With a modified emulator that might be a lot easier since I could just set breakpoints and patch where required, and save the required memory out to a file on the host machine.

 

10 hours ago, Gez said:

I think "Station Doom" is perfectly cromulent. I could suggest something like Psych Doom (PSX -> Psych). Or "Loco Doom" since this port allows the game to leave the station. Or, same idea, "Dynamite Doom", since station is static, and the opposite of static is dynamic.

 

I think you might be onto something with 'Psy'... It could be named that in reference to PlayStation 1 SDK (PsyQ) that the game is built with and in honor of the legendary studio that worked on it, Psygnosis. It also has a nice ring to I think... Hmm, 'PsyDoom' - what do you guys think?

 

1 hour ago, Redneckerz said:

What do you think of the names put forward so far?

 

I think we're making some progress on this!

[Erick194]

@intacowetrust

 

You know, there is little left to finish recompiling PsxDoom in Native Psx, once it is finished and it works correctly, your project will advance exponentially, I only ask for a little time.

 

As you can see in the picture all that is already converted into C/C++

[Kaiser]

This is really impressive. This was something that I've always wanted to see happen but never had the resources/knowledge to pull it off at the time. Hopefully, the code can be cleaned up and documented as the project advances, especially with things like the existence of Z_Alloc and why it needs to allocate at the end of the heap. Definitely looking forward to seeing further development on this.

[intacowetrust]

4 hours ago, Erick194 said:

@intacowetrust

 

You know, there is little left to finish recompiling PsxDoom in Native Psx, once it is finished and it works correctly, your project will advance exponentially, I only ask for a little time.

 

As you can see in the picture all that is already converted into C/C++

 

Wow that's awesome @Erick194 - amazing work! I did not know you were already this far along! Having access to this code would be enormously helpful towards getting the PC client off the ground and would allow me to focus more on removing the dependency on the hardware. Do you have an idea of how long it will take to finish off the rest?

 

In the meantime as well I am more than happy to help out if you want. If there's a particular function or piece of code you want me to investigate just let me know. Or if you want to verify some existing work within this project I can do that also, just let me know.

 

43 minutes ago, Kaiser said:

This is really impressive. This was something that I've always wanted to see happen but never had the resources/knowledge to pull it off at the time. Hopefully, the code can be cleaned up and documented as the project advances, especially with things like the existence of Z_Alloc and why it needs to allocate at the end of the heap.

 

Indeed, I'm looking forward to aspect of this as well. I fully intend for it to be as clean and as well documented as possible, and also to serve as a nice basis for future modifications.

 

As far as the 'Z_Alloc' stuff goes my initial hunch would be that it is perhaps a strategy for reducing heap fragmentation, maybe through placing larger or more static allocations near the end of the heap? I have not yet studied all the places where it is used though, so that's just a guess right now.

[Erick194]

Another function that goes hand in hand with the z_zone is the P_LoadBlocks, this reads and inserts the memory blocks of the textures and sprites back to the memory of the z_zone.

 

enum compressFlags {Decode,NoDecode};
typedef struct psxblock_s
{
	int		size;               //*     including the header and possibly tiny fragments */
	void    **user;             //*4    NULL if a free block */
	short   tag;                //*8    purgelevel */
	short   id;                 //*10   should be ZONEID */
	short   lump;               //*12
	short   flags;              //*14   0 = Decode || 1 = NoDecode || >2 = Error
	struct psxblock_s   *next;  //*16
	struct psxblock_s	*prev;  //*20
} psxblock_t;

void P_LoadBlocks(char *filename)//L80023698()
{
	psxblock_t	header, *base, *block, *next, *prev;
	int i, file_num, data_size, size;
	boolean error;
	byte *ptr;

	i = 0;
	while (true)
    {
        if (i >= 4)
			I_Error("P_LoadBlocks: Data Failure");
        i++;

        error = false;

        file_num = OpenFile(filename);
        data_size = SeekFile(file_num, 0, PSXCD_SEEK_END);

        ptr = (byte *)Z_Malloc(data_size - sizeof(psxblock_t), PU_STATIC, 0);

        base = (psxblock_t *)((byte *)ptr - sizeof(psxblock_t));
        header.size = base->size;
        header.user = base->user;
        header.tag = base->tag;
        header.id = base->id;
        header.lump = base->lump;
        header.flags = base->flags;
        header.next = base->next;
        header.prev = base->prev;

        prev = base->prev;
        next = base->next;

        SeekFile(file_num, 0, PSXCD_SEEK_SET);
		ReadFile(file_num, (byte *)base, data_size);
		CloseFile(file_num);
        block = base;
        size = data_size;

        do
        {
            if ((((block->id != ZONEID) || (block->lump >= numlumps)) || (block->flags > NoDecode)) ||
                (block->flags == Decode &&
                (decodedsize((byte *)block + sizeof(psxblock_t)) != lumpinfo[block->lump].size)))
			{
            error_:
				error = true;
				break;
			}

            size -= block->size;
            if (size < 0) goto error_;

            (byte *)block = (byte *)block + block->size;
        } while (size != 0);

        if (!error)
        {
            base->prev = prev;
            do
            {
                if (lumpcache[base->lump].cache == NULL)
                {
                    *(void **)&base->user = (void *)((byte *)lumpcache + base->lump);
                    *(void **)&lumpcache[base->lump].cache = (void *)((byte *)base + sizeof(memblock_t));
                    lumpencode[base->lump] = base->flags;
                }
                else
                {
                    base->user = NULL;
                    base->tag = 0;
                    base->id = 0;
                }

                data_size -= base->size;
                if (data_size == 0)
                {
                    if (next)
                        *(psxblock_t **)&base->size = (psxblock_t *)((int)next - (int)base);

                    base->next = next;
                }
                else
                {
                    base->next = (psxblock_t *)((int)&base->size + base->size);
                }

                if (base->next)
                    base->next->prev = base;

                base = base->next;

            } while (data_size != 0);
            Z_CheckHeap(mainzone);
            return;
        }

        base->size = header.size;
        base->user = header.user;
        base->tag = header.tag;
        base->id = header.id;
        base->lump = header.lump;
        base->flags = header.flags;
        base->next = header.next;
        base->prev = header.prev;
        Z_Free((byte *)ptr);
    }
}

 

[Erick194]

52 minutes ago, intacowetrust said:

Do you have an idea of how long it will take to finish off the rest?

 

If everything goes well, it can last between 1 month or less, because I only need (p_pspr.c | p_setup.c | st_main.c) and review other files in the hope of not forgetting anything, which I really have to test It is the distribution of the leafs and their rendering.

[intacowetrust]

On 12/30/2019 at 9:50 PM, Erick194 said:

Another function that goes hand in hand with the z_zone is the P_LoadBlocks, this reads and inserts the memory blocks of the textures and sprites back to the memory of the z_zone.

 

Yeah that was a fun one to decipher. Was drawn to it mainly because I was wondering 'what the hell is that'? Here was my own interpretation of it if you're curious: https://github.com/BodbDearg/PsyDoom/blob/a8eafbff51b9cdc4a9d74d268d8b8bc28bd7c695/game/Doom/Game/p_setup.cpp#L1676

 

On 12/30/2019 at 10:09 PM, Erick194 said:

If everything goes well, it can last between 1 month or less, because I only need (p_pspr.c | p_setup.c | st_main.c) and review other files in the hope of not forgetting anything, which I really have to test It is the distribution of the leafs and their rendering.

 

Nice - that's pretty close then!

Edited January 25, 2020 by intacowetrust : Github URL change

[Redneckerz]

13 hours ago, intacowetrust said:

 

I think you might be onto something with 'Psy'... It could be named that in reference to PlayStation 1 SDK (PsyQ) that the game is built with and in honor of the legendary studio that worked on it, Psygnosis. It also has a nice ring to I think... Hmm, 'PsyDoom' - what do you guys think?

 

 

I think we're making some progress on this!

The very similarly named PsiDoom already exists and is an source port for Amiga. It just has no Wiki entry yet.

 

PsyQDoom could be something? It differentiates enough from PsiDoom and QZDoom in my eyes and its both a reference to PS1 SDK and Psygnosis (Stupid of me that i didn't think of this first up when looking up codenames...)

 

6 hours ago, Erick194 said:

 

If everything goes well, it can last between 1 month or less, because I only need (p_pspr.c | p_setup.c | st_main.c) and review other files in the hope of not forgetting anything, which I really have to test It is the distribution of the leafs and their rendering.

So, as it stands then, we would have two PSX source port projects:

• DZDoom (DarkZDoom) - A GZDoom based build with all kinds of features from the PSX version added in to work with all the features that GZDoom brings.
• PsyQDoom (I am just holding this on for now as placeholder) - A port of the PSX Doom code to PC, without additional enhancements like Phoenix Doom does, and which strives for a vanilla port of the PSX framework. (I assume that for more modern stuff like high res/OpenGL support, you could fork this stuff).

Sounds about right, no?