PrBoom-Plus, ver. 2.5.1.4

Hmm works now I think. Thanks!

I'm about thirty minutes into a map, and I take a short break, pressing the windows key to return to my desktop. I go back to prBoom+ and it has become totally invisible -- it switches back to my playing resolution, I can even press escape and move up and down the menu, hearing the typical noise, but all I see is my desktop.

Great. Just great. -____________-

Edit: Luckily I was recording an FDA so I just had to learn how to use -recordfromto and go to the end. :) :) :) :) :)

Anyway, I'm not sure why it does that.

Based on this thread, I'd like to ask about allowing jumping and vertical aiming to be recorded in demos with complevel -1. The main rationale is that there are no other ports that preserve demo compatibility and support these features, as far as I know. (Maybe Eternity will in the near future?) There certainly are wads that exist like New World that require jumping but run and work fine for demos in PrBoom+ otherwise.

Sorry to bring this old chestnut up again, but if jumping is legitimized to any extent beyond being a non-recorded cheat, the value really should be 8 instead of 9, because 99.9% of Doom maps with jumping were designed with 8. No, there isn't any "official" value sanctioned by id themselves, but that doesn't mean there isn't a well-established standard; the fans decided on 8 over 15 years ago.

If you want to consider Hexen's value more "official" due to being a licensed commercial release, note that Strife is also one and uses 8. Also note that Hexen uses a bigger player, whereas Strife used Doom's player proportions. 9 is for Hexen maps, this isn't Hexen.

However, I'm not sure jumping as a non-cheat fits the semi-purist philosophy. I wouldn't mind if it became a 'normal' feature, but I'm not exactly clamoring for it either. Despite how I felt last time, now I don't care what its value is as long as it remains a cheat.

Sodaholic said:

However, I'm not sure jumping as a non-cheat fits the semi-purist philosophy.

I'm not either, however it would be really nice to have a port that had both jumping and demo compatibility, and to me PrBoom+ seems like the most likely candidate right now.

I would also agree with setting the jump power to 8, if it were available for demos.

Considering that several "pre-zdoom" WADs use custom palettes which necessitate the inclusion of stock doom assets (dubious legality) Would it be possible for PrBoom+ as probably the most popular Boom and Limit-removing port to support a "color translation" lump which would allow for recolorization of sprites via text?

Marcaek said:

Considering that several "pre-zdoom" WADs use custom palettes which necessitate the inclusion of stock doom assets (dubious legality) Would it be possible for PrBoom+ as probably the most popular Boom and Limit-removing port to support a "color translation" lump which would allow for recolorization of sprites via text?

I'd like to see some ports come up with a scheme for this, but I'm not sure the one you suggest would be the best.

I was idly wondering if overloading the patches-compose-textures system so you could have patches on top of sprite frames might be a neat way to do it.

I had a couple of Ultimate Doom coop demos recorded (-longtics, -complevel 3, coope2p1 is my POV, 2016-05-12_0524 is the other person's POV) a few weeks ago using Crispy Doom. They both play back correctly under said source port, and they play back correctly in PrBoom-Plus...most of the time. For whatever reason, it doesn't play back correctly with -viddump used. Normally, there is a brief period of walking, then a short pause, then the action continues (this all happens within the first 15 seconds of the demo). However, with -viddump turned on in PrBoom-Plus, there is the brief period of walking, but the game never leaves the pause screen.

In case its relevant...

# Video capture encoding settings
cap_soundcommand          "ffmpeg -f s16le -ar %s -ac 2 -i - -c:a flac temp.flac"
cap_videocommand          "ffmpeg -f rawvideo -pix_fmt rgb24 -r 35 -s %wx%h -i - -c:v h264 -qp 0 -preset placebo temp.mkv"
cap_muxcommand            "ffmpeg -i temp.flac -i temp.mkv -c copy %f"
cap_tempfile1             "temp.flac"
cap_tempfile2             "temp.mkv"
cap_remove_tempfiles          1
cap_fps                      35

Also, I am running Xubuntu 16.04 64-bit using the latest trunk build of prboom-plus.

Here are the demos: https://drive.google.com/file/d/0B8lbmaOG_ORKVzM5VjdMekFLZFk/view?usp=sharing

Can you guys check what's going on here?

I cannot reproduce this on Debian GNU/Linux amd64 with latest SVN trunk and the standard video capturing settings:

# Video capture encoding settings
cap_soundcommand          "oggenc -r -R %s -q 5 - -o output.ogg"
cap_videocommand          "x264 -o output.mp4 --crf 22 --muxer mp4 --demuxer raw --input-csp rgb --input-depth 8 --input-res %wx%h --fps 35 -"
cap_muxcommand            "mkvmerge -o %f output.mp4 output.ogg"
cap_tempfile1             "output.ogg"
cap_tempfile2             "output.mp4"
cap_remove_tempfiles          1
cap_fps                      60

Edit: Can't even reproduce if I use your video capturing settings. :/

Here is a link to the video produced from the command https://drive.google.com/open?id=0B8lbmaOG_ORKU2lnYldrUnNXQlE

And here is a link to the video of recording the video, along with demo footage without -viddump https://drive.google.com/open?id=0B8lbmaOG_ORKOUg2NUo3V21GOXc

Do you want me to post my compiled build of prboom-plus? Should I compile a debug build? How do I compile a debug build in ubuntu x86_64

Danfun64 said:

However, with -viddump turned on in PrBoom-Plus, there is the brief period of walking, but the game never leaves the pause screen.

confirmed. thanks

how's the fix going? It seems like the repo hasn't been updated since you made your comment.

Sorry for the double post, but there still has been no fix for my prboom-plus problem. Also, entryway hasn't been seen since the "confirmed. thanks" post.

Maybe somebody else can take a go? Should I give more information concerning my problem?

Well hi there folks. It's a pleasant Tuesday and I've got a couple of questions relating to GLBoom+. First of all I'm a bit unclear on what the "permanent strafe50" and "strafe50 on turns" does. How does this affect the movement in game and do these options remain on when recording a demo in -cl 9 for instance? And secondly, about mouse sensitivity. I understand vertical and horizontal but what does the "mouse look" slider affect as well as the "acceleration" option? My mouse movement feels a bit weird sometimes, especially when demo recording. Doesn't happen in other ports. Cheers!

Yes, permanent sr50 does stay on when recording if you set it. Doom by default has 40 set and you can bind a key to strafe run to the left or to the right with it held down but you cannot turn whilst using sr50, to do so would be cheating (as automated sr50 allows you to turn). In other words there's a slight speed increase and it can be used to get to some areas that are otherwise unreachable via sr40 needs. Think that's right. I would advise looking at the Wiki for a more thorough in depth analysis on it. As for mouse look, I would assume it does what it says on the tin and probably alters the speed at how one can use mouse look I.e; looking up and down. Vertical mouse sensitivity is moving the player forward and backward by using the mouse.

Is there any way to change the keybind of the help screen? I need it to go.

^ If there isn't (which I suppose), you could always physically jam the F1 key on your keyboard. :)

It is now a little over two weeks since I initially reported my bug, and there still aren't any changes in the repo.

Should I report my bug to the sourceforge page? Am I supposed to do something more? What happened to entryway, who confirmed the bug but disappeared immediately afterwards?

Danfun64 said:

It is now a little over two weeks since I initially reported my bug, and there still aren't any changes in the repo.

Should I report my bug to the sourceforge page? Am I supposed to do something more? What happened to entryway, who confirmed the bug but disappeared immediately afterwards?

That's because you have "cap_fps 35" in cfg. 60 is default for 2.5.1.5.test builds (and --fps %r instead of --fps 35)

Try this: http://pastebin.com/jeFi7riR

Does it help?

That did it. Thank you!

Sodaholic said:

If you want to consider Hexen's value more "official" due to being a licensed commercial release, note that Strife is also one and uses 8. Also note that Hexen uses a bigger player, whereas Strife used Doom's player proportions. 9 is for Hexen maps, this isn't Hexen.

I think Strife uses 9. Note how you always get the landing "oof" after jumping, while in Doom jumping with speed 8 does not produce that.

Why does the crosshair disappear when switching to the fist or chainsaw? The punching range feels super short already but the missing crosshair is really ruining my already poor Berserk game.

Do PNG graphics crash PrBoom? I have a map which uses PNG graphics as well as new DECORATE actors and the map crashes PrBoom with "I_SignalHandler: Exiting on signal: signal 11." It crashes the very moment a PNG image comes into the view.

I'm pretty sure PrBoom doesn't. If you mean PrBoom-plus, I think the OpenGL version supports PNG graphics, but it certainly doesn't support DECORATE.

I ran into a little sky texture bug tonight, which I think is related to a fix that was implemented recently (brought it up here ages ago, and it was fixed a few months ago).

Anyways, the problem has to do with tall skies (240px in this case), which replace the vanilla sky textures (RSKY1, RSKY2, RSKY3), not being displayed in the same way as MBF sky transfers. The fix only applied to transferred skies it seems. Here's a visual of what I'm talking about :

Misaligned sky (replaced RSKY1)


Good sky (using MBF transfer)


I can whip up a quick test map if needed.

prboom still best port for single player.

Hauss said:

prboom still best port for single player.

same with me. XD

I think I remember this being brought up before, but I'll mention it anyway:

is there any possibility of extending the maplist (under certain compat modes, maybe) to some higher value, like, 100 or something? I've been fiddling around with the source and it only required a few minor changes:

- extending midi list in sounds.c/sounds.h, m_misc.c/m_misc.h

in order to get dehacked map titles:

- extending various lists in d_deh.c/d_deh.h, d_englsh.c/d_englsh.h
- removing the <=33 limit in hu_stuff.c:69

it seems to work fine on a test wad that had MAP40 + d_m40.mid + "HUSTR_40 = level40: yay!"

there's probably a few other things I missed (e.g. editing plutonia/tnt map names, default skies, etc), but nothing crashed horribly or anything. I'm not an expert but I don't think those changes affect demo playback.

it's fine to completely ignore me if the idea is against the spirit of the port or is otherwise obtrusive in some way, but I figure it was worth the inquiry :)

also here's another thing I just noticed after updating to 2.5.1.5test:

when using the -warp option the mouse gets initialized to a weird position:

this would be really annoying for demo recording, obviously :p. could be a sdl2 thing?

Thanks for working on that 100 mapslots thing Ribbiks, I don't think anyone replied when I asked about it in 2012. I think it'd be awesome if that was added.

Were you able to exit map40 and get an intermission screen and go to map41? What about after beating map30 and it goes to the monster types screen?