PrBoom+ 2.6.66 (Jun 20, 2023)

[Kappa971]

Sorry, I'd like to do some kind of "survey" and see if I'm the only one to notice this problem. I opened an issue about it on github with all the details: https://github.com/coelckers/prboom-plus/issues/400

 

I would like to pay more attention to this issue as, in my opinion, it affects the overall gameplay a lot

[Redneckerz]

2 hours ago, Kappa971 said:

Sorry, I'd like to do some kind of "survey" and see if I'm the only one to notice this problem. I opened an issue about it on github with all the details: https://github.com/coelckers/prboom-plus/issues/400

 

I would like to pay more attention to this issue as, in my opinion, it affects the overall gameplay a lot

Two things:

• What are your specs?
• Given you run VSync, can i assume you use the OpenGL renderer?

[Kappa971]

5 hours ago, Redneckerz said:

Two things:

• What are your specs?
• Given you run VSync, can i assume you use the OpenGL renderer?

My specs are Ryzen 5 1600 CPU, GTX 1060, 16gb of RAM. I have tested with several PCs that I have at home and in all of them there is the exact same problem so I find it difficult that no one else can reproduce it. For completeness I can also enter the data of the other PCs: Intel Core i7 860, GTX 660, 16gb RAM and an old laptop with Debian: Intel Pentium SU4100, integrated Intel GMA 4500 graphics, 4gb of RAM (I lowered the resolution to have a fixed 60 fps).
Stuttering, as specified on GitHub, is very evident playing at 60fps (therefore on 60hz monitors with active vsync but also with freesync monitors limiting frames to 60) both with software and OpenGL renderings, the more FPS are reproduced and the more the phenomenon is reduced. (but it does not disappear)... at 144fps for example the stuttering is minimal, almost irrelevant but not everyone has a 144hz monitor. Disabling vsync is also not a solution as tearing would arise and the game would not be smooth anyway.
I came to the conclusion that it could be a bad interpolation code implemented in PrBoom-plus (always present, I've always had these problems with all the versions I've tried over the years), but I'm not an expert, I could be wrong. In support of this thesis, I can say that with Uncapped Framerate disabled, at 35 fps with freesync monitor, there is no stuttering. 

Crispy Doom and Woof! are very smooth, work very well, probably have better frame interpolation.

 

In any case, it is enough to have a PC, a 60hz monitor and vsync enabled (or a freesync monitor with a 60 fps limiter) to reproduce the problem, very simple.

I'm talking about 60fps because at 60fps the problem is very evident and also because most people have a 60hz monitor.

You have to produce more than 120 fps to alleviate stuttering and, in any case, it doesn't disappear but it reduces.

 

EDIT

I don't understand why anyone else notices it apart from me and @Sr_Ludicolo on GitHub (I hope it's the same person), perhaps due to a different sensitivity to stuttering, but at 60fps it's so obvious... it would be enough to play Woof! first and then DSDA-Doom/PrBoom-plus at 60fps, the difference is obvious.

It cannot be said to be my PC as I have tested with three different PCs and, in all three, the same problem is present. It seems unlikely that I have three bad PCs :)

Edited November 6, 2021 by Kappa971

[Bytefyre]

14 hours ago, JadingTsunami said:

 

I filed an issue for you at the GitHub project. I am able to reproduce this issue.

Thank you!  Much appreciated!

[JadingTsunami]

1 hour ago, Bytefyre said:

Thank you!  Much appreciated!

 

The fix has been merged in, so the next development builds should resolve this issue.

[Ludi]

14 hours ago, Kappa971 said:

My specs are Ryzen 5 1600 CPU, GTX 1060, 16gb of RAM. I have tested with several PCs that I have at home and in all of them there is the exact same problem so I find it difficult that no one else can reproduce it. For completeness I can also enter the data of the other PCs: Intel Core i7 860, GTX 660, 16gb RAM and an old laptop with Debian: Intel Pentium SU4100, integrated Intel GMA 4500 graphics, 4gb of RAM (I lowered the resolution to have a fixed 60 fps).
Stuttering, as specified on GitHub, is very evident playing at 60fps (therefore on 60hz monitors with active vsync but also with freesync monitors limiting frames to 60) both with software and OpenGL renderings, the more FPS are reproduced and the more the phenomenon is reduced. (but it does not disappear)... at 144fps for example the stuttering is minimal, almost irrelevant but not everyone has a 144hz monitor. Disabling vsync is also not a solution as tearing would arise and the game would not be smooth anyway.
I came to the conclusion that it could be a bad interpolation code implemented in PrBoom-plus (always present, I've always had these problems with all the versions I've tried over the years), but I'm not an expert, I could be wrong. In support of this thesis, I can say that with Uncapped Framerate disabled, at 35 fps with freesync monitor, there is no stuttering. 

Crispy Doom and Woof! are very smooth, work very well, probably have better frame interpolation.

 

In any case, it is enough to have a PC, a 60hz monitor and vsync enabled (or a freesync monitor with a 60 fps limiter) to reproduce the problem, very simple.

I'm talking about 60fps because at 60fps the problem is very evident and also because most people have a 60hz monitor.

You have to produce more than 120 fps to alleviate stuttering and, in any case, it doesn't disappear but it reduces.

 

EDIT

I don't understand why anyone else notices it apart from me and @Sr_Ludicolo on GitHub (I hope it's the same person), perhaps due to a different sensitivity to stuttering, but at 60fps it's so obvious... it would be enough to play Woof! first and then DSDA-Doom/PrBoom-plus at 60fps, the difference is obvious.

It cannot be said to be my PC as I have tested with three different PCs and, in all three, the same problem is present. It seems unlikely that I have three bad PCs :)

 

It is! And yes, the problem persists with vanilla prboom+, the UMAPINFO fork, and DSDA-Doom. What a weird bug...

[GoneAway]

Do you still get stuttering in dsda-doom if you play with the automatic key frame depth set to 0? PRBoom+ does have some timing problems in its interpolation scheme that were fixed in dsda-doom (but they were pretty minor). I did considerable tests at the time in the consistency of frames, and it's very consistent for me - the problem just doesn't exist on my computer. You could try disabling vsync and playing with uncapped and "render limit per tic" set to 2 as well on a 60fps monitor. Not really sure if that will help though :^)

[Ludi]

Key frame depth? Educate me, por favor

[GoneAway]

dsda-doom writes key frames (time interval is configurable) that store the whole game state, so that you can rewind the game. The depth is how far back you can go. So it's possible you can get a stutter when the key frame gets stored (on complex levels it can become quite noticeable and needs to be disabled). It shouldn't make a difference on vanilla maps, but it could be worth checking. You can edit that in the settings.

[Ludi]

Interesting. I tried both ideas, and the stuttering was even worse than before. The issue might just require an overhaul of the interpolation code, which would really suck. Perhaps Fabian's interpolation code for Woof! would be useful, since that runs perfectly, from Hangar to Okuplok on my PC.

[Kappa971]

7 hours ago, Sr_Ludicolo said:

Perhaps Fabian's interpolation code for Woof! would be useful, since that runs perfectly

Even in my case.

[Never_Again]

Latest Win32 dev build, as of commit e08f129 (November 06 2021).

 

Noteworthy changes since last dev build (November 05 2021):

* UMAPINFO: fix 'entering' and 'enterpic' shown on exit levels

+ console output

 

prboom-plus-20211106-w32.zip (Mediafire)

prboom-plus-20211106-w32.zip (Google Drive)

 

Includes the 40 required DLLs. See the accompanying TXT file for details.

For a complete list of changes since last official release look here.

Edited November 10, 2021 by Never_Again
replaced Filedropper link with Google Drive one

[grendelw]

Is there an idiot-proof guide on how to setup multiplayer with this port? Not sure if I have to start the server or if I can just start a networked game and have people join that.

 

edit: any time I use the -net launch command with the client it fails to launch without any errors.

Edited November 9, 2021 by grendelw

[Danfun64]

Using multiplayer with PrBoom+ is not recommended. IIRC the net code hasn't been maintained in any fashion since the original PrBoom 2.5. If you're specifically interested in recording coop -complevel 9 and -complevel 11 demos, there doesn't appear to be any modern, maintained solution for this problem.

If you want to do multiplayer with Boom compatibility or better, the best options are the C/S ZDoom based ports (Zandronum for a relatively modern experience, ZDaemon and Odamex for relatively old school ones), and none of them have any intentional backwards compatibility with their native file formats (though Odamex has some support for Vanilla Doom demos).

For recording demos that DSDA-Doom can recognize, you're limited to Vanilla Doom and Limit Removing at the moment (equivalent to -complevel 2 for Doom 2, -complevel 3 for Ultimate Doom, and -complevel 4 for Final Doom). You could either go with Chocolate or Crispy Doom if you want to stick to modern executables, or you could try to configure a vanilla doom setup with DosBox/IPXNET or Kali95 (I believe nobody uses Kali95 much anymore though), either with the original executables or hacked ones, along with an appropriate network driver (XTTL's IPXSETUP seems the most popular https://github.com/AXDOOMER/ipxsetup_xttl).

There is IPXBoom, which is a driver for the DOS versions of Boom and MBF, but nobody seems to use it anymore, and Boom and MBF don't perfectly match -complevel 9 and -complevel 11 respectively.

[grendelw]

I guess there's a reason I only see multiplayer Boom demos from PrBoom 2.5. Maybe this is the motivation I need to contribute code finally, haha

[GoneAway]

Woof is working on multiplayer, I think that will be the premier port for coop on higher complevels once it's ready.

[AF-Domains.net]

Just a quick note regarding the comment about no intentional backward compatibility with native file formats for ZDaemon specifically: that is incorrect.

We go to great lengths to ensure that our own demo format going back to very early versions of ZDaemon 1.x are fully compatible with the latest version.

"If" there are any examples of this not being the case, please link the .zdo/.zdd demo in a direct message and also reference the needed wads.

[Never_Again]

Latest Win32 dev build, as of commit 9e2c554 (November 10 2021).

 

Noteworthy changes since last dev build (November 06 2021):

* GL: adjust sky offsets for non-standard FOVs

+ console output

 

prboom-plus-20211110-w32.zip (Mediafire)

prboom-plus-20211110-w32.zip (Google Drive)

 

Includes the 40 required DLLs. See the accompanying TXT file for details.

For a complete list of changes since last official release look here.

[JadingTsunami]

I suppose I will post it here too in case there is cross-interest; I have released a new editing tool called UMAPINFO Designer that will let you create UMAPINFO interactively instead of in raw text format.

 

I hope you will find it helpful when designing maps for UMAPINFO-enabled ports.

[Never_Again]

Latest Win32 dev build, as of commit 9ff6f87 (November 15 2021).

 

Noteworthy changes since last dev build (November 10 2021):

* fixed stuttering with uncapped framerate
* added support for widescreen low resolutions

+ console output

 

prboom-plus-20211115-w32.zip (Mediafire)

prboom-plus-20211115-w32.zip (Google Drive)

 

Includes the 40 required DLLs. See the accompanying TXT file for details.

For a complete list of changes since last official release look here.

 

Edited November 16, 2021 by Never_Again
updated to reflect new commit

[Cilian]

How do you play in 680x480 but in wide screen? I love how crispy doom looks and how smooth its software renderer is on my machine thanks to low resolution, so I want to make prboom+ look the same. Setting the resolution manually in the config file doesn't work because the port just sets its own resolution back (I'm trying to change screen_resolution).

[Valboom]

12 minutes ago, Cilian said:

Come si gioca a 680x480 ma in widescreen? Adoro l'aspetto croccante di Doom e la fluidità del suo renderer software sulla mia macchina grazie alla bassa risoluzione, quindi voglio che prboom+ abbia lo stesso aspetto. L'impostazione manuale della risoluzione nel file di configurazione non funziona perché la porta reimposta semplicemente la propria risoluzione (sto cercando di cambiare screen_resolution).

Try 852x480

[Cilian]

3 minutes ago, Valboom said:

Try 852x480

It works, thanks

[fabian]

The next release will support low-res widescreen resolutions. 

[Never_Again]

Latest Win32 dev build, as of commit d648724 (November 19 2021).

 

Noteworthy changes since last dev build (November 15 2021):

* added REKKR to launcher string list
* let G_GotoNextLevel() close the circle for maps with an endpic

+ console output

 

prboom-plus-20211119-w32.zip (Mediafire)

prboom-plus-20211119-w32.zip (Google Drive)

 

Includes the 40 required DLLs. See the accompanying TXT file for details.

For a complete list of changes since last official release look here.

 

[deathz0r]

Reposting from the DSDA-doom thread, re-tested with PrBoom+ 2.6.1um Windows build - it has issues with looping on tracker music. I've only tested M.K.-header MOD files specifically so I don't know if this affects MODs with other headers or S3M/XM/IT, but it forces a restart of the song rather than respecting the looping that the files use. Both WADs replace D_RUNNIN.

 

In patternbreak_bug, the intended behaviour is to jump to the fourth line of the first pattern (as indicated by the D03 in the last pattern) while in positionjump_bug, the intended behaviour is to jump to the fourth pattern (as indicated by the B03 in the last pattern). These WADs work fine in GZDoom for reference.

 

patternbreak_bug.zip

positionjump_bug.zip

[fabian]

Which music backend do you use? If you are using SDL (i.e. SDL2_Mixer) there isn't much we can do about it and I would have to ask you to forward the bug accordingly (again). If you are using the DUMB music backend, though, then the bug is on our side, but then we would need someone familiar with that code to fix this.

[deathz0r]

I do not see the DUMB backend with the Windows build, how do I enable that?

[fabian]

3 minutes ago, deathz0r said:

I do not see the DUMB backend with the Windows build, how do I enable that?

 

You'll have to provide the corresponding headers and libraries at build time.

[Never_Again]

4 hours ago, deathz0r said:

I do not see the DUMB backend with the Windows build, how do I enable that?

 

4 hours ago, fabian said:

 

You'll have to provide the corresponding headers and libraries at build time.

 

Currently DUMB support is broken: bug report.

 

edit: not broken, just not exposed in the menu (see Fabian's reply in the linked report for explanation).

Edited December 3, 2021 by Never_Again
added quotes