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

1 hour ago, CoTeCiO said:

Will this be able to load custom maps in native PSX format?

It already is, see the video in the OP, starting from 2:20.

On 1/15/2020 at 8:40 AM, CoTeCiO said:

Will this be able to load custom maps in native PSX format?

That is most certainly the plan... I've got a very basic custom map capability already (as shown towards the end of the video) but there are a couple of things that I need to fix up for it to be complete, and maybe some small quality of life things for mappers too.

Current limitations:

(1) At the minute the sound .LCD files don't load because the code handling that is much lower level and will need to be reversed and tweaked first - so some sounds won't play depending on the map/monsters.

(2) There isn't a mechanism currently for overriding map names, or switching music etc. Perhaps supporting a very small subset of ZDoom's MAPINFO lump might satisfy that requirement: https://zdoom.org/wiki/MAPINFO/Map_definition

(3) Adding new textures isn't possible currently without them existing in PSXDOOM.WAD first, which is painful. That limitation needs to be removed.
(4) Probably other stuff I won't be aware of until I try actually mapping for this version...

On 1/17/2020 at 1:04 AM, intacowetrust said:

That is most certainly the plan... I've got a very basic custom map capability already (as shown towards the end of the video) but there are a couple of things that I need to fix up for it to be complete, and maybe some small quality of life things for mappers too.

 

Current limitations:

(1) At the minute the sound .LCD files don't load because the code handling that is much lower level and will need to be reversed and tweaked first - so some sounds won't play depending on the map/monsters.

(2) There isn't a mechanism currently for overriding map names, or switching music etc. Perhaps supporting a very small subset of ZDoom's MAPINFO lump might satisfy that requirement: https://zdoom.org/wiki/MAPINFO/Map_definition

(3) Adding new textures isn't possible currently without them existing in PSXDOOM.WAD first, which is painful. That limitation needs to be removed.
(4) Probably other stuff I won't be aware of until I try actually mapping for this version...

 

That's fine! I'm asking because I have a full mapset of PC versions of Doom 1 for PSX Final Doom that I can't really play anywhere because there are no means of building an ISO with these modified maps, only a small test ISO with a custom map as MAP01, so I have around 30 CDs of PSX Final Doom with each map on them, but I'd like to play those maps in succession, because swapping CDs and resetting the console each time I want to go to the next map sucks heh

One thing I noticed working on these maps, is that PSX Doom has no defined secret map slots, you can define which level an exit takes you too just by assigning a secret exit and the map number in the tag. Pretty cool stuff!

On 1/18/2020 at 3:12 PM, CoTeCiO said:

That's fine! I'm asking because I have a full mapset of PC versions of Doom 1 for PSX Final Doom that I can't really play anywhere because there are no means of building an ISO with these modified maps, only a small test ISO with a custom map as MAP01, so I have around 30 CDs of PSX Final Doom with each map on them, but I'd like to play those maps in succession, because swapping CDs and resetting the console each time I want to go to the next map sucks heh

Yeah totally understandable - that's a bit of a pain! I was going to suggest maybe I could supply you with a build so you could go through those more easily, but unfortunately I only support the original PSX DOOM map format & engine limits at the moment. I aim to support Final DOOM eventually but for now I'm just concentrating on the original game. If you could get the maps into regular PSX DOOM format though then you could totally use this - but I realize that may not be possible (due to different engine limits) or convenient either.

On 1/18/2020 at 3:12 PM, CoTeCiO said:

One thing I noticed working on these maps, is that PSX Doom has no defined secret map slots, you can define which level an exit takes you too just by assigning a secret exit and the map number in the tag. Pretty cool stuff!

Indeed - 'data driven design' FTW! :P

On vendredi 17 janvier 2020 at 5:04 AM, intacowetrust said:

(2) There isn't a mechanism currently for overriding map names, or switching music etc. Perhaps supporting a very small subset of ZDoom's MAPINFO lump might satisfy that requirement: https://zdoom.org/wiki/MAPINFO/Map_definition

I'd suggest implementing UMAPINFO. It's very similar.

The reference implementation is in this PrBoom fork: https://github.com/coelckers/prboom-plus

• https://github.com/coelckers/prboom-plus/blob/master/prboom2/doc/umapinfo.txt
• https://github.com/coelckers/prboom-plus/blob/master/prboom2/src/umapinfo.cpp
• https://github.com/coelckers/prboom-plus/blob/master/prboom2/src/umapinfo.h

On dimanche 19 janvier 2020 at 12:12 AM, CoTeCiO said:

One thing I noticed working on these maps, is that PSX Doom has no defined secret map slots, you can define which level an exit takes you too just by assigning a secret exit and the map number in the tag. Pretty cool stuff!

Strife had pretty much the same idea for making its hub system work within the constraints of the Doom map format.

14 hours ago, Gez said:

I'd suggest implementing UMAPINFO. It's very similar.

The reference implementation is in this PrBoom fork: https://github.com/coelckers/prboom-plus

Thanks, will check that out when the time comes!

On 1/21/2020 at 3:03 PM, intacowetrust said:

I was going to suggest maybe I could supply you with a build so you could go through those more easily, but unfortunately I only support the original PSX DOOM map format & engine limits at the moment. I aim to support Final DOOM eventually but for now I'm just concentrating on the original game. If you could get the maps into regular PSX DOOM format though then you could totally use this - but I realize that may not be possible (due to different engine limits) or convenient either.

Actually, I don't think porting the maps to the original PSX format is that hard. I made the maps in Final Doom format because it supports a mouse (pretty neat if using an emulator with a keyboard!) and I only needed 27 slots. I didn't use any stuff exclusive to Final, so it should be pretty easy. I was thinking about porting them to original PSX anyway because I can see someone wanting to include episode four into the mix. I'd be honored if you let me try this port out!

Soo...after only reading the OP, I gotta ask, what is the major difference between this PSX project and the other major PSX TC going on?

4 hours ago, warman2012 said:

Soo...after only reading the OP, I gotta ask, what is the major difference between this PSX project and the other major PSX TC going on?

This project aims to be more faithful to the original PSX Doom code and quirks compared to the limited amount of things a TC could accomplish, I've noticed that there's instant loading but that's something that comes from the speed of modern SATA and SSD drives compared to a like, 4x speed CD-rom drive back in the mid 90's. Probably a stable and consistent framerate while also preserving the original resolution and everything where afaik the GZDoom based stuff typically has a higher resolution than the original PSX Doom does.

42 minutes ago, Lynnie said:

This project aims to be more faithful to the original PSX Doom code and quirks compared to the limited amount of things a TC could accomplish, I've noticed that there's instant loading but that's something that comes from the speed of modern SATA and SSD drives compared to a like, 4x speed CD-rom drive back in the mid 90's. Probably a stable and consistent framerate while also preserving the original resolution and everything where afaik the GZDoom based stuff typically has a higher resolution than the original PSX Doom does.

So could this port play actual custom pwads then?

5 hours ago, warman2012 said:

Soo...after only reading the OP, I gotta ask, what is the major difference between this PSX project and the other major PSX TC going on?

This aims to be as faithful as possible to the original thing, and I think (I might be wrong here) this is built, just like Phoenix Doom, with the console codebases expanded to the PC, and not the other way around like the PSX TC and the GEC port (which is more of a really elaborate TC more than an actual port) are. That means this is as accurate as possible to the original version, whereas the TC will never be 100% accurate, and the GEC GZDoom TC won't be either (unless the GEC guys really go their way to do tons of tweaking to the source code) because GZDoom internally behaves a bit differently to Doom 1.2, which is the version Jaguar Doom is based on, which in turn is the codebase for PSX Doom.

5 minutes ago, warman2012 said:

So could this port play actual custom pwads then?

Yeah! But they have to be in native PSX Doom format, so your everyday WADs won't run here.

On 1/22/2020 at 3:35 PM, CoTeCiO said:

Actually, I don't think porting the maps to the original PSX format is that hard. I made the maps in Final Doom format because it supports a mouse (pretty neat if using an emulator with a keyboard!) and I only needed 27 slots. I didn't use any stuff exclusive to Final, so it should be pretty easy. I was thinking about porting them to original PSX anyway because I can see someone wanting to include episode four into the mix. I'd be honored if you let me try this port out!

That's cool - I'd be happy for you to give it a go! :)

I've uploaded a build here for Windows x64 (I can do a MacOS build also if needed):

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

I've also updated the instructions (see the 'Running' section) with a bit more info, controls and how to use the temp 'modding' stuff I showed in the video:
https://github.com/BodbDearg/PsyDoom

Let me know if you have any issues or questions etc.

On 1/22/2020 at 10:07 PM, CoTeCiO said:

This aims to be as faithful as possible to the original thing, and I think (I might be wrong here) this is built, just like Phoenix Doom, with the console codebases expanded to the PC

Yep that's true - except in this case the original codebase to work with is the actual machine code of the PlayStation .EXE itself. Having that said I am referencing the Jag version in particular heavily, and @Erick194 has been helping me out with enormously with tons of code from his own reverse engineering efforts. So it's not as bad as it might first seem...

On 1/22/2020 at 9:17 PM, Lynnie said:

Probably a stable and consistent framerate while also preserving the original resolution and everything where afaik the GZDoom based stuff typically has a higher resolution than the original PSX Doom does.

Yeah the framerate and instant loading you mentioned are some of the current benefits of the port. I can run maps that absolutely crawled on the PSX like 'Perfect Hatred' without any issues in this port. I do intend to eventually support higher res and do more of a 'remaster' eventually - but that will happen in a separate fork. This version will be for the purists who want the game more less as it originally was - but running natively on their PCs.

@intacowetrust please call it PsyDoom. :P

4 minutes ago, Redneckerz said:

@intacowetrust please call it PsyDoom. :P

Haha.. yes - that's been on my TODO list! :) I'll probably get round to doing that this weekend...

19 hours ago, intacowetrust said:

I've uploaded a build here for Windows x64 (I can do a MacOS build also if needed):

https://github.com/BodbDearg/StationDoom/releases/tag/releases%2F0.0.1

Quick note for anyone trying this out: If you get an error that says "VCRuntime140_1.dll is missing", download and install the Visual C++ redistributable.

https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

I've only given it a quick look so far, but it's so cool to see this up and running on PC firsthand. Things I've spotted so far:

• Noclip cheat message only says "on." or "off."
• Warp Level cheat prompt is active even if you unpause the game. Pressing open or shoot will cause whatever level you selected to load. (Expected behavior: Warp Level prompt is deactivated upon unpausing, cheat must be re-entered)
• Doesn't seem to work correctly with multi-bin CUEs. (Loads the data track just fine, but all CD audio will be missing)
• Music for Club Doom doesn't appear to play correctly. (Cuts mid-track, is silent for a minute, then progresses to the next CD audio track)

It's fun to see passwords from the PS1 game working in this port. I had to play through 'Suburbs' and 'The Mansion' on PS1 just to verify that my copy of Doom wasn't the source of the problem for the Club Doom music. I'm more thankful though that your port makes the bonus levels freely accessible via the Warp cheat, lol.

As far as required files go: Is the goal for the port to eventually only need a BIN/CUE for Doom? I can understand why SCPH1001.bin is currently needed, but it seems interesting that the port needs PSXDOOM.exe from the disc when it's already present on the BIN.

edit: Oops lol, just saw this is covered on Github. Looking forward to seeing this port grow!

1 hour ago, intacowetrust said:

I can do a MacOS build also if needed

Yes, please.

I'm getting an api-ms-win-core-libraryloader-l1-2-0.dll missing error. I tried installing the redistributable and nothing, and a Google search led me to shady dll download sites and error reports with specific fixes for each program, so I'm stuck.

EDIT: Apparently that DLL was added in Windows 8, and I'm using Windows 7, so I guess I'm SOL.

Hey everyone, just to let you know that I've renamed the project from 'StationDoom' to 'PsyDoom'! I've also added a new build with a few small fixes:

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

On 1/23/2020 at 1:09 AM, Lollie said:

Quick note for anyone trying this out: If you get an error that says "VCRuntime140_1.dll is missing", download and install the Visual C++ redistributable.

https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

Thanks for bringing this up! I've added this note to the github instructions. The latest build is statically linking against the C runtime so hopefully this shouldn't be a problem anymore, but just in case people can try the remedy you suggested.

On 1/23/2020 at 1:09 AM, Lollie said:

• Noclip cheat message only says "on." or "off."

Yeah that's a weird product of current technical restrictions which will be eventually lifted. Essentially at the moment I can only point to an existing string within PSX binary for the hud message - so I just took the tail end of one of the existing HUD message strings for that new cheat :)

On 1/23/2020 at 1:09 AM, Lollie said:

Warp Level cheat prompt is active even if you unpause the game. Pressing open or shoot will cause whatever level you selected to load. (Expected behavior: Warp Level prompt is deactivated upon unpausing, cheat must be re-entered)

Thanks for pointing out - that annoying issue should be fixed in the new build (0.0.2).

On 1/23/2020 at 1:09 AM, Lollie said:

• Doesn't seem to work correctly with multi-bin CUEs. (Loads the data track just fine, but all CD audio will be missing)
• Music for Club Doom doesn't appear to play correctly. (Cuts mid-track, is silent for a minute, then progresses to the next CD audio track)

Oh interesting - those issues might be something with the Avocado PSX emulation backend. It's a little wonky with the handling of CD audio - even if you run the original PSXDOOM.EXE. Should be fixable eventually once layers of emulation are stripped away and CD audio & I/O are handled natively.

On 1/23/2020 at 1:34 AM, cybdmn said:

Yes, please. (MacOS build)

Done! I've added a MacOS build to the 0.0.2 release page. In order to run, you can put all of the required files (PSXDOOM.EXE, SCPH1001.BIN etc.) in the same folder as the .app.

On 1/24/2020 at 9:43 AM, CoTeCiO said:

 

EDIT: Apparently that DLL was added in Windows 8, and I'm using Windows 7, so I guess I'm SOL.

Give the latest build (0.0.2) a go instead... I applied a similar fix to what I did recently for Phoenix Doom and recompiled the app with the WindowsXP SDK and Visual Studio 2017. Using this older toolchain appears to avoid generating these dependencies on Win 8/10. Not sure how long this toolchain will continue to work (it's marked as 'deprecated' by MS right now) but at least for the moment I can continue to do builds that work on older Windows.

Its about time this slowly gets a Wiki mention. Ill wait a few more versions (say 0.0.4), primarily for native rendering, but an programmer's page should be in order.

12 hours ago, intacowetrust said:

Yeah that's a weird product of current technical restrictions which will be eventually lifted. Essentially at the moment I can only point to an existing string within PSX binary for the hud message - so I just took the tail end of one of the existing HUD message strings for that new cheat :)

You could try using the "picked up a clip." string to get the "clip." part.

I got it working! It's playable and works fine! The in-game music runs quite slow, but the game runs at normal speed. There's noticeable input lag here as well. I don't know if that's a problem of my laptop being an old crappy thing or something else.

Now, the main issue for me... Is there any way to resize the window? Because it's so big even in 1080p that I can't see the whole screen. Unfortunately I don't have a 4K TV around to try there. I'm sorry to be such a pain in the ass bringing up problems constantly!

Now, as @Lollie said, my image is multi-bin and the Redbook audio doesn't work. Although, about that... I had some images laying around from some modding I was doing to the game, those images are not multi-bin (and the music works with them) and they have modified graphics, sounds, music and one even got maps. They run natively on PsyDoom, just place them instead of the original cue+bin and they run perfectly. I expected them to work fine, since they were made keeping the internal structure of the CD table of contents intact from the original. I posted about how I did it here, except that was just for the first thing I did that was the sounds. I can run them in the console by physically swapping the original CD after the game started running for the modded one and it doesn't even realize it has a different CD in it... Except for the one with modified maps. In the console, after some maps, some textures start appearing in places they shouldn't and it just gets worse the longer you play, I don't know if the same thing happens in PsyDoom because I can barely see the game in my 1366x768 laptop screen (at that resolution you can't even see the status bar or messages at all) and I didn't keep playing.

One thing of interest for modders is that PsyDoom exhibits the same behavior as the original with sectors taller than 256 units, with the textures stretching vertically or turning upside down, so it serves as a great tool to test maps and fix bugs without having to rely on running an emulator!

EDIT: Those modded images are from a completely different project than the one I mentioned the other day of the maps done for Final Doom. I still have to try that, but I want to see if I can resize the window of the game to something a bit more acceptable for my screen first heh

On 1/26/2020 at 3:55 AM, Redneckerz said:

Its about time this slowly gets a Wiki mention. Ill wait a few more versions (say 0.0.4), primarily for native rendering, but an programmer's page should be in order.

Sure thing - I can add that in there eventually, or someone else can either if they want... Phoenix Doom could probably use one too!

On 1/26/2020 at 12:21 PM, CoTeCiO said:

Now, the main issue for me... Is there any way to resize the window? Because it's so big even in 1080p that I can't see the whole screen. Unfortunately I don't have a 4K TV around to try there. I'm sorry to be such a pain in the ass bringing up problems constantly!

 

No worries - I appreciate problems being flagged and receiving feedback on things. It's early days yet and there is a lot of stuff broken but it's still good to have a list of these things at hand as it makes fixing stuff later much more efficient :)

I've just uploaded a new build (0.0.3) that should hopefully address some of your issues:

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

The changes are:

Quote

• Window is auto sized based on user screen resolution.
• Window can be resized.
• Game now applies the NTSC scaling that the original game did, stretching the framebuffer from 256 pixels wide to 293 pixels wide. Aspect ratio appears more correct.
• Frame pacing improvements and input handling tweaks to try and reduce input latency.
• Demos now play at the correct speed (15 Hz).
• Xbox 360/One controller can now be used along with analog sticks. Controls are hardcoded at the minute and based on more modern layouts.

Music pacing should be a little improved too with the frame pacing changes, though I do notice a little bit more (occasional) audio skipping - a small regression.

On 1/26/2020 at 12:21 PM, CoTeCiO said:

I expected them to work fine, since they were made keeping the internal structure of the CD table of contents intact from the original.

Indeed, if you place your data at the exact same sectors on the CD and occupy the exact same number of 2048 byte sectors as the original (or less) then modding files on the disc should work. The retail version of the game does not consult the ISO 9960 file system at all and hardcodes the start sector and size in bytes into this giant table (embedded in the .EXE) for fast access: https://github.com/BodbDearg/PsyDoom/blob/master/game/Doom/cdmaptbl.cpp

This is what makes modding the retail game an absolute pain. Presumably dev builds did not work like this and instead consulted the file system because those numbers would have been constantly changing... Eventually I hope to mod PsyDoom so that it uses the standard file system, which should make modded CDs easier to do.

On 1/26/2020 at 12:21 PM, CoTeCiO said:

In the console, after some maps, some textures start appearing in places they shouldn't and it just gets worse the longer you play

Interesting - that sounds like some sort of memory corruption or buffer overflow. Perhaps an unchecked engine limit has been exceeded or something like that; for example a subsector can only have at most 20 edges but I did not see any bounds checks anywhere for that. Maybe in that case though it was hoped that the nodebuilder would do such verification. You could try again now in PsyDoom and see what happens! :)

On 1/26/2020 at 12:21 PM, CoTeCiO said:

One thing of interest for modders is that PsyDoom exhibits the same behavior as the original with sectors taller than 256 units, with the textures stretching vertically or turning upside down, so it serves as a great tool to test maps and fix bugs without having to rely on running an emulator!

Yes indeed - I'm currently bound by the same hardware limits as the original PS1 version. The reason for the 256 unit wall height limit is because texture coordinates on the PS1 are all a single byte, which can only encode 256 unique values. This also restricts the max texture size to 256x256 and limits the amount of times you can wrap textures; for example a 64 pixel texture can be wrapped 4 times on the PS1 hardware.

The PS1 renderer could have got around this limit by splitting up the vertical wall columns into 2 or more pieces but for some reason chose not to - maybe due to performance concerns or because of time limits on the project.

Interestingly the same problem also exists for flat span rendering but the developers were forced to implement a solution there, as the alternative would have been unacceptable - restricting rooms to 256 units in size. You can see this code here where PSX DOOM splits up spans into multiple pieces where required:

https://github.com/BodbDearg/PsyDoom/blob/46750ffaf7f8896b19ea5431f272690359f2153b/game/Doom/Renderer/r_plane.cpp#L330

This is also part of the reason why larger outdoor areas tend to perform poorly on PSX DOOM - it has to render more flat span polygons for wide open floor areas that are far in the distance.

2 hours ago, intacowetrust said:

Sure thing - I can add that in there eventually, or someone else can either if they want... Phoenix Doom could probably use one too!

I could make all of these, eventually! I would start with the user page, but when that comes, i better PM you about this :)

6 hours ago, intacowetrust said:

Perhaps an unchecked engine limit has been exceeded or something like that; for example a subsector can only have at most 20 edges but I did not see any bounds checks anywhere for that. Maybe in that case though it was hoped that the nodebuilder would do such verification. You could try again now in PsyDoom and see what happens! :)

It does! That flat on top should not be that one, and it is static, it doesn't animate.

This only happens with flats, I've never seen it happening with wall textures. Interestingly, E1M3 exhibited no wrong flats, and the game crashed when trying to enter E1M9, but I wrote down the password and I'll play more later to see if I see more of these things happening. Although it kinda defeats the purpose, since resetting the game brings everything back to normal.

I might know why this happens on these maps, though. Because the Jaguar mapset use fairly different textures compared to the original PC versions, I had to use textures that are not present in the cache file for the maps. Unlike using sprites not present in the map, which crashes the game, or sounds not present in the map, which are just ignored (it actually happens in the original Hangar with the Lost Souls from the Pain Elemental, they're completely silent), the game actually load the textures not present in the cache from the WAD file. It takes a lot longer to load when using on a console, but the textures appear in the map and mostly work fine, except for those flats. I could have tried limiting the textures I could use in the maps by keeping them within limitations of the cache file, but that was not what I wanted to do with that project. Apparently PSX Doom have a 16 flat per map limit, it might be that the game loads all the flats into memory, including the ones in the cache that were not actually used, and overflows or something like that. 

6 hours ago, intacowetrust said:

Yes indeed - I'm currently bound by the same hardware limits as the original PS1 version. The reason for the 256 unit wall height limit is because texture coordinates on the PS1 are all a single byte, which can only encode 256 unique values. This also restricts the max texture size to 256x256 and limits the amount of times you can wrap textures; for example a 64 pixel texture can be wrapped 4 times on the PS1 hardware.

That's quite interesting! You are really good at explaining this kind of stuff!

This is pretty awesome stuff. I'm glad that PSX Doom has been getting so much love lately. It was how I was first introduce to Doom!

On 1/28/2020 at 9:04 AM, CoTeCiO said:

I might know why this happens on these maps, though. Because the Jaguar mapset use fairly different textures compared to the original PC versions, I had to use textures that are not present in the cache file for the maps. Unlike using sprites not present in the map, which crashes the game, or sounds not present in the map, which are just ignored (it actually happens in the original Hangar with the Lost Souls from the Pain Elemental, they're completely silent), the game actually load the textures not present in the cache from the WAD file. It takes a lot longer to load when using on a console, but the textures appear in the map and mostly work fine, except for those flats. I could have tried limiting the textures I could use in the maps by keeping them within limitations of the cache file, but that was not what I wanted to do with that project. Apparently PSX Doom have a 16 flat per map limit, it might be that the game loads all the flats into memory, including the ones in the cache that were not actually used, and overflows or something like that. 

Interesting... I've converted most of the map loading code to C++ at this point but not the particular code which handles updating the texture cache. I suspect it might be something to do with the 16 flat limit as you suggest though - I can probably tell you more about this later once I get to that code.

8 hours ago, Uroboros87 said:

This is pretty awesome stuff. I'm glad that PSX Doom has been getting so much love lately. It was how I was first introduce to Doom!

Same here! I love all the other versions of Doom and all but the PSX still remains my all time favorite. Something about the combination of the creepy ambient music, atmospheric sfx and the moody colored lighting make it a special experience in my opinion. The changes are not as drastic as D64 (which I really like also, just for the record) so it still feels more like the original game, yet it it's refreshingly different... It really feels like you're in this hellish alternate world at times. So yeah... that's what makes me want to open up this game - so we can extend and improve upon that experience even more :)

Hey everyone, I've just hit a big milestone (rendering complete!) so the time has come for a new build - 0.1.0 :)

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

Here's the summary of the main changes in this version:

• All rendering and UI code is now implemented pretty much completely natively (i.e regular C++ code) and talks directly to the Avocado rasterizer/gpu. The only remaining work that needs to be done is moving global variables out of the address space of the emulated PlayStation, which I will do near the end of the project. Leaving globals inside the PlayStation's RAM makes it easier to re-emulate certain functions to compare behavior, if required.

• Further improvements to input latency, bypass emulation layers completely to reduce input lag.

• Screen fades now work.

• Improved audio handling, hopefully less stutter.

• Updated Avocado with some fixes for CD music not stopping and some UI sprites rendering 1 pixel too small.

• Title screen: fix a bug from the original game with a 4 pixel gap in the fire at the right side of the screen.

• Allow the 'Nightmare!' skill to be selected from the main menu (note: currently Nightmare passwords are broken)

• Fix not being able to close the window on an I_Error (fatal error message, like "Texture Cache Overflow").

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

For the > 30 FPS hack, I've also uploaded a video showing it in action:

Note that some levels (which require jumping) will be currently severely broken in this mode, due to greatly increased gravity at higher frame rates. Eventually I aim to fix that.

My next major milestone for the project will be to convert the audio engine and all low level SPU and CD handling code to native C++ code, and hopefully eliminate all bios dependencies along the way. My aim is to end up with a very simple and clean re-implementation of the PlayStation libraries, similar to what was done with LIBGTE and LIBGPU:

https://github.com/BodbDearg/PsyDoom/blob/master/game/PsyQ/LIBGPU.cpp
https://github.com/BodbDearg/PsyDoom/blob/master/game/PsyQ/LIBGTE.cpp

Once this is done it should be easier to get a handle on the audio sync issues, and also to fix the annoying freeze which sometimes happens during level loading.

I will probably be a while at this effort so if I don't update this thread in a while do not fret - I'll be continuing to chip away at this behind the scenes until it is done. Audio is the last major technical challenge to be finished, once that is out of the way the rest of the work should be relatively straightforward.

Congratulations on the milestone! Great to see this port make progress. Seeing it run at 60fps feels like forbidden magic, but it's very cool.

CD audio does feel better in this release! Stutters and skips are still present, but they don't feel quite as severe this time. It's also much nicer to hear CD audio cut out completely upon starting a new game, instead of dragging out for a few seconds like it used to.

One more small audio bug that I've noticed: When paused, in-game sequenced music doesn't currently fade all the way out to 0. You can hear the music faintly droning based on whatever notes were currently playing at the time of pausing the game. Interestingly, in-game CD audio (Club Doom) doesn't have this issue, it fades out correctly.

Good luck with your next milestone! Even if you don't remove all bios dependencies, it sounds like a hell of a task.

On 2/28/2020 at 5:02 AM, Lollie said:

Congratulations on the milestone! Great to see this port make progress. Seeing it run at 60fps feels like forbidden magic, but it's very cool.

 

CD audio does feel better in this release! Stutters and skips are still present, but they don't feel quite as severe this time. It's also much nicer to hear CD audio cut out completely upon starting a new game, instead of dragging out for a few seconds like it used to.

 

One more small audio bug that I've noticed: When paused, in-game sequenced music doesn't currently fade all the way out to 0. You can hear the music faintly droning based on whatever notes were currently playing at the time of pausing the game. Interestingly, in-game CD audio (Club Doom) doesn't have this issue, it fades out correctly.

 

Good luck with your next milestone! Even if you don't remove all bios dependencies, it sounds like a hell of a task.

Thanks! And appreciate you taking the time to check out the new build :)

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. It could also be possibly reverb related, since there were some big changes in Avocado relating to reverb. Hopefully all will become clear soon!