PrBoom-Plus, ver. 2.5.1.4

[Marcaek]

If you load a saved game on a map with friction effects apparently they fail? Map05 of 32in24-14 demonstrates this in PRB+ 2.5.1.3

[ReFracture]

Would you ever consider implementing the original resolution of Doom/Boom 2.02 upscaled the way Chocolate-Doom does? I know you can kind of do this if you set the game to 320x200 with software rendering and enable 4 times screen multiply factor.. but the aspect ratio isn't right.


Also unrelated, but I just noticed a couple things about translucency:
Using -complevels, at least 2 or 4 (all I've tried EDIT: Does it with 9 as well, strange since that is boom 2.02) will disable it, and the option doesn't seem to do anything in OpenGL mode.

I notice if I run with no complevel and start in software mode, I can fire plasma balls that will have translucency applied. If while they are still visible I enter the menu, change to OpenGL, then go back to the game, the already existing plasma balls will be translucent still. Any new ones will not be. If I then switch back to software mode none of them will, no matter what the settings are at.. a restart is required to get it back.

I'm running the latest 2.5.1.4 test build. Recreated the same behavior with a newly generated config.

[ReFracture]

Found another bug in glboom-plus 2.5.1.4.test:
gl_texture_external_hires 1

Setting this to 1 will break colored sectors.

Fresh configuration, no changes made at all. boomedit.wad


And with gl_texture_external_hires set to 1:

[fabian]

I have found a slime trail in r4417 that wasn't there in r4403:



Edit: Never mind, I am stupid. It was always there, it is just very hard to see.

[Rez]

fabian said:

I have found a slime trail in r4417 that wasn't there in r4403:

If that's a fireline (I'm the one who named 'em that) then IIRC it's actually a nodebuilder artifact that displays to varying degrees in BOOM descendants.

[fabian]

Rez said:

If that's a fireline (I'm the one who named 'em that) then IIRC it's actually a nodebuilder artifact that displays to varying degrees in BOOM descendants.

Never heard about "fireline", but if you are talking about the color, it's red because of the flashing HOM and the screenshot being taken in just the right moment (i.e. when the flash was red).

Actually, I have first seen it in Crispy Doom, panicked, then checked in PrBoom+, felt relief and posted it here for Andrey to fix. ;) BTW, it is also present in Doom Retro, so it is in no way restricted to the Boom code base.

[Rez]

fabian said:

Never heard about "fireline", but if you are talking about the color, it's red because of the flashing HOM and the screenshot being taken in just the right moment (i.e. when the flash was red).

Oh, didn't realise you had the HOM flashing on -- I haven't even thought about that feature in so long I'd forgot it exists. :)

[Sp00kyFox]

regarding the viddump feature. I don't know exactly how the uncapped framerate option works, but would it be possible to use it together with the timedemo parameter in conjunction with a target framerate?
since youtube supports 60fps that would be a nice feature for converting demos to smooth HFR video files.

VGA said:

Why does the SC-55.sf2 soundfont sound great on gzdoom with timidity++, but on latest prboom+ with fluidsynth D_RUNNIN sounds like it's coming from inside a well?

I can confirm that. I also noticed that the fluidsynth version bundled with prboom+ is outdated. tried to replace it with a recent build (got it from zdoom.org/Download) but no difference.
for now I switched to portmidi using VirtualMidiSynth to select the soundfont I wanna use.

edit: while the portmidi option works fine, it breaks the music recording with -timedemo -viddump. so that's also not a solution.

[entryway]

VGA said:

Why does the SC-55.sf2 soundfont sound great on gzdoom with timidity++, but on latest prboom+ with fluidsynth D_RUNNIN sounds like it's coming from inside a well?

Just tried SC-55.sf2 with gzdoom and prboom+. Both with fluidsynth player of course. D_RUNNIN sounds similar.

[Sp00kyFox]

entryway said:

Just tried SC-55.sf2 with gzdoom and prboom+. Both with fluidsynth player of course. D_RUNNIN sounds similar.

yes, you're right. if you try using the soundfont with timidity or VirtualMIDISynth (it's an implementation of BASSMidi) though you'll get a much clearer sound. for whatever reason it seems that the reverb effect with SC-55.sf2 gets out of hand when using it with fluidsynth. with gzdoom I have the option to lower or disable this effect in the ini with the fluid_reverb* parameters. would it be possible to add similar options to the ini config of prboom+?

[entryway]

Sp00kyFox said:

with gzdoom I have the option to lower or disable this effect in the ini with the fluid_reverb* parameters.

What values? I tried some random, but without a luck.

[Sp00kyFox]

entryway said:

What values? I tried some random, but without a luck.

for a quick test to check if this is related to the reverb effect I just set fluid_reverb=false.

[entryway]

Marcaek said:

If you load a saved game on a map with friction effects apparently they fail? Map05 of 32in24-14 demonstrates this in PRB+ 2.5.1.3

No, it shouldn't. Probably you try to load savegame which was saved with complevel 2?

[entryway]

Sp00kyFox said:

for a quick test to check if this is related to the reverb effect I just set fluid_reverb=false.

Still hear "inside a well" effect.

[entryway]

Ok, I've added mus_fluidsynth_chorus and mus_fluidsynth_reverb config variables

[Sp00kyFox]

entryway said:

Still hear "inside a well" effect.

this is weird. are you sure it didn't work? I used the latest SVN of GZDoom from the DRD Team site and the fluidsynth build from the ZDoom section. fluid_reverb=false disabled the effect for me, just tested it again. setting fluid_reverb_level to 0.0 also does the job. but I guess it doesn't matter anymore...

entryway said:

Ok, I've added mus_fluidsynth_chorus and mus_fluidsynth_reverb config variables

just tested the new build. the new parameters are working fine, thank you very much! I usually used the SGM soundfont but patch93's SC-55 is a nice option.

[entryway]

Sp00kyFox said:

just tested the new build. the new parameters are working fine

music from map07 still sounds strange

[Sp00kyFox]

don't worry, that's just how the soundfont sounds. one can still distinguish between reverb off and on on this track.

[ReFracture]

A note about using fancy mice with polling rate adjustments:

If PrBoom-Plus feels like it is a little jittery when moving the mouse, try toning down the polling rate. My Logitech G500S felt wonky in this engine for quite a while until I adjusted that. All good now.

[dew]

Since the wigglefix was implemented, I started encountering catastrophic node errors. This one is from the southeast corner of sodfinal map28. And it seems tame and harmless when compared to this one from a Valiant beta. skillsaw fixed it for the release candidates by vertex manipulation, but I guess we can send the faulty map if necessary..

It happens when standing right on top of a linedef and it doesn't appear in 2.5.1.3, so I assume the wigglefix causes this. Also so far I've only encountered it in Boom wads, but I don't know if that's an important information.

[entryway]

dew said:

Since the wigglefix was implemented, I started encountering catastrophic node errors. This one is from the southeast corner of sodfinal map28.

Thanks. Confirmed.

[dew]

You mean the one on the site from 2015-Feb-23 20:29? I used that one - I checked and it fixes the midtex "greenscreen" bug in Valiant map04, but this "huge slimetrail" bug persists.

[entryway]

dew said:

You mean the one on the site from 2015-Feb-23 20:29? I used that one - I checked and it fixes the midtex "greenscreen" bug in Valiant map04, but this "huge slimetrail" bug persists.

Try the latest one (2015-Mar-01 23:33). Do you still see slimetrails?

[dew]

I can't trigger the bug either in sodfinal or in the valiant beta anymore. Seems like you fixed it, thanks a lot! I'll report if it reoccurs anywhere else.

[mdmenzel]

...from the crispy doom thread

Xaser said:

Huh, okay. I was confused because of the use of the phrase "limit-removing" in your earlier post before; that and the wiki page mentions outright removal of some limits (for just Doom, I suppose?) but later states that limits "for all four games" have been raised to that of Doom+. Which is it?

The search for a (non-ZDoom) limit-removing Heretic port continues, I suppose.

entryway, do you have any desire to incorporate support for the raven games into the code base? If not, would you be open to someone forking?

[RjY]

Replying to a year-old post from here which I'd not seen before, and another in another subforum which I saw this morning:

TimeOfDeath said:
I think I'm using prplus v2513 (dec04/2011), and using the grid on the automap doesn't show where the blockmap actually is.

Linguica said:
OK, I rechecked in Chocolate Doom, and turns out PrBoom-plus doesn't actually use the blockmap for the grid, because... uh....

I am convinced this is not the intended behaviour to which TimeOfDeath had been led to believe, but a bug.

The automap internally converts map coordinates from the usual 16:16 fixed point to a special 20:12 fixed point, to avoid numerical overflows in coordinate calculation when viewing large maps zoomed all the way out (at the cost of a small amount of precision, which isn't noticable for automap drawing, even when zoomed in).

However it wasn't converting the blockmap origin into the same modified coordinates. You can't subtract coordinates in two different systems of units and hope to get a sensible answer.

I have a patch to restore the automap grid showing what we all know to be true, such as there being on map01 a blockmap line right through the centre of the exit room, which makes the imp in there hard to shoot.

[dannebubinga]

My PC doesn't seem to like the latest glboom.exe!

Whenever I launch it without going through gzdoom builder, my explorer crashes as soon as I tab out or quit glboom.exe. If I don't open the task manager and restart the explorer, my whole pc lags like crazy.

I tried going back to an older version of glboom and then it worked like a charm. Any ideas what's causing this?

[VGA]

dannebubinga said:

My PC doesn't seem to like the latest glboom.exe!

Whenever I launch it without going through gzdoom builder, my explorer crashes as soon as I tab out or quit glboom.exe. If I don't open the task manager and restart the explorer, my whole pc lags like crazy.

I tried going back to an older version of glboom and then it worked like a charm. Any ideas what's causing this?

Your explorer crashes? What Windows are you using? XP?

[dannebubinga]

Yes. Since I have my windows in Swedish I might be using the wrong name here ... I mean that the explorer (the folder you open to locate c:\) says that it's crashed in the task manager. I hit "restart" and then after a couple of seconds of lag, everything is back to normal. I use windows 8.

[Afterglow]

Is there a known issue with neighbouring sector sky heights differing? e.g, sector #1 is 256 and neighbour sector #2 is 384. Raised surfaces visible in sector #2 should be visible from sector #1.





It's as if the sky ceilings are taken at face value with the sky directly drawn where the usual flat surface would be. Rather it should be transparent to show geometry beyond and then the sky. AFAIK that was the behaviour of doom2.exe?

I know this works in ZDoom-derivations and Doomsday. Not sure about other source ports since the map has too many SEGS/sidedefs and I can't be stuffed putting a demo together.