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

schwerpunk said:

Hey, just butting my head in here to say this is beautiful looking port. Like, really sexy!

One thing I've noticed, and hopefully this hasn't already been mentioned, is that the client hangs for a significant split-second when the music loops (doom.wad).

Thanks very much! I believe that's caused by the SDL_mixer library used, and at this stage I'm not sure how to get around it other than completely revamping the music system. Chocolate DOOM uses the same library: do you get the same amount of hanging using that port? I'll need to test this further in case something else is causing this...

Megamur said:

If you're going to be doing sprite mirroring, have you given any consideration to altering the revenant sprites? The fact that they visibly fire both shoulder launchers, but only let one rocket go, was always a nitpick for me. So maybe you could replace the launching sprites with altered ones where only one launcher is firing, and code the attack animation sprites to randomly mirror themselves so the revenant randomly "chooses" which launcher to fire a missile from. Obviously, this would cause compatibility issues with mods that use altered revenant sprites, but I don't think broad compatibility with mods is a priority of this engine anyway.

I'm likely not to physically alter sprites, because to then include that content with DOOM RETRO has copyright issues, but yeah, I have noticed that "issue" with the Revenant. One idea I had was for the Revenant to fire two rockets instead of one, halving the damage of each, but that might be a bit too much...

bradharding said:

Thank you very, very much NightFright! These look absolutely incredible! Exactly what I want! They will definitely be part of DOOM RETRO's next release (which I'm looking at late January at this stage). I really appreciate all your help with this. Under what name and email address/link do you want to be credited in the release notes?

Great that you like it. It was more work than I thought... didn't expect that I had to squeeze in so much text. xD HELP1/2 were easier after all since Doom 1 help screen has no 1px gaps between lines. This way, there's more space.

For the credits, just use the info from the Duke3D HRP website, that will do. ^^

Also great that the sprite fixes are already in. This could really turn into a very good port (it already is, anyway) with all the little improvement mods I currently load separately already included. Maybe it won't run with all PWADs out there, but for that you have other ports. :)

What's on top of my wishlist right now would be a config tool like the one from ChocDoom and maybe the GUS support which had been added in ChocDoom 2.0. Using native MIDI sucks for me, GUS patches are at least a little improvement - unless you consider soundfont support.

*EDIT Dec 31, 2013*
Another idea that just came to my mind: How about preventing health/armor bonuses from being picked up if you have reached the maximum values (200)? This has always been annoying me in Doom, trying to avoid picking this stuff up if I don't need it, because later if I do, it's not there. Maybe it's something to consider for your port. ^^

Hi,

Another tiny bug.

In file wi_stuff.c the table 'chartoi[130]' has two entries for 26. The second one should be -1.

  25, 26, -1, -1, -1, -1, -1,  0,  1,  2, // 090 - 099

  25, -1, -1, -1, -1, -1, -1,  0,  1,  2, // 090 - 099

jeff-d said:

In file wi_stuff.c the table 'chartoi[130]' has two entries for 26. The second one should be -1.

Thanks jeff-d! Fixed.

NightFright said:

What's on top of my wishlist right now would be a config tool like the one from ChocDoom and maybe the GUS support which had been added in ChocDoom 2.0. Using native MIDI sucks for me, GUS patches are at least a little improvement - unless you consider soundfont support.

One thing I am considering implementing is an in-game console that will allow all the customization people would need, but still keeping everything hidden away and neat. That will be a huge undertaking though.

Since DOOM RETRO uses SDL_mixer, Timidity sound fonts are automagically supported, as described here. Is this what you mean?

Another idea that just came to my mind: How about preventing health/armor bonuses from being picked up if you have reached the maximum values (200)? This has always been annoying me in Doom, trying to avoid picking this stuff up if I don't need it, because later if I do, it's not there. Maybe it's something to consider for your port. ^^

I have considered this, but resorted to only stopping the player picking up health when god mode is on. I'll look into it... Thanks again...

Well, in Chocolate Doom, you can set the path for the GUS patches via the setup utility. I really don't want to create a C:\Timidity dir, I have a custom dir where all my soundfonts and GUS patches reside, and it's on the D: drive. Would be great to have that customization feature at least. ^^

bradharding said:

I have considered this, but resorted to only stopping the player picking up health when god mode is on. I'll look into it... Thanks again...

I also considered this, but there are some PWADs that change the Armour bonuses to other things. E.g. some of the Wolfendoom conversions by Las Rojas (sorry, probably spelt that wrong) change them to treasure chests.

Well, this port won't be too compatible towards mods in general anyway, it seems... but anyway, this pickup behavior is nothing that's a must-have. Just wondered if it makes sense to "fix" it.

After all, you also don't pick up more ammo if you are maxed out already. One could only argue it's a strategic element, so you are supposed to avoid these bonuses if you don't need them (yet).

bradharding said:

To keep it as "Windows friendly" as possible

Not everyone uses Windows, of course. Maybe consider a Linux-buildable source release?

Something with, perhaps, fewer MSVC-isms? Win32 API calls are annoying enough to deal with when attempting to port over. And I hope your processor is the same as mine with that inline assembly.

Chocolate Doom built perfectly fine on a variety of systems using a variety of methods. Your changes sound interesting, if fundamentally uninspired and plain from a map making perspective, but I fail to comprehend how or why you destroyed what was otherwise a multi-platform build system.

- Gio

Giomancer said:

I fail to comprehend how or why you destroyed what was otherwise a multi-platform build system.

Well, the author made it clear that this is essentially his own experimental Doom-based sandbox, never claimed broad vanilla compatibility or cross-platform compatibility, and released it "as is" to whomever may find it useful.

Whether such a port warrants a public release or may appeal to anyone but its author is debatable, but beyond the scope of this discussion, IMO.

Maes said:

...never claimed cross-platform compatibility, and released it "as is"...

I never said he did, did I? Sit down, Maes.

My primary point remains: why kill the cross-platform ability in the first place? If brad doesn't want to update the configure script, I can understand, but the other things I mentioned drive a stake in anyone not running MSVC building DR. To me, that's bad form.

- Gio

Giomancer said:

My primary point remains: why kill the cross-platform ability in the first place?

As I said, this port is primarily the author's personal Dooming sandbox -and that includes programming aspects. If he also wants to try programming hacks that work only on his computer and his developing tools, that's his prerogative. He doesn't have to add cross-compatibility layers on top of his work.

I intend to continue working on DOOM RETRO for a long time. I was always expecting it to be a "niche" source port, not an "everything for everybody" source port that, say, ZDoom may be. If it's important to people to have Linux support, even as "uninspired" and "plain" as DOOM RETRO is, then I will reintroduce that which I took out. This is a learning experience for me, and I'm happy to take any constructive feedback. (I will replace the inline assembly straight away. I wasn't aware it could be a problem, which shows my inexperience. Thank you.)

Maes said:

Whether such a port warrants a public release or may appeal to anyone but its author is debatable

A bit harsh. Clearly you're not a fan, Maes, but on this thread, on the @doomretro Twitter, a few comments on doomretro.com, and emails I've received: there certainly are people who DOOM RETRO appeals to.

That wasn't quite my intention, but the kinds of changes you're bringing to Doom Retro are mostly the kind of changes that could be done either by Dehacked, by DECORATE, or which could be better described as personalizations/tinkering with the engine, in places where normally neither DEH or DECORATE cannot "reach".

I have no problem with a port specializing in hardcoding such changes, but if you try and keep up with every feature request that people might have asked you (some of which, I bet, must be outrageous) sooner or later you'll realize that it's impossible to please everybody, and that this type of customization is better suited for an entirely different type of source port. At which point, it's more efficient to develop a scripting system exposing certain aspects of the engine "to the crowd", and let the crowd gouge their eyes out with it ;-)

And don't forget that, by your own words:

This is a learning experience for me, and I'm happy to take any constructive feedback.

Personally I find it refreshing to see a new port changing and adding stuff just because the dev finds it nice, without caring too much about backward compatibility with dehacked mods or old demos or whatever. It's like the early days are back!

bradharding said:

I intend to continue working on DOOM RETRO for a long time. I was always expecting it to be a "niche" source port, not an "everything for everybody" source port that, say, ZDoom may be.

Thank the stars, too. I am a niche fan, after all.

If it's important to people to have Linux support, even as "uninspired" and "plain" as DOOM RETRO is

Well, it's important to me.. if nobody else is bothered.. *shrugs* It'll be hell for others to port, since it's way beyond my ability to do so.

As for uninspired and plain.. I was referring to the map editing side of things, not the gameplay. One of the reasons I'd like to see it Linux-side is to check out what you've done with that, since it sounds interesting.

This is a learning experience for me, and I'm happy to take any constructive feedback.

Yeah, I was a jackass. I was a bit annoyed and frustrated that day. Apologies.

- Gio (the humbled)

Gez said:

Personally I find it refreshing to see a new port changing and adding stuff just because the dev finds it nice, without caring too much about backward compatibility with dehacked mods or old demos or whatever. It's like the early days are back!

I agree with this sentiment. I personally look forward to if and when brad adds editing features without worrying about what other ports do/have done.

- Gio

Giomancer said:

I agree with this sentiment. I personally look forward to if and when brad adds editing features without worrying about what other ports do/have done.

- Gio

Me too. What's the point of another source port if all it offers is the same as what's already around?

Keep up the good work Brad. :)

Any chance of an option to turn translucency off?

Giomancer said:

Yeah, I was a jackass. I was a bit annoyed and frustrated that day. Apologies.
- Gio (the humbled)

It's all good! :)

What sort of editing features would you like to see implemented guys?

BaronOfStuff said:

Any chance of an option to turn translucency off?

No, probably not. Do you want this option because you find the translucency to be too dark? The next version of DOOM RETRO will use additive blending for the translucency, making everything brighter.

bradharding said:

Do you want this option because you find the translucency to be too dark?

Not really, it's just that I've never liked how translucency looks with the palette restrictions:


Something about it has always just seemed 'off' to me.

BaronOfStuff said:

Not really, it's just that I've never liked how translucency looks with the palette restrictions:
...

Something about it has always just seemed 'off' to me.

I see your point. Explosions are looking better now:



(The white particles are from the smoke trail.)

It’s been only 6 short weeks since the debut release of DOOM RETRO, and yet now I’m glad to announce a new version! DOOM RETRO 1.1 contains several bugfixes and enhancements, (many of which were suggested by members here), as well as a few new surprises. Visit doomretro.com to download and check out the release notes.

I would like to sincerely thank everyone for supporting me in creating a DOOM source port that is new and fresh, and perhaps heading in a different direction to all else that is currently out there. Please keep your feedback coming, either by commenting here, on the website, or on Twitter.

Glad to hear about that widescreen thing! However, Norton is giving me issues. I'm sure it is safe, but Norton is saying it is a Heuristic Virus. I assume that is just because it is an uncommonly downloaded file and stuff, but I just want to make sure nobody else is getting any trouble.

Magnetick said:

Glad to hear about that widescreen thing! However, Norton is giving me issues. I'm sure it is safe, but Norton is saying it is a Heuristic Virus. I assume that is just because it is an uncommonly downloaded file and stuff, but I just want to make sure nobody else is getting any trouble.

It is probably because I'm using UPX to compress the executable. Bad move. I'll correct it right now. Thanks.

The ability to rotate the monsters' sprites at the end of Doom II is cool. I always thought it was a nice feature that permitted to fully contemplate Doom64's art. While I was playing with that, I found a bug: during a monster's death animation, it's already possible to rotate the next monster.

Would you prefer bug reports on Github?

axdoom1 said:

The ability to rotate the monsters' sprites at the end of Doom II is cool. I always thought it was a nice feature that permitted to fully contemplate Doom64's art. While I was playing with that, I found a bug: during a monster's death animation, it's already possible to rotate the next monster.

Would you prefer bug reports on Github?

Thanks, I'll look into it. If you could please submit a bug report on Github, that'd be great! (Have to get used to using it!)

Looking at your new v1.1 release... if you had told me you wouldn't need the background images included with those help screens, I could have given you my templates (only with the text) directly. Would have saved you that effort. Just saying. :P