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

VGA said:

It was Zone 300 - MAP29 "Den of Torture"

Maybe when I was trying to debug in Visual Studio and ran into that exception during (afair) configuration loading, the cfg got screwed and I copied it over or something (?) I certainly didn't change that variable to "0" myself :-D

By the way, where is the -nwtmerge functionality of Choco?

Fixed the savegame issue here.

The -nwtmerge option has been removed. Is there a specific wad you need it for?

For this:
http://www.doomworld.com/idgames/index.php?file=levels/doom2/s-u/ttp103.zip

There are cetainly other released projects with wads that are meant to be merged to doom2.wad with ye olde NWT.EXE DOS program. Like Obituary.
http://www.chocolate-doom.org/wiki/index.php/Obituary

EDIT:
http://www.chocolate-doom.org/wiki/index.php/WAD_merging_capability
Did the -aa -as -af switches also get disabled? Can't check now.

Holy shit, I ran into some map-breaking bug, check out this demo:
https://www.sendspace.com/file/qmalkr

It's for Requiem MAP17, nomonsters mode. Try to do the same in Doom Retro, the second stair-building switch always fails and you can't get to the blue key, the lowest switch is also blocked/hidden when that happens. Or try to use the other switch first, then the second, the third gets blocked.

There is some bug regarding sector lowering/raising? It may also have something to do with the special activated when walking in front of that switch (I hear a sector moving).

Chocolate Doom and Crispy Doom behave the same as prboom+

P.S.: Using latest code.

VGA said:

Holy shit, I ran into some map-breaking bug, check out this demo:
https://www.sendspace.com/file/qmalkr

It's for Requiem MAP17, nomonsters mode. Try to do the same in Doom Retro, the second stair-building switch always fails and you can't get to the blue key, the lowest switch is also blocked/hidden when that happens. Or try to use the other switch first, then the second, the third gets blocked.

There is some bug regarding sector lowering/raising? It may also have something to do with the special activated when walking in front of that switch (I hear a sector moving).

Chocolate Doom and Crispy Doom behave the same as prboom+

P.S.: Using latest code.

Thanks yet again, VGA! Just fixed this here.

You've been so incredibly helpful and I appreciate it immensely, but in the future, so I can keep track of things better, could you please report any bugs or suggestions here?

Ok, for important things I will use that, actually I just created a new issue, please note that my nickname there is AnotherLife.

Brad, is Doom Retro supposed to have full BEX support? Because I have an issue to raise then, heh ;-)

VGA said:

Brad, is Doom Retro supposed to have full BEX support? Because I have an issue to raise then, heh ;-)

I'd just file the issue if I were you. It may be interesting for others as well, e.g. I do also occasionally read through DR's bug reports. And if Brad considers it invalid, he can just close it again.

VGA said:

Brad, is Doom Retro supposed to have full BEX support? Because I have an issue to raise then, heh ;-)

Yes it does, so please do! :)

Do you have any interest in an uncapped framerate option? I am working on a uncapped branch of Crispy Doom, and I was curious if you had any interest in a similar feature. The branch isn't ready yet, but I wanted to know if you were interested ahead of time.

If so, are the changes in the branch easy enough to follow that you think you could handle it yourself (since both your and their ports is a chocolate-derivative), or would you prefer it if I tailored the patch for your port myself?

Brad merged it and it seems to be working perfectly so far :-D
Thanks AlexMax and Brad!

AlexMax said:

Do you have any interest in an uncapped framerate option? I am working on a uncapped branch of Crispy Doom, and I was curious if you had any interest in a similar feature. The branch isn't ready yet, but I wanted to know if you were interested ahead of time.

If so, are the changes in the branch easy enough to follow that you think you could handle it yourself (since both your and their ports is a chocolate-derivative), or would you prefer it if I tailored the patch for your port myself?

Already merged a couple of days ago, like VGA said! Excellent work, AlexMax, thank you! (Here's the commit from a couple of days ago where I credited you.) It works really well, and didn't take much to get it working. Still having a couple of small issues:
1) Blood splats and shadows are still an issue sometimes when on moving sectors. They're treated differently to other mobjs since they don't have thinkers.
2) Monsters passing through teleports. Seems their position is still being interpolated so you may want to check this in Crispy as well. I've fixed this, but still having a problem setting the z-pos of the shadow.
3) Input is pretty laggy when vsync is on, which I know is to be expected, but seems to be more so when compared to other ports.

bradharding said:

2) Monsters passing through teleports. Seems their position is still being interpolated so you may want to check this in Crispy as well. I've fixed this, but still having a problem setting the z-pos of the shadow.

Oh yeah, I see how that might be a little problematic. You might have noticed in the original patch that I did my own attempt at fixing the local player's camera already (check the patch for MAXMOVE), but if I fix things in the place where you did, my original player camera fix might not be needed after all.

bradharding said:

3) Input is pretty laggy when vsync is on, which I know is to be expected, but seems to be more so when compared to other ports.

If the port you are comparing it with is ZDoom, don't bother. :) ZDoom doesn't actually interpolate the local camera, it actually samples input multiple times per tic, taking any mouse movement and using it to manipulate the local camera immediately.

Since Crispy Doom tries to remain vanilla compatible, I think trying to do this in Crispy would be much more difficult than it is worth. If you want to take a crack at it, however, I suggest taking a look at ZDoom's G_AddViewAngle() and G_AddViewPitch() and seeing what rabbit holes that takes you down...

https://github.com/rheit/zdoom/blob/master/src/g_game.cpp#L810
https://github.com/rheit/zdoom/blob/master/src/g_game.cpp#L763

double post, delete me

Re: player movement, would this be feasible:

• As we know, movement is only updated by the game logic every tic
  
• You want to make it look like you are sampling player input at a higher rate than 35 hz
  
• So sample at a higher rate, and each time you sample it, integrate over all the samples up to that sub-tic position, and do a display update at the "fake" predicted spot the player would be at
  
• At the end of the tic, integrate over all the intra-tic inputs to determine the "real" input
  

So for example, imagine that a player is running forward, by holding down the "forward" button:

• tic + 1/10: player is still holding down forward button, so assume button will be held down the whole tic, calculate where the player would be with another GF50 tic, and render viewpoint 1/10 of the way there
  
• tic + 2/10 through 7/10: same
  
• tic + 8/10: player has let go of forward button! Now assume button will continue to be let up the rest of the tic, so calculate where the player would be with a GF40 tic (in other words, GF50 * 0.8), and render a view 8/10 of the way there
  
• tic + 9/10: same
  
• tic + 1: register the "real" input as a GF40 tic.
  

Of course, in my example there would be a discontinuity between tic + 0.7 where 50*0.7 = 35, and tic + 0.8 where 40*0.8 = 32, but the existing player momentum would probably disguise that well enough, or you could do a second-order interpolation of the viewpoint to smooth it out or something.

So yeah, basically I'm asking if it is possible to use a higher input rate, and use it to interpolate values for the final input command at the end of the tic.

The tricky hurdle #1 to overcome is to try and uncap the polling of input in the first place. It's not quite as simple as uncapping the framerate. While I was creating this post, I took another look at the mess and this is what I found.

To start, TryRunTics() calls NetUpdate(), which calls BuildNewTic() only if there is enough time passed for a new tic. BuildNewTic() is where the interesting stuff happens. It runs:

• I_StartTic(), which does the actual SDL polling for keyboard, mouse and joystick events and puts them in a queue.
  
• D_ProcessEvents(), to pop every event from the queue and turn them into the gamekeydown/mousex/mousey globals in G_Responder().
  
• G_BuildTiccmd(), to turn those globals into actual ticcmds.
  

So the trick is to poll events outside of BuildNewTic() without causing the responder to freak out.

Brad, on the latest code at this moment opening or closing the automap gets rid of the currently displayed message. Is that intended? It's not that way in other ports.

VGA said:

Brad, on the latest code at this moment opening or closing the automap gets rid of the currently displayed message. Is that intended? It's not that way in other ports.

It is intended, yes. :)

I overlooked that commit. It always annoys me in ZDoom, because I often save and then go to automap where I have killed/secrets stats. Then I have to wait till message disapear.

Krazov said:

I overlooked that commit. It always annoys me in ZDoom, because I often save and then go to automap where I have killed/secrets stats. Then I have to wait till message disapear.

Yes that annoys me, too. But Doom Retro doesn't have anything on the upper left of the automap :-D

It's weird because sometimes when I encounter a locked door I tap TAB then M to create a marker then TAB again. But I see no message o.0

I did it this way with the idea that the automap is "its own thing". Automap messages appear when in the automap, other messages appear when not. Reevaluating this though: you can still move in the automap to pick up items which create messages. So maybe I'll change this.

Brad, it could just clear the message that was on the screen while player entered automap. After all the message can be looked up in a console. Moving around a map with an automap would generate messages without any disturbance.

VGA, you’re right, there is nothing on automap in Doom Retro. And yet. The feeling of annoyance is strong enough.

That's what it does now, opening AND closing the automap clears any in-display message.

Maybe only *opening* the automap should clear messages so that the automap looks clean.

Hi all! After almost 3 months of some pretty solid development, I'm proud to finally announce the availability of DOOM RETRO v1.7. This is a major release, and contains many differences to prior versions, the most significant of which are SDL2 support, a console, and uncapped framerates. Visit doomretro.com for the download and release notes.

I’ve been toying with betas of this version for some time and I have to say that I am amazed by the speed of the game. You all should try it.

It's just a Chocolate Doom fork.

With fixed bugs, double the native resolution, widescreen+fullscreen, uncapped framerate, brightmaps, mirrored corpses, animated liquids, shadows, blood, best fuzz effect of all ports, non-infinite-z actors, correct blood color etc etc

This is the best way to play vanilla and limit-removing content :-D

Slime trails are still around occasionally. Dunno if there's really much to be done with the normal Doom renderer though.

Let’s say, it’s part of a Doom charm.

What are the possible solutions?

According to: http://doomwiki.org/wiki/Slime_trail
if I understand correctly it's either to use ZDBSP as a forced internal node builder or go Knee Deep In Lee Killough and see how MBF deals with it. Right?

VGA said:

What are the possible solutions?

According to: http://doomwiki.org/wiki/Slime_trail
if I understand correctly it's either to use ZDBSP as a forced internal node builder or go Knee Deep In Lee Killough and see how MBF deals with it. Right?

Lee Killough's P_RemoveSlimeTrails() is in there, and has been for several versions. Strangely, going back to v1.5 of DR, slime trails were fixed (eg. the one Linguica points out above isn't there), but at some point they've come back. I think it might have something to do with kb1's wiggle fix...

bradharding said:

Lee Killough's P_RemoveSlimeTrails() is in there, and has been for several versions. Strangely, going back to v1.5 of DR, slime trails were fixed (eg. the one Linguica points out above isn't there), but at some point they've come back. I think it might have something to do with kb1's wiggle fix...

I have applied Lee Killough's P_RemoveSlimeTrails() in Crispy Doom as well and experience shows that it is not able to remove *all* slime trails. For example, the one Linguica pointed out is still there, but it's really hard to find the right spot and angle -- barely noticeable in regular play, if you are asking me. I am sure, however, that the WiggleFix has nothing to do with it. It is just that it's merely impossible to remove slime trails more efficiently than the current code does without touching the nodes themselves.