DOOM Retro v5.2.1 (updated January 12, 2024)

fraggle said:

Great to see another Chocolate Doom fork!

Unfortunately I can't try it out because I don't have anything resembling a Windows machine, but hopefully someone will port it to other platforms.

I really appreciate and respect the fact that you have a clear vision of what you want the source port to be, and I like the "subtle enhancements" philosophy. It reminds me of perkristian's remastered SFX and weapon animations. Would it make sense to include those with DOOM RETRO?

Thanks Fraggle! DOOM RETRO wouldn't have been possible without your hard work on the excellent Chocolate DOOM! (At one point, I was thinking of calling the port "Cookies 'n' Cream DOOM".)

Hmm, those mods certainly would work well with my vision. I'll add them to the list... :) Thanks again!

fabian said:

Cool source port! Could you please make the source code available in a VCS?

Thanks. And absolutely! I'll put it up on Github as soon as I am able...

I found a bug: Flying monsters can enter inside other things like this pole. The player can also do the same if he jumps on something. If I remember correctly, all objects like this (lamps, trees, flying heads...) have a height of 16, because it doesn't matter for them in vanilla-Doom.

axdoom1 said:

I found a bug: Flying monsters can enter inside other things like this pole. The player can also do the same if he jumps on something. If I remember correctly, all objects like this (lamps, trees, flying heads...) have a height of 16, because it doesn't matter for them in vanilla-Doom.

Ah, so I may have to alter each height to better represent each object. The Caco didn't get stuck, did it?

bradharding said:

Ah, so I may have to alter each height to better represent each object. The Caco didn't get stuck, did it?

No, he didn't.

I would be careful with implementing the "Smooth Weapon Animations" mod from Per. While it's certainly cool, keep in mind this will break PWADs which have custom weapons. They replace only those frames which were in the original game, while Per's mod adds many more.

Maybe you could implement them like a switch via the ingame menu, so you can turn the enhancement off for mods that break otherwise. That would actually be quite a cool thing to have.

[On a side note, we improved PerK's mod a bit some while ago. A few changes we made could be reversed if needed, such as the flipped pistol hand and the gloved fists. I am not 100% satisfied with the way the BFG turned out, but at least it's less static than in the original game.]

Implementing the sound mod is no problem at all, any PWAD can override those sound replacements again if needed.

Another bug: Archviles can resurrect monsters that are crushed under doors. It can also resurrect a monster under him, so both monsters will be stuck inside each other.

Edit: The Icon of Sin takes 8 rockets before it explodes.

axdoom1 said:

Another bug: Archviles can resurrect monsters that are crushed under doors. It can also resurrect a monster under him, so both monsters will be stuck inside each other.

Edit: The Icon of Sin takes 8 rockets before it explodes.

Thanks again axdoom1! Argh! I thought I had fixed that vanilla bug! But as for an Archvile raising a monster underneath him... I can see I didn't accommodate for that. I'll look into the Icon of Sin as well. So much to do, and not a good time of year to do it...!

NightFright said:

I would be careful with implementing the "Smooth Weapon Animations" mod from Per. While it's certainly cool, keep in mind this will break PWADs which have custom weapons. They replace only those frames which were in the original game, while Per's mod adds many more.

Maybe you could implement them like a switch via the ingame menu, so you can turn the enhancement off for mods that break otherwise. That would actually be quite a cool thing to have.

[On a side note, we improved PerK's mod a bit some while ago. A few changes we made could be reversed if needed, such as the flipped pistol hand and the gloved fists. I am not 100% satisfied with the way the BFG turned out, but at least it's less static than in the original game.]

Implementing the sound mod is no problem at all, any PWAD can override those sound replacements again if needed.

You're right. But I guess with what I'm trying to achieve with this source port, I'm always going to run into danger of breaking mods. But that's okay, there are other ports out there, and I plan on finetuning this beast for years to come. Not too keen on adding additional options, as I want to keep everything clean and minimalist.

I do not understand exactly the "minimalism" in your approach, as a lot of changes seem the result of someone experimenting/playing with the SC in order to achieve some of the effects achievable with scripting on source ports that have long diverged from vanilla or even plain Boom. Any idea how far you have diverged from vanilla demo compatibility at the current state?

Maes said:

I do not understand exactly the "minimalism" in your approach, as a lot of changes seem the result of someone experimenting/playing with the SC in order to achieve some of the effects achievable with scripting on source ports that have long diverged from vanilla or even plain Boom.

By "minimalism" I was referring more to altering the in-game menus, and presenting the user with a lot of config options, preferring instead to keeping things clean and simple, and looking at alternatives for things to "just work". I know I may not have implemented some features in the best way possible, and will continue to look for alternatives. This is a learning experience for me...

Any idea how far you have diverged from vanilla demo compatibility at the current state?

Demo compatibility is pretty broken at this stage, and I hope to return to it eventually. I'm thinking maybe implementing a completely new demo recording system, if that's feasible. Recording video.

I saw this and looked over the change list this morning before work. A couple things that stuck out to me as issues:

- Preventing monsters from entering sector heights they could originally enter is going to mean some monsters spawned in stuck positions where they can't move, and other monsters being incapable of entering places they're clearly supposed to. This is the kind of thing that unfortunately IMO just has to be lived with, as there's no way to get around it without noticeably breaking gameplay in a lot of maps.

- Resetting the player's health to its pre-IDDQD state when disabling degreelessness mode means that a useful playtesting feature of IDDQD is eliminated: the ability to enable and then disable it to reset the player to 100% health.

BTW, have you considered additive blending for some of your translucent objects (projectiles in particular)? Translucently blending a bright projectile with its surroundings will mean making it darker and dimmer as a result of the combination, but additively blending it will allow it to still pop out brightly from the background.

esselfortium said:

- Preventing monsters from entering sector heights they could originally enter is going to mean some monsters spawned in stuck positions where they can't move, and other monsters being incapable of entering places they're clearly supposed to. This is the kind of thing that unfortunately IMO just has to be lived with, as there's no way to get around it without noticeably breaking gameplay in a lot of maps.

Good point. It's just the Arch-vile and Revenant whose heights I've changed. Easily corrected.

- Resetting the player's health to its pre-IDDQD state when disabling degreelessness mode means that a useful playtesting feature of IDDQD is eliminated: the ability to enable and then disable it to reset the player to 100% health.

Hmm... I've never used IDDQD for that. Something to consider...

BTW, have you considered additive blending for some of your translucent objects (projectiles in particular)? Translucently blending a bright projectile with its surroundings will mean making it darker and dimmer as a result of the combination, but additively blending it will allow it to still pop out brightly from the background.

I recall working on additive translucency at one point, but I think I had some difficulty with it. Thanks esselfortium, its definitely worth revisiting...

Not really any major bugs to speak of, aside from the few minor things mentioned by others.

Anyway, a minor cosmetic issue: The mirrored deaths feature is great, but one of the monsters, the Cyberdemon, doesn't really work well with it. When the Cyberdemon uses the mirrored death, its rocket launcher can be seen to switch sides. This is the only mirrored death that is noticeably "off", all the other monsters look okay with it.

TheUltimateDoomer666 said:

Not really any major bugs to speak of, aside from the few minor things mentioned by others.

Anyway, a minor cosmetic issue: The mirrored deaths feature is great, but one of the monsters, the Cyberdemon, doesn't really work well with it. When the Cyberdemon uses the mirrored death, its rocket launcher can be seen to switch sides. This is the only mirrored death that is noticeably "off", all the other monsters look okay with it.

Thanks for this. I'll change it so the Cyberdemon doesn't have a mirrored corpse. The feature is only of benefit when there are lots of corpses of the same type of monster in the one area anyway, and (hopefully) you're not going to be confronted by more than one or two Cyberdemons in the same area too often.

Ah, from what I can tell, you want this to be between a fancy source port like Boom and a simple source port like Chocolate Doom? This could work. Improve the mouse support, controls and settings. Add in some kind of wide screen support and I'd use this regularly.

Magnetick said:

Ah, from what I can tell, you want this to be between a fancy source port like Boom and a simple source port like Chocolate Doom? This could work. Improve the mouse support, controls and settings. Add in some kind of wide screen support and I'd use this regularly.

That's right. I'm trying to find a nice balance between the two types of source ports.

Thanks for the suggestions. What specifically would you like me to improve with the mouse and controls? Is it a matter of allowing them to be customized, or do you have something else in mind?

As for widescreen support, I'm not sure. I feel the 4:3 aspect ratio is something that needs to stay as is, to keep DOOM RETRO... retro.

esselfortium said:

- Preventing monsters from entering sector heights they could originally enter is going to mean some monsters spawned in stuck positions where they can't move, and other monsters being incapable of entering places they're clearly supposed to. This is the kind of thing that unfortunately IMO just has to be lived with, as there's no way to get around it without noticeably breaking gameplay in a lot of maps.

Sprite frames for the rev and barons to duck down to their actual height? ;0)

You will include an external config tool like they have for ChocDoom? I'd really like to tweak settings like resolution (even if it's just about scaling), keys, MIDI device etc without having to mess with config files.

Speaking of which, you only support Windows MIDI device right now or also GUS like in ChocDoom v2 branch? Because that sounds a lot better, at least for me. Unless you add an option to use soundfonts. ^^

About the PerK animations:
Well, if you say straight away: "My port won't work with PWADs that feature modified weapons" - absolutely fine by me. I don't like those so much, anyway. And those smooth weapons really look wonderful. It's hard to go back to the original versions once you have used those. Too bad they break savegame compatibility in ZDoom (for example) if removed (which wouldn't be a problem if you implement them directly into the port, though).

This looks like a really awesome port, congrats on getting started. :)

I may try to run this in Wine at a point, since I don't have Windows. But all the same, I'm wondering if you might consider putting up the source code on GitHub? Maybe even by forking http://github.com/chocolate-doom/chocolate-doom so you can easily merge changes between. Not trying to demand anything but it may help for collaboration and potentially porting it to other OSes too :)

bradharding said:

That's right. I'm trying to find a nice balance between the two types of source ports.

I don't know how possible that is -at least I'm not aware of any port that attempted this, without practically being a recreation, rather than a port. Certainly, e.g. ZDoom has forfeited demo compatibility a long time ago, and rather than hardcoding specific behaviors in the source code (which practically makes a port only its programmer's plaything), has an extensive cvar and scripting system exposing all those innards. Eternity also pretty much does this, but with a different cvar/scripting system altogether.

What I mean is, that at some point, the temptation to go full-fledged scripting will be nearly irresistible, especially after even the programmer gets tired of recompiling at every change ;-)

If I may suggest a different approach, that would be e.g. loading the various hardcoded state_t etc. tables from an external human-readable format, easier to read and edit manually than e.g. DEHACKED (JSON or XML notation would be cool), as part of the source port's normal operation (so they would no loner be compiled along with the .EXE, but entirely dynamically loaded at runtime).

Maes said:

(JSON or XML notation would be cool),

DECORATE would be better.
Those general purpose definition languages have the problem that they are ill suited to the specifics of how Doom states work so they inevitably end up more verbose than would be good.

Maes said:

If I may suggest a different approach, that would be e.g. loading the various hardcoded state_t etc. tables from an external human-readable format

You mean, like DDF, DECORATE, or EDF? :p

Okay, I guess JSON is more hype.

Maes said:

What I mean is, that at some point, the temptation to go full-fledged scripting will be nearly irresistible, especially after even the programmer gets tired of recompiling at every change ;-)

If I may suggest a different approach, that would be e.g. loading the various hardcoded state_t etc. tables from an external human-readable format, easier to read and edit manually than e.g. DEHACKED (JSON or XML notation would be cool), as part of the source port's normal operation (so they would no loner be compiled along with the .EXE, but entirely dynamically loaded at runtime).

Thanks Maes, this sounds like a great idea. It was something I was considering (state_t and mobjinfo_t in info.c at least), but one thing at a time... :)

chungy said:

This looks like a really awesome port, congrats on getting started. :)

I may try to run this in Wine at a point, since I don't have Windows. But all the same, I'm wondering if you might consider putting up the source code on GitHub? Maybe even by forking http://github.com/chocolate-doom/chocolate-doom so you can easily merge changes between. Not trying to demand anything but it may help for collaboration and potentially porting it to other OSes too :)

Thanks, chungy! I'll be putting up on GitHub at some point, but want to tidy up the code some more beforehand. I probably won't fork Chocolate DOOM, as it has already deviated too far from it.

As far as demos go, I've never understood why someone hasn't made a stand alone demo player. I know PrBoom+ has lots of demo features but, honestly, it's pretty intimidating for a new comer to get into. A simple player where you can just drag a file onto it's exe like any other demo player would be great. Maybe something like that could be a sister project to DoomRetro? That way you would never have to worry about bloating the game engine and you wouldn't have to worry about retaing compatibility as your engine develops. Just a thought. :)

bradharding said:

I probably won't fork Chocolate DOOM, as it has already deviated too far from it.

That's a pity. I was hoping you could slice out some separate patches, e.g. the one for resolution doubling, as this might be one that I'd like to apply to my own chocolate-doom builds.

I suspect that the two codebases have diverged enough that it's probably more effort than it's worth. Brad can quite easily cherrypick individual changes for inclusion if he wants, though.

bradharding said:

The same goes for 32-bit rendering. I looked into it, but as with the resolution, I feel that the 256 colour palette is part of DOOM's vanilla charm.

Maybe, but have you seen the screenshots from _bruce_'s Chocolor Doom? If done carefully, I think 32-bit rendering can be "subtly enhancing" in a way that might fit in nicely. Ultimately it's your project though :)

fraggle said:

I suspect that the two codebases have diverged enough that it's probably more effort than it's worth. Brad can quite easily cherrypick individual changes for inclusion if he wants, though.

Exactly. I diverged some time ago, and I didn't start with the v2-branch. And have been cherrypicking here and there ever since.

fraggle said:

Maybe, but have you seen the screenshots from _bruce_'s Chocolor Doom? If done carefully, I think 32-bit rendering can be "subtly enhancing" in a way that might fit in nicely. Ultimately it's your project though :)

Yes, I've checked out _bruce_'s great work, and at one point I was contemplating implementing 32-bit color but... I like the idiosyncrasies of the 256-color palette too much (especially after implementing the darker gamma levels).