PrBoom-Plus, ver. 2.5.1.4

noshutdown said:

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.

Ah, it could well be. I figured that as I could run other 320x200 programs in fullscreen I shouldn't have a problem, but I suppose that's not necessarily the case. PrBoom+ is so good, I would just love being able to play with the original resolution. If anyone figures out a way to do so fullscreen I would appreciate the info.

probably sdl_videodriver "directx" can help?

I dunno if anyone can help me here but trying to run the latest version on OS X is kind of a pain in the butt for me, I can't play in fullscreen and can't seem to get any other midi options like fluid synth or whatever work. Playing in full screen makes the game crash. It also doesn't keep my options saved.

I tried compiling it from source with a tarball to see if that would work better but then it claims I'm missing some development libraries and I'm not sure what 'cause I know I have installed all the necessary things it says there, SDL and such.

I dunno how to get the "OpenGL support" the terminal complains about when I try to run ./configure.

More info in this text copied from the terminal for anyone who wants to help:

https://www.dropbox.com/s/fzch2vzqihubiy3/PrBoom-PlusAttemt1.txt?dl=0

Some problems might be because I'm running a beta of OS X 10.11 so maybe it can't be helped. But I'm asking just to make sure.

^^ I made a post awhile back outlining the steps for compiling from scratch on a fresh os x 10.10.X install, it should help: http://www.doomworld.com/vb/post/1167545

if you want fluidsynth midi you can install that via macports as well iirc.

Ribbiks said:

^^ I made a post awhile back outlining the steps for compiling from scratch on a fresh os x 10.10.X install, it should help: http://www.doomworld.com/vb/post/1167545

if you want fluidsynth midi you can install that via macports as well iirc.

Hmm. My computer won't let me do the symlinks for some reason, I just get a message saying "operation not permitted", more here:

https://www.dropbox.com/s/67r6kxh18gp734x/Symlink1.txt?dl=0

I dunno if anything's different because I use Homebrew rather than Macports and I think you can't have both on your system without things getting weird.

how strange, I've only heard of symlinks failing if the disk is formatted as fat32, or if you didn't in fact have root privileges.

An ugly alternative might be to straight up copy the headers and whatnot (basically just cp, instead of ln -s). Theoretically it also seems like you should be able to let the configure script know where the GL libraries are hidden away at inside the xcode bundle via CFLAGS, LDFLAGS, but I remember that not being as working as nicely as expected when I tried.

Ribbiks said:

how strange, I've only heard of symlinks failing if the disk is formatted as fat32, or if you didn't in fact have root privileges.

An ugly alternative might be to straight up copy the headers and whatnot (basically just cp, instead of ln -s). Theoretically it also seems like you should be able to let the configure script know where the GL libraries are hidden away at inside the xcode bundle via CFLAGS, LDFLAGS, but I remember that not being as working as nicely as expected when I tried.

Hmm, I think I know why the symlinks didn't work, the directories you specified the symlinks for are different on my computer but I think I might've made some mistake and need to start over so how do I remove the symlinks in order to start over?

I can't seem to find libgl.dylib or libGLU.dylib on my computer, though...
Well, I've tried copying the stuff you asked but when I replace ln-s with CP terminal tells me this:

CrocBookPro2:~ coffeegator$ cp /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers /usr/include/GL
cp: /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers is a directory (not copied).

Am I doing something wrong with the copying? I'm pretty sure you can copy directories and folders with terminal but I forgot how. And it won't let me copy via finder.

Turns out I just fixed it and I have no idea how. Still, glad to see it's working now!

In this post Never_Again describes MBF-compatible demo format. I want to force compatibility options in my MBF-compatible wad (complevel 11), so all the demos recorded for it will have the identical compatibility settings in their header. It is possible for PrBoom+ to add OPTIONS lump support, but read only options which are present in this demo header (and ignore all others)?

Hi, is there a way to retain the correct 4:3 aspect ratio by putting black bars at the left and right borders of the screen (i.e. force 1440x1080 on a 1920x1080 monitor)? I can't seem to find a way to do it... thanks

Not sure if this qualifies as a bug or not. If one doesn't specify an absolute path to the fluid synth sound font in the configuration file, the latest build looks for the sound font in the same location as the loaded PWAD. Should PRBoom+ not look in the same place where the PRBoom+ executable is located if a full path is not specified?

mdmenzel said:

If one doesn't specify an absolute path to the fluid synth sound font in the configuration file, the latest build looks for the sound font in the same location as the loaded PWAD.

In current dir, not in "pwad dir".

mdmenzel said:

Should PRBoom+ not look in the same place where the PRBoom+ executable is located if a full path is not specified?

Try the latest build. It have to search in exedir too.

It does not seem to look in the proper place (as if it stops looking for it after not finding it in the CWD). As I mentioned in the post, I have the lastest build. To humor you, I downloaded it again but the problem persists.

Here are the relevant lines from stdout:

I_InitSound: configured audio device with 2229 samples/slice
Fluidplayer: Fluidsynth version 1.1.3
fl_init: error loading soundfont WeedsGM3.sf2
portmidiplayer device list:
MMSystem:Microsoft MIDI Mapper
MMSystem:Microsoft GS Wavetable Synth
portmidiplayer: Opening device MMSystem:Microsoft MIDI Mapper for output
I_InitSound: sound module ready
S_Init: Setting up sound.
S_Init: default sfx volume 11


...and it sounds like it is defaulting to inferior OPL because it did not find the sound font.

When I put an absoulte path in my configuration file, I get this:

I_InitSound: configured audio device with 2229 samples/slice
Fluidplayer: Fluidsynth version 1.1.3
portmidiplayer device list:
MMSystem:Microsoft MIDI Mapper
MMSystem:Microsoft GS Wavetable Synth
portmidiplayer: Opening device MMSystem:Microsoft MIDI Mapper for output
I_InitSound: sound module ready
S_Init: Setting up sound.
S_Init: default sfx volume 11

...and it sounds normal.

Trying a more current build of fluidsynth (1.1.6) has the exact same effect (with the version number being different, obviously).

mbflight.wad, complevel 11

In prboom+:

Looks normal.

In glboom+:

Things shouldn't be black.

cybermind said:

mbflight.wad, complevel 11

In prboom+:
Looks normal.

In glboom+:
Things shouldn't be black.

Thanks. Fixed.

Just a note about PRBoom Plus 2.5.1.4's Linux build installation note:

In the listed dependencies, automake is not present. The 2.5.1.4 tarball requires the bootstrapping script to be run to create the configure script which builds the correct makefiles. This bootstrap calls automake.

Not sure if the following counts.

D-Touch 3.2, Prboom Plus.
Final Doom, Evilution.
Bug, MAP30

Description: On MAP30, the part where you need to get the red skull key on a pillar by pressing a switch to form a spiral staircase, it doesn't finish.
the staircase doesn't become complete all the way to the top, so I'm stuck.
The final step of the staircase doesn't go up to the top part of the pillar, to be precise, doesn't go all the way.

Sounds pretty much like a complevel issue. Is it possible to somehow set the port to complevel 4 (2 or 3 should also do, though)?

Vertical synchronization in glboom has suddenly stopped working for me. What could be the reason? I remember it ceased to work right after I tried updating GPU drivers, but installing the previous version didn't fix the problem.

My GPU is Radeon 7750, just in case.

longwall.wad:

PrBoom+ 2.5.1.4 (@ 2015-Oct-19 20:42) long wall error.


PrBoom+ 2.5.1.3 (long wall error looks better).

make it 1 pixel shorter. 32767, not 32768.

fixed

Cheats.deh:

Patch File for DeHackEd v3.0
# Created with WhackEd4 1.1.0 BETA
# Note: Use the pound sign ('#') to start comment lines.

Doom version = 19
Patch format = 6


Cheat 0
Invincibility = behv
Lite-Amp Goggles = behl
Auto-map = beha
Invisibility = behi
Radiation Suit = behr
BEHOLD menu = beh
Berserk = behs

Video

...what's the bug?

Linguica said:

...what's the bug?

I typed behv and I got invulnerability, 200% health and 200% armor, not only invulnerability.

This is because "Invincibility" is mapped to call all of cheat_health(), cheat_megaarmour() and cheat_pw(pw_invulnerability) in src/m_cheat.c:

  CHEAT("idbeholdh",  "Invincibility",    cht_never, cheat_health, 0),
  CHEAT("idbeholdm",  "Invincibility",    cht_never, cheat_megaarmour, 0),
  CHEAT("idbeholdv",  "Invincibility",    cht_never, cheat_pw, pw_invulnerability),

When using -viddump the video is recorded way too fast, and the doors and lifts close much faster than specified e.g. in the Boom Generalized's linespecial effect duration byte.

For example, a door that was marked to open and close in 3 seconds do so in much less time in prboom+ -viddump mode.

This makes playing puzzl4.wad map01 impossible as it don't give time for the archvile jump; the archvile door simply opens and closes so quick and the archvile can't complete the attack.

Also in -viddump mode I don't hear sound effects even if it is at 100%.

Finally, in -viddump mode (too!) the game is slooooow...

You'd better read prboom's docs, they describe the proper usage.

It says it is meant to be used with -timedemo, not actually playing and recording to video. You are supposed to record demos and later viddump+timedemo to get a video.

VGA said:

You'd better read prboom's docs, they describe the proper usage.

It says it is meant to be used with -timedemo, not actually playing and recording to video. You are supposed to record demos and later viddump+timedemo to get a video.

How I am a idiot! Why didn't I think on that! Thank you!
Life quality += 1.

Hello. There are two issues that I'd like to point out in relation to Freedoom compatibility.

First, I've noticed that for some reason, neither PrBoom 2.5.0 nor PrBoom+ 2.5.1.3 (Win32 versions) seem to use lumps for extra menu items from Freedoom IWADs. Instead, the hardcoded lumps from the port executables are used:

Boom and MBF do not have this issue and load menu text lumps from IWADs as intended:

IIRC it is specifically mentioned in Boom and MBF code that lumps found in WADs should always have priority over their counterparts that are hardcoded in the executable.

The second issue is apparently related to all Boom derivative ports. Namely, if a Freedoom IWAD is run with a PWAD that alters some text strings (messages or level names, for example) via a DEHACKED patch, PrBoom+ (as well as other Boom derivatives) will still use strings loaded from the BEX lump inside the Freedoom IWAD. The rest of the DEHACKED patch (e.g. altered monster animations/behaviour) will work normally. Can this please be fixed?

No more any additional lumps for menu. OPTIONS menu from prboom+ 2.5.1.4: