intacowetrust

Ah yes sorry - you are right, mixing up the port devs heh...

Yeah this makes sense given how the code works at the minute. I might just eliminate this 'feature' entirely in the next release so the turn speed is consistent in all situations. Maybe it was helpful with the 3DO's digital controller but I don't think it's helpful on PC. I'm not sure - was just spitballing a little because I can't see why else it would be happening. If it works for other games though that seems like less of a possibility... It could be a bug in SDL as well. If you like maybe you could send a copy of the game's config .ini file found in '%APPDATA%\Roaming\com.codelobster\phoenix_doom'? Maybe there is something in that which is causing problems, like a doubly bound key or something.

Cool, yeah that sounds more or less like what I was describing. Yeah I'm aware of that. My point was that they already solved more or less the exact same problem for floor spans (see visualization here of the floor span splitting) so I was curious why they didn't just apply the same solution to wall columns also. Either it was extreme time limitations or the devs were concerned about potentially doubling or tripling (or more) the number of triangles being thrown at the GPU for walls in certain scenes - that already seemed like a bottleneck as it was given the way the renderer works. Hexen on the PSX from what I've read was also pretty poorly optimized and suffered from a lot of frame rate issues - so probably not a shining example of pushing the hardware to it's limits for later titles. Certainly not when you compare it to something like Hammerhead's superb port of Quake 2, for example.

Nice work! That removes a very annoying limitation for mapping and the need for hacks like razor thin 'steps' to give the illusion of higher walls (like in the 'O Of Destruction'). Does Hexen split up the wall columns the same way that PSX Doom was forced to do for the floor spans, to get around the hardware texture coordinate limitations? I always wondered why PSX Doom never attempted to extend that idea to wall columns, might have saved the mappers a lot of trouble in various levels. Perhaps a product of tight deadlines or concerns over performance (due to added draw primitives) - who knows...

Just to add I tested for this issue and was unable to reproduce. I don't see anything in the code that would cause it either - left/right axis movement is completely independent to forward/back. Maybe it's something with the OS/keyboard that's causing the problem?

Thanks for the feedback @Nevander! Yeah it looks for an .IMG file named 'Doom3DO.img' by default. Usually the easiest thing is to just name your .IMG file the same as that. You can change the .IMG path to whatever you like though by editing the generated config file. The game intentionally terminates itself if it doesn't have any data because that's not a situation which can be recovered from. I think they *finally* fixed this issue in recent Win 10 updates, but probably of no use if you're still on 7: https://arstechnica.com/gadgets/2018/05/notepad-gets-a-major-upgrade-now-does-unix-line-endings/. I could perhaps change it though so it uses different line endings for the .ini depending on platform, to make it a bit friendlier on older Windows. If you're looking for a good text editor though I would highly recommend https://www.sublimetext.com. It's very extensible, supports many syntaxes and plugins, and works cross platform. NotePad++ is also another good one (I used to use before Sublime) - but I find it a bit more clunky and it seems to be constantly popping up annoying dialogs asking to be updated. Yeah the turning thing is a holdover from the 3DO code - turning is slightly quicker (fast turn speed) when you're standing still on a spot. If that feels annoying, perhaps I can get rid of it - I think it was done with digital controllers in mind. Hadn't ran into the strafe issue - sounds odd... I can take a look. Thanks for your ticket, just seeing it now - odd that github doesn't send me emails when new ones are added. Maybe I turned off notifications or something a while ago to avoid spam :P I would say this project is more in 'maintenance' mode at the minute. I'm reasonably happy with the feature set but willing to fix any bugs or stability issues that come up. Having that said as well, I do want to integrate a hardware accelerated renderer at some point to allow for fast gameplay at high resolutions and do movement interpolation, so that framerates beyond 60 FPS can be done very smoothly. I'll likely do those when I add similar features to PsyDoom and kill two birds with the one stone.

@fenderc01 just added a fix for the issue you encountered in commit 7956f33256a39db905cae5032a1ccc0ce1f42a60. Should work now if you pull the latest code.

Thanks for checking out the build and reporting this issue! Looks like a problem introduced while adding support for demos larger than the previous 16 KiB limit. I allocate the demos now outside of the Avocado PlayStation's 2 MiB of RAM (to allow for very long demos and not exhaust memory) but some low level CD-ROM handling code was still expecting the demo buffer to reside in the PlayStation's memory. I should have a fix for the issue shortly.

I doubt Carmack would find much interest in game engine development anymore. He seems very much the pioneering type and likes to take on new challenges and unsolved problems. Advancements in graphics are definitely not occurring at the same rate they used to as the 90s (save perhaps for recent raytracing stuff) so perhaps this is why the field became less interesting and why he moved onto VR as it was emerging and now AI. Engine development these days is much more about the less sexy topic of improving tools and workflows so that large teams can work effectively than it is about coming up with some revolutionary new rendering technique. I’ve no doubt though that John Romero would still have the design chops to come up with a fun modern take on a game like Doom. Perhaps one factor working against that would be the team sizes and investment required for something as polished and large scale as Doom 2016/Eternal. That would tend to stifle a lot of creative freedom and spontaneity that the early id team was able to enjoy. The abstract level design for instance that we all knew and loved from older id games would probably be one casualty of such an environment. Blackroom was an exciting concept though, it sounded like it had potential to be like a modernized version of the early id approach to the FPS, perhaps mitigating some of those scaling issues mentioned. I hope he gets the chance to return to that idea at some point.

That’s awesome, thanks! I’ll keep an eye out for that when the time comes around. All those other tools as well sound like they will be super useful for people modding the game. Makes sense, can’t imagine he spent any time polishing/iterating on those once word got out that the arch-vile was being canned. I guess worst case scenario is that the PC sounds can be used, if acceptable results can’t be gotten from the work that was scrapped. Or we all get creative and come up with new ones - would be nice/consistent to have a PSX twist on this enemy’s audio, like everything else in the game.

@Erick194 that is friggin awesome!! Nice work! Some questions on this: Do you plan on incorporating the changes made for Archvile etc. support back into PSXDOOM-RE, or will you be publishing them somewhere else? If possible I would like to make PsyDoom support the GEC Master Edition and the new additions to the enemy roster. Do you plan on making use of Aubrey's unused sounds for the archvile or will you use the PC sounds instead? Given that the archvile will require new sounds to be added to the game, will you be making tools to edit/update the .WMD file? (like what we discussed in the PsyDoom thread)

Just to clarify a few things about memory limits on the PS1 which may be helpful for mappers to bear in mind: Main RAM is actually 2 MiB in size, VRAM is 1 MiB. A large chunk of your main RAM however is used up by the .EXE itself and the global variables it declares, as well as 64 KiB reserved by the BIOS. In the greatest hits version of DOOM all this leaves 1,368,380 bytes available for the program via Z_Malloc (usable heap space). The 2 screen framebuffers (front & back) consume only VRAM, not main memory. They always consume (except during screen fade transitions) a fixed 256 KiB of VRAM. Palette colors are also squeezed into otherwise unused parts of this 256 KiB too. Wall and flat textures only temporarily occupy main RAM during level loading, after that they are promptly evicted once they are uploaded to VRAM. Therefore these types of textures do not count towards your main memory budget during gameplay. 64 KiB of VRAM is used at all times during gameplay for the STATUS graphic lump (UI and fonts etc.) 64 KiB of VRAM (a 256x256 pixel texture 'page') is reserved for flats used by the level, not matter how many flats are actually used. This limits you to 16 64x64 flats per level but since the amount used is fixed, reducing the flat texture count does not impact memory usage. A fixed 192 KiB of VRAM (3 256x256 pixel texture pages) is reserved exclusively for wall and sky textures by the engine during gameplay. The engine supports textures with widths of 128, 64 and 16 pixels only (except for regular skies which are 256x128). This translates to a theoretical maximum of 12 128x128 textures, 24 64x128 and 96 16x128 textures which can be used during a level. The (previously hidden) VRAM viewer can be helpful to visualize where each texture is going into VRAM. As I identified earlier in the thread, there is a 256x256 pixel (64 KiB) texture page unused by the engine during gameplay. This further eats into the VRAM budget but could potentially be unlocked for use by @Erick194 to help make texture cache overflows less likely. After all of these things eating into VRAM, you have 6 256x256 pixel texture pages (384 KiB) leftover for sprites in VRAM. Sprites are uploaded to VRAM on each frame, depending on what is visible. Therefore they must kept loaded in main RAM at all times, as well as occupying VRAM when they are being drawn. The sprite lumps are stored compressed in main RAM however, therefore more effective compression could in theory reduce this main memory overhead. If the number of unique sprites being rendered in a particular frame exceeds the 384 KiB VRAM budget for sprites mentioned above, you get a "texture cache overflow" error. Again just to reiterate, your texture cache overflow error is caused by the fixed 384 KiB of VRAM dedicated to sprites being exceeded in a particular frame - it has nothing to do with running out of main memory. Changing the sky texture would also not help this issue, because the areas of VRAM dedicated to sprites, flats and textures are fixed and separate to each other. There are a couple of things you can do to try and reduce the VRAM usage by sprites on a particular frame: (1) Use less types of monsters and sprites. (2) Use monsters and sprites with smaller graphics. (3) Have less monsters and sprites onscreen at the same time by partitioning up the level with solid walls, using less monsters in individual encounters etc. This can be easily overlooked but the key thing to remember with the texture cache overflow is that it's the number of unique sprites that are visible at the same time (and their size) which contributes towards the error. For example 4 imps could use as much VRAM memory for a particular frame as 4 different types of monsters, because each of those imps could be showing a different frame/pose. The more monsters you have onscreen the more likely each one will be showing something different, so this can add to the strain too... It's the reason why levels such as 'The Suburbs' can experience overflows due to the very large amounts of onscreen monsters, even though in theory they might be using the same level of monster variety as other levels. I realize that with a level like 'Dis' your hands might be a bit tied for using some of those options, so perhaps @Erick194 might be able to help out with engine changes. Right off the bat there's that unused 64 KiB of VRAM which I've identified, which could be put to good use. He could also make it so that the texture cache overflow is not treated as a fatal error in the release version of the game and deal with the problem in one of two ways: Allow VRAM already being used for sprites in a frame to be overwritten and suffer the resulting (temporary) graphical glitches that follow. It might look funky for a few frames but probably much more preferable to a hard crash? Force the GPU to finish all current drawing, clear all sprites from the texture cache and allow it to be filled again. This would probably come with a large FPS drop, but still probably much preferable to crashing. In fact, I plan on doing this for PsyDoom and banishing texture cache overflows entirely since there isn't really much of a performance penalty in that case. This is indeed possible, it would take a long time though. The game will outright refuse to launch a level (crashes with 'P_SetupLevel: not enough free memory') if it doesn't have at least 48 KiB of main memory free in the heap after everything is loaded. This 48 KiB is reserved for things that spawn during runtime, like bullet puffs, blood and spawned lost souls etc. so you are always guaranteed to have that amount of main RAM leftover on starting a level. Given that a the size of a thing allocation at runtime is 172 bytes (including zone allocator overhead), this allows you to spawn approximately 285 map objects at runtime at a minimum - possibly more if the map doesn't require as much main RAM. There are a few other allocations (like thinkers for map changes/effects) that eat into heap space, but that should give you an idea of the kinds of limits you are playing with. You are much more likely to run into the VRAM limits with texture cache overflows (caused by lots of souls being active) than hitting the main RAM limit most of the time.

Good news everyone, the demo compatibility of PsyDoom with the original game is looking pretty solid at this point! I recorded playthroughs of all 59 maps using the original game in Avocado - every single demo played back correctly in PsyDoom. Even bugs such as the lost souls occasionally slipping through walls were replicated correctly :P I now also have saved the high level expected results for each demo, which can be used in automated testing. To leverage this, I added a 'headless' mode to the game so it can run a demo without any display or sound and verify the result against what is expected. A small python script I created also does a playthrough of the entire game and verifies everything behaves as expected. The entire playthrough completes in about 8-9 seconds, which is awesome and means I can run it very frequently to sanity check everything.

The approach I took with PsyDoom was inspired by what this project attempted, and could be applied to any reverse engineering effort: https://github.com/ughman/c2c Essentially I used the original machine code to generate C++ to execute the exact same work or MIPS instructions, using the RAM and CPU registers available in a PlayStation emulator (Avocado in my case). Unlike C2C though, I spent some time identifying functions in the machine code so I could split the code up and not just get one massive chunk of instructions - which would have been extremely difficult to work with. I then used the PlayStation emulator to handle bios calls and other hardware specific functions like SPU and GPU. There were a few hacks here and there I had to add to get the emulator syncing to real time, sound to work etc. but for the most part I was able to get the game up and running surprisingly quickly. The key thing about this approach is getting to a working (or mostly working!) build quickly and then once you have that, gradually transition over piece by piece. If something breaks then you can do a git bisect and go back to the commit where the problem starts appearing - it can be a powerful tool to quickly resolve problems. Having that said though I did have some huge factors in my favor for PsyDoom which you would not have for SNES Doom. The main one being of course that the Jaguar Doom source code had already been released and was known to be basis for PSX Doom. Hence I wasn't coming into this completely in the dark... Later on of course, @Erick194 kindly shared his own (completed) reverse engineering efforts with PSXDOOM-RE, so at that point I more or less had all the code - minus the internals of the PsyQ libraries. My work now mainly consists of verifying @Erick194's work, spotting differences between the PSX Doom Editions (original vs greatest hits) and gradually transitioning everything to running natively on PC. Yeah I would advise that, it sounds like Randy was fully intending to make this available. Maybe they eventually wanted to but their work wasn't really at a point where they felt comfortable doing that? It is a shame though when such hard earned knowledge fades away into obscurity...

Haven't got a final one yet - have mainly been focusing on getting the fundamentals of the project done first before polishing up stuff like that. However if you want to go ahead and use the concept that I made earlier then that would work for now. When it changes and is polished we can always update later. It's in SVG format so you can export to whatever size you need: https://github.com/BodbDearg/PsyDoom/blob/master/docs/PsyDoom Concept Logo.svg InkScape can be used to convert to PNG. You need the 'ZRNIC' font installed to render correctly though: https://www.dafont.com/zrnic.font @Redneckerz was just mentioning in jest, since PsiDoom (the Amiga port) came up earlier during the naming discussion and also because said he would do a wiki entry if I provided him with a logo :P

Yeah I was thinking of eventually doing a pack/unpack utility for the module (.WMD) file also - you'd certainly need that to add new patches and sequences. Your point is valid, a tracker might not be able to reproduce the sound exactly as it would be on the hardware, especially with the hardware reverb that the SPU provides. Another approach might be to create tools to edit the module file and the patches/instruments contained within, as well as importing music sequences from midi like you suggested. A specialized VST plugin could also be created which uses Avocado to emulate the PSX SPU and which exposes the instruments defined in the Williams module file to a music sequencer program. Once you had that you could use a DAW application of your choice (like FL Studio etc.) to compose the music and test against the actual instruments as they are in the game, and hear pretty similar results. Once you are happy with that then your sequence can be exported to midi and ultimately back into the module file and played back in game. A more complicated and fragmented workflow than the tracker approach perhaps, but potentially more powerful and accurate? This might be an interesting little project for me actually... Many years ago I was very much into making electronic music, and always thought it would be cool to create my own VST instruments. At the time though I was only just beginning my programming career and learning Visual Basic 6 (shudder!) so such a thing was far beyond my abilities. I'm really curious though does anyone know anything about the process or workflow that @Aubrey Hodges used for creating music in the game? Has such a question been raised to him and answered before? Not necessarily saying it's what we should do now (VST instruments did not exist back in the early 90s), but perhaps it might give some insight into how to get into the 'spirit' of making music for this game. Curious how it was done...

Had a quick look at that library and it looks promising - thanks for the suggestion! Something like that would definitely help with handling the specifics of known tracker formats like .xm and .mod etc. I don't think any tool would exist to convert to the PSX DOOM formats though unless someone has cooked up something already based on Erick's source release. That's ok though - I'm familiar with the sequencer now so hopefully should be able come up with a tool given a little time.

Thanks! Because that part of the game is currently off limits - I'm very much motivated to get it working again ;-) It's not going to be a very lag tolerant thing at all and will basically be synchronous multiplayer like the original DOOM. That means it'll just be sending across inputs, and no prediction etc. - which is basically all the link cable did. Hopefully though that should be OK over a LAN at least... Yes indeed, eventually I will add those at a later stage. At the very least I'm going to make the scaling/stretching configurable. I'm considering (slightly) higher resolution support in this port (like Crispy Doom) as well while using the PSX rasterizer, but that mainly depends on how messy it gets. If there's too many code changes then I might keep original PsyDoom to vanilla resolution and do the high res stuff in a fork with a rewritten renderer. Not sure about that - I'll probably be iterating on this for a while at least. My ambition for all this is to make some new maps and music with the PSX engine, and allow for fun stuff that wasn't possible on the original hardware due to memory constraints. That means some tooling (for music) and limit removing work.

Managed to get some demo recordings against the original game out of Avocado - turned out not too difficult in the end. Did a playthrough of map 01 and 02 and tested the resulting demos in PsyDoom. So far it's all looking good - no demo desync! My plan is to build up a library of these demos for every map in the game, that should build confidence in the accuracy of the port. Here is the patch/hack I made for Avocado as well for those who are interested in how it was done: https://github.com/BodbDearg/PsyDoom/blob/master/docs/avocado_demo_record_hack.patch And now that I have control the music sequencer, here's something I did just for fun to hear a fresh twist on the old tracks:

Time for another new build - 0.2.0! https://github.com/BodbDearg/PsyDoom/releases/tag/releases%2F0.2.0 Here is the list of changes in the new version: The music sequencer and sound system is now entirely converted to native C++. The game can now load .LCD (sound sample) files using the current modding/overrides mechanism. This makes it possible to play new PSX maps with sound, such as those found in "[GEC] Master Edition PSX Doom". The game can play now custom maps without having to provide 'MAPSPR--.IMG' and 'MAPTEX--.IMG' files. If these files are not present, the required lumps are loaded from PSXDOOM.WAD instead. The music in Club Doom now loops correctly. Fixed the first 2 seconds of CD audio tracks being skipped. Fix for pause/unpause of cd audio not resuming playback from the previous position. Automap: fix a PSX DOOM bug where lines flagged with ML_DONTDRAW would draw when the computer map powerup is obtained. I'm now done with audio and turning my attention finally to gameplay (the last category of code to be made native), since rendering, audio, ui, base engine and most low level PsyQ stuff is now all done. First immediate goals (aside from converting the gameplay code itself) will likely be to figure out how to record more demos against the original binary, for verification. If I get a lot of demos gathered also it might be nice to automate the demo verification and run the game in headless mode. Another task is to try and figure out the multiplayer stuff, and get that running over local tcp/ip. By doing that also I can implement the last few remaining PsyQ SDK functions (mostly link cable related) and finally remove the BIOS dependency once and for all. I'm VERY close to being able to run without a bios - I did a few quick temp hacks and the game was able to get by just fine without it. Will post up more new builds as interesting stuff is added.

Ah... you are correct. Initially I had thought the damage calculation was being done with respect to a point and not a volume (hence the hitscan bug would not apply) but reading the code in 'PIT_RadiusAttack ' a little more closely I see there is also an adjustment for radius. So yeah, in that case it would cause splash damage to be missed in certain circumstances.

Good call out! I've fixed this in the following commit for PsyDoom. It's a simple change so could easily be pulled into PSXDOOM-RE (and therefore eventually this project) also: https://github.com/BodbDearg/PsyDoom/commit/5a9b4059ac7a18b724edc380c26fa3fc6e548f5a The hidden lines outside the starting point window (on Deimos Anomaly) now don't show, for example:

Yeah seems that way - the effect of the mistake would be to cause MAXRADIUS to be ignored (via overflow), since it only lives in the upper 16-bits and is being shifted up by a further 16-bits. This bug seems pretty harmless to me - probably not necessary. I think the 'MAXRADIUS' addition was intended to make the blockmap search area a little bigger just as a precaution/fudge but it seems unnecessary to me as it already pulls in blocks 'dist' units away (in radius). Since that's the area over which damage falls off (linearly) that should be enough as it is I think... You could even argue that the bug is helpful since it reduces the number of blockmap blocks visited in some cases :P

@Devils950003 Hopefully I should have a fix for that eventually ;-)

So I'm just after noticing an odd bug in PsyDoom and it reminded me of this comment. I mention it since the N64 version is derived from the PS1 port, so presumably carried over a few of it's quirks. I have a quick 60 FPS hack in PsyDoom at the minute that allows me run the game beyond its previous 30 FPS cap - albeit currently with some issues. Tonight, when testing Doom II's 'Entryway' map running at 60 FPS I found myself getting stuck trying to go back through this door from the outside area: When I drop the game back down to its regular 30 FPS cap I can get through the door and past this column just fine. It seems as though some of the sliding behavior in this game might depend on the frame rate that the game is running at. Walls seem to be definitely more 'sticky' when the game is running at higher FPS. I don't know if that specifically is a problem for D64 on PC (due to increased performance) and the game is meant to be demo compatible with the original, so perhaps not. Just thought I'd mention anyway in case it rings a bell for some of the devs.