PrBoom-Plus, ver. 2.5.1.4

[vdgg]

26289048 bytes in the .wad, don't think it was the problem

. My another guess, I hope a better one this time. I must have put by mistake "- skill" in the command line, without a number 1-5. What exactly does this parameter does then?
* I tried with the same map, same WAD, without this mistake and no more problems, so...

[entryway]

vdgg said:

26289048 bytes in the .wad, don't think it was the problem

. My another guess, I hope a better one this time. I must have put by mistake "- skill" in the command line, without a number 1-5. What exactly does this parameter does then?

Yeah, ar04207.lmp has garbage (0xFD) instead of skill (0-4) in header

Fixed version:
http://prboom-plus.sf.net/ar04207.lmp.zip

[vdgg]

OK thanks

[Megamur]

Are we still unable to map specific functions to mouse buttons? I wanted to make MOUSE2 my screenshot button, but the control configuration menus don't seem to recognize mouse buttons when reassigning keys.

I'm also surprised that having no items in a map leaves you with a 0% Items tally instead of 100%. They made a fix for 0% Secrets ages ago.

And I still occasionally encounter long wall error in PrB+, which also surprises me.

[entryway]

Megamur said:

And I still occasionally encounter long wall error in PrB+, which also surprises me.

Fix it, please.

[Megamur]

entryway said:

Fix it, please.

I, uh...have no idea how to do that.

[DaniJ]

Simply split the offending linedef(s) adding another vertex near the centre.

[Megamur]

I know the level design workaround, sure. Just seems odd such errors would still be displayed in the engine. I don't see it being something you'd need to keep for the sake of demo compatibility or anything, but I guess I could be wrong.

[entryway]

DaniJ said:

Simply split the offending linedef(s) adding another vertex near the centre.

I think he meant this (software only):
http://prboom-plus.sf.net/unprecise_lines.mkv.zip

[DaniJ]

Surely thats this then, no? In which case splitting the linedef is the normal "fix".

[Megamur]

entryway said:

I think he meant this (software only):
http://prboom-plus.sf.net/unprecise_lines.mkv.zip

No, no. That's another strange rendering holdover from vanilla, yes, but I meant long wall error. Sadly, I don't have a file hosting account to upload a video of what I mean, but there's a notable example of it in Vile Flesh, Map17. If you press yourself up against line 2673 (a really long, east-west wall at the northernmost part of the map), go as far east as you can (until you collide with line 2674), face west, then move side to side, the wall to your right (line 2673) will kind of "tremble" as you move. Strangely, this only seems to occur with really long walls on the right side of your field of vision, not ones to your left.

I've not tried this in GL modes, only software.

[Spoofer]

Hello! I'm recently getting back into Doom for the first time in a few years, and I'm loving the latest prBoom+. I'm trying to get it to play as much like vanilla as possible, with the exception of fixes for monsters stuck in doors / walls and the like.

Can someone please clarify what comp_dropoff & comp_falloff are intended to do (and what the difference between them is)? No matter what I do with them, I can still BFG the Cyberdemon off his perch in Doom II "Gotcha!" (for example), which I'd rather not be able to do as it alters the original gameplay.

Thanks. :}

[RjY]

Welcome aboard :-)

comp_dropoff is the one about pushing monsters off ledges so you want comp_dropoff=1.

comp_falloff is the MBF torque simulation, that is corpses and things sliding off edges when they end up hanging over them. You want comp_falloff=1 as well.

The bad news though is that comp_dropoff=1 is basically broken. It does work in MBF compatibility (-complevel 11) though.

Here's another post I wrote about this years ago, which basically says the same thing.

[Spoofer]

Thanks a lot. :D I had found that post in a search, but it didn't click until you basically restated it, lol.

I have monster behavior exactly as it was in vanilla (aside from walls / door freezeups), but the last bit I'm wondering about is comp_staylift. I imagine this is as simple as what's described in the menu, where leaving compatibility off ensures that live monsters don't wander off moving lifts? Did they frequently leap off in vanilla doom levels? I honestly don't recall. I'm more conflicted on this one, maybe I'll play around and see which I like, so long as leaving it off doesn't actually impede enemy behavior as far as walking onto or activating lifts.

I ran across a recently uploaded Alien Vendetta level playthrough, which totally inspired my return. I figure I'll work my way up to that skill level with Ultimate, DII, Master Levels, & FD replays first. Then work on all these great custom maps I foolishly never got around to. It's been a blast so far. ^_^

[Janizdreg]

A couple things I've noticed or am curious about in 2.5.1.1.

Firstly there seems to be a software mode rendering issue in Doom II MAP22 exit room ceiling. You easily notice it if you just strafe back and forth in the room. I believe other Doom II IWAD areas are also affected by similar issues, but it's easiest to spot in the room I mentioned.

Secondly I get annoying sound stuttering on average maybe once in 10 seconds, though the frequency varies quite a bit. It occurs in prboom-plus.exe while using the uncapped framerate and it doesn't occur in glboom-plus.exe at all. Sound effects seemed to stutter regardless of various settings I tried and MIDI stutters with sound fonts used under SDL/TiMidity & Fluidsynth. Based on a few quick tests the issue seems to affect version 2.5.0.1 and 2.5.0.8 but not versions 2.2.6.19 and 2.4.3.1. I haven't tried with other versions yet. In case it matters, I have Windows 7 64-bit and I'm using the VIA VT1708s integrated sound board.

And a couple automap questions. Is textured automap coming for the software mode later? I know at least ZDoom currently has that. And will there be a menu binding option for the overlay map key in future versions?

[entryway]

Janizdreg said:

Firstly there seems to be a software mode rendering issue in Doom II MAP22 exit room ceiling. You easily notice it if you just strafe back and forth in the room. I believe other Doom II IWAD areas are also affected by similar issues, but it's easiest to spot in the room I mentioned.

http://www.doomworld.com/vb/post/1011717

Janizdreg said:

And a couple automap questions. Is textured automap coming for the software mode later? I know at least ZDoom currently has that. And will there be a menu binding option for the overlay map key in future versions?

Probably

Have no idea about sound issue. Works fine for me (I think not just for me). Did you try "process_affinity_mask 0" in cfg? It is not necessary to force one core while you are not using SDL midi player.

[tempun]

Janizdreg said:

It occurs in prboom-plus.exe while using the uncapped framerate and it doesn't occur in glboom-plus.exe at all. Sound effects seemed to stutter regardless of various settings I tried and MIDI stutters with sound fonts used under SDL/TiMidity & Fluidsynth.

If you have an old CPU, don't try big soundfonts. I use this: http://soundfonts.homemusician.net/collections_soundfonts/roland_sound_canvas_tuned.html and it WFM on my netbook.

[Janizdreg]

entryway said:

Did you try "process_affinity_mask 0" in cfg?

Thanks, that fixed the issue. =)

[Phml]

Looking at 2.5.1.2 test change log, there's one line I don't understand:

[-] MBF-added codepointers worked with any complevel.

Does that mean MBF codepointers worked with any complevel in previous versions of PrBoom+, and won't work from 2.5.1.2 onwards?

[Grazza]

The "[-]" indicates that this is a bug that has been fixed.

That is, the descriptive text refers to a problem that had existed and has now been removed.

[Phml]

I assume that is a "yes" then. Thanks.

[tempun]

DV.wad D_RUNNIN sounds terrible with portmidi and fluidsynth (wrong notes played). OPL2 and SDL are fine.

[Graf Zahl]

tempun said:

DV.wad D_RUNNIN sounds terrible with portmidi and fluidsynth (wrong notes played). OPL2 and SDL are fine.

How about Fluidsynth in ZDoom? Checking might be useful to see if it's an error with FluidSynth or the MIDI playing code in PrBoom.

[natt]

tempun said:

DV.wad D_RUNNIN sounds terrible with portmidi and fluidsynth (wrong notes played). OPL2 and SDL are fine.

I listened to it with both OPL2 and fluidsynth player, didn't notice anything obviously wrong. Could you provide more information?

[tempun]

Graf Zahl said:

How about Fluidsynth in ZDoom? Checking might be useful to see if it's an error with FluidSynth or the MIDI playing code in PrBoom.

As far as I can be sure that it's Fluidsynth, it works. This does seem to confirm the that it's a bug in PrBoom+ sound code.

Semi-related: I noticed that in PrBoom+ Fluidsynth the pitch is slightly lower than in portmidi - I think less than half-tone but noticeable.

More information: I use Windows XP. The beginning is fine; the problems begin after a while.
Also, should I make an audio capture?

[Gez]

tempun said:

Also, should I make an audio capture?

Yeah, that's the best way to make what you mean clear.

[tempun]

OK, I made the captures: http://www.sendspace.com/file/tda269
The difference can be heard about 8 sec in.

[natt]

I hear it in your recording; one instrument is a whole step down from where it should be. The first thing I'd think of would be a bad soundfont... but you say this happens with portmidi as well?

[tempun]

natt said:

I hear it in your recording; one instrument is a whole step down from where it should be. The first thing I'd think of would be a bad soundfont... but you say this happens with portmidi as well?

I'm sorry, apparently it doesn't happen with portmidi. And indeed when I switch soundfont to Unison problems go away. What's interesting is that GZDoom with fluidsynth seems to play it correctly. Can't tell if it's just falling back to something else, though. It does seem to respond to changing soundfont. The soundfont is this: http://soundfonts.homemusician.net/collections_soundfonts/roland_sound_canvas_tuned.html

[eargosedown]

I updated to newer version to look at a demo (this one, actually) and with the latest version I'm getting no audio at all. I've tried screwing around with all the settings I could think of both in the cfg/options, as well as on windows itself. It doesn't seem to be outputting to the correct audio device (even though there's only one enabled.) In the audio mixer tab, it's showing prboom-plus producing audio.

Any advice? Should I upload my config file?

[edit]: changing snd_midiplayer to "sdl" fixed it.