DOOM Retro v5.3 (updated March 3, 2024)

[JackBoi]

6 minutes ago, Endless said:

you could probably try an edit the r_gamma command. By default it's set at 0.90, which is a bit dark. You can also try r_ditheredlighting off and r_graduallighting off (by default both are ON).

this does not fix the issue, the hand is still noticeably darker, and the level still doesn't appear to be affected by the limited color as it is in other sourceports.

[bradharding]

On 1/31/2022 at 2:53 PM, Breezeep said:

Hey, I dunno if anyone else pointed this out yet, but there's an issue when the cyberdemon's sfx don't really fall off properly when you're far away from it

As others have said, yes, this is vanilla behavior but I'm not particularly keen on it and will consider "fixing" it.

 

On 2/1/2022 at 6:33 AM, JackBoi said:

i am very certain that the lighting in doom retro is different than lighting in other sourceports (it seems to be noticeably darker), is there any way to make it look like other sourceports?

Yes, DR's lighting is darker by design and won't change. The lighting of the player's weapon is deliberately different and better matches the lighting of the sector that the player is standing in, if compared with vanilla.

[ludicrous_peridot]

Hey, congrats on getting the new version out!

One thing I am curious about - and pardon if this was asked before - is why for actors there are 3 separate Name attributes (6 with plurals) that can be set via DEHACKED, but for weapons, names are only assigned in the code as per the wads loaded... or am I missing something? 

[bradharding]

4 hours ago, ludicrous_peridot said:

Hey, congrats on getting the new version out!

One thing I am curious about - and pardon if this was asked before - is why for actors there are 3 separate Name attributes (6 with plurals) that can be set via DEHACKED, but for weapons, names are only assigned in the code as per the wads loaded... or am I missing something? 

Because I haven't got 'round to doing that yet. I'll look into it soon.

 

EDIT: And done.

Edited February 3, 2022 by bradharding

[PKr]

I just wanted to tell you that Doom Retro has the absolutely best and most tasteful blood system out of all modifications I have ever seen, period. After I saw it for the first time a few years ago in your source port I wish I could have it in every single source port I play. It simply feels like a legacy feature of Doom. 😔

 

Could you possibly think about working on mods for other source ports? Idk, maybe crispy doom, or gzdoom, or wherever it is possible to recreate/emulate your ideas? I have no indepth understanding of source ports, so sorry if that question may sound too stupid. 

[Gibbon]

23 minutes ago, PKr said:

Could you possibly think about working on mods for other source ports? Idk, maybe crispy doom, or gzdoom, or wherever it is possible to recreate/emulate your ideas? I have no indepth understanding of source ports, so sorry if that question may sound too stupid. 

I guess that would be up to the authors of those source ports 'if' they want such features changed /added.

 

But yes Doom Retro rocks!

[bradharding]

15 hours ago, PKr said:

I just wanted to tell you that Doom Retro has the absolutely best and most tasteful blood system out of all modifications I have ever seen, period. After I saw it for the first time a few years ago in your source port I wish I could have it in every single source port I play. It simply feels like a legacy feature of Doom. 😔

 

Could you possibly think about working on mods for other source ports? Idk, maybe crispy doom, or gzdoom, or wherever it is possible to recreate/emulate your ideas? I have no indepth understanding of source ports, so sorry if that question may sound too stupid. 

 

Thanks. I've put a lot of effort in getting the blood splats "just right" in DR. They have a real weight to them, and I feel they fit with the existing Doom sprites as if they always belonged. As for other source ports? I don't think their developers would want this feature, as it is also out of scope for their port (crispy = more conservative, gzdoom = such features are left to mod devs). And as for me contributing to other source ports (aside from the small extent I have already): DR and real life keep me busy enough. :)

[ludicrous_peridot]

On 2/3/2022 at 11:41 PM, bradharding said:

EDIT: And done.

 

Wow. Thanks, will check out the next release! 

 

EDIT: that was way sooner than anticiapted. Appreciate the changes made.

Edited February 7, 2022 by ludicrous_peridot

[liPillON]

hi Brad, I was wondering if autoload support is something you would consider worthy of inclusion

I've read this closed issue over at github, regarding adding autoload paths to the .cfg file (like gzdoom)

What about the crispy/woof/dsda approach instead? they automatically load any wad they find in a specific folder, keeping the clutter out of the configuration files 

 

thank you!

[bradharding]

On 2/6/2022 at 7:03 PM, Delfino Furioso said:

hi Brad, I was wondering if autoload support is something you would consider worthy of inclusion

I've read this closed issue over at github, regarding adding autoload paths to the .cfg file (like gzdoom)

What about the crispy/woof/dsda approach instead? they automatically load any wad they find in a specific folder, keeping the clutter out of the configuration files 

 

thank you!

 

This is definitely on the [very long] list. I haven't looked into how those ports do it. How I'd do it: if anything is put in autoload\, it's always autoloaded. But for each wad loaded a subfolder is created (in the same way as in savegames\), so anything put in any of those subfolders will be autoloaded for that wad only.

[liPillON]

yeah that's basically the same as crispy, woof and dsda

 

I'm looking forward to it.. keep up the good work!

[PKr]

I noticed that weapon .deh files from Doom 4 Vanilla (3.2.1) are broken (stuck in some weird animation loop/some flashing sprites appear in the upper left corner of the screen) in current version of Doom Retro.

There is one .deh called VORTEX_DoomRetro.deh which was focused on Doom Retro, but it doesn't work either.

 

I have checked the latest mod version in other source ports (Crispy Doom, GZDoom) and they work correctly.

 

[bradharding]

Thanks @PKr. I'll have a look at this over the weekend.

[NieMaMordy]

Recently, a BOOM feature, where monsters slide from the edges due to received damage, while they are still alive, started to bother me more and more, since I started to play more vanilla compatible wads. This makes it impossible to kill monsters when they fall into the spot where Player is unable to go, unless they use IDCLIP. Is there no way of disabling it?

Also,

Quote

MIDI music will now actually pause rather than just be muted when DOOM Retro’s window loses focus or the PAUSE key is pressed.

While I appreciate the change, and it certainly makes sense, sadly, it does not resolve my issue. To set up my midi app, I've got to minimize the doom retro window, which results in the music stopping to play. May I request adding a CVAR that would make the game not go into the 'pause' state when the window loses focus, and just remain in the state that it was?   

[bradharding]

18 hours ago, NieMaMordy said:

While I appreciate the change, and it certainly makes sense, sadly, it does not resolve my issue. To set up my midi app, I've got to minimize the doom retro window, which results in the music stopping to play. May I request adding a CVAR that would make the game not go into the 'pause' state when the window loses focus, and just remain in the state that it was?   

 

Done.

[jeremieh]

Just out of curiosity, in what ways does doom retro differ from vanilla gameplay wise?

[PKr]

"Further improvements have been made to the support for DOOM 4 VANILLA."

 

Strange, it's still the same in 4.4.5 for me. Everything works as intended, but alternative weapons don't work at all. For example adding 7_GAUSS.deh changes sprites of the weapon, but it doesn't function properly.

https://youtu.be/jXny_oLgrso

While shooting it the weapon disappears completely, random sprites appear in the upper left corner of the screen, ammo stays the same, etc.

 

P.S. Oh, and you know what else... 😅 I hate to mention it again but the mouse movement has gotten worse in 4.4.5. Now, if fps is uncapped and you move camera while walking/running it "gets stuck" all the time.

 

P.P.S. Interesting. So, basically, as mentioned in this thread ( https://www.doomworld.com/forum/topic/127475-sdl2-v-sync-and-mouse-movement/ ), I don't have mouse movement issues when fps is uncapped. At least not in v4.4.4. But whatever you did in 4.4.5, you have managed to find a way to replicate this exact issue with uncapped framerate.

Edited February 18, 2022 by PKr

[bradharding]

52 minutes ago, PKr said:

"Further improvements have been made to the support for DOOM 4 VANILLA."

 

Strange, it's still the same in 4.4.5 for me. Everything works as intended, but alternative weapons don't work at all. For example adding 7_GAUSS.deh changes sprites of the weapon, but it doesn't function properly.

https://youtu.be/jXny_oLgrso

While shooting it the weapon disappears completely, random sprites appear in the upper left corner of the screen, ammo stays the same, etc.

 

P.S. Oh, and you know what else... 😅 I hate to mention it again but the mouse movement has gotten worse in 4.4.5. Now, if fps is uncapped and you move camera while walking/running it "gets stuck" all the time.

 

P.P.S. Interesting. So, basically, as mentioned in this thread ( https://www.doomworld.com/forum/topic/127475-sdl2-v-sync-and-mouse-movement/ ), I don't have mouse movement issues when fps is uncapped. At least not in v4.4.4. But whatever you did in 4.4.5, you have managed to find a way to replicate this exact issue with uncapped framerate.

 

How are you loading D4V? The changes made in v4.4.5 were if D4V.wad and all the .deh files are loaded through the WAD launcher, then they are loaded in a specific order so they work. If you're using the command-line, are you specifying the files in the correct order as per the D4V readme?

 

I think the issues you've been having with your mouse come down to SDL's mouse support. I can't find it now, but I vaguely recall seeing mention of issues with high resolution mice. (The reason why v4.4.5 is different again, is I needed to make a change to how the mouse is handled to get the external automap working again.) Does it help if you play around with your mouse settings, adjusting the DPI?

[PKr]

I have tried multiple methods before posting here:

 

1. Through zdl 3.2.2.2, by dropping external files in this order (without adding any arguments):

-chrondis.wad

-D4V.wad

-D4V.deh

-7_GAUSS.deh

2. Through zdl 3.2.2.2's command line, and through the batch file with these arguments:

-file chrondis.wad D4V.wad -nodeh -deh D4V.deh 7_GAUSS.deh

and

-file chrondis.wad D4V.wad -deh D4V.deh 7_GAUSS.deh

 

The results are identical.

 

What DPI should theoretically work nicely with Doom Retro?

No, extremely low DPI values don't change anything. It doesn't get any better nor worse.

Edited February 19, 2022 by PKr

[PKr]

Here is a small update... https://youtu.be/DGZDM1OXvQQ

 

At uncapped fps the mouse is completely smooth while standing still just like it was in previous versions. But when you start moving in v4.4.5 that's when problems begin. Feels like game tries to read inputs from keyboard, then from mouse, then from keyboard again, and so on, but can't read them "simultaneously". So as a results the game moves your character a little bit, then turns camera by some degree, then moves character again, and the movement feels extremely choppy.

 

And once again that doesn't happen when using arrow keys or controller.

 

Mouse issues have been completely fixed in v4.4.8!

Edited March 4, 2022 by PKr

[Endless]

Hey Brad! Was wondering if there's any way to limit blood drops/splatter? It seems in big slaughter maps, there's a considerable drop of frames once a big number of enemies are killd and blood starts accumulating. I think a command that deletes/removes the current blood could be useful in such cases.

 

And also, was wondering if you can add a clock/time counter in the future? Like you added map stats on the automap, that'd be great!

[NieMaMordy]

20 minutes ago, Endless said:

Hey Brad! Was wondering if there's any way to limit blood drops/splatter? It seems in big slaughter maps, there's a considerable drop of frames once a big number of enemies are killd and blood starts accumulating. I think a command that deletes/removes the current blood could be useful in such cases.

I had the same problem so I used the r_bloodsplats_max 0 cvar, but you can use a higher number. Since I use 0, I never checked if bloodsplats stop to appear upon reaching this number, or if the oldest ones start to get replaced with new ones. Either way, give it a try

[PKr]

1 hour ago, NieMaMordy said:

I had the same problem so I used the r_bloodsplats_max 0 cvar, but you can use a higher number. Since I use 0, I never checked if bloodsplats stop to appear upon reaching this number, or if the oldest ones start to get replaced with new ones. Either way, give it a try

It is former. Once you reach r_bloodsplats_max, new blood splats won't be generated anymore.

[Endless]

1 hour ago, PKr said:

It is former. Once you reach r_bloodsplats_max, new blood splats won't be generated anymore.

I think I'd prefer an option/CVAR for the opposite. Instead of blood splats stopping, older blood splats disappear and make room for new ones.

[bradharding]

5 hours ago, Endless said:

I think I'd prefer an option/CVAR for the opposite. Instead of blood splats stopping, older blood splats disappear and make room for new ones.

 

This sounds like a great idea, but I'm not sure if it could be done efficiently. A change I've made to the next release, however, is: the further away blood splats are away from the player, the less likely they are to be drawn. This should help.

[Endless]

3 hours ago, bradharding said:

 

This sounds like a great idea, but I'm not sure if it could be done efficiently. A change I've made to the next release, however, is: the further away blood splats are away from the player, the less likely they are to be drawn. This should help.

I believe Nash's Gore Mod uses something like that. The user can set a limit of blood splatters, and once the limit is reached, old blood gets replaced by new blood. Although it uses Zscript, perhaps is still a good idea to look into.

[Lim_bad_day]

Nice! i download it 

 

[kaleb.]

Quote

If the r_fov CVAR is changed from its default of 90, it is now only effective when the vid_widescreen CVAR is on.

 

so uh, why? i use 4:3 with 110 fov and now i just cant?...

[bradharding]

51 minutes ago, kaleb. said:

 

so uh, why? i use 4:3 with 110 fov and now i just cant?...

so uh I figured only people with widescreen displays would bother adjusting fov. but fine, I'll change it back.

[kaleb.]

24 minutes ago, bradharding said:

so uh I figured only people with widescreen displays would bother adjusting fov. but fine, I'll change it back.

thanks, didnt want to seem rude but it just felt really random and weird change for no reason lol