Kroc

There's also the PSX-PortaDOOM I made here: https://spideroak.com/browse/share/Kroc/PortaDOOM/releases/ This is a self-contained, pre-configured doom engine with PSX-DOOM (and Lost Levels). This will be the easiest to run, but will have less flexibility than rolling your own PK3s with the customizer.

Very impressive, very clean! Well done!

The level of conversion is scarily impressive; even just playing E1M1, it's like I'm playing Dark Forces. This is a crazy level of implementation detail. My only complaint is that high-resolution assets don't match with low-resolution and I'm not a fan of high-resolution textures in general. I personally feel this would look a lot better (and be a smaller download) if you could make a version with low-resolution textures.

This has been great, I really enjoy this series as there's very little good videos out there about 3DO hardware. I've never known about the combined HW/SW floor/ceiling rendering - a clever way of working around the lack of texture offsets in the hardware. Your visualisations are great! Can I suggest that when the white pixel moves through the texture (showing the reading point) that it fades out as it goes so that you can see a reading 'tail', as after YouTube compression, the fast moving white-dot becomes much less clear. Please keep producing these videos, even if you're only covering a small part of the rendering, we all want to learn more about the quirks of the 3DO and its DOOM port (and if it could ever be improved)

I know it's a big ask. It's the kind of thing that needs to start small and build over time because the community as a whole needs to be slowly steered into the right direction of taking compatibility seriously. Look at the HTML/CSS world where there's caniuse.com which can tell you exactly what browsers/versions can use what features. I'd be happy to help with such a tool. I can't program C (only web-languages and Golang, but I might learn Rust), though I can help with testing, information gathering and advanced batch scripting. My launcher can already automate over 30+ DOOM engines/versions.

Love that you're doing this -- command line tools for DOOM formats are seriously lacking making automation very difficulty. I have a project called DOOM-Crusher that unpacks WADs/PK3s, compresses the resources inside (jpgtran/pngout etc.) and then repacks the file. Currently I use a modified version of "lumpmod", an old and creaky tool that lists the contents of WAD files. In order to automate compression, a friendly doomer modified it to include an extra column that gives the file-type of the lump, i.e. JPG, PNG so that I know what lumps to extract without having to extract and examine all of them. If you could add this feature, with a broader set of recognised file-types, that would be helpful to everybody working with WADs. I have another project, PortaDOOM, which is both a launcher and '90s style disk-zine WAD collection. It contains a 1500+ line batch file that can take WAD files and a desired engine and it will launch the engine with all the necessary and correct command-line switches as well as managing config files, save files (separating them by IWAD/PWAD) and numerous other behaviours designed to make a massive variety of engines all behave the 'same'. All of this has taken a great deal of time to build up and good quality DOOM command-line tools make it easier. At this moment I'm working on expanding my launcher to more intelligently manage the highly complex relationship between WADs <> engines <> MODs. Different engines support different features (e.g. Boom, UDMF, DECORATE etc.) WADs might include different amounts of modifying content, e.g. DEH, ACS, ZScript This affects what mods would be compatible, based on what the mod also modifies (monsters, weapons etc.) How this is all managed at the moment is that I work out this compatibility and encode it in some meta-data (command-line params / .ini files) so that PortaDOOM can pass on what a WAD requires and my launcher can find the compatible engines accordingly. This limits my launcher to PortaDOOM's curated list of WADs. What the DOOM world is missing is better tools to test and identify compatibility. Is there any way you can build a tool that can find what features a WAD is using? Are Boom, MBF, SMMU etc. features being used? Is ACS present? Is DECORATE present? Is ZScript present, what functions are being called? (these would narrow down the exact GZDoom version needed) Is UDMF being used? Is this using extended (>32K) nodes? GL nodes? Information about these features is scattered to the winds with no specific details readily available on which engines support what. This can be worked out over time, but we need to begin with the ability to even tell what is being used in a WAD/PK3 file as a guidance to compatibility.

OK, finally completed this; took my time, just over 5 hours. This is definitely the best Wolfenstein WAD I've ever played. Innovative features, great level design and atmosphere (holy crap that secret level), I loved just about every bit of it, looking forward to a pt.III. The only complaint I can levy against it is that the bosses are far too difficult. I play on HNTR because I'm more interested in exploration and I find too many enemies an annoyance, but the bosses take *way* too many hits to kill and there's very little strategy you can employ. At least at this difficulty level the bosses should be nerfed more, higher difficultly levels can stay how they are if nobody else has complained as such.

The prison and boat levels were just amazing!

Excellent, thanks for the tip off!

I'm writing a launcher, and I'm wondering if I can make some educated guesses on compatibility by sniffing the WAD for features; i.e. Boom, ACS, DECORATE, UDMF &c. Existing documentation, in general, is very poor at listing exactly when and where different features became available in different engines, so I additionally have the issue of testing when certain features become available on different engines (I am already compiling a history of release-notes), so if there existed a set of WAD files that used each feature individually, I could narrow this data down. I can code, but I'm not familiar with internal WAD formats, and I feel like this would be better done by extending GZDoom or some-such to spit out a list of stuff it detects during its usual WAD-loading.

I don't make the config file, I allow Chocolate Doom to generate it itself (in a specific location); perhaps its Chocolate Doom that is writing 0 to the config file when it creates it? (with some set of command line parameters triggering the behaviour). Once that default is generated, PortaDOOM makes a personal copy for the user and uses that from there on.

This is the command-line invocation being generated by PortaDOOM's "doom.bat". START "doom.bat" /D "saves\choco-doom\DOOM" "..\..\..\ports\chocolate-doom\chocolate-doom-setup.exe" -width 1366 -height 768 -fullscreen -iwad "C:\Program Files (x86)\Steam\steamapps\common\Ultimate Doom\base\DOOM.WAD" -savedir "." -config "..\..\..\config\default.choco-doom.cfg" -extraconfig "..\..\..\config\default.choco-doom.extra.cfg" This is the "default.choco-doom.extra.cfg" file: And this launches the setup program, if I tick "off" full-screen, then the following is shown. If I then save and launch that, I get a 320x200 window.

Great, been waiting for this for a while for PortaDOOM. There is some strange behaviour if you provide `-width` / `-height` outside of the accepted choices. If you call `chocolate-doom-setup -width 1366 -height 768` then it displays as "0x0" in setup. Perhaps if an invalid size is given, the nearest 4:3 size that would fit within could be selected instead (i.e. 1024x768).

Does this allow you to record commentary on an pre-recorded demo? I.e. if someone wanted to do an analysis of a speed-run they had already completed.

Hi there! The `-config` parameter is not honouring relative paths. I have a project, PortaDOOM, that provides a batch-script launcher that normalises the behaviour of a myriad of different engines and ensures portability by separating out config files, save files and so on. When it launches an engine, the 'current directory' will be where the saves go (for engines that don't support a `-save` or `-savedir` parameter) and the `-config` parameter will be something like "..\config.doomretro.cfg". This works for everything except DOOM Retro that ignores the parameter and creates a "doomretro.cfg" file in the same path as the executable -- not even the 'current directory'!