Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
entryway

PrBoom-Plus, ver. 2.5.1.4

Recommended Posts

PRBoom+ 2.5.1.5 enables vertical aiming, I believe. I know that GLBoom+ 2.5.1.5 does, in the "compatibility for common mapping errors" section under the general menu in Options.

Spectre, I don't believe there is a way to cap fps at something like 60, so I think vsync might be the way to go there.

Share this post


Link to post
11 hours ago, Aquila Chrysaetos said:

Spectre, I don't believe there is a way to cap fps at something like 60, so I think vsync might be the way to go there.

That's too bad. I've always found vsync to feel awkward with what feels like slight input delay. I was hoping there was some kind of option to set a manual cap in the config file.

 

Also, I can confirm that vertical aiming has been under "compatibility for common mapping errors" as the last option since at least 2.5.1.4. Although, to be honest, a more advanced port like GZDoom is better if you want to use a more modern FPS control scheme. Free aim combined with infinite height creates a lot more cheesable scenarios.

Share this post


Link to post

you could try capping your fps in your graphics cards settings - you can set specific program settings in nvidia's i know for a fact, and im sure ATi have something similar

Share this post


Link to post
On 9/6/2018 at 2:54 PM, Spectre01 said:

Is there a way to cap FPS to something reasonable in GLBoom+, like how ZDoom stops at 200? I'm getting over 2k frames on vanilla/low detail maps and it looks weird when turning quickly. And I'm not a fan of vsync or the standard 35FPS cap.

I believe using Riva Tuner Statistics server is the best bet in this case, native fps cap isn't implemented in glboom+ as far as I know.

 

On 9/6/2018 at 3:21 PM, KVELLER said:

I've been using PrBoom+ 2.5.1.4 for a couple weeks now, and I just realised that enabling mouse look won't actually let me aim vertically. I've looked around the options menu and found nothing. Is that really not an option?

Since PrBoom+ is still a conservative port that aims for compatibility, such feature is basically considered a cheat (cause it really kinda is, it alters the intended gameplay quite a bit). I'm not sure if the actual vertical aim is an option, it may be among some "bad" compatibility settings, which exist to let you bypass some really broken buggy maps.

Share this post


Link to post

Mouse look exists purely so you can look around, aiming isn't supported due to the gameplay implications.

 

As far as framerate goes.. if you run Windows with an Nvidia GPU then you might consider EVGA Precision X, I've found it can cap glboom-plus at at anything between 25 and 120 fps reliably.

 

That said if your display supports 70hz (or variable refresh, freesync on AMD, gsync on Nvidia) then using the 35 fps cap is the way to go in my opinion.

Share this post


Link to post

Can somebody explain what this quote of the PrBoom (not Plus) page on the DoomWiki means, and whether it affects complevels 9 and 11 or not?

Quote

PrBoom in Doom compatibility mode treats straferunning differently than usual, which makes it possible to identify demos recorded with it.

Also could somebody provide citations for that quote? 

Reason I ask is because PrBoom-Plus's netplay capabilities are considered broken in comparison to the original PrBoom, and PrBoom seems to be the only way of recording a cooperative demo of a limit breaking Boom wad/map (like Community Chest 2 MAP32, or IIRC all of Community Chest 4)

Share this post


Link to post

@Spectre01 I learned from the changelog that it is possible to cap fps in PRBoom+ 2.5.1.5. If you go into your prboom-plus.cfg, near the halfway point, there should be a line that says "cap_fps <value>" and you can set it directly there.

 

Question: in software mode, does PRBoom+ not render 192 pixel wide textures properly? It seems to render them as 128 wide textures. 256 wide seem fine, so I, and a few others, were wondering.

Share this post


Link to post
15 hours ago, Aquila Chrysaetos said:

If you go into your prboom-plus.cfg, near the halfway point, there should be a line that says "cap_fps <value>" and you can set it directly there.

 

I believe this setting is for capturing video only, not for the actual game rendering. It's located in "Video capture encoding settings" block. So Riva Tuner is still the way to go.

Share this post


Link to post

Mayb a stupid question, but if I want to record on glboom-plus the 2515 version, how do I make the game start the same time as the recording?

If I try to record I have  2 sec that the game is already started but I still have a black screen..

any suggestions ?

Share this post


Link to post

I already have the answer, wel sort of.. if I up the resolution higher than 640x480 it doesent have the 2 sec play delay, but if I try to record on resolution 640x480 or lower the game starts 2 sec while I cant do anything for 2 sec.. maybe it startsup to quick for my monitor to handle.. ?

 

Share this post


Link to post

if else fails, try recording in windowed mode. Also note that your vid settings are irrelevant for anybody watching your demo, as they will use their very own vid setting for playback to begin with.

Share this post


Link to post

I've always found it works best if the resolution you use in Prboom+ matches that of your desktop.

 

Share this post


Link to post
3 minutes ago, Grazza said:

I've always found it works best if the resolution you use in Prboom+ matches that of your desktop.

 

Well that's universal for any program. The display doesn't have to reset if the resolution remains the same.

Share this post


Link to post

The problem is that my desktop resolution is 1680x1050 and in that resolution the game runs laggy..

Also a strange problem I have with prboom+ 2515 is when I play in the reduced turning resolution, shorttics, when I move my mouse very slow it doesent move at all for 1 tick, which makes the controls a little jerky, even more so than normal recording..

And its to bad but I cant use older versions of Prboom+ at all becuz they use sdl version 1 and that doesent run correct on my windows 10 64bit..

any suggestions at the mouse not moving at all for 1 tick when recording or with shorttics ? this problem doesent occur in crispy-doom or vanilla doom..

Share this post


Link to post
46 minutes ago, doomaddict82 said:

Also a strange problem I have with prboom+ 2515 is when I play in the reduced turning resolution, shorttics, when I move my mouse very slow it doesent move at all for 1 tick, which makes the controls a little jerky, even more so than normal recording..

And its to bad but I cant use older versions of Prboom+ at all becuz they use sdl version 1 and that doesent run correct on my windows 10 64bit..

any suggestions at the mouse not moving at all for 1 tick when recording or with shorttics ? this problem doesent occur in crispy-doom or vanilla doom..

 

Unless I'm missing something, based on what I've read on an older thread somewhere around here the game not registering slow mouse movement while recording is a limitation of the engine, and using -shorttics during normal play only replicates that behavior so it's best to avoid using it.

 

However, you can correct this behavior while recording by using the -longtics parameter, it's what I use while making demos and the mouse behaves perfectly fine with it.

Share this post


Link to post

@agent6 thanks for ur reply, the thing is, I know about shorttics\longtics but in cripsy-doom or vanilla doom while recording, I do have the jerky mouse movement but not that the mouse doesent move at all for one tick, which is anoying if u want to pixel line up to glide or for plutonia map01 strafe50 gap for example makes it a pain, lol.. but if I read ur post correctly u say that it is normal for the mouse not registering for a tick at all.. Still I dont have this problem with -shorttics on the other source port/ or vanilla.. thats strange..

Share this post


Link to post

All I can suggest is temporarily changing your desktop resolution before playing Doom (i.e. to match what you intend to play with), and then changing it back again afterwards. I'm surprised to hear that any modern computer can't handle 1680x1050 smoothly. I recall my bog-standard desktop machine back in 2003 handling Nuts.wad pretty decently at 1600x1200 or whatever.

 

Using longtics cocks up precision positioning for things like glides and so will hamper your speedrunning. If shorttics behaviour really feels awkward to you at present, I suspect it is because your mouse sensitivity is too low. Push it way up and it should feel better. Experiment with differing degrees of acceleration. You'll get used to it quicker than you expect.

Edited by Grazza

Share this post


Link to post

I have a general question about the state of PRBoom+: I've been hearing rumours that it's no longer being developed. Is this the case and the changes in 2.5.1.5 are the final update?

Share this post


Link to post
17 hours ago, doomaddict82 said:

The problem is that my desktop resolution is 1680x1050 and in that resolution the game runs laggy..

Also a strange problem I have with prboom+ 2515 is when I play in the reduced turning resolution, shorttics, when I move my mouse very slow it doesent move at all for 1 tick, which makes the controls a little jerky, even more so than normal recording..

And its to bad but I cant use older versions of Prboom+ at all becuz they use sdl version 1 and that doesent run correct on my windows 10 64bit..

any suggestions at the mouse not moving at all for 1 tick when recording or with shorttics ? this problem doesent occur in crispy-doom or vanilla doom..

Nine Inch Heels' suggestion is a good one: By running windowed, your monitor will treat Doom like any other windowed app, without switching resolutions.

The 'mouse doesn't move' thing is not vanilla behavior, is it? Can someone verify this?

Share this post


Link to post

@kb1 I have fixed the 2 sec delay by turning up my in-game resolution and lowering my screen resolution.. I am not used to playing in window mode, feels akward.. The mouse not moving at all for one tick doesent ocure in vanilla ports like chocolate\crispy\vanilla but does in prboom 2515, I do have alot of mouse issues since update to windows 10 64bit.. all the ports that use sdl 1.xx are unplayable, incl Cndoom, wich is ashame they dont update to sdl 2.. I would like to know if other ppl have this issue with that version of prboom and if there is a way to fix it or is it related to my old razer copperhead mouse, but then it should ocure in the other source ports aswell..

Share this post


Link to post

I'm not sure I quite understand what you mean by "doesn't move for one tic". A tic is 1/35 second - a very short amount of time and not really humanly perceptible. Are you recording and then analysing with LMPC? If you mean that it is possible to move the mouse a little to the side and have no turn register, then yes, this is absolutely vanilla behaviour (when recording - and therefore with "short tics"). How much movement is needed to clear the threshold for the minimum shorttics turning angle depends on the mouse sensitivity, which might explain how you are observing this in some vanilla-emulating ports and not in others.

Share this post


Link to post
1 hour ago, Grazza said:

I'm not sure I quite understand what you mean by "doesn't move for one tic". A tic is 1/35 second - a very short amount of time and not really humanly perceptible. Are you recording and then analysing with LMPC? If you mean that it is possible to move the mouse a little to the side and have no turn register, then yes, this is absolutely vanilla behaviour (when recording - and therefore with "short tics"). How much movement is needed to clear the threshold for the minimum shorttics turning angle depends on the mouse sensitivity, which might explain how you are observing this in some vanilla-emulating ports and not in others.

Thanks for clearing that up. I knew I had read it before, but I didn't know where, or which engines were affected.

 

2 hours ago, doomaddict82 said:

@kb1 I have fixed the 2 sec delay by turning up my in-game resolution and lowering my screen resolution.. I am not used to playing in window mode, feels akward.. The mouse not moving at all for one tick doesent ocure in vanilla ports like chocolate\crispy\vanilla but does in prboom 2515, I do have alot of mouse issues since update to windows 10 64bit.. all the ports that use sdl 1.xx are unplayable, incl Cndoom, wich is ashame they dont update to sdl 2.. I would like to know if other ppl have this issue with that version of prboom and if there is a way to fix it or is it related to my old razer copperhead mouse, but then it should ocure in the other source ports aswell..

Yeah, window mode is usually not ideal, as its got window borders, and it's usually a bit slower. So, to clarify:

  • On your win 10-64 box, you cannot use SDL 1.x engines. (Does it refuse to launch, crash, or is just not responsive)
  • The issue happens with PrBoom+, but not Chocolate. Have you tried a different complevel?

I suppose I can understand there being a option to emulate this mouse issue. The shorttics code chops off the fractional part of the mouse movement. The issue here is that, instead of adding this fractional component into the next tic's mouse calculation, it is simply discarded. In other words, it's easy to fix, and I'm really surprised that there's no option (or complevel) to toggle such a fix in PrBoom+. Actually, putting this fix inside a complevel would be inappropriate, since the fix wouldn't affect demo sync, but it would make the mouse work a lot better :)

Share this post


Link to post

@grazza what I mean with mouse doesent move for one tick is when u move ur mouse very slowly when recording or shorttics, the mouse just stops moving gets stuck for a few mili seconds, for example when u try to pixel line up to glide, it stops moving for one pixel, this only seems to happen or at least noticable if u move ur mouse very slowly, if I move it fast left and right it doesent seem to get stuck for one tick/pixel/ms or whatever the best way to discribe it, it makes for anoying situations and this doesent ocure with choco ports or with orginal doom2.exe .. I have no idea what causes this,  if it were a mouse related issue it would do the same thing in all the ports regarding the mouse not moving when turning very slow.. :(

 

@kb1 I tryd most complevels, 2,4,9 but it doesent change anything in prboom in regards to mouse getting stuck for 1 pixel in recording/shorttics..

 

Share this post


Link to post

That is exactly what is supposed to happen. It is not a bug. It also works that way in vanilla and choc. If you are not observing it, then it can only be due to different mouse sensitivity.

Share this post


Link to post

I don't wanna start no thing here, but why is the sound stacking so awful? The options seem to be either to use 8 channels and get a lot of sounds cut off or using the default 32 and get your eardrums popped by alerting a group of Revenants. Even 5 Arachnotrons walking around is exessively loud and annoying. And don't get me started on playing Scythe map26 on anything above 8 channels. This is not an issue in other ports like GZDoom when using even 64 sound channels.

Share this post


Link to post
33 minutes ago, Spectre01 said:

This is not an issue in other ports like GZDoom when using even 64 sound channels.

Because Gzdoom changes how sound works. Namely in this case it limits the maximum number of instances an individual sound can play. This isn't a Doom feature however so only ZDoom derived ports do this. 

Share this post


Link to post
39 minutes ago, Edward850 said:

Because Gzdoom changes how sound works. Namely in this case it limits the maximum number of instances an individual sound can play. This isn't a Doom feature however so only ZDoom derived ports do this. 

Does this also affect staircase builders? Sometimes those are loud as fuck (in some other ports, not sure about Gzdoom)

Share this post


Link to post
51 minutes ago, 𝕍𝔾𝔸 said:

Does this also affect staircase builders? Sometimes those are loud as fuck (in some other ports, not sure about Gzdoom)

It affects all sounds. ZDoom does remove this limit on some sounds though (although not platforms), but for any other sound the limit defaults to 3.

 

Vanilla Doom's only limits are actors can only play one sound at a time (strangely absent in the Xbox/PS3/BFG ports), sounds are removed once the attached actor is removed (something ZDoom does not do), and of course the global channel limit.

Edited by Edward850

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×