PrBoom-Plus, ver. 2.5.1.4

Creaphis said:

My copy of PrBoom-Plus 2.5.0.8 "OSX104u" doesn't have that option.

I found that I can launch the launcher by right clicking on the app and selecting Show Package Contents > Contents > MacOS > Launcher.

Have to do it every time though.

Great, fez1-924 now plays back perfectly in latest 2.5.0.9.test with improved backside overflow emulation, thanks entryway.

Ryback said:

Great, fez1-924 now plays back perfectly in latest 2.5.0.9.test with improved backside overflow emulation, thanks entryway.

I still do not understand, why those 'middles' on fez1.wad (541, 542, etc if I remember correctly) look differently with -setmem dosbox/dos71/dos622. Also I do not understand why your demo desynchs with default memory layout (dos622), because Hitherto checked it for me with win98/dos71/dos622 and it looked similar and did not desynch in all three cases. Anyway, you can play it now and that's nice.

I have a little problem with PrBoom-Plus-2.5.0.8.
When I turn down the music volume from options, my SFX volume goes down too. I just can't turn off the music without losing other sounds.
Turning SFX volume down works fine.

Hmm, -nomusic parameter seems to work fine (so this might be useless post).

Paska said:

I have a little problem with PrBoom-Plus-2.5.0.8.
When I turn down the music volume from options, my SFX volume goes down too.

You have to install timidity patches if you want to control MIDI volume independently in Vista/7.

HOW TO: Timidity for PrBoom-Plus

This is not about PrBoom+, but rather Doom+.

There is at least one map in Inferno (E3M7) which crashes Doom+ for me. This happens near the start of the map, when I try to climb the stairway behind the chainsaw. Doesn't happen with the original Doom.exe. Discussion.

Hitherto said it worked fine for him, so I tested whis under XP and 98SE, with and without -nosound. The crash does not happen under XP with -nosound, but with sound it does. Under 98SE it happens in both cases. The error message is one that I have never seen before:

R_DrawFuzzColumn: -13 to -12 at 65

The numbers are different under XP and 98SE.

I am curious what's the reason of this crash and whether it can be fixed.

I noticed a GLBoom rendering glitch on MAP03 of 1monster. Some Sectors that make up the conveyors display the wrong flat (silver-ish, instead of FLAT5_2). They look fine in PRBoom, ZDoom and GZDoom.

Andy Olivera said:

I noticed a GLBoom rendering glitch on MAP03 of 1monster. Some Sectors that make up the conveyors display the wrong flat (silver-ish, instead of FLAT5_2). They look fine in PRBoom, ZDoom and GZDoom.

http://prboom-plus.sf.net/clip/2011-02-10_0.55.53.png

BAH! Not FLAT5_2. Not sure what I was thinking, there. STEP1. Specifically, sectors 38 (and adjacent), 56 (and adjacent), 176, 178, 180, 212 and others.

Andy Olivera said:

BAH! Not FLAT5_2. Not sure what I was thinking, there. STEP1. Specifically, sectors 38 (and adjacent), 56 (and adjacent), 176, 178, 180, 212 and others.

Fixed.

Nice! It amazes me how well you know this code that you can fix bugs so quickly. Thanks! :-)

Donce said:
This is not about PrBoom+, but rather Doom+.

There is at least one map in Inferno (E3M7) which crashes Doom+ for me. This happens near the start of the map, when I try to climb the stairway behind the chainsaw. Doesn't happen with the original Doom.exe. Discussion.

Hitherto said it worked fine for him, so I tested whis under XP and 98SE, with and without -nosound. The crash does not happen under XP with -nosound, but with sound it does. Under 98SE it happens in both cases. The error message is one that I have never seen before:

R_DrawFuzzColumn: -13 to -12 at 65

The numbers are different under XP and 98SE.

I am curious what's the reason of this crash and whether it can be fixed.

I can't replicate the issue using Windows 98. Did you try "reinstalling" Doom+ by applying the patch to a fresh copy of the executable file? Have your PWAD or IWAD been modified in any way?

Curiously, there is a spectre up there near the start of those stairs, and the error is related to drawing graphics with semi-invisibility...

myk said:

I can't replicate the issue using Windows 98. Did you try "reinstalling" Doom+ by applying the patch to a fresh copy of the executable file? Have your PWAD or IWAD been modified in any way?

Curiously, there is a spectre up there near the start of those stairs, and the error is related to drawing graphics with semi-invisibility...

Funny thing is that I actually had the IWAD altered, but reverting did not help.

Yes, it does not crash with -nomonsters or when I enter the staircase looking back. I tried doom2+, and it played back my NM demo to the end, without crashing.

I downloaded doom+ exe from prboom-plus.sourceforge.net after encountering VPOs and finding out that I didn't have doom+, only doom2+. The site was pretty much crippled with Seamonkey 1.x, I could hardly find the needed link (it was hidden by some other elements of the webpage). Anyway, I downloaded it and it crashed. The exe is dated at 2007 April 1.

Btw, I don't know of any patch, I downloaded the full executable file.

April 1... Andrey may be playing a prank on you!

Actually, I solved your issue. Due to the browser incompatibilities, you were led to the download for the older and buggy Doom+ 1.92.1 instead of the corrected Doom+ 1.92.2. Your comments about Seamonkey helped here because what you described made me suspect this possibility, and after testing, I got the error (R_DrawFuzzColumn: -2 to -2 at 63) with that older version on my system.

Try getting it from here:

http://sourceforge.net/projects/prboom-plus/files/doom-plus/1.92.2/

If that doesn't work, you might need to try with another browser.

PS: The patch is in src.zip. It's called udoom.crk and is applied with CRACKER.EXE. I had simply forgotten that the ZIP includes the already hacked binary in addition to the patch.

myk said:

Actually, I solved your issue. Due to the browser incompatibilities, you were led to the download for the older and buggy Doom+ 1.92.1 instead of the corrected Doom+ 1.92.2.

(off-topic) I bet that explains this PrBoom bug of yours as well, I wouldn't put it past them to misuse user-agent header identification

So it was the wrong Doom+ version. Thanks, now everything is fine!

There seems to be something wrong with the Extended Demo Format, whereby unwanted data is added to the demo header. From my experience, it appears to be normally just a small amount of data (1 byte?) that doesn't stop the demo working, but it means that LMPC cannot analyse the demo.

In some cases though, a big piece of junk gets placed in the demo, stopping it from working entirely. Links:

http://www.doomworld.com/vb/doom-speed-demos/54446-demo-weights-11-kb-but-lasts-only-1-second/

http://www.doomworld.com/vb/doom-speed-demos/53433-help-corrupted-gunk-in-demo-header-and-footer/

(Just posting in this thread in case Andrey isn't reading all threads in the Demos Forum. I'd post this as a bug at the sourceforge page, but I don't really know what the problem is with any degree of certainty.)

memfis started to record another demo before closing previous prboom. It is impossible to open file for writing with fopen() in exclusive mode. I can disable ENDOOM screen regardless of misc_fastexit if demorecording.

A strange visual effect occurred while testing PRCP with glBoom+2508:



Full Size Image

Looks like you died under a Specter.

Ah yes, I think you are right. I checked the map and Spectres can get to that area after teleporting in. I must have died right next to it. Thanks, the mystery is solved.

I wondered if it's possible to switch back to the older "secret revealed" sound effect of the 2.5 versions/previous (if im right) from the current most updated one ("dlang"- I guess it was from quake if im correct? the older one was instead used in ancient times for the respawning items with doom95 for the ones who remembers ;o )

thanks in advance

blob1024 said:

I wondered if it's possible to switch back to the older "secret revealed" sound effect of the 2.5 versions

http://www.doomworld.com/vb/showthread.php?s=&postid=941031#post941031

Is pausing MIDI playback allowed by SDL mixer? It would be nice if prboom does it on game pause (like original exe) and whi;e out of focus.

Hitherto said:

Is pausing MIDI playback allowed by SDL mixer? It would be nice if prboom does it on game pause (like original exe)

mus_pause_opt 1

Never_Again said:
What entryway said. Open any IWAD in Slade 3 and find the DSITMBK entry. That's the sound items make when respawning in DM 2.0 (AKA -altdeath). Replace the DSSECRET entry in prboom-plus.wad with it.

I guess it doesnt, but better being sure and asking
.
changing this string for the secret-revealed sound, won't bring any kind of demoreplaying troubles of any sort right? or any troubles for what concerns the compatibility between the ports?

Changing DSSECRET or the "secret revealed" message has no effect on demo compatibility.

I noticed something odd when I played blob1024's max run of map 22 of community chest 3. He hit the exit at 3:50.97, but the final time came up as 3:51 on the stats screen. I was able to reproduce this repeatedly. I had been using glboom-plus.

Then I tried with prboom-plus, and the results became even more bizarre. Half the time he hits the exit at 3:50.97 and half the time at 3:51.00. It is seemingly random which number it is. Regardless, the time on the stats screen is always 3:51.

I tried to replicate this 50/50 behavior in glboom-plus but couldn't. When I use glboom-plus, he *always* hits the exist at 3:50.97 (stats screen always says 3:51 though) and never at 3:51.00.

Here are the exact command lines I was using to test.

glboom-plus -file cchest3.wad -playdemo cch3-22-3-51 -skipsec -12

prboom-plus -file cchest3.wad -playdemo cch3-22-3-51 -skipsec -12

Is there an explanation for this?

Here is the link to the post with the demo: http://www.doomworld.com/vb/showthread.php?postid=962071#post962071

Have you tried watching the last few moments with slow motion (e.g. 10%)? It is possible (indeed, rather likely) that it is always reaching 3:51.00 but that you are not always seeing it.

HUD widgets are recalculated not every 35Hz frame. That's because delta time is mostly 0.6 instead of 0.3 (35/1000)

doit = !(gametic&1); //jff 3/4/98 speed update up for slow systems
if (doit)            //jff 8/7/98 update every time, avoid lag in update
{
  ....
  if (hudadd_gamespeed || hudadd_leveltime)
  {
    HU_widget_build_hudadd();
  }
}

HU_widget_draw_hudadd();