PrBoom-Plus, ver. 2.5.1.4

myk said:

The current light mapping method you described is Doom's and Boom's, and the one that caused full-bright walls was a buggy one from PrBoom.

Aw crap... ZDaemon and ZDoom use the buggy one too. I've been playing many dark wads from '96 lately and it's so hard to see!

manny said:

I'm experiencing some rendering issues: when standing onto or directly underneath a section of wall, the wall texture is twitching.

PrBoom has had this problem for years. Try playing The Chasm in DOOM II. Quite an interesting challenge watching those narrow platforms twisting shape under your feet. :)

I still find it funny that, regardless of the compatibility setting, this engine still suffers from long wall error in software mode.

Megamur said:

PrBoom has had this problem for years. Try playing The Chasm in DOOM II. Quite an interesting challenge watching those narrow platforms twisting shape under your feet. :)

I still find it funny that, regardless of the compatibility setting, this engine still suffers from long wall error in software mode.

Prboom+ does neither of that for me.

Do you use PrBoom-plus or GLBoom-plus? The GL (hardware) version doesn't have those issues. Only the regular (software) PrBoom+ does. (Or at least, it does in v.2.5.1.3.)

The Mac front-end of PrBoom-Plus has two problems:

• Its PrBoom+ actual version is v2.5.1.2, despite the distribution DMG from Sourceforge having the PrBoom-Plus-2.5.1.3.dmg file name:

  M_LoadDefaults: Load system defaults.
   default file: /Users/macbook/Library/Application Support/PrBoom-Plus/prboom-plus.cfg
  
  prboom-plus v2.5.1.2 (http://prboom-plus.sourceforge.net/)
  mask for stdout console output: DA
  mask for stderr console output: 
  IWAD found: /Users/macbook/Library/Application Support/PrBoom-Plus/doom.wad
  PrBoom-Plus (built Nov 27 2011 21:01:25), playing: The Ultimate DOOM
  PrBoom-Plus is released under the GNU General Public license v2.0.
  You are welcome to redistribute it under certain conditions.
  It comes with ABSOLUTELY NO WARRANTY. See the file COPYING for details.
  

• Its compatibility settings in the menu are wrong. See this screenshot. What you see in the text file at the left is correct, what you see in the menu of the front-end is wrong. What selected appears as "PrBoom v2.1.0" is actually MBF.
  
  

Unfortunately I can't patch the fix for the latter for you, because the PrBoom-Plus source code doesn't include the interface resource files (NIB or XIB) for the front-end!

printz said:

Unfortunately I can't patch the fix for the latter for you, because the PrBoom-Plus source code doesn't include the interface resource files (NIB or XIB) for the front-end!

This?
https://www.crowproductions.de/repos/prboom/branches/prboom-plus-24/prboom2/src/MAC/English.lproj/MainMenu.nib/

I guess I didn't look hard enough. But I'll have to see where is the pop-up complevel menu defined.

Okay, I fixed it. Here's the replacement MainMenu.nib which contains the missing compat. settings:

http://files.drdteam.org/index.php/files/get/tGY65XKrls/mainmenu.nib.zip

I edited the CompatMenu interface object using Interface Builder, by dragging two new NSMenuItem to it.

Replace the old one with this one. You don't need to recompile anything. Note: it's a ZIP, you'll have to extract the NIB from it.

Still me, making a third post.

I'd like to add that there is no *.xcodeproj folder (project package) inside the Mac OS X launcher source code folder. There are only the source files. This means I can't easily reprogram it if I want to. Who is in charge of the Mac launcher? Neil?

Does the "Rakefile" file help? Why do people choose to use simple text editors and builder scripts, than the official development environment?

printz said:

Who is in charge of the Mac launcher? Neil?

Yes.

I'd like to know: is there a way to have mouse aiming on glboom-plus? If it is a problem with demo compatibility, it could be an option auto-disabled when recording...

I play and do stuff with glboom-plus since years and sometimes I wish I could play it with mouse aiming when I am on a very vertical map...

I've got a crash while playing the Mac OS X version. Here's the crash dump: http://pastebin.com/nVK5gwPm

Here's what was written to the console (standard output) until the crash:
http://pastebin.com/xeq4jUfw

I was using the MBF complevel.

The crash happened as I was playing E1M4 from DTWID.WAD while listening to this music from PROIECT.WAD: http://files.drdteam.org/index.php/files/get/UNWGEieGKZ/d-e1m4.zip.

Crashed Thread:  1  Dispatch queue: com.apple.libdispatch-manager

Thread 1 Crashed:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib   0x99c5a382 kevent + 10
1   libSystem.B.dylib   0x99c5aa9c _dispatch_mgr_invoke + 215
2   libSystem.B.dylib   0x99c59f59 _dispatch_queue_invoke + 163
3   libSystem.B.dylib   0x99c59cfe _dispatch_worker_thread2 + 240
4   libSystem.B.dylib   0x99c59781 _pthread_wqthread + 390
5   libSystem.B.dylib   0x99c595c6 start_wqthread + 30

I have no idea what is com.apple.libdispatch-manager and why it crashes

Apple uses a thing called "Grand Central Dispatch" as a concurrency abstraction over a thread pool. I think you're reading it backwards though, I would guess it crashed in Z_ChangeTag for some reason.

I saw this was mentioned by Never_Again and Grazza when v1.2 synching was fixed, and I agree: A new command line parameter named something like -waittics, which adds a designated amount of virtual blank tics between the last tic and the end marker, should be very useful when watching existing v1.2 demos, that always end at the exit switch or line, but also for any other demos where the player quit the stats screen too quickly for most people to notice what it says.

There could also be an option to make automatic for v1.2 demos, maybe with a user defined tic length, so the viewer doesn't need to mess with the command line in obvious cases. If PrBoom+ were to start marking v1.2 demos produced by itself with an identifier somewhere after the end marker, this option could be made to affect only vanilla v1.2 demos. Perhaps the presence of a footer would be enough, as an identifier?

PrB+ currently does not produce proper v1.2 demos. The data section is correct, but the header is wrong: it should be 7 bytes, not 13.

On an unrelated note I just discovered something truly alarming: bnb2_na.lmp (for BNBEYOND.WAD) desyncs in vanilla around ~10:19 (after teleporting to a lone Baron on a ledge). Same with Choco v1.6.0. The latest v2.5.1.4-test goes all the way to the tally screen, in vanilla the Baron doesn't die and things go wrong from there.

This is a HMP demo recorded with v2.5.0.9. I just checked it with v2.2.6.26 and it gets to the tally screen there, too; so the problem must be really old.

Any chance of OPL pass through like chocolate-doom?

Submitted bug report 3560985 re: the bnb2_na.lmp desync in vanilla.
Another bug (3560987): all keys are blue in automap with the IDDTIDDT cheat.

I just wanted to point out this annoying visual glitch with the Plasma Gun in hopes it could be fixed, please.

When running forward or backward a white line flashes at the top of the Plasma Gun for a frame or two as seen in the pic below.

It happens in Software mode at most resolutions and aspect ratios. The only way to lessen the effect is to force the aspect ratio to 5:4 which isn't too bad in a 4:3 resolution like 640x480 or 800x600 but very stretched in a 16:9 or 16:10 resolution and the white line still shows up a little less frequently.

Tested in Win7

HackNeyed said:

I just wanted to point out this annoying visual glitch with the Plasma Gun in hopes it could be fixed, please.

That's a really old PrBoom bug. If I remember correctly, it was introduced when high color modes were added. It actually affects all weapons, not just the plasma gun. Never_Again and myself both reported this to e6y on the PrBoom-Plus bugtracker, but it has never been addressed because fixing it would involve disabling color modes above 8-bit (I think?).

The only two resolutions at which this bug does not occur are 320x200 and 640x400. However, the prevalence of the bug varies per resolution, as you've already noted with 640x480. If you want to use non-standard DOOM resolutions in software mode, my only suggestion would be to use a resolution where it is least noticeable and try to ignore it. Personally, I play at 848x480 with the default aspect ratio, and it doesn't bother me too much.

Here's the link to my bugtracker report: http://sourceforge.net/tracker/?func=detail&aid=3004102&group_id=148658&atid=772943

If I press fn+left, I die! How do I unbind Home from committing suicide, from the menu?

There is no key for suicide. Do you mean Home key for "Restart Current Map"? It's in Misc section.

Yes. Can keys be unbound in PrBoom+ without editing the CFG?

printz said:

Yes. Can keys be unbound in PrBoom+ without editing the CFG?

no

Okay. I have now tested prboom+ on no less than 7 devices: 3 laptops and 4 desktop computers. In only ONE out of the seven could I adjust the music volume without it affecting the SFX at the same time. Every other time, when I adjust the music volume, the SFX is adjusted too. Whats up with that shit?

Midi and SFX works fine here, can lower music to nothing and keep sfx and vice versa I'm on linux tho did hear its a windows but tho with SDL_mixer

Old sdl_mixer bug that it seems they'll never fix.

Try the other "preferred midi player" options, such as fluidsynth or portmidi. That should solve this issue - indeed, it's one of the reasons why they were added.

I just took notice to a rendering inconsistency between GL and software in E4M6.

GL
Software

The lowered sky ceiling over the castle blocks parts of the castle behind it in GL, but doesn't in software. Looking at the map, I don't understand why this isn't an issue in software as well. The ceiling and walls in the secret area with the plasma gun are also being rendered, when they shouldn't be.

GL also messed up the battlements inside the moat.

Oh wow, I had completely overlooked that somehow.