PrBoom-Plus, ver. 2.5.1.4

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?

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
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

Share this post


Link to post
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...

Share this post


Link to post
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.

Share this post


Link to post
Blondie said:

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

Thanks. Fixed?

Share this post


Link to post
entryway said:

Fixed?

Looks like it. Thanks, e6y!

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post
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!

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