intacowetrust

Just added a new 'noclip' cheat to the game. Was exploring the maps out of bounds a bit when I noticed this in E1M3 - which I thought interesting. Got me thinking, I wonder is the fake 'floating' wall effect just a happy coincidence of how the PSX renderer works? Presumably because it is drawing back to front and not doing the same per column occlusion stuff that the PC version is doing: I'm guessing maybe the mappers realized this capability and decided to use it a little in Final DOOM, as discussed/shown in this thread: I also ran into the 'linedef deletion' bug while going out of bounds. If you stray too far outside the map coords, eventually things become corrupted. That'll have to be fixed eventually! Presumably that bug is caused by the lack of bounds checking in some of the blockmap handling code. Maybe I can confirm a fix on that soon...

Interesting - always fun to see old games being picked apart! I'll probably be busy with this for a long time (at least a year I think) so not much time for other projects I'm afraid. After that I'll likely take a break and then move onto some other stuff, maybe back to having some more hobbyist fun with Vulkan: It's actually running fine on MacOS at the moment for the most part, I hope to support Linux as well when it's all done. Occasionally the build on MacOS will get broken (since I work on Windows most of the time) but it's usually very quick to fix up. Most of the time when I'm travelling I take a MacBook Pro so a side effect of that tends to be portability :)

Thanks, happy new year to you too! Glad it worked out for you :) I believe the game should build for and run in a 32-bit environment so it might work on even older Windows too, I'm not sure... I didn't bother with a 32-bit build since most people are on 64-bit systems these days but I think it should be possible to do this. I don't know about going back as far as Win 98 though haha... I did make some simplifications however to the fixed point math routines that take advantage of 64-bit registers, so perhaps those might not be as optimal in a 32-bit environment.

Yep that's precisely it. I fully intend to do a Phoenix Doom type job on the PSX codebase when I'm done as well, but the vanilla version must come first. Thanks for pointing that out, I was not aware! I'm not fond of name confusion myself but I'm not sure it would be much of a problem in this instance given that the author abandoned the project way back in 1997 with no source release that I can see of (so it's truly dead), and also given that it's for a relatively obscure platform. No disrespect to the Amiga and that (I was an avid A600/A1200 user back in the day) but I can't see this phonetic clash being a problem for most people. Just my own thoughts though, if anyone feels really strongly against the name 'PsyDoom' I'm willing to listen. Also open to other suggestions too, this isn't something that needs to be decided immediately... Oh and happy new year everyone! May 2020 be a great year for progress on the PSX DOOM front. Hopefully by this time next year I'll be able to enjoy the fruits of all these efforts and mapping for PSX DOOM with a new engine running on the PC. Back full circle to how I got started in game development in the first place! We'll see how it goes.. :)

Added an updated binary (1.0.2) that should hopefully fix the DLL issues. @CoTeCiO can you try it out when you get a chance and see if this fix works for you? Thanks! https://github.com/BodbDearg/phoenix_doom/releases/tag/releases%2F1.0.2 The issue was resolved in the end by rebuilding using the Windows XP platform toolset, later toolsets all introduce this dependency and I couldn't find any way to avoid it.

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 Nice - that's pretty close then!

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. 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.

Not sure it's redistributable issue since I statically linked against the C runtime in order to try and avoid such headaches. I think it's maybe an unintended dependency on something in Win 8/10. Going to investigate shortly to see if it can be avoided...

Interesting, thanks for sharing! 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. 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!

Thanks for letting me know! I've seen reports of this on YouTube also... I think there may be a dependency being generated for Windows 8/10 by the MSVC compiler. I will have to see if I can get rid of this dependency somehow. Unfortunately I only have a Windows 10 environment to test with so I may need some help verifying any fix.

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! 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. 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 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.

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! :)

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...

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. 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! 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: 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...

@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! :)

Yep that's me! :) Thanks for the link, definitely good to have as many reference points as possible! Just posted an update on this topic in another thread:

2020 objective: work on porting PSX Doom to PC. That should probably keep me occupied for the year, possibly longer! :)

Thanks for trying out the game and for submitting feedback - glad you are enjoying :) It's there but it's a little hard to find as you've found, being on the 2nd page of the options menu. I added this since it was bugging me too :) Some people might not even realize there is a second options page though, perhaps there is some way I could indicate that better from the 3DO version... I put the option on the 2nd page deliberately as well because I didn't have time to do a quit confirm menu, and didn't want quit to be activated accidentally - which would be infuriating. Saving is in there but it's pretty basic - working similarly to the 'saving' in the 3DO version. Basically it remembers what level you reached and some prefs like music and sound volume. If you restart the game then you can go to levels you reached previously but you have to do a pistol start unfortunately (same as the original 3DO version)... The save file is in the same folder as the prefs file if you want to edit, it's just a simple .ini. Mainly it's using the appdata folder because I'm using SDL's 'give me a writeable path' functionality which is portable and works similarly under Windows, Linux and MacOS. It's also a more reliable method of getting a place to put the save file, since it's possible that the user might put the .EXE in a place that is not writable or requires elevated privileges, like in 'Program Files' on Windows. I agree it's slightly awkward to navigate to though, perhaps I could put in a shortcut to it within the game's options menu that opens up an explorer window etc.. I had considered adding more stuff to the options menu but mainly a lack of time in the end prevented me. I had a self imposed deadline to finish this project before my son was born (before other priorities took over!) and I was running very short on time towards the end - somewhat ironic considering the game's history... Putting most options in the config file was a quick way to get this done. There's also the issue of the UI design itself; cramming loads and loads of options into the 3DO menu would probably require a UI redesign, which might affect the authenticity of the menu a little. I might require some new UI assets for example which would go against the goal of making the client work entirely with the original data set. It also might necessitate forcing a higher resolution, which would not be good if you wanted to play at the original resolution. Perhaps a compromise here though would be to add mouse/gamepad sensitivity sliders and resolution options to the menu, since that's what people would want to tweak most commonly. The standard WASD controller bindings etc. are probably fine for most people.

My absolute dream would be for someone to release the PSX source! I wonder who even owns the rights to that anymore? Is it languishing away on some dusty old hard drive or backup media somewhere? (hopefully it still exists) Yeah there's probably stuff in there that @Optimus or others compiling for the real hardware might find useful. Found and fixed a few interesting bugs along the way!

Thanks! Yeah it's source assets for the most part that are in Rebecca's repo, as well as some of the scripts used to build those assets. You'd be hard pressed getting some of that stuff to compile though since the toolchain appears to rely on some archaic stuff found on 68K Macs and in the 3DO SDK.