PrBoom-Plus, ver. 2.5.1.4

[Jon]

Danfun64 said:

I may not be cybermind, but I have to ask. How do I find descriptions of prboom-plus svn commits? The main trunk doesn't give any descriptions, and the github mirror doesn't give a clear idea of svn commit numbers.

After I recovered from the shock of realising prboom+ still used SVN, I went into my checkout and typed

svn log -rNUMBER

.

[Danfun64]

so... why was PC_WRONG_FIXEDDIV removed? Did it make things overly complicated?

[cybermind]

// delete me

[Azuruish]

I have some weird issue with sound. In Deus Vult MAP04 (ending) instead of sound I hear there ugly shitty noise. Same shit I have with midi in Newgothic Movement 1 Map11 - instead of music I hear noise.
Is it possible to fix it? I tested different 'midi players' and no effect. On others ports as Dos Boom, Chocolate Doom are the same problem.

[kuchitsu]

I have a problem with keybinds. When I set "Screenshot" to the Print Screen button, it says just JUNK:

The bind still works but only until I quit the game. After that it resets and I have to set it again. What is going on?

[Danfun64]

Azuruish said:

I have some weird issue with sound. In Deus Vult MAP04 (ending) instead of sound I hear there ugly shitty noise. Same shit I have with midi in Newgothic Movement 1 Map11 - instead of music I hear noise.
Is it possible to fix it? I tested different 'midi players' and no effect. On others ports as Dos Boom, Chocolate Doom are the same problem.

So it only sounds right in vanilla?

[Azuruish]

Danfun64 said:

So it only sounds right in vanilla?

Yes. On Zdoom (for example) everything ok.

[VGA]

Music plays fine here. Do you have some midi device installed? Like BASSMIDI?

[rehelekretep]

i've installed VirtualMIDISynth ( http://coolsoft.altervista.org/en/virtualmidisynth ) and im using a Roland SC-55 soundfont with it.

in GLBoom+ 2.5.1.4 the music hangs/repeats 3 times in quick succession when the MIDI itself changes (i.e. between intermission screens & levels). this does not happen in GZDoom.

any idea why?

many thanks,

[mdmenzel]

[Azuruish]

VGA said:

Music plays fine here. Do you have some midi device installed? Like BASSMIDI?

Yeah. I got it but I have no idea how to install others midi players - they are doesn't appear in main menu.

[entryway]

Azuruish said:

I have some weird issue with sound. In Deus Vult MAP04 (ending) instead of sound I hear there ugly shitty noise.

because of unsupported format of DSBOSSIT

[damerell]

damerell said:

I've just sent a pull request on github:

I gather Sourcefrog may be the main development site for prboom-plus - should I raise an issue there pertaining to this, or just be less impatient, or something else?

(It's fine if the answer is "be less impatient".)

[entryway]

damerell said:

should I raise an issue

I saw your patches. I'll apply later. Thanks.

[BrainMuncher]

First post, hope this is the right place to mention this.

I've been using GLBoom-plus with the shader-based sector lighting mode (which is by far the best one imo), and there is a strange bug where all of the sprites and textures fail to draw until you've looked at some sky. So I start the program, and it looks like this:

Spoiler

Then as soon as once I've looked at some sky (eg by turning to the left to look at where the chainsaw is), it works perfectly until I quit and restart the program.

It's only really a minor annoyance unless I'm playing a megawad which replaces all the usual levels, so I don't know where to warp to before playing to find some sky to look at.

Any ideas about how to remedy this?

[entryway]

BrainMuncher said:

Then as soon as once I've looked at some sky (eg by turning to the left to look at where the chainsaw is), it works perfectly until I quit and restart the program.

Try gl_skymode 1,2,3 and 4 in cfg. Same effect?

[BrainMuncher]

entryway said:

Try gl_skymode 1,2,3 and 4 in cfg. Same effect?

gl_skymode=0 - Initial behaviour where looking at the sky fixes it
gl_skymode=1 - Looking at sky no longer fixes it, sky renders as solid red
gl_skymode=2 - Same as mode=0
gl_skymode=3 - Looking at sky no longer fixes it, sky renders correctly
gl_skymode=4 - Same as mode=3

Screenshot of mode 0:

Spoiler

Screenshot of mode 1:

Spoiler

Screenshot of mode 3 & 4:

Spoiler

[dew]

2.5.1.5 does something weird with binding the printscreen key. When bound, the menu will show "junk", but the key will work correctly. However on restart it shows... a star or something and the config file contains 0x40000046. I'm using win8.1.

[vadrig4r]

BrainMuncher said:

First post, hope this is the right place to mention this.

I've been using GLBoom-plus with the shader-based sector lighting mode (which is by far the best one imo), and there is a strange bug where all of the sprites and textures fail to draw until you've looked at some sky. So I start the program, and it looks like this:

Shader sector lighting works perfectly on my setup(HD4870 512 with EOL drivers on Win7 64). What's your video card? Driver version? OS?

dew said:

2.5.1.5 does something weird with binding the printscreen key. When bound, the menu will show "junk", but the key will work correctly. However on restart it shows... a star or something and the config file contains 0x40000046. I'm using win8.1.

I could have sworn I remember this from previous versions too but might be wrong.

[damerell]

entryway said:

I saw your patches. I'll apply later. Thanks.

Thank you (especially if they seem to work). I'll be less impatient. :-)

[Doom_user]

I'm getting an error message when I try to start today's builds of PrBoom+ and GLBoom+. It says something about pcre3.dll being missing. The February 24th builds work perfectly for me.

[entryway]

Doom_user said:

It says something about pcre3.dll being missing.

reuploaded with dll

[Doom_user]

entryway said:

reuploaded with dll

Thanks. It works perfectly now.

[plums]

Latest build gives me an error when I try to run it:

The procedure entry point _except_handler4_common could not be located in the dynamic link library msvcrt.dll

Using Windows XP, still. I think I've got all the MSVC redists installed that I should need.

[plums]

Newest build works, thanks.

[printz]

POSSIBLE DEMO DESYNC ALERT

I've noticed that PrBoom+ still uses the P_CreateBlockMap function from Boom, instead of the newer one from MBF. Eternity uses the MBF one.

What happens: the demo va27-1201.zip for Valiant (http://doomedsda.us/lmps/2601/1/va27-1201.zip), recorded with -complevel 11, which should run on Eternity, fails on Eternity at some point late in the level.

Suspicion: Demon (doomednum 3002) thing index 254 at location (14233.56, -1570.53) tries to move (P_TryMove from P_Move) into a spot that hits both walls and spechits. I've noticed that in PrBoom+ the spechits after this attempt are 0, while in Eternity they're several. This causes a movedir reset to NODIR in Eternity. After this moment, the demo desyncs in Eternity. And I could only explain this by the blockmap lines being ordered differently, due to different algorithms between Boom and MBF. If this is true, then demos in huge maps from PrBoom+ may also fail in plain MBF.

[BrainMuncher]

I've been having an issue with mouse precision when recording demos in PrBoom-Plus, and I think I've figured out what is happening.

When recording with -complevel 17, the mouse behaves the same as when not recording. But with most lower levels (9, 2, etc.), there seems to be minimum amount of granularity to the turning. The minimum amount you can turn seems to be about the same as a single stroke of an arrow key. I noticed the same behaviour in Chocolate Doom, so I'm assuming this is a result of the demo format itself.

My issue is that in PrBoom-Plus, any amount of movement that is less than enough to cause one increment of turning appears to be discarded. This makes mouse movement very imprecise and unpredictable.

Let's call the minimum amount of turning that can happen a "step". If I move the mouse enough to turn 3.5 "steps", it will turn 3 steps and the 0.5 is lost. If that happens twice in a row, I've only turned 6 steps when I should have turned 7. If you want a really noticeable example of this, turn your mouse sensitivity way down, start recording a demo, and move the mouse slowly. It is possible to move the mouse all the way across your mouse pad with out the character turning at all. If you try the same thing in Chocolate or Crispy Doom you should be able to see what I am getting at - they still have the coarse quantisation, but without the loss of precision between "steps".

The leftover precision that isn't enough for a full step should be getting carried over and summed with the next input measurement, this would result in much smoother mouse movement.

[vadrig4r]

Wow, interesting find. I don't record demos much so never came across this but the difference is very noticeable.

[Linguica]

Just to be clear, your complaint about loss of mouse half-steps is only happening in PrBoom, right?

[BrainMuncher]

vadrig4r said:

Wow, interesting find. I don't record demos much so never came across this but the difference is very noticeable.

Yeah it reminds me of the feeling of an old ball mouse when the ball would stick, so your hand would move but the cursor would not.

Linguica said:

Just to be clear, your complaint about loss of mouse half-steps is only happening in PrBoom, right?

Right, and only while recording a demo, and only at lower -complevels. There's no issue at -complevel 17, presumably because it's not even trying to do the low-res turning thing when compatibility isn't a factor (same goes for zdoom).

At first I thought my mouse was dying or had some fluff in it or something, I didn't assume it was prboom because people seem to recommend it for demo recording.