intacowetrust

Hey @francis247uk I've posted the answer to your question in the PsyDoom thread:

Hey @francis247uk in order for maps to be playable with PsyDoom, they must first be converted to the PlayStation engine's map format. The GEC Master Edition project does that and can run on the real hardware, or in an emulator. It's essentially the Lost Levels, except in PSX engine format and stripped down for the PSX hardware's limitations. I'm planning to add official support for the GEC ME in a future release of PsyDoom, once beta 4 becomes available and some important changes that @Erick194 is currently working on make their way into the project. For now it is still possible to play the levels from the GEC ME in PsyDoom (albeit in a roundabout way) by using the '-datadir' command line argument. I've described the process for doing that here:

Creating this thread to document and publish some strange stuff I ran into recently for PSX Doom, which was discussed on the GEC Team Discord server. Maybe somebody else has noticed this before, not sure, but I'll throw it out there anyway... Perhaps some of you might know something or have an idea :) In PSX Doom sectors have a new field added for flags, similar to the flags field already present for linedefs and things. In the retail game just 1 bit (the lowest bit) of this 16-bit field is used, and it controls whether a sector uses reverb for its sound effects or not. Typically this is used to disable reverb in outdoor areas, when set. No other bits of the flags field are used in the retail machine code, as far as we can tell. For PsyDoom and upcoming versions of the GEC Master Edition we decided to repurpose one of these unused bits (the next one up, 0x2) to achieve a new effect similar to self referencing sectors on the PC. The new flag would enable 'invisible' floors, by making a floor render at the height of the lowest sector surrounding it. This would allow maps from say Plutonia, to be converted more faithfully to the PSX engine and enable invisible bridges like this one: So this idea worked great initially, until I started testing some maps from the original game, and noticed things like this: Oh no - the new invisible floor trick is being applied where we don't want it! So it turns out that some of the sectors in the original game were already using this flag (0x2) for some reason. To investigate further, I did a quick pass through both Doom and Final Doom and found it used in the following maps: Doom map usages (flag 0x2): 04, 05, 06, 07, 10, 14, 18, 21, 23, 28, 29, 33, 34, 35, 39, 41, 44, 45, 46, 47, 49, 50, 54, 55, 57, 58, 59 Final Doom map usages (flag 0x2): 06, 07, 08, 14, 15, 17, 18, 19, 20, 23, 24, 25, 26, 27, 28 Next, I thought well why not try the next bit up for the new flag we want to add, 0x4. Sure enough I found sector flag 0x4 used in the following maps in both Doom and Final Doom: Doom map usages (flag 0x4): 04, 05, 06, 07, 09, 10, 14, 18, 19, 27, 28, 29, 30, 33, 34, 35, 39, 41, 44, 45, 46, 47, 50, 54, 55, 57, 58, 59 Final Doom map usages (flag 0x4): 03, 06, 08, 14, 15, 17, 18, 19, 20, 23, 24, 25, 26, 27, 28, 29 So I kept repeating this experiment and searching for a single bit (out of the 16 available) in the flags field which WASN'T already in use in either Doom or Final Doom. Turns out every single bit in the flags field has at least one usage in either Doom or Final Doom. Perplexed by this, I applied a very quick hack to PsyDoom's Vulkan renderer to help visualize when these mystery sector flags are used. The hack colors sector floors and walls in a solid color, based on which flag bits are set. Here are some screenshots from various different maps showing where the mystery sector flags are used: Very very strange... Some patterns I've noticed with these flags, is that they tend to be used a lot around key doors or keys but that's not always the case. For example in the "Unruly Evil" screenshot the torch light sector has the mystery flags set for some reason. "Club Doom" also has the flags set all over the place. Initially I thought the flags might have been some leftover from a feature that was abandoned earlier in development. Seeing that these flags were carried over to Final Doom and apparently very deliberately set throughout the maps makes me think otherwise, however. At a high level it seems like these flags might have been used for development purposes, but it's unclear exactly what their use was. Some ideas I had was that they were used for some sort of editor tagging functionality, or perhaps to offer hints to the nodebuilder on how to split up the map. It's also possible different bits of the flags field might have had very different purposes - which might further confuse the matter. Anyhow, that's a quick overview of what I ran into. A little bit of a mystery that maybe we'll never solve, but interesting nonetheless. Feel free to comment if you have any interesting theories! And of course if you want to play around with this visualization hack for PsyDoom and explore further, the code is here: https://github.com/BodbDearg/PsyDoom/blob/f7c35c4304913e40119ad4d48de9c3c0d7e5aeba/extras/psydoom_code_hacks/view_unknown_psx_sector_flags_hack.diff

Yeah who knows, maybe we'll get lucky and he might pop on at some point to explain - assuming he can recall that is... (it was a long time ago at this point) Yeah something lighting related was one of the theories we discussed on the GEC Discord. There doesn't seem to be any definitive connection however between lighting and the appearance of the flags from what I can tell, or at least no consistent one. It does seem to occur a lot around key doors though, which often have colored lighting applied as a hint. What a strange mystery... Another (less interesting) theory might be that we are just looking at junk data which was not properly initialized. Maybe whatever editing tools were used just initialized that single bit that was used (for reverb) and the rest of the bits were left as garbage/undefined values. Perhaps the tools to import maps from the PC also tended to cleanly initialize/define the flags field to '0' so the garbage mainly occurred in new sectors that were edited after that?

Yeah it's a bug you ran into - the comparison for file overrides should be case insensitive. Coincidentally I was working on fixing this issue tonight; in the next release you shouldn't need to worry about case.

Some fun with NUTS.WAD:

Heh... I don't know about that but if someone wants to compile without the limit removing stuff then you can just do the following in CMake (uncheck this box): Also for more accurate Z_Malloc behavior, target 32-bit when generating the project: The memory heap in PsyDoom is much larger (2x) in the standard 64-bit build, because I have to make it that way to account for larger 64-bit pointers and extra size for some of the data structures. This compensation is probably overly generous in most situations and will allow you to go over the limits of what the original hardware could do. //------------------------------------------------------------------------------------------------------------------------------------------ // How much heap space is available to Doom's zone memory allocator, via functions like 'Z_Malloc'. // // The heap space available was roughly as follows for the original games: // - Doom : 1,368,380 bytes // - Final Doom : 1,357,328 bytes //------------------------------------------------------------------------------------------------------------------------------------------ static constexpr uint32_t Z_HEAP_SIZE = 1368380 * (IS_64_BIT_BUILD ? 2 : 1);

Thanks for reporting @Chris0neilson - had forgotten about this slight discrepancy, will check it out!

No you're right, these changes will be for a niche audience only. Mainly for mappers who want a very authentic PSX look, sound and feel but with some of the crushing limits of the real hardware removed. PsyDoom can also be used as a quick way of testing and iterating for those wanting to target the real hardware, and it will be possible to produce custom builds of PsyDoom that have many of those limits restored for that purpose. I'm hoping as well some of the work in this port can possibly be incorporated into other ports to improve efforts like the PSX TC. On the ZDoom forums I left an anonymous post (because my 'intacowetrust' user somehow got deleted) about how the PSX lighting & shading could maybe be incorporated into GZDoom: https://forum.zdoom.org/viewtopic.php?f=18&t=71282&sid=675fceb732dcc2f055fa43f9b07e22a8&start=15#p1184715 Someone was also asking @bradharding about adding PSX style reverb to Doom Retro: https://github.com/bradharding/doomretro/issues/29 It would be possible to route sounds through PsyDoom's 'SimpleSpu' module for that purpose, it's very self contained and should be easy to integrate with other projects: https://github.com/BodbDearg/PsyDoom/blob/master/simple_spu/Spu.h https://github.com/BodbDearg/PsyDoom/blob/master/simple_spu/Spu.cpp The PsyQ SDK reverb presets can be found here: https://github.com/BodbDearg/PsyDoom/blob/master/game/PsyQ/LIBSPU_Resources.cpp

Just put up another new build of PsyDoom, 0.7.4. It can be downloaded from the usual location: https://github.com/BodbDearg/PsyDoom/releases This build contains some limit removing features originally planned for 0.8 and a few bug fixes. The main motivation for this build is to fix the 2x speed exploit but it's also a chance to sneak in a few other small improvements before I dive deep into 0.8 work and exploration, which could take some time. Here is the changelist for the 0.7.4 build: Feature changes & improvements (0.7.4) Add a new '-turbo' command line parameter that enables the 'turbo mode' cheat. Turbo mode allows the player to move and shoot twice as fast, and doors and platforms also operate twice as fast. Vulkan renderer: draw an extended in-game status bar for widescreen mode, using the existing HUD assets. Can be disabled however if letterboxing is preferred. Allow an input key to execute a 'pause' and 'menu back' action at the same time. This allows a key such as 'Escape' to go directly from gameplay to the options screen, bypassing the intermediate 'pause' screen. Change the default key bindings also so that 'Escape' goes directly to the options menu. Vulkan renderer: add a small tweak to make sky scrolling smoother. Engine limit removing: no longer load .IMG files (containing sprites and textures) for maps, instead load resources from WAD files. This makes modding easier since it removes the need to produce these files. We also don't need to worry about lump number references in .IMG files being invalidated if we add new lumps to the main IWAD. Classic renderer limit removing: fix view corruption for tall cliffs of 1024 units or more in height; fix a numerical overflow issue. Spu limit removing: extend SPU RAM to 16 MiB by default and make the amount configurable. Will allow any monster variety on a map without worrying about exceeding SRAM limits, and plenty of SRAM for new music and SFX etc. Spu limit removing: extend the number of available voices from 24 to 64. This should allow PsyDoom to handle even extremely busy scenes and music without dropping any sounds. Spu limit removing: upgrade audio processing and mixing from 16-bit to floating point quality. Improves precision and eliminates distortion on loud sounds caused by audio clipping. Spu: add dynamic range audio compression to limit the strength of very loud sounds. Required since audio loudness is almost unlimited and does not clip anymore with the float SPU. The compression is very light in most cases and barely noticeable until very loud situations occur. Bug fixes (0.7.4) Fix an exploit where it was possible to move at 2x speed if using analog and digital movement at the same time. Fix an original and PSX specific audio bug that could sometimes cause enemy and player sounds to cut out prematurely. The logic for stopping a missile's spawn sound on explode was slightly flawed, and causing other (unintended) sounds to be stopped instead. Vulkan renderer: fix a failure to redraw the screen while connecting to a multiplayer game, after resizing the window. Debug builds: fix Vulkan validation layer errors on starting a multiplayer game and on encountering an error during a multiplayer game. Windows debug builds: fix an error printed to the console about invalid command line arguments when there are no arguments specified. For 0.8 I'm going to be focusing on extending the engine and removing limits. As part of that work I'm going to be going through the process of making a new (engine stressing!) map along with adding new graphics and new music. It should be a fun chance to explore the possibilities now that the project has made it to this stage, and something I've been looking forward to for a long time.

Not yet - it's something I'll be looking at eventually once all the main features for PsyDoom are done and dusted. This is what I had in the interim (feel free to use if you like): The final logo will likely be just an evolution/polishing of this.

@Redneckerz thank you so much for taking the time to put this together - it looks great! :) Happy to hear you are both enjoying the new renderer! :) Thanks for the suggestion and as @Lollie mentioned the best thing for that (and my current thinking too) would probably be to have a separate launcher. PsyDoom already has a '-cue' launch parameter that you can use to specify the disc with, so a launcher could just use this. In the meantime you can also use this parameter to create shortcuts or scripts to launch the game disc of your choice. Another workaround would be to create two separate folders for the Doom & Final Doom discs, and copy the same .exe to both places.

Thanks @Gez, I'll submit a pull request shortly! :) Heh... that was not intentional, that's for sure! Thanks for bringing this bug to my attention. Although I will have to fix the issue I don't want to spoil the fun people are seeming to have with the exploit, so perhaps the 2x 'turbo mode' could be formalized as a command line parameter or cheat setting.

You can point the -datadir directory to wherever you like on your local machine. If it contains any of the files that are on the disc then PsyDoom will use those versions of the files instead. That way you can overwrite existing maps etc. I added new textures by overwriting the entire of PSXDOOM.WAD with an edited version containing the new textures. Not exactly ideal but it works for the moment. I also had to hex-edit the texture lumps to get them into the PSX Doom format, as well as hex editing the TEXTURE1 lump to add entries for the new wall texture. I've just made a small change to my own fork of SLADE however that can make it do the conversions to the PSX texture format; I might try to see if this would be accepted as a pull request: https://github.com/BodbDearg/SLADE/commit/fad8c553561d1f6afd0077459d26b3533170f915 I also plan to eliminate the use of the TEXTURE1 lump in PsyDoom to make modding easier. It's just there basically as a way of telling how big a texture is without actually loading it, but I think I can bypass/ignore this completely now for PsyDoom.

Interesting thing I found on MAP46, The Courtyard: A while ago I put in this warning as a new PsyDoom feature to help map makers and forgot about it; recently however I noticed it triggering on this map. The warning tells you if you've run out of SPU RAM after loading the level. It appears that this issue is responsible for the Cacodemon death sounds not playing on this level. I did a little work this evening to raise the available SPU RAM from the original 512 KiB to a configurable amount (now defaulted to a very generous 16 MiB) and it appears that this fixes the Cacodemon sound issue. So if you're wondering why the Cacos don't play death sounds on this map, lack of SRAM is the reason why...

Hey @Tarvis thanks for the good suggestion! I have this on my list to take a look at for the next release.

Hey everyone just put up a new release (0.7.3) with more fixes, including one for AMD GCN 4 cards: https://github.com/BodbDearg/PsyDoom/releases Here is the changelist: Feature changes & improvements (0.7.3) Vulkan renderer: add the ability to specify a preferred GPU device to use, useful for manual selection in multi GPU systems. Bug fixes (0.7.3) Fix graphical corruption issues on AMD GCN 4 cards and possibly other AMD GPUs. Fix discontinuities and 'wobbling' of the sky for some scenes, particularly at lower draw resolutions. W_ReadMapLump : fix a crash with reading uncompressed map lumps (affects user maps). P_LoadSectors : issue a descriptive error when a flat texture is not found rather than crashing.

Makes sense, thanks for confirming! That is correct; you could probably use the GEC Master Edition tools written by @Erick194 to rebuild and potentially fix the issue. The 'file overrides' mechanism that PsyDoom has can be used to load the new version of the map. You can use it to do new maps too, of course... Here's one I'm currently experimenting with for example, with some new textures from OTEX that I managed to hack in:

An maith leat Gaillimhe? Being from Ireland and as someone who keeps a close eye on the Irish Games industry, I'm curious to hear about your experiences so far setting up a development studio there. What are the benefits you have found and are there any areas you feel that could be improved upon to encourage more game development within Ireland?

I believe it would, but I have not checked.

Yessssss!!! Finally! Thank you so much for being patient and for helping me diagnose this issue :) I should have a build with this fix available soon. You're welcome, glad you're finding that feature useful! Thanks for reporting! Yeah noticed this before - there is something weird with the nodes/data for that particular map at that location. It happens in the classic renderer too: Unfortunately there is not much that PsyDoom can do about this since it's bad map data and non-trivial to fix. The map and BSP tree etc. would need to be rebuilt to try and solve this.

Got the AMD card delivered. Tried playing around with it and used various different settings and toyed with the AMD driver settings (adaptive sync etc. etc.) but was still unable to reproduce any of the GCN 4 issues. @SaladBadger curious if the following commit on the 'develop' branch makes any difference for you at all: https://github.com/BodbDearg/PsyDoom/commit/2fd3e8b87b97fe79b6b1034bae2d980a9c968b51 There were some parts of the render pass setup that were being defaulted and handled by the driver - perhaps this is where issues could be creeping in. I'm going to try and be explicit and spell out what PsyDoom needs there even though that seems to cause no issues on most cards; perhaps the AMD driver for GCN 4 is trying to do something clever which is breaking synchronization.

I could perhaps make the game log generated passwords to a text file so you can go back and retrieve old ones, would this help? Scrolling in the PSX UI might be a bit slow/tedious. I also have it planned to do a proper save file feature eventually, so I'm figuring this will eventually become the preferred method of saving progress for PsyDoom users.

Thank you for the screenshot! Very interesting patterns there, like you can almost see where the GPU has divided up particular parts of the screen into tiles. The middle diagonal is probably due to the two triangles used for full screen MSAA resolve step. Presumably the timings worked out more favorably for the other triangle and there was no corruption.

Thank you both for confirming, glad to hear it's now working! :) So to summarize it sounds like after all of the feedback so far we are down to just issues on these cards: Radeon RX 580 (@SaladBadger) Radeon RX 570 (Reported by Whiteysnakey on the GEC discord) Radeon RX 560 (@Tarry) Interesting that they are all GCN 4 cards - I wonder if there are problems on that specific GPU architecture? I updated my Vulkan SDK to the very latest also, so I would have the most up-to-date version of the 'synchronization' validation layer. Apparently this tool is now out of the alpha phase and ready for full use according to the previous SDK version release notes: https://vulkan.lunarg.com/doc/sdk/1.2.162.1/windows/release_notes.html There is even a whole section in the tool docs on how it should be used to optimize synchronization to ensure that you are only doing the minimum amount of blocking ("Optimizing Synchronization with Synchronization Validation" section): https://www.lunarg.com/wp-content/uploads/2021/01/Final_Guide-to-Vulkan-Synchronization-Validation_Jan_21.pdf It sounds like they are pretty confident in its abilities to flag sync problems now, which sucks because it is not finding anything else with the synchronization code. I'm almost tempted to say "driver issue" but that should always be the last assumption. Hopefully the test hardware can reveal something, though if it's now sounding GCN 4 specific maybe not... Yeah I would have tiled the menu screens but the graphic does lend itself to that unfortunately without new artwork; the options background can tile but it would look weird switching between a widescreen UI versus non widescreen when exiting out of options. There's also the added complication that user mods (which target the real hardware, via the GEC toolchain) might override the background so that wouldn't be widescreen aware either. This might also conflict with any new widescreen artwork added... PsyDoom should be able to work with such mod discs eventually, once official support is added for the GEC ME. In the end it seems the best option is to just leave the extended areas of the UI alone, since it serves no useful purpose anyway. It's a limitation of the port but one I don't think is ultimately that important... Possibly, I've been thinking about how to do that actually - it's a little tricky but will make a note to look at it. The problem is that the escape key also serves as a 'back' option in menus and going to the options screen is actually two separate steps, the combination of a pause + menu back action as per the original game. Maybe ESC could combine both of those actions in certain situations, or a new action could be added which takes priority over the 'menu back' that directly goes to options and directly back to the game (without the intermediate 'paused' screen). Yeah I thought about CRT shaders, I think these are best handled externally by post-fx tools that are constantly maintained and updated like 'ReShade'. I had tested it's basic CRT shader before and it looked OK, and here is CRT-Royale in PsyDoom (classic renderer, but you can of course use it with Vulkan too):