PrBoom+ 2.6.66 (Jun 20, 2023)

I was playing a wad using crispy doom and then i switched to prboom+ 32 bit mode and holy shit... The mouse feels horrendous, why is that?

I am very sensitive to input lag and this makes prboom+ software mode unplayable for me

GLBoom+ was causing lockups in my system. Weird.

@JuanchoES Did you try disabling VSync?

1 hour ago, Gustavo6046 said:

GLBoom+ was causing lockups in my system. Weird.

 

@JuanchoES Did you try disabling VSync?

I always have vsync off in my games

4 minutes ago, JuanchoES said:

I always have vsync off in my games

try enabling it, sometimes it work the opposite, don't know why :/

Does disabling uncapped framerate change anything?

There's also the "Carry fractional tics" option to consider, found under Options -> General -> 3rd page -> Mouse. It enables Chocolate Doom-like mouse behavior that's of most benefit at low sensitivity. By default this option is turned off.

A couple of pages earlier in this thread there was a discussion of mouse issues. The Windows' "Enhance pointer precision" option was mentioned, among other things. Look for it in Control Panel in the Mouse section (it's on the "Pointer Options" tab in Win 7).

4 hours ago, Gustavo6046 said:

GLBoom+ was causing lockups in my system.

Please submit a report to prboom-plus' bug tracker here:

https://github.com/coelckers/prboom-plus/issues

Latest Win32 dev build, as of commit aabe578 (March 2 2021).

Noteworthy changes since last dev build (March 1 2021):

* fluidsynth: reset all controllers when looping a song

prboom-plus-20210302-w32.zip (TinyUpload)

prboom-plus-20210302-w32.zip (FileDropper)

If you don't use Fluidsynth for music or don't have problems with tracks looping you can skip this build.

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

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

Can someone using ALSA and a Fluidsynth daemon on Linux verify the issue of hanging notes in PortMIDI? For instance, load Doom2.wad, start game, idclev to MAP07 or MAP29 (the guitar notes at the beginning of D_SHAWN are sufficient to provoke the issue right away), then exit the game. I tried fixing it, but it didn't seem to do anything so far.

21 hours ago, P41R47 said:

try enabling it, sometimes it work the opposite, don't know why :/

Now I have more input lag, it doesn't make sense, vsync adds input lag no matter what.

21 hours ago, Da Werecat said:

Does disabling uncapped framerate change anything?

Nope, the more fps you have the better, https://blurbusters.com/wp-content/uploads/2017/06/blur-busters-gsync-101-vsync-off-w-fps-limits-60Hz.png

18 hours ago, Never_Again said:

There's also the "Carry fractional tics" option to consider, found under Options -> General -> 3rd page -> Mouse. It enables Chocolate Doom-like mouse behavior that's of most benefit at low sensitivity. By default this option is turned off.

A couple of pages earlier in this thread there was a discussion of mouse issues. The Windows' "Enhance pointer precision" option was mentioned, among other things. Look for it in Control Panel in the Mouse section (it's on the "Pointer Options" tab in Win 7).

 

 

Please submit a report to prboom-plus' bug tracker here:

https://github.com/coelckers/prboom-plus/issues

Installing a mod that disables mouse acceleration on windows makes that option really good in my experience, i know all of the other things you posted.

I dont think is a problem with my pc, its just that software mode in prboom+ has a really annoying input lag that crispy doom doesnt have.

Nevermind, Portmidi bug fixed, and also ALSA backend implemented. Two PRs, and an extra music device! Oo baby!

Although, you do have to connect the MIDI ports manually with the latter. Not sure how to select a default port yet.

5 minutes ago, JuanchoES said:

Nope, the more fps you have the better, https://blurbusters.com/wp-content/uploads/2017/06/blur-busters-gsync-101-vsync-off-w-fps-limits-60Hz.png

I figured since the game logic has to run at 35 Hz and uncapped framerate enables some rendering interpolation, it might introduce some discrepancies. Some people complained about that in regards to ZDoom. I never noticed it personally; in fact, ZDoom always had the greatest mouse handling for me.

Tried it myself and can't see any difference with vsync off.

I'm really curious about this issue because people's accounts vary so wildly. Hard to ascribe it to perception. Even with vsync and uncapped framerate on, the handling feels perfectly agreeable to me.

16 minutes ago, JuanchoES said:

Now I have more input lag, it doesn't make sense, vsync adds input lag no matter what.

Nope, the more fps you have the better, https://blurbusters.com/wp-content/uploads/2017/06/blur-busters-gsync-101-vsync-off-w-fps-limits-60Hz.png

Installing a mod that disables mouse acceleration on windows makes that option really good in my experience, i know all of the other things you posted.

 

I dont think is a problem with my pc, its just that software mode in prboom+ has a really annoying input lag that crispy doom doesnt have.

Its hard to tell, for sure what may be happening to you.

I always try my ports to be as vanilla as possible, taking the chocolate config as a base for all.

Thats it, capped frame rate, 320x200, just 1 or 2 point of horizontal sensitivity

PrBoom+, Doom Retro and Crispy all felt exactly like Chocolate 3.0 to me With the same setting

Cryspy has a little more acceleration than what i like, don't know why, but changing it on the setup helped become kinda like on chocolate. And its also not that hard to acommodate to it as its just slightier off than to what i am accostumed.

Input lag is a serious thing for sure.

Hope you find a way around.

Okay, so far in my PR 234, one might be able to use the ALSASUBxxxy (xxx = dest client num, y = dest port num) in order to subscribe to a destination port, when testing. E.g. if fluidsynth is 128:0, then typing ALSASUB1280 ingame should manually set that up. This is mostly for people testing the ALSA backend.

I have not yet figured a way to have this be configurable from the existing settings interface provided by the game''s menus. I don't know anything about that side of the pond..ahem..I mean codebase. @ketmar would be proud of me! :p

i've reached my daily joke limit, so please, write one yourself, and send me the patch.

Jokeception, hah

On a serious note, both PRs fix the one issue that made me go down this whole rabbit hole. But hey, two flies with one rock! At least the people who play on PrBoom+ on non-Windows systems and use either the Portmidi or ALSA backends will be happier now :D

4 hours ago, JuanchoES said:

I dont think is a problem with my pc, its just that software mode in prboom+ has a really annoying input lag that crispy doom doesnt have.

Then it's a problem with your settings. prboom-plus' 32-bit software mode is very slow with little visual benefits. If you run prboom-plus with the same render settings as Crispy (320x200x8 or 640x400x8) there should be little lag.

There is almost no reason to run PRBoom+ in 32-bit mode. It slightly improves translucency at a noticeable performance cost. If you want Software, it's 8-bit or go home at the moment.

2 hours ago, Spectre01 said:

There is almost no reason to run PRBoom+ in 32-bit mode. It slightly improves translucency at a noticeable performance cost. If you want Software, it's 8-bit or go home at the moment.

Fabian did propose making 32-bit mode truecolor, but that's about it.

Uncapped frame rate directly introduces visual lag, that's how the interpolation works. Rendering at 35 fps your view ranges from 0 to 1/35 "behind" over the course of the game tic whereas at uncapped fps your view is *always* 1/35 behind (it is always "catching up" to smooth out the display). If your goal is to have as little lag as possible, 35 fps is significantly better.

Ey! Input lag decreased a lot when activating the exclusive fullscreen option, but now the game looks like this when playing with low resolutions (looks blurry, not pixelated), I don't know if it's a bug.

1 hour ago, JuanchoES said:

Ey! Input lag decreased a lot when activating the exclusive fullscreen option, but now the game looks like this when playing with low resolutions (looks blurry, not pixelated), I don't know if it's a bug.

what resolution are you using?

maybe i'm blind, but for me it doesn't seem blurry... its kinda look like the regular vanilla look.

Not like Chocolate or Crispy, thats true, but not bad either.

This is how it looks for me on 320x200, you are probably on a little higher resolution.

EDIT: heck! i intended to put the chaingun for better comparison, sorry!

10 minutes ago, P41R47 said:

what resolution are you using?

maybe i'm blind, but for me it doesn't seem blurry... its kinda look like the regular vanilla look.

Not like Chocolate or Crispy, thats true, but not bad either.

This is how it looks for me on 320x200, you are probably on a little higher resolution.

EDIT: heck! i intended to put the chaingun for better comparison, sorry!

do you have this option enabled? 

9 minutes ago, JuanchoES said:

do you have this option enabled? 

i don't seem to have it on my built :/

I have the latest 2.6, not the nightly built.

36 minutes ago, P41R47 said:

i don't seem to have it on my built :/

I have the latest 2.6, not the nightly built.

Thats why

2 things:

1- When youre using exclusive full screen you cannot go lower than 640x400 for some reasons

2- Exclusive fullscreen didnt do the thing with input lag, i still have a really good input lag without that option enabled. For some reasons, the input lag of prboom+ software mode is really good now on my pc.

Im using this built https://github.com/coelckers/prboom-plus/actions/runs/622318899

32 minutes ago, JuanchoES said:

Thats why

2 things:

 

1- When youre using exclusive full screen you cannot go lower than 640x400 for some reasons

2- Exclusive fullscreen didnt do the thing with input lag, i still have a really good input lag without that option enabled. For some reasons, the input lag of prboom+ software mode is really good now on my pc.

 

Im using this built https://github.com/coelckers/prboom-plus/actions/runs/622318899

probably i'm doing something wrong, cause after exporting all the .dll i still can't run that built :/

i donwloaded the vs_win32.

1 hour ago, P41R47 said:

maybe i'm blind, but for me it doesn't seem blurry... its kinda look like the regular vanilla look.

I think what they mean is that it looks blurry after being resized. Probably due to being resized by the monitor rather than the program.

55 minutes ago, P41R47 said:

probably i'm doing something wrong, cause after exporting all the .dll i still can't run that built :/

i donwloaded the vs_win32.

You also need these DLLs to run those builds.

23 minutes ago, Andromeda said:

You also need these DLLs to run those builds.

thanks, mate! now it worked :D

1 hour ago, JuanchoES said:

Thats why

2 things:

 

1- When youre using exclusive full screen you cannot go lower than 640x400 for some reasons

2- Exclusive fullscreen didnt do the thing with input lag, i still have a really good input lag without that option enabled. For some reasons, the input lag of prboom+ software mode is really good now on my pc.

 

Im using this built https://github.com/coelckers/prboom-plus/actions/runs/622318899

i tried it again with the help above, and i don't have any slowdown :/ or input lag.

So its probably something that you changed on the config.

Here, try with my config:
prboom-plusCFGP41R47.zip

12 minutes ago, P41R47 said:

thanks, mate! now it worked :D

 i tried it again with the help above, and i don't have any slowdown :/ or input lag.

 So its probably something that you changed on the config.

Here, try with my config:
prboom-plusCFGP41R47.zip

Huh? Im not saying that i have more input lag, im saying that im having less input lag with the newest built.

4 hours ago, JuanchoES said:

Input lag decreased a lot