PrBoom-Plus, ver. 2.5.1.4

[Never_Again]

fabian said:

I can confirm the HOM on TNT09 with "-iwad doom2.wad -file tnt.wad", but not the one on PG29.

You need to use PERDGATE.WAD (CRC-32 0B9D63BC) that the Maximum Install generates rather than PG-RAW.WAD (or PG-RAW-X.WAD) to see the HOM.

[entryway]

Never_Again said:

TNT MAP09

fixed

[Blastfrog]

It would really make more sense if the jump momentum were configurable, with the default set to 8 instead of 9.

Sure, there's no "canon" jump momentum for Doom, but there is a defacto one, and it's undeniably 8. Most maps made with jumping in mind assumed ZDoom's jump height because of that port's wide influence and long history. If you think that's too subjective, find me a map that was made with 9 in mind - even if you do, those designed for 8 will still vastly outnumber those designed for 9.

As for the "it doesn't really matter because it's a cheat anyway" argument, I disagree. In maps not designed for it, sure. But there are many maps that were designed for it, sometimes even required to complete the map. It should be the user's discretion whether or not to jump, unless the map author specifically disables it in his map's metadata (there should be an override, ofc).

[scifista42]

I prefer 9, because it feels natural to climb a common crate, I like being able to do it without a supportive half-sized crate nearby.

[Blastfrog]

Another thing to consider: Hexen had a higher viewheight, therefore a higher jump height was used to compensate for the perceptual scale difference. Doom does not have this higher viewheight.

scifista42 said:

I prefer 9, because it feels natural to climb a common crate, I like being able to do it without a supportive half-sized crate nearby.

I don't see how anything I said conflicts with that. Most maps designed for jumping assumed 8, so that's what the default should be. I think it should be a config option, so it's not like you'd be forced to use my proposed default.

This debate would have more merit in the late 90s/early 00s. By now, 8 has solidified as the defacto standard as that was the value that was established first, and is overwhelmingly common.

[scifista42]

It doesn't invalidate what you said, I've just added my own input.

[Never_Again]

entryway said:

[TNT09] fixed

That fixed PG29 as well, thank you.

Sodaholic said:

As for the "it doesn't really matter because it's a cheat anyway" argument, I disagree. In maps not designed for it, sure. But there are many maps that were designed for it

Such maps were not designed to be played in classic ports like Prb+ in the first place, so that counter-argument is irrelevant.

[Rez]

Sodaholic said:

As for the "it doesn't really matter because it's a cheat anyway" argument, I disagree. In maps not designed for it, sure. But there are many maps that were designed for it, sometimes even required to complete the map. It should be the user's discretion whether or not to jump, unless the map author specifically disables it in his map's metadata (there should be an override, ofc).

I love to replay old maps with jumping -- it can put new life (or new panic, depending on where you jump into) into old familar maps.

[Blastfrog]

scifista42 said:

It doesn't invalidate what you said, I've just added my own input.

Ah, alright. Thanks for clarifying, I thought you were trying to counter my argument on the basis of personal preference.

Never_Again said:

Such maps were not designed to be played in classic ports like Prb+ in the first place, so that counter-argument is irrelevant.

Not necessarily. I'm sure there are plenty of maps that just so happen to be limit-removing or Boom compatible, despite intending jumping. As long as such maps don't have any compatibility issues with Prb+, I don't see the problem.

My proposition is simple and sensible - go with the strongly established precedent. Retaining Hexen's jump height as the default is obtuse and doesn't have nearly as much justification as using Strife's/Legacy's/ZDoom's. The only place Hexen's should be default is in Hexen or some mod.

Rez said:

I love to replay old maps with jumping -- it can put new life (or new panic, depending on where you jump into) into old familar maps.

Not relevant to my points. I was talking about maps that were deliberately designed with jumping in mind, not cheating in those that weren't.

[Never_Again]

Sodaholic said:

I'm sure there are plenty of maps that just so happen to be limit-removing or Boom compatible, despite intending jumping.

They are either limit-removing/Boom-compatible or they require jumping.

[Blastfrog]

Never_Again said:

They are either limit-removing/Boom-compatible or they require jumping.

By limit-removing/Boom-compatible, I was referring to map formats, not gameplay mechanics.

My point is that since jumping is already implemented, why not tweak its strength to be the defacto standard? Anyone that doesn't like it could simply edit their config file.

I don't want to get all pedantic or argumentative, I just don't understand why there's any good reason to force the user to use 9.

[Never_Again]

Sodaholic said:

I don't want to get all pedantic or argumentative

Good, because the more you argue the more muddled your arguments, like the following:

Sodaholic said:

By limit-removing/Boom-compatible, I was referring to map formats, not gameplay mechanics.

Map formats are Doom, Hexen and UDMF. What you were referring to is your desire to see Prboom-plus behave like Zdoom, and that has nothing to do with map formats or compat categories.

Sodaholic said:

My point is that since jumping is already implemented, why not tweak its strength to be the defacto standard? Anyone that doesn't like it could simply edit their config file.

Because it's supposed to be a kludge to get through a broken map, not a standard gameplay feature. The nonstandard value is there most likely to emphasize that point, not to make anyone like it and get used to it. It may also be an extra safety margin or just a way to demonstrate that "our jump goes to eleven. :P

[Da Werecat]

There may be some maps that were made for early source ports and used only vanilla features, but relied on jumping. Unfortunately, I can't remember any of such maps off the top of my head.

I don't think it's very important. Jumping can't be recorded in a demo anyway.

[Memfis]

^ Daniel Level Serie 01 is one example, a full megawad of Doom format maps that often require jumping and in some cases the increased height allows you to "cheat". Cool maps. There is probably more Legacy stuff like this.

[Rez]

Memfis said:

^ Daniel Level Serie 01 is one example, a full megawad of Doom format maps that often require jumping and in some cases the increased height allows you to "cheat". Cool maps. There is probably more Legacy stuff like this.

The oldest WADs I can recall offhand that require jumping are by Roger Ritenour, the updated versions of "Earth" and "Pleiades".

http://www.doomworld.com/idgames/index.php?file=levels/doom2/Ports/d-f/earthzd.zip
http://www.doomworld.com/idgames/index.php?file=levels/doom2/Ports/p-r/pleiades.zip

[DeletedUser]

Trying to launch the latest (2.5.1.4 test) version with this Doom 64 music wad:
http://www.doom2.net/doomdepot/doom64tc/d64mus.wad

I get this error:

[VGA]

Which version do you have? Look in stdout.txt
I have this version: (built May 6 2015 22:34:37)
and it is working fine, that dll doesn't exist and isn't needed.

[Never_Again]

That's not the latest version. The latest version is dated June 18.
MP3 soundtracks won't play with Options -> General -> Preferred MIDI Player = SDL.

@BK: are you doing your own builds? Try building with "-static-libgcc" and "-static-libstdc++" if you are.

[DeletedUser]

Wait so the same version title '2.5.1.4 test' got updated twice with a new build without first mentioning it's a 2nd version of the same name? Hence why does the first post of the Valiant thread dated 'February 7th 2015' state:

'If you're using PrBoom-plus, make sure to update to the 2.5.1.4 build.' :>

Changing the 'Preferred MIDI Player' option fixed it, good to know! xD

Also how do you switch between the new fullscreen hud with health/ammo indicators similar to ZDoom and the smart HUD for demo playback, doesn't seem obvious toggling stuff in the menus :x

[entryway]

smpeg.dll from sdl_mixer 1.2.12 imports libstdc++-6.dll. I've replaced it with smpeg.dll from 1.2.11.

[Never_Again]

v2.5.1.4-test has been updated at least five times since 2012. New test revisions don't get a different number or an announcement. It's been that way for the past ten years.

[Ribbiks]

hello there. noticed some funky rendering in software today, latest prb+.

scythex.wad, map03

[entryway]

Ribbiks said:

noticed some funky rendering in software today, latest prb+.

savegame please

[fabian]

Ribbiks said:

latest prb+.

Nope, can reproduce with SVN commit 4425 but not with 4429. Please update.

[3dfx]

I recorded a demo for betalabs with strawberry-doom -longtics.
It plays back fine in strawberry-doom and vanilla ultimate doom with 1.91 patch, but it fails in prboom-plus. It goes out of sync soon after start.

http://s000.tinyupload.com/index.php?file_id=77568205491456238941

What am I doing wrong?

[entryway]

3dfx said:

It goes out of sync soon after start.

Add -nodeh command line switch. Or extract DEHACKED lump and use/apply it with strawberry/vanilla during recording.

[Aqfaq]

Here's a "signal 11 error" demo.
Recorded with prboom-plus-2.5.1.3.
Alien Vendetta map 13 tyson attempt.

Game crashed suddenly after more than an hour of normal playing.
Error message said "exiting on signal 11".
This has never happened to me before, so it was a nice experience.
What a brutal end to a long demo that looked promising.
I wonder what caused it.

Strangely, it looks like the demo ends playback a few seconds early.
The actual crash happened a few seconds after this demo ends.
Somehow the last few seconds of the demo got cropped out, corrupted or something?

doomworld.com/vb/attachment.php?postid=1403085

[Blastfrog]

skillsaw said:

They don't and won't work in prBoom+ due to a bug. ZDoom has since fixed the bug but it has been kept intact in prBoom+ for compatibility reasons.

So how about fixing it and adding a compatibility flag for it?

[vadrig4r]

Hey entryway, thanks for the great port! It's my go to for limit removing wads and demo playback.

I was wondering if there is any intention to support 320x200 in fullscreen. I tried to force it from the command line but fullscreen places the game in a small, centred window (with pickup flashes occupying the top left) and isn't aspect ratio corrected. I use Chocolate Doom normally, and I tested ZDoom which also functions with 320x200. It would be nice if I could use PrBoom-Plus in the game's original resolution, but I understand it could be difficult or not something you're interested in.

Thanks anyway for reading and again for the top job.

[noshutdown]

vadrig4r said:

Hey entryway, thanks for the great port! It's my go to for limit removing wads and demo playback.

I was wondering if there is any intention to support 320x200 in fullscreen. I tried to force it from the command line but fullscreen places the game in a small, centred window (with pickup flashes occupying the top left) and isn't aspect ratio corrected. I use Chocolate Doom normally, and I tested ZDoom which also functions with 320x200. It would be nice if I could use PrBoom-Plus in the game's original resolution, but I understand it could be difficult or not something you're interested in.

Thanks anyway for reading and again for the top job.

i guess its a matter of videocard driver rather than prboom. when i ran prboom+ on old computers i could choose 320*200, but on my current computer the lowest i can choose is 640*480.