intacowetrust

This should be interesting to see - thanks for sharing! CppCast (which Jason also hosts) is one of my favorite podcasts and a great source of news & information for all C++ devs - fun to see him have a go at converting DOOM. I dealt with a lot of this stuff myself when working on Phoenix Doom, which was converted to C++. Certainly makes you appreciate more the differences and incompatibilities between the two languages, especially crusty old ‘C89’.

Not sure what your issue is specifically, but I can offer a little more info on that message - perhaps that might give a clue. Basically you get that error during gameplay when the renderer goes to draw a sprite which isn't already loaded/cached into RAM. Since storage on the PS1 was so slow (2x CDROM) the developers decided to just treat this situation as an error (and hence force it to be fixed) rather than trying to stream in whatever WAD lump was not loaded, like on PC. Streaming in WAD lumps on the fly on PS1 would have caused unacceptably large stalls due to the latency/speed of CDROM drives... As to how you ensure the WAD lump is pre-loaded, that is done via the 'MAPSPR--.IMG' file associated with the map wad. This file basically contains duplicates of WAD lumps found in PSXDOOM.WAD for whatever sprites are needed for that particular map. The lumps contained within this file are cached entirely into RAM when the map loads and this is basically where the game must ensure it has everything it needs for gameplay. 'MAPSPR--.TEX' serves a similar purpose also, but for texture lumps. So in this situation it probably means your MAPSPR--.IMG file is missing the particular lump that it's complaining about. In the original PlayStation DOOM (not sure about Final Doom) that lump number is associated with `BAR1A0` in the main IWAD - so it probably means you are looking at an explosive barrel which is not loaded. Again not sure how you ended up with this situation using the tools, but that is the general idea of what is happening. It's possible you may have run into a bug also in which case maybe @Erick194 might be able to investigate further.

It's a valid point and entirely possible. I mean it feels like fair (ish) use to me and in 'good faith' given that the project is a fan-made client for an already existing Doom game, and is open source and non commercial. Projects like this serve to promote and preserve interest in Doom games and the Doom universe, which is probably in Bethesda's interest. I'm pretty sure it wouldn't meet the legal definition of fair use though so such a logo could only exist provided Bethesda continued to allow it, and as long as it didn't cause confusion with the official Doom games. I've tried to differentiate the logo enough to make sure that is the case, and this is very much a niche project anyway but perhaps that is not enough... Worst case scenario, if I'm asked to change it then I will and something else can be used instead. There is precedent for this sort of thing already also: https://doomwiki.org/wiki/Brutal_Doom And also Delphi Doom, which would probably have a similar scale (probably larger!) audience to what PsyDoom should eventually have: https://sourceforge.net/projects/delphidoom/ Yeah that's pretty much what I was thinking, or maybe PS and the 'D'? I can experiment with this in a while. Shortening might also help with the legal aspect, so the logo is more like that of say Chocolate Doom: https://www.chocolate-doom.org/wiki/index.php/Downloads I do like your idea, it looks very interesting! :) Going back to the earlier points about legalities however I feel like this one might be flying a little closer (perhaps too close) to the sun given how similar it looks to the present day PlayStation logo (minus coloring). Whatever about using the Doom logo (or aspects of it) for a Doom fan project I think it might be a lot riskier incorporating the Sony logo. Cool idea though!

Thanks for all the cool mockups and suggestions everyone! Some of these concepts have given me a few ideas - I couldn't resist having a pop despite what I said earlier :P Here's a very rough idea I came up with: The colors here were inspired by the buttons on the PlayStation controller, and the font chosen for the 'Psy' portion (ZRNIC) somewhat resembles that of the original PlayStation 1 logo. The geometric shapes obviously are inspired by the controller buttons, though I've left out the cross symbol however for future uses. I'm thinking a future fork of PsyDoom might have the 'X' suffix added to it. What do you think?

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

Glad you found the info helpful! :) As far as no visplanes go, PlayStation Doom achieves this by essentially just rasterizing floor & ceiling polygons through use of the leaf data structure. Each leaf is a complete collection of all the edges in a subsector, which is sadly missing from the regular PC BSP tree. The glBSP Specs intro talks about this problem a little more and why it's an issue for hardware renderers. When the time comes to render a flat plane for a subsector, the PS1 renderer steps through all the pixels in all the screenspace edges to determine the top and bottom screen y values for the polygon, as well as the left and right x values for each horizontal row of pixels. Because the each subsector polygon is convex, all that is needed is a single continuous line for each horizontal row, and a single pair of left and right x values per row. Once it has the screen positions and bounds for each horizontal span/line in the polygon, the renderer can then figure out the floor or ceiling texture coordinates using the view position and direction. Once that is done, all that needs to happen is to submit a single textured line to the GPU for each horizontal row in the polygon, using all of the computed info. This is submitted as an extremely thin polygon that basically rasterizes to a line... That is the happy case... Unfortunately a complication arises for larger polygons due to the previously mentioned 1 byte texture coordinates on the PS1. If the texture wraps too many times the PS1 renderer has to split a horizontal span into many smaller spans to get around the fact that the PS1 can only express texture coords from 0-255. This means that larger open areas can see decreased performance due to more horizontal lines being submitted to the GPU. I've hacked together a quick visualization of this, with each line submitted to the GPU colored randomly so you can see what it is doing. Subsectors here are colored most differently, with slightly less random variance for individual horizontal rows in a polygon: Notice how for the larger green subsector by the window there is a slight change in line color midway through the line. This is where the renderer had to split up the horizontal span into multiple smaller spans to workaround PS1 hardware limitations. That is the basic idea of how it all works, but of course there is more detail in the actual implementation. The code is all here and commented for those who want to take a look: https://github.com/BodbDearg/PsyDoom/blob/master/game/Doom/Renderer/r_plane.cpp Yeah it's definitely on my TODO list, but far down on the list priorities. I'm no artist either but have used Inkscape before in the past so could probably cobble together something. Once all the hard stuff is done I can sort out stuff like that.

Yeah it's the result of PlayStation hardware limitations. Texture coordinates on the PS1 are specified in terms of whole pixel locations only - there is no fractional component to the numbers. Most of the time that's fine but what happens with doors, plats etc. when they are in motion is that the wall columns end up being not entirely integer sized in terms of their height, due to floor and ceiling heights being in between whole units. When the time comes to submit wall columns to the GPU, rounding must occur (due to the aforementioned hardware limit) and the fractional coordinates are converted to integers. This results in the stepping between pixels shifting slightly and the texture being stretched and squeezed slightly, depending on the current fractional values of the ceiling and floor heights. This causes the 'shimmer' or distortion effect you are observing.. This slight glitch can also be found in the original game too, in fact PsyDoom shares pretty much all of the rendering quirks of the original game. Here are a few of the most common ones: Invalid Z Order Sometimes layering is wrong and sector flats 'cut' into sprites. This is due to the simplified way the renderer handles z-ordering for sprites, it basically emits them as it visits a subsector and relies on the BSP tree to handle Z-Order in relation to everything else - unlike the PC renderer. Most of the time that approach works fine, but occasionally you will see stuff like this: Texture Drift Sometimes depending on the view angle, texture coordinates can 'drift' quite a bit due to various imprecisions. It happens often up close or at seep viewing angles to walls, but sometimes it also happens at very particular view angles as you can see here. This switch texture that isn't displaying as it should: Holes or gaps in walls and floors This precision issue can occur in most places, but larger levels seem to have the issue more. The yellow pixels are the gaps here where the sky can be seen through: Occluded sector ceilings visible through the sky The ceiling here shouldn't be showing as it is for a room around the corner. This happens due to the simplified way the PSX renderer handles occlusion and Z sorting. Flats extend beyond their bounds by 1 or 2 px This is a more subtle issue, but floors and ceilings can sometimes be seen over-extending past where they are supposed to be. I believe it's due to a hack that was trying to prevent cracks in between flats and walls. Sometimes its a little over eager and causes slight visual glitches. In some ways the PS1 renderer is superior, the improvements include: 16-bit 'true color' framebuffer instead of the 8-bit palette based display on PC. The PS1 version can display a much greater range of colors because of this. Colored lighting. Alpha blending effects for transparency and subtractive blending (for 'nightmare' spectres). Animated fire skies No use of 'visplanes', therefore no more dreaded 'visplane' overflow errors. Some of the downsides include the bugs discussed above (most of which can probably be fixed, given enough time or CPU power) and also: Wall heights are limited to 256 units, due to (again) hardware limitations with PS1 texture coordinates. The coordinates are only a single byte so can only have 256 values. This limit can be worked around to some extent however with some hacks during mapping... Texture widths are restricted to 128 units wide, 64 units wide and 16 units wide only to simplify VRAM mangement - you can't have a 48 px texture for instance. VRAM is severely limited on the PS1, resulting in a much reduced variety in textures. On some of the busier levels with lots of monsters (like 'The Suburbs'), the 'Texture Cache Overflow' error can be triggered. This error happens when the game runs out of VRAM to display all of the sprites currently visible in the scene. The screen resolution is low (only 256x240) and is stretched slightly (horizontally) to fill out the TV display more. In some scenes lots of overdraw can occur which can drag down the framerate quite a bit. This is due to the simplified occlusion culling versus the PC engine, which tries to keep overdraw to an absolute minimum. Perhaps this was a deliberate tradeoff however, to shift some of the burden off of the cpu? Probably lots of other stuff, feel free everyone to chime in and add to this list... I believe that should be pretty much it, though I haven't examined that code yet in detail.

Nice map - good use of PlayStation lighting :) Gave it a quick spin in PsyDoom to see what it looks like: Looking forward to seeing more original maps for PSX coming out of this effort!

I did a quick check just to see what might be involved and I think it might be beyond the scope of this project - sorry. If it was just a simple asset swap (enabled by a user supplied WAD) and maybe changing a few texture atlas coordinates for the STATUS image then I might consider adding support but unfortunately that is not the case. The main issue is that the Saturn HUD is much wider than that of the PlayStation, being 320 pixels in width instead of 256. The maximum texture size supported on the PlayStation is 256 pixels and the framebuffer is 256 pixels wide also, so I'd have to make pretty drastic changes with regard to VRAM management, screen resolution etc. in order to support this. PsyDoom is intending to imitate the original PlayStation version fairly faithfully (a chocolate Doom style approach) so I'm keeping a PlayStation style rasterizer in place (most likely I'll continue using the Avocado 'gpu') with similar hardware limitations. Eventually I'm planning to fork PsyDoom and add a hardware renderer, widescreen support etc. so such a change might become more feasible then. But that will not be for quite a while...

Yeah I'd still have to do interpolation anyway in order to be able support refresh rates like 144 Hz or whatever the flavor of the month is for monitors. It's not very difficult to implement though, just a bit of extra book-keeping to keep track of previous positions and mixing between the two values. The easiest win would be to simply do it for the player position also - that could be implemented very quickly. Yeah it's bad, it was causing some issues for the GEC Master Edition mappers as well: I made a video exploring the difference in behavior between 15/30 Hz framerates here:

Sure thing! Here are the frame states for the super shotgun on PSX that I pulled from the original .EXE, the 3rd column of data is the 'tics' or duration field for the state: 8005910C: u32[7] State_S_DSGUN = { 6, 0, 1, 80020298, 20, 0, 0 } // 80020298 = A_WeaponReady 80059128: u32[7] State_S_DSGUNDOWN = { 6, 0, 1, 8002053C, 21, 0, 0 } // 8002053C = A_Lower 80059144: u32[7] State_S_DSGUNUP = { 6, 0, 1, 800206B4, 22, 0, 0 } // 800206B4 = A_Raise 80059160: u32[7] State_S_DSGUN1 = { 6, 0, 2, 0, 24, 0, 0 } 8005917C: u32[7] State_S_DSGUN2 = { 6, 0, 3, 8002112C, 25, 0, 0 } // 8002112C = A_FireShotgun2 80059198: u32[7] State_S_DSGUN3 = { 6, 1, 3, 0, 26, 0, 0 } 800591B4: u32[7] State_S_DSGUN4 = { 6, 2, 3, 8002051C, 27, 0, 0 } // 8002051C = A_CheckReload 800591D0: u32[7] State_S_DSGUN5 = { 6, 3, 3, 80021690, 28, 0, 0 } // 80021690 = A_OpenShotgun2 800591EC: u32[7] State_S_DSGUN6 = { 6, 4, 3, 0, 29, 0, 0 } 80059208: u32[7] State_S_DSGUN7 = { 6, 5, 3, 800216B4, 2A, 0, 0 } // 800216B4 = A_LoadShotgun2 80059224: u32[7] State_S_DSGUN8 = { 6, 6, 2, 0, 2B, 0, 0 } 80059240: u32[7] State_S_DSGUN9 = { 6, 7, 2, 800216D8, 2C, 0, 0 } // 800216D8 = A_CloseShotgun2 8005925C: u32[7] State_S_DSGUN10 = { 6, 0, 2, 80020480, 20, 0, 0 } // 80020480 = A_ReFire For reference, here's the actual struct for state_t (7 32-bit words), pretty much the exact same as on PC: struct state_t { spritenum_t sprite; // Sprite number to use for the state int32_t frame; // What frame of the state to display int32_t tics; // Number of tics to remain in this state, or -1 if infinite void* action; // Action function to call upon entering the state, may have 1 or 2 parameters depending on context (map object vs player sprite). statenum_t nextstate; // State number to goto after this state int32_t misc1; // State specific info 1: appears unused in this version of the game int32_t misc2; // State specific info 2: appears unused in this version of the game }; The state you mentioned which occurs before firing (S_DSGUN1) lasts for 2 tics here on PSX instead of 3 on PC. The timebase on PSX DOOM however is 15 Hz instead of 35 Hz, so that delay amount is 2/15 seconds or 0.1333 seconds - a much longer delay than on PC. So it looks like you are correct again :)

Just on the melee range stuff as well, it seems as though you may be correct @VGA. The following definition can be found in Linux Doom: #define MELEERANGE (64*FRACUNIT) On Jag Doom and PSX it's this instead (extending the maximum allowed melee reach by 6.0 units): #define MELEERANGE (70*FRACUNIT) To add to this further the PC version of 'P_CheckMeleeRange' appears to shorten the allowed range by 4.0 units, by subtracting 20.0 units and then adding the player's radius (16.0 units) to the range: boolean P_CheckMeleeRange (mobj_t* actor) { mobj_t* pl; fixed_t dist; if (!actor->target) return false; pl = actor->target; dist = P_AproxDistance (pl->x-actor->x, pl->y-actor->y); if (dist >= MELEERANGE-20*FRACUNIT+pl->info->radius) return false; if (! P_CheckSight (actor, actor->target) ) return false; return true; } Here's the same code from Jag Doom: boolean P_CheckMeleeRange (mobj_t *actor) { mobj_t *pl; fixed_t dist; if (! (actor->flags&MF_SEETARGET) ) return false; if (!actor->target) return false; pl = actor->target; dist = P_AproxDistance (pl->x-actor->x, pl->y-actor->y); if (dist >= MELEERANGE) return false; return true; } So yeah, it looks like monsters can reach you from an extra 10.0 units away on Jag and PSX Doom - confirming what you suspected.

Thanks @InDOOMnesia! I'm feeling pretty good about the project now, a lot of the biggest technical challenges are done and thanks to the reverse engineering work of @Erick194 (https://github.com/Erick194/PSXDOOM-RE) converting the rest of the application to run natively on PC should be relatively straightforward. Looking forward to capitalizing on this effort later on with mouse support, analog controls, high fps, modding, limit removal, and multiplayer over a LAN among other things...

Will do! Another thing which could be a factor also is that the game renders to a 256x240 framebuffer which gets stretched out to approximately 293x240 on the display. That would make horizontal distances and gaps seem larger than they are on PC and might make the hit detection seem a little more eager than it was before. I don't know if that would account for all the differences you described but it's definitely a thing. It's also responsible for the more 'flattened' look of PSX Doom with regards to sector heights.

From looking at the Greatest Hits (v1.1) binary of PSX DOOM the player radius at least appears to be the same as Linux Doom. The radius is 16.0 units and height 56.0 (both in fixed point). Not sure about the collision code, I haven't gone through that in detail yet.

Hey everyone, I've just put up a new build (0.1.1) for Windows 64-bit and MacOS: https://github.com/BodbDearg/PsyDoom/releases/tag/releases%2F0.1.1 Changes in this version: Fixed issues with the game freezing sometimes on level loads. Fixed music not stopping fully on game pause. The music sequencer is now driven completely by the host machine's clock, not an emulator clock. As a result music timings and playback should be more accurate. The sequencer logic also no longer runs under emulation and can be debugged normally. The lowest levels of cdrom and spu handling (via the PsyQ SDK) are now completely native and talk directly to the emulator 'hardware'. Having control over the interactions with the hardware allowed the game freezing issue to be fixed. Spu and cdrom advancement have been completely detached from the rest of the emulated PlayStation and now advance at their own pace and as required. Having isolated spu/cd components will eventually allow me to move sound and music to another thread and make it more reliable.

Yeah I'm going to have do interpolation for movement in order to be able to support high frame rates without breaking demo compatibility. Unfortunately gravity is still broken even when running at 30 Hz, as this video shows: https://www.youtube.com/watch?v=7RBycvyZf3I I might have to tick the player logic at 15 Hz like the rest of the game in order to fix that one. Will see what I can do once I start looking at that code; hopefully I can make it consistent without making input lag feel bad.

Looks like it was caused by a very subtle emulator issue in the end, introduced when I updated Avocado recently. This commit fixes the problem: https://github.com/BodbDearg/PsyDoom/commit/d8203f6eea1e7b594bfc31b83c0d681f916480ec I might do another build again soon (despite what I said previously) since I have a fix for both this and that nasty freezing issue (on level loads) which have been plaguing the project since I began. That's worth doing another build for alone since it's a big quality of life improvement. The level loading issue went away once I converted the LIBCD PsyQ library to fully native code. This new version is greatly simplified, works synchronously and talks directly to the Avocado 'cdrom': https://github.com/BodbDearg/PsyDoom/blob/master/game/PsyQ/LIBCD.cpp https://github.com/BodbDearg/PsyDoom/blob/master/game/PsyQ/LIBCD.h

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!

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.

Yeah there's many places in the PSX Doom machine code where optimizations can be spotted. There's plenty of instances of inlining, and also code de-duplication where the instructions for similar code blocks are collapsed into one. Other tricks commonly used by the compiler in this binary include reducing multiplies (by a constant factor) to a series of adds and bit shifts, reducing division (by a constant factor) to multiply by a reciprocal, and eliminating branches (for values that depend on them) by using bitwise operations if possible. Having that said there seems to be many instances where the optimizer seems to make odd choices for inlining, like inserting very large functions into smaller ones. There also seems to be a lot of dead/unused code in final executable, both for functions that are inlined everywhere (and never called explicitly anymore) or for library functions like from LIBGPU or LIBGTE that are simply never used at all. I often wonder if this was recompiled with a more modern toolchain how much more smaller & efficient the machine code could be made, given the advances in compiler technology over the past 25 years.

Is it something to do with cd sector encodings and whether the .RAW data is interpreted to include the CD sector header and error detection information or not? A raw CD sector (for mode 1) has 2,352 bytes of information and encodes 2,048 bytes of data. The ratio between the two (2048 / 2352 = ~ .8707) looks similar to the skew you are seeing in the file sizes above. For example for DOOMRAVE.RAW 19204/16722 = 0.8707.

If I had to pick an absolute favorite, it would probably be the soundtrack for the original Mass Effect - in particular the "The wards" and "Noveria". Jack Hall did an amazing job with that soundtrack and it really made the atmosphere of the game for me. A close second (surprised nobody has brought this up yet!) would be the OST from the Wipeout series of games. I love this track in particular from the demo build: Other top favorites (some of which may not have been mentioned yet) include: The Settlers (Amiga): https://www.youtube.com/watch?v=r385tMuVwjg Streets Of Rage I & II (Megadrive/Genesis): https://www.youtube.com/watch?v=mW03QgubN0M Monkey Island I:https://www.youtube.com/watch?v=_fj5pIpjS14 Monkey Island II: https://www.youtube.com/watch?v=_N9sJAxUpCI Frontier Elite II (Amiga): https://www.youtube.com/watch?v=S0jSvRa2spE Hired Guns (Amiga): https://youtu.be/PEGAwobDAiM?t=97 Super Hexagon: https://www.youtube.com/watch?v=jigRSeRYMzA Other honorable mentions include, The PSX Doom soundtrack (that goes without saying!), Quake 1 and Doom I/II soundtracks, Deus Ex: Human Revolution, Terraria.

Ah I see - thanks for clarifying @Gerardo194! I'll likely be busy with PsyDoom and the eventual 'high res' fork and/or limit removing work for quite a while, and maybe eventually some tooling stuff to make new music for the game. I'm very impressed by this guy's work and want to see if it can make its way into some WADS: https://www.youtube.com/channel/UC63VIPOgIiAsAk7MSyN1eJQ/videos After that though I'm not sure; I wouldn't rule anything out but it's likely I'll take a break from reverse engineering stuff for a while. We'll see...

Sounds great, looking forward to working with you more on this! :)