PrBoom-Plus, ver. 2.5.1.4

[Lingyan203]

In my version of PrBoom+, 2.5.1.4, sometimes the enemies move backwards and when hit sometimes they fall off the ledges even when they're not dead. I set the Compatibility level to either Default or Boom and that's what happens. It does not happen when I set it to Vanilla settings. Why does it do that?

[vdgg]

It's a very annoying Boom feature, one of the reasons why I avoid -complevel 9 wherever possible. I checked it now and to my surprise, I didn't find a compatibility option under SETUP/DOOM COMPATIBILITY, which would switch it off.

[xAn]

I can´t get ffmpeg to work. The demo runs trough but no files puts out. What files do i need for ffmpeg and what config for glboom.cfg/video-caputering?

[entryway]

http://www.doomworld.com/vb/post/1038882
http://www.doomworld.com/vb/post/1065690
http://www.doomworld.com/vb/post/968123

[xAn]

Thanks for the links/cfg´s. But none of them actually works...

What files exactely do i need for converting with ffmpeg? And where do i have to put the libaries/presets in?

[entryway]

xAn said:

Thanks for the links/cfg´s. But none of them actually works...

What files exactely do i need for converting with ffmpeg? And where do i have to put the libaries/presets in?

You need only ffmpeg.exe (static version) in your prboom-plus's folder

http://ffmpeg.zeranoe.com/builds/

Also, you can check following output files if something is wrong with command lines: mux_stderr.txt, sound_stderr.txt, video_stderr.txt

I've tried Andy's command lines with the latest ffmpeg and got:

Unrecognized option 'cqp'.
Error splitting the argument list: Option not found

in video_stderr.txt

Works fine after removing "-cqp 0". I think "-cqp 0" meant max quality. Check ffmpeg documentation for details.

[Blondie]

I'm encountering a bug with the latest prboom+ test release that causes a crash when loading a .deh or .bex file.

Error message:

D_DoomMainSetup: Cannot find .deh or .bex file named PWADS\DTWID.DEH

[Blondie]

Just wanted to add that this bug appears to only affect environment variables. When loading a .deh file with an exact path, the game launches as normal. However, when I abbreviate per the path specified by my DOOMWADDIR environment variable, it crashes. I don't experience this issue with either iwads or pwads, only dehacked patches and boom extensions.

[Plut]

--

[Holering]

Annoying glitch that's never been fixed is sounds cutting out (only one sound channel seems to be used it seems).

You can try it in MAP01 of Doom 2 by picking up the chainsaw at beginning and getting the blue health packs where the rocket launcher is. Everytime you pick-up an item holding the chainsaw, the chainsaw idling sound cuts out. This problem is with every other sound. Setting the sound channels to 32, 16 or whatever doesn't fix it.

You have to change "retain quirk's in doom's original sound code" under compatibility options to "on" and then back to "off" to temporarily fix it. This has to be done everytime after start-up since the problem comes back after exiting prboom-plus.

Regards

[entryway]

Blondie said:

I'm encountering a bug with the latest prboom+ test release that causes a crash when loading a .deh or .bex file.

Error message:

Can't reproduce. Just tried:
glboom-plus -iwad doom.wad -file pwads/DTWID.wad -deh pwads/DTWID.deh

[ixfd64]

ixfd64 said:

I'm having problems getting PrBoom+ 2.5.1.3 to work on my laptop. The application just quits with a message saying it "failed to initialize properly."

I know someone else had a similar problem before, but I've tried all the solutions other users have mentioned, none of which worked. Any advice would be appreciated.

I'm using Windows XP Service Pack 3, if this helps.

I just downloaded PrBoom+ again, and it somehow worked this time. Interesting...

[Blondie]

entryway said:

Can't reproduce. Just tried:
glboom-plus -iwad doom.wad -file pwads/DTWID.wad -deh pwads/DTWID.deh

Strange. I changed my DOOMWADDIR environment variable path from "C:\Games\DOOM\" (PWADs subfolder) to "C:\Games\DOOM\WADs\" (DTWID subfolder), and I still get the same issue:

D_DoomMainSetup: Cannot find .deh or .bex file named DTWID\DTWID.deh

Here are my exact paths and command line as of now:

DOOMWADDIR environment variable path: "C:\Games\DOOM\WADs\"

IWADs subfolder path: "C:\Games\DOOM\WADs\IWADs\"

DTWID subfolder path: "C:\Games\DOOM\WADs\DTWID\"

Command line: "prboom-plus.exe -iwad IWADs\DOOM.WAD -file DTWID\DTWID.wad -deh DTWID\DTWID.deh -complevel 3"

This is definitely some sort of bug introduced by 2.5.1.4.test, because I do not encounter this problem with 2.5.1.3. If I remove the .deh file from the command line, it loads as expected. However, inclusion of a .deh or .bex file in the command line via my DOOMWADDIR path results in a crash. I'm using Windows XP SP3, if it makes any difference.

[entryway]

Blondie said:

inclusion of a .deh or .bex file in the command line via my DOOMWADDIR path results in a crash

Thanks. Fixed?

[Blondie]

entryway said:

Fixed?

Looks like it. Thanks, e6y!

[ixfd64]

I'm not sure if this issue is related, but PrBoom+ doesn't seem to make full use of .bex files.

I was playing The Lost Episodes of Doom using the unofficial Ultimate Doom patch and the .bex file that came with it. PrBoom+ did correctly replace the level names, but it didn't change the intermission text after I beat the bosses.

[entryway]

ixfd64 said:

I'm not sure if this issue is related, but PrBoom+ doesn't seem to make full use of .bex files.

I was playing The Lost Episodes of Doom using the unofficial Ultimate Doom patch and the .bex file that came with it. PrBoom+ did correctly replace the level names, but it didn't change the intermission text after I beat the bosses.

Does any other port process it correctly? In any case I don't know what is unofficial Ultimate Doom patch.

[fabian]

entryway said:

In any case I don't know what is unofficial Ultimate Doom patch.

I guess he is talking about the fix found here:
http://www.doomworld.com/pageofdoom/lostdoom.html

[entryway]

fabian said:

I guess he is talking about the fix found here:
http://www.doomworld.com/pageofdoom/lostdoom.html

Thanks. It's formatted wrongly. MBF.EXE disallows it too.

[Blondie]

Bug: Spectres flicker in certain situations when using the new shaders light mode. See the red key room in E1M6 DOOM.WAD as an example.

Added to the tracker: https://sourceforge.net/p/prboom-plus/bugs/228/

[fabian]

entryway said:

Thanks. It's formatted wrongly. MBF.EXE disallows it too.

Gosh, I was just going to play that WAD myself. Could you maybe either provide a fixed version of that BEX file or make prboom-plus's file parser more tolerant against the formatting mistakes found in it, please?

[entryway]

fabian said:

Gosh, I was just going to play that WAD myself. Could you maybe either provide a fixed version of that BEX file or make prboom-plus's file parser more tolerant against the formatting mistakes found in it, please?

http://prboom-plus.sf.net/Jptr_fix2.bex.zip

More tolerant parser will be a reason of increasing incompatible dehs

[fabian]

entryway said:

http://prboom-plus.sf.net/Jptr_fix2.bex.zip

More tolerant parser will be a reason of increasing incompatible dehs

o_O Great, thanks!

[Quasar]

BOOM's DeHackEd/BEX parser is the biggest piece of shit ever. 9_9

[printz]

entryway said:

http://prboom-plus.sf.net/Jptr_fix2.bex.zip

More tolerant parser will be a reason of increasing incompatible dehs

The parser should be equally tolerant to the Dehacked application.

[Graf Zahl]

Well, ZDoom handles that patch properly. It wouldn't really be that hard to concatenate the lines if they end with a backslash, and strip out all those whitespace, isn't it?

In case it interests anyone, here's the code responsible:

static int PatchStrings (int dummy)
{
	int result;

	DPrintf ("[Strings]\n");

	while ((result = GetLine()) == 1)
	{
		FString holdstring;
		do
		{
			holdstring += skipwhite (Line2);
			holdstring.StripRight();
			if (holdstring.Len() > 0 && holdstring[holdstring.Len()-1] == '\\')
			{
				holdstring.Truncate((long)holdstring.Len()-1);
				Line2 = igets ();
			}
			else
			{
				Line2 = NULL;
			}
		} while (Line2 && *Line2);

		ReplaceSpecialChars (holdstring.LockBuffer());
		holdstring.UnlockBuffer();
		GStrings.SetString (Line1, holdstring);
		DPrintf ("%s set to:\n%s\n", Line1, holdstring.GetChars());
	}

	return result;
}

And this doesn't look like 'piece of shit' to me.

Sorry, but if your parser can't handle this it's not because it's formatted wrongly, it's because the parser isn't well designed.

[entryway]

I've checked Eternity and Risen3D. Risen3D is able to handle it, but Eternity does not.

[Quasar]

entryway said:

I've checked Eternity and Risen3D. Risen3D is able to handle it, but Eternity does not.

Because EE uses the BOOM DEH/BEX parser, for the same reason - "compatibility." I can't tell you how badly I want to ditch it though. It's chock full of potential security exploits and crashing glitches; if given deformed-enough input I have absolutely no doubt you could accomplish arbitrary code execution using it. Static analyzers throw a fit over half the code in there.

Graf: if you haven't actually seen BOOM's d_deh.c, I suggest taking a look at it. You may need an exorcist for your eyeballs afterward, though.

[printz]

Has anyone looked at how Dehacked itself parses DEH files? Or hell, Whacked2, if you want to really be GPL.

[ixfd64]

entryway said:

http://prboom-plus.sf.net/Jptr_fix2.bex.zip

More tolerant parser will be a reason of increasing incompatible dehs

That worked like a charm. Thanks!

By the way, I have a suggestion: it would be nice if the GUI launcher could handle sub-directories. I'm sure a lot of us prefer to keep our PrBoom+ folder from becoming too cluttered. Thanks!