PrBoom-Plus, ver. 2.5.1.4

5 hours ago, Da Werecat said:

Do you have the same problem with other games running in 4:3 modes? Stretching is the defaut behavior. Some displays can center or stretch without distortion depending on the mode set in their settings, and it also should be adjustable driver-side. Unless you have to use one of the numerous AMD video drivers where the feature is broken.

 

You can always try to set a widescreen resolution if everything else fails.

 

I don't think restarting a level works for recording. Last time someone asked about the best way to restart recording, restarting the game was the only option presented. Hopefully, I will be corrected if I'm wrong.

 

Additional HUD options are all for the fullscreen HUD, which is accessible by pressing + enough times, or by pressing F5 (keep pressing it to switch layouts).

I Just tried to use the version compiled by seed and the aspect ratio now works without issue! :)

Thank you for the HUD tip! It now correctly displays the time

Regarding the level restart - the bind is there so I assume that there must be a way although it is not working (Also I think I've seen people do it on twitch).

I can't possibly believe that the only way is to close the program and restart the bat with the demo being overwritten every time (that would really be a dealbreaker for me)

4 hours ago, ReaperAA said:

In my case, I get mouse lag in both Crispy and PrBoom+ when Vsync is on and this goes away when Vsync is off.

I just tried with both and couldn't find any noticeable difference on my end - It's also hard to tell if I'm not imagining things because my steelseries broke and right now I'm using a super cheap noname mouse with a HORRIBLE sensor. So I can't really trust my baseline but it still feels like it's "slightly" better on prboom+.

Right now, I think that If I manage to find a way to restart the level and have a new demo record start every time like on crispy - I'd be all set and happy :)

Thanks for trying to help guys!

I think Choco 3.x got significantly worse mouse input, and ports based on it followed. Too lazy to check, but it's probably that. Maybe disabling enhanced pointer precision in Windows could help, but it's not ideal to turn it on and off every time you play.

Coincidentally, PrBoom had this problem in the past, but it was fixed (in -Plus) roughly around the same time Choco got worse.

3 hours ago, Da Werecat said:

I think Choco 3.x got significantly worse mouse input, and ports based on it followed. Too lazy to check, but it's probably that. Maybe disabling enhanced pointer precision in Windows could help, but it's not ideal to turn it on and off every time you play.

 

Coincidentally, PrBoom had this problem in the past, but it was fixed (in -Plus) roughly around the same time Choco got worse.

Choco 3.x is quite snappy for me, so I don't think that's the case.

I think the problem is simply SDL since it's the one constant between all ports that suffer from input lag. Even ports such as vkQuake do for me. SDL's nput handling simply isn't great, and when you turn VSync ON, especially if the framerate is capped to 60 rather than 35 or so, it becomes very obvious. Disabling that setting in Windoze likely does nothing since the ports use raw input anyway.

13 minutes ago, seed said:

Disabling that setting in Windoze likely does nothing since the ports use raw input anyway.

Enhanced pointer precision in windows affects mouse control while playing doom.

4 hours ago, Da Werecat said:

Maybe disabling enhanced pointer precision in Windows could help

Oh, I'd rather have someone shoot me in the groin than playing with that horrible nonlinear accel. Always turned off for me.

That option doesn't affect input lag though.

Honestly, It might very well be my mouse - I think that it's making up for its terrible polling rate and IPS by implementing some hardware accel.

Only way to be sure would be to either try with my click broken rival 110 or wait until I save enough for a logitech g pro hero wired. CBA to get down there and plug the rival just to test that so it'll have to be the second option.

About the level restart during demo recording and separate demo files, anyone has an idea? :(

28 minutes ago, Fonze said:

Enhanced pointer precision in windows affects mouse control while playing doom.

Not if the ports already implement raw input and use it by default/the user toggles it on, where it gets completely bypassed...

Pretty sure all existing - and actively maintained - Doom ports have it enabled by default.

3 hours ago, seed said:

 

Choco 3.x is quite snappy for me, so I don't think that's the case.

 

I think the problem is simply SDL since it's the one constant between all ports that suffer from input lag. Even ports such as vkQuake do for me. SDL's nput handling simply isn't great, and when you turn VSync ON, especially if the framerate is capped to 60 rather than 35 or so, it becomes very obvious. Disabling that setting in Windoze likely does nothing since the ports use raw input anyway.

I think it is possible to use SDL to "grab" and "ungrab" the mouse, and listening to mouse events if (and only if) the mouse is grabbed. Unreal Tournament's community native patch type thing, XC_Engine, has a Raw Input option, and it is usually the preferred way to play.

You do, of course, need to write some code to convert platform-specific mouse events into either a common format, or into a format that is already read by code above (like X11 mouse events).

May have been asked before, but is it possible for the new fork of PRBOOM to get an auto-restart button like crispy?

Sorry if this has already been asked/answered.

1 hour ago, Bob9001 said:

May have been asked before, but is it possible for the new fork of PRBOOM to get an auto-restart button like crispy?

 

Sorry if this has already been asked/answered.

Somebody is working on this:

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

On 6/16/2020 at 8:44 PM, fabian said:

 

Somebody is working on this:

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

Awesome thank you, I reliased I posted in wrong thread when I made the above post so apologies :)

So PrBoom+ no longer compiles for me on Linux, and I think it's due to my distro moving to GCC 10. Has anyone else encountered this?

1 hour ago, plums said:

So PrBoom+ no longer compiles for me on Linux, and I think it's due to my distro moving to GCC 10. Has anyone else encountered this?

This has already been fixed in GIT:

https://github.com/coelckers/prboom-plus/commit/8a390a16853aef9348d714eb3b0b4e15f39ff217

@fabian Thanks! That's the UMAPINFO fork/continuation right? For some reason I was under the impression it still didn't build on Linux. I'll have to give it a shot.

I just decided to try out prboom-plus, downloaded and compiled it from sourceforge today. I'm running on ubuntu 18 at 1920x1080 fullscreen with doom2.wad, and I have just noticed the guns seem very inaccurate, like I will miss enemies right in front of me. Is this a known behavior/bug, or something with a fix I just don't know about? I mention resolution because maybe that's it? I tried playing the game in gzdoom ( also on this linux box ) just to see if it was my imagination but no it's very obvious when I come back to prboom-plus

1 hour ago, zaichikred said:

I just decided to try out prboom-plus, downloaded and compiled it from sourceforge today. I'm running on ubuntu 18 at 1920x1080 fullscreen with doom2.wad, and I have just noticed the guns seem very inaccurate, like I will miss enemies right in front of me. Is this a known behavior/bug, or something with a fix I just don't know about? I mention resolution because maybe that's it? I tried playing the game in gzdoom ( also on this linux box ) just to see if it was my imagination but no it's very obvious when I come back to prboom-plus

That's normal, the blockmap bug says hi. You're probably playing with the Default preset in GZDoom as it preserves the blockmap bug too, and quite well I dare say.

BTW I would also point you to the UMAPINFO fork instead, the original PrBoom Plus has ceased development after the transition to SDL2 and the maintainer considers it "complete" since. There will be no further support and updates for it.

Development has since moved here:

20 minutes ago, seed said:

 

That's normal, the blockmap bug says hi. You're probably playing with the Default preset in GZDoom as it preserves the blockmap bug too, and quite well I dare say.

 

BTW I would also point you to the UMAPINFO fork instead, the original PrBoom Plus has ceased development after the transition to SDL2 and the maintainer considers it "complete" since. There will be no further support and updates for it.

 

Development has since moved here:

 

 

Oh so it's actually a bug in the original game that PrBoom+ replicates, but I've gotten so used to Zdoom over the last decade+ where its fixed that I didn't know it's the original behavior. Thanks 

But that's a very rare bug. Could it be a compiler related problem instead?

PRBoom did not fix the bug AFAIK, ZDoom did but unless i'm wrong it's a partial fix for hitscans and monsters. The old code can be used via a compatibility option but the fix is on by default.

Then both ZDoom and PRBoom use a real PRNG instead of the original Doom fixed table but the results should be pretty much the same for both ports despite being different algorithms. Comparing with original Doom would be another thing.

currently playing through valiant (in line with decino's playthrough on Youtube). i got to map07 and its really strange but i cant see the things (viles or barrels) through the transparent windows. any idea why this is happening? im playing with glboom+ 2.5.1.4

when i play in prboom+ 2.5.1.4 i can see them.

7 minutes ago, rehelekretep said:

currently playing through valiant (in line with decino's playthrough on Youtube). i got to map07 and its really strange but i cant see the things (viles or barrels) through the transparent windows. any idea why this is happening? im playing with glboom+ 2.5.1.4

when i play in prboom+ 2.5.1.4 i can see them.

ok i found the culprit:

if you have Smooth Sprite Edges to YES, the viles and barrels disappear.

does anyone know why?

Are you sure you have transparency enabled on the first page? Not seeing things through otherwise transparent objects means that it's turned off.

Why are you still using 2.5.1.4 BTW?

yeah transparency is enabled. im going to take a picture in the exact same space with Smooth Sprite Edges on and off.

a mixture of SDL2 and changes i cant work out makes prboom+ 2.5.1.5 and up feel and look laggy, both to the eyes and my mouse movement.

whereas 2.5.1.4 looks and feels much better.

note the lights through the force-field in the background (transparency on in both shots)

Smooth Sprite Edges ON

Smooth Sprite Edges OFF

That's interesting. How does this option even work?

On 7/4/2020 at 7:31 PM, dmslr said:

That's interesting. How does this option even work?

Smooth texture filtering will cause the edges of transparent objects to have a gradient from opaque to transparent, which can cause sorting issues (presumably pictured above). There's also a speed penalty to semi-transparency. So turning it off simply sets a hard cut off threshold for transparent edges (i.e. any edge >0.5 transparency is fully opaque, any pixels below that threshold are discarded entirely), which won't cause depth sorting issues or create graphically taxing overdraw but may look worse.

cheers Gradius - i understood about 50% of that (my fault, not yours :D ) but appreciate you explaining it!

I hate to be that guy, but is a restart demo key ever going to be implemented? That would be awesome.

2 hours ago, lazy91geek said:

I hate to be that guy, but is a restart demo key ever going to be implemented? That would be awesome.

Someone's trying to achieve that in the UMAPINFO fork, that would be your best bet.

This one is dead.

Ah, yeah. I need to get in the habit of using that thread.

8 hours ago, seed said:

 

Someone's trying to achieve that in the UMAPINFO fork, that would be your best bet.

 

This one is dead.

It's dead? I was under the impression Andrey was making very, very slow additions, but maybe not.

2 hours ago, maxmanium said:

It's dead? I was under the impression Andrey was making very, very slow additions, but maybe not.

That was my understanding as well, at least according to this comment by Proff.