PrBoom-Plus, ver. 2.5.1.4

[Searcher]

I recorded a run in av.wad, map 25. The demo was done with prboom 247 w/ doom2 v 1.9 (default) compat.

The run will not fully play back in prboom-plus 2481 but will play back fine with prboom 247. Just for fun I tried -spechit 2230937832 and that did not help. At about 12 minutes of the demo, leaving the red key room, with prboom plus the monsters go into clipping/ghost mode and can not be shot.

I was using, for the mindless slaughter fun, suprwep8.deh if it might make any difference.

Any ideas what might help it play back in prboom plus? Prboom plus does recognize it as a doom2 v 1.9 demo.

I did not yet check to see if any other port/exe would play it back.

Not sure if it is a prboom-plus or prboom issue or?

[Grazza]

Sounds like an Intercepts Overflow - Prboom-plus is emulating (or attempting to emulate) the behaviour of Doom2.exe. You'll probably find that the same thing happens (or it might crash) if you play it back with Doom2.exe (with the deh applied, of course).

You can turn off Intercepts Overflow emulation in order to play back "Doom-incompatible" demos that were recorded without it. This can be done via the "General" menu, last page.

[Searcher]

OK, it was intercepts overflow. Turned it off and it plays back perfectly. Thanks Grazza.

[ultdoomer]

I noticed this line...

 Events queue will not be cleared at the start. (like vanilla does)

...in Prboom-Plus's most recent changelog. Will this cause the turn-snapping bug to return?

[Grazza]

No. In fact, the start-up behaviour is greatly improved (you can, like with vanilla, be holding down a key during the program start-up without getting fouled up). You can see this for yourself in the current test version.

[entryway]

You can download it and check up.

[emailking]

How come the files sizes on the test versions keep juumping around? Like the code change will be a couple of lines but the final file size goes up 20K. And then the next test version it will be back down again. Is it a debug/release thing?

[entryway]

It happens because generally I compile PrBoom+ with Visual Studio 2005, but sometimes I do it with Visual Studio 6.0 (on the work). The first one produces greater binaries.

[emailking]

Oh, ok. That makes sense then. Good to know.

[myk]

Features that are pretty essential, and are (AFAIK) missing:

• Reinstate the MBF OPTIONS lump, but adding, naturally, PrBoom(-plus)'s additional extensions, such as compatibility levels, new specific compatibility settings, longtics, and so on. Just like ZDoom has wad options in its MapInfo lump, any engine with many settings really needs something of the sort to ensure that users won't be confused when playing wads, and to help authors make wads that can played properly without having to relay redundant or repetitive information.
  
  
• Expand BEX to include any missing DeHackEd strings that are of importance, such as some graphic resources, and perhaps also the startup message (some PWADs use it, and some authors may want it displayed).

I could have posted this in the PrBoom thread, but since PrBoom+ is generally more up to date in regard to demo stuff or bugfixing (even if subtly), and is updated more often, it seems to me like the one to implement these (first).

[chungy]

Starting from a recent SVN revision (I'm not sure which one exactly, my guess would be 2560 or so), I can no longer compile PrBoom+. I don't have OpenGL support, and even when I pass --disable-gl to the configure script (which would work previously), I get this:

if gcc -DHAVE_CONFIG_H -I. -I. -I..      -g -O2 -Wall -Wno-unused\
 -Wno-switch -Winline -Wwrite-strings -Wundef -Wbad-function-cast\
 -Wcast-align -Wcast-qual -ffast-math -O2 -fomit-frame-pointer\
 -I../src -I/usr/local/include/SDL -D_REENTRANT -MT\
 gl_wipe.o -MD -MP -MF ".deps/gl_wipe.Tpo" -c -o gl_wipe.o\
 gl_wipe.c;  then mv -f ".deps/gl_wipe.Tpo" ".deps/gl_wipe.Po";\
 else rm -f ".deps/gl_wipe.Tpo"; exit 1; fi
In file included from gl_wipe.c:34:
/usr/local/include/SDL/SDL_opengl.h:44:65: GL/gl.h: No such file or directory
/usr/local/include/SDL/SDL_opengl.h:45:62: GL/glu.h: No such file or directory

And then a buttload of errors related to my lack of OpenGL.
(edited to not stretch the page, newlines are escaped with \)

[Grazza]

Currently we're at 2569. 2560 (and the following few) featured new code (gl_wipe.c), and 2565 and 2568 included fixes for compilation. I suggest updating and trying again.

[chungy]

There won't be any differences from my current situation:
$ svn up
At revision 2569.

btw, I'm running OpenBSD-current.

[entryway]

MikeRS
try again

[chungy]

thanks, it works now

[entryway]

Can somebody try to compile PCRE for MAC in context of prboom-plus? I want to release the new version of port, but it can't be compiled for MAC with all new features, because Neil don't want to spend his time for compiling PCRE sub-project.

[entryway]

There is a following "problem"

You should know, BOOM has no support for sky property-transfer linedef types (271-272), but prboom shows transferred skies with boom compatibility (-complevel 9) After fixing this incompatibility problem in the latest beta I got a few negative feedbacks. Of course, some people thought that these actions are BOOM actions, but it is not true. PrBoom is a very strict port in contrast to zdoom and my suggestion is emulation of boom in boom compatibility and it is obvious. But in this case all boom compatible demos on "boom" wads such as scythe2, Cchest2, etc which used this feature will be played with default doom skies instead of transfered.

What do you think about that?

[myk]

entryway said:
What do you think about that?

You're quite right, and they're plain wrong. If they want those features they should aim for MBF compatibility (or higher).

On that account, also see my previous post on this thread for v1.9 and MBF stuff that is not supported.

Another thing that I noticed is that if in Boom I disable translucency and play a demo, translucency is not used, but PrBoom's compatibility level 9 forces translucency on the fireball sprites and such no matter what my settings are.

[emailking]

Not an issue I care too much about since I almost always play on 2 or -1. But your logic sounds right. I think people are probably just resisting change.

[Grazza]

I agree that in Boom-compatibility mode this MBF feature should not be supported. This doesn't really lead to any enormous problem, as it just means that the standard (or normally replaced) sky will be displayed instead - i.e. a cosmetic issue, rather than one that breaks a level.

[Squonk]

Hi there,
Is it possible to automatically remove the stdout.txt file each time a demo is read, or avoiding the file to be made?
I've made a research in readme's and others txt, but didn't found...
Thanks

[entryway]

you can't
these files annoy me too

[myk]

How can that file be a problem?

It does log useful startup info. Not that I look at it much. Could you not add a CFG option telling the engine not to write it?

[Squonk]

I don't know, anyway the line doesn't exist in prboom.cfg or glboom.cfg.
These files are not really a problem, but as I just have to double click on a demo to read it, I have stdout.txt files everywhere...

[CODOR]

entryway said:
you can't
these files annoy me too

Maybe you can... take a look here, although it seems you'd need to distribute a copy of SDL.dll compiled with nostdio...

[Squonk]

Is it hard to do? I don't understand a single word of that :)

[Grazza]

I find these files very often useful (they contain a mass of info that isn't too easy to get otherwise), so if it is a choice between having them every time or never having them, I'd certainly prefer every time.

Squonk said:

These files are not really a problem, but as I just have to double click on a demo to read it, I have stdout.txt files everywhere...

Funny, for me, no matter where the demo is that I am viewing, the stdout.txt file is always written into the folder where the exe is (overwriting a previous stdout.txt), so I don't get multiple copies of it strewn all over my hard disk. The command line (via default or right-click action) is:

C:\Doom2\glboom.exe "%1" -auto

(glboom.exe is just glboom-plus.exe renamed to distinguish it from the all-in-one version). I am using a version of sdl.dll dated 20/07/07 (and the current 'test' version of prboom-plus), in case that is relevant.

[Squonk]

I've no use of these files, as I just watch demos from Compet-N and from friends.

And to watch demos by double-clicking on, I just told windows to open all lmps with glboom.exe (plus). So when I open it, prboom ask me which iwad and pwad I wanna use. That's not exactly your method.
And I have stdout.txt files everywhere, not in the exe folder... Which is quite annoying

[emailking]

For me it's just like Grazza said. I just have one that overwrites every time. I followed his instructions for setting it up to the letter. Maybe you can try that.

[entryway]

Hmm. Strange things. Prboom created these files in a current dir, not in the exe dir and it annoyed me often, because I had these files in my folders with demos, temp folders with wads, etc. But. I try it now and the stdout.txt file is always written into the folder where the exe