PrBoom+ 2.6.66 (Jun 20, 2023)

[seed]

On 1/15/2020 at 6:25 PM, Redneckerz said:

Perhaps the worst timing for this but ill just bring it up for the sake of it:

 

There was a portname thread last year -

 

@Graf Zahl suggested Omega, @Linguica went with Proboom and @seed suggested UBoom/UBoom+.

 

Have we reached some consensus in this? Because the current name sake is not really a proper name (It writes out as PrBoom+UM. Which, um.... is not that glamorous.)

 

On 1/15/2020 at 6:27 PM, seed said:

I still think UBoom+ is the best option, and I've already started referring to Graf's fork as such :p.

 

[Graf Zahl]

Can you please stop this useless discussion?

I said last time that the preferred name is PrBoom, but that entirely depends on Proff.

 

[Spectre01]

Is there any progress on implementing a better sound system or anything else happening with this version?

[seed]

17 hours ago, Spectre01 said:

Is there any progress on implementing a better sound system or anything else happening with this version?

 

There's been quite some activity recently, yes, mostly improvements that aid speedrunning in general. So far nothing going on on the sound front. You can also follow the repo for updates you know :) - https://github.com/coelckers/prboom-plus/commits/master

 

Also, damn, it's been 8 months since 2.5.1.7, I'm only now noticing this, time sure flies fast...

 

But um... since I've learned to compile it from source recently I could provide (unofficial) 32-bit Win builds to check out the recent changes and additions if you want. No x64 because Portmidi is apparently borked and it doesn't play music at all if compiled that way, and since that's what most use in PrBoom...

Edited February 29, 2020 by seed

[Danfun64]

Portmidi is borked on x64 windows? I did not know this. Does this affect other source ports like the ones in the Chocolate lineage? 

[Graf Zahl]

When I last tried to compile a 64 bit binary it crashed within PortMidi, the version at that time had code that wasn't 64 bit proof. As a consequence I had to disable the player to allow it to run at all.

 

If other ports use the same version of PortMidi they will also be affected.

 

[seed]

5 hours ago, Danfun64 said:

Portmidi is borked on x64 windows? I did not know this. Does this affect other source ports like the ones in the Chocolate lineage? 

 

No idea, haven't tried with other ports, but I suppose it's the same if they aren't x64 proof either.

 

In PrBoom it caused it to outright crash, so it had to be disabled in the engine. There is now an x64 dependency which does not crash it anymore, but it doesn't play music at all - since it was disabled I guess. If building as x86 and using the x86 version it works mighty fine.

Edited February 29, 2020 by seed

[Gez]

Dunno if this could be useful. Apparently a slimmed-down fork of PortMidi that has had some fixes for x64. It looks to be very outdated though.

[seed]

3 minutes ago, Gez said:

Dunno if this could be useful. Apparently a slimmed-down fork of PortMidi that has had some fixes for x64. It looks to be very outdated though.

 

Mental found and implemented some fixes for x64, and added an updated x64 version that is part of the windows_dependencies package on git. The problem is that it was pretty much disabled in the engine, so even if that's one is used with a x64 PrBoom build it just plays nothing.

[Graf Zahl]

The disabling was just commenting out a few lines of code, searching the commits will easily find it.

 

[seed]

And after the dependencies got updated again recently, Portmidi was re-enabled for x64 systems and I can indeed confirm it works fine now :) . Building both executables during the compile process also works now, by the way, addressing the concern that only a renamed glboom_plus.exe was getting build at once.

 

interest anyone in an unofficial Win build?

Edited March 3, 2020 by seed

[ReaperAA]

1 hour ago, seed said:

interest anyone in an unofficial Win build?

 

Ofcourse ;)

[seed]

3 hours ago, ReaperAA said:

Ofcourse ;)

 

Excellent :D .

 

Well, here it is. This was compiled with VS2019, so naturally that should also imply no XP support - sorry folks, but even if I knew how to make it compatible with that OS unsupported means unsupported as far as I'm concerned.

 

Some notable changes in this (unofficial) version would be:

• the addition of the -statdump parameter (ported from Chocolate Doom - courtesy of @fabian)
• some enhancements for speedrunning purposes
• improved boom random seed
• inclusion of secret exit in levelstat
• configurable quickstart window
• removed/replaced non-free data lumps
• replaced free dog sprites and sounds, added free plasma ball sprites (ported from GZDoom; based on sprites from the Freedoom project)
• stroller parameter
• no more waiting for VSync when running a timedemo
• building with DOGS support unconditionally
• "popping skull player death" easter egg has been disabled
• inaccuracies of the v1.2 compat mode have been remedied (courtesy of @SmileTheory)
• Complete CMake build system + continuous integration
• fullscreen desktop for the Software renderer
• added some extra states, sprites, and mobjtypes (introduced in Doom Retro, later adapted to Crispy Doom)
• support for the DOOMWADPATH environment variable
• incorporates changes from PrBoom+'s SVN r4542
• printed blinking arrows next to the selected item in the settings menu
• fixes Ultimate Doom level progression (this was one major issue that accidentally slipped into 2.5.1.7)
• 180 is forbidden while strafe is ON
• mouse strafe divisor settings
• fixed compilation with MSYS2
• junk files removed

Those were taken from the PRs that were merged since 2.5.1.7. Hopefully I got everything and all works as intended. I suppose I could make an x86 version as well if it's really wanted, but I'm not really seeing much point in it. This was build off of the fork's master as of 3rd March 2020.

 

Link: https://drive.google.com/file/d/1sFS_Ey9sxVzfGwjAR8RxRWcsSbfgKnH9/view?usp=sharing

 

Edit: If you're getting an error saying that you're missing "VCRUNTIME140_1.dll" download the missing runtime package from here - https://support.microsoft.com/en-gb/help/2977003/the-latest-supported-visual-c-downloads

Edited March 3, 2020 by seed
Update regarding a crash on startup.

[UnluckySpade7]

Thanks for the unofficial build but there seems to be a missing VCRUNTIME140_1.dll from the files which causes it to crash.

[seed]

9 minutes ago, UnluckySpade7 said:

Thanks for the unofficial build but there seems to be a missing VCRUNTIME140_1.dll from the files which causes it to crash.

 

Had a small heart attack when I read the word "crash".

 

It works fine for me, and a quick Google search for the error seems to point to a missing VC Runtime (as the name implies, I guess :v). Try installing the 2015-2019 package from here - https://support.microsoft.com/en-gb/help/2977003/the-latest-supported-visual-c-downloads

Edited March 3, 2020 by seed

[Graf Zahl]

10 minutes ago, UnluckySpade7 said:

Thanks for the unofficial build but there seems to be a missing VCRUNTIME140_1.dll from the files which causes it to crash.

 

 

You will have to install the compiler's runtime from here: https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

 

Sorry, but that hassle is entirely Microsoft's doing. Compiling PrBoom with a static runtime and this many DLLs nearly doubles the binary size and the runtime DLL won't work without installing it.

 

[UnluckySpade7]

That worked, thanks.

[Spectre01]

I am getting this error, which closes the program after attempting to take a screenshot (with the in-game screenshot hotkey):

What the heck does this mean?

[Graf Zahl]

That means "illegal instruction", i.e. the EXE or one of the DLLs was compiled for a CPU more recent than the one you have. So what do you have?

Which of course also begs the question, why errors are being reported in such a useless manner? It cannot be worse than locking out the system crash handler which allows opening a debugger and not providing any useful information itself - and to top it off, report something the average user has no idea what it means.

 

 

[Spectre01]

I've got a Ryzen 5 2600X. I hope that's not holding me back from snapping screenshots in PRBoom+. :P

[Graf Zahl]

My suspicion would be that one of the libraries runs afoul of a CPU identification check and uses incorrect intrinsic code. That CPU is far too recent to not support the code generated by the compiler itself.

 

[seed]

And the CPU I run is a 6th Gen i5, so nothing bleeding edge on my end either. It never occurred to me to check something like this, but it will probably be fine on my end so that won't be of too much help...

 

The curious thing is that I've seen some "Exiting on Signal" errors in the OG PrBoom+ too. Makes me wonder whether it's something inherited, and it's even more curious that it occurs on a system equipped with an AMD CPU.

 

E: Yeah, bound it to F5 and it works here, the screenshot is both saved and the port doesn't crash.

 

@ReaperAA Does taking screenshots crash on your end?

Edited March 4, 2020 by seed

[Da Werecat]

50 minutes ago, seed said:

The curious thing is that I've seen some "Exiting on Signal" errors in the OG PrBoom+ too.

I suspect most of those would be signal 11, which is unrelated, IIRC.

[seed]

5 minutes ago, Da Werecat said:

I suspect most of those would be signal 11, which is unrelated, IIRC.

 

Hm, yes, you seem to be correct, that looks unrelated:

 

 

These errors have such uninformative messages...

Edited March 4, 2020 by seed

[Graf Zahl]

Indeed. Signal 11 is an access violation, btw., mostly null pointer accesses.

I really don't understand what's so appealing about catching such errors with a Posix-based feature that's totally worthless for reporting problems on Windows and eliminates all really useful info entirely.

 

[ReaperAA]

11 hours ago, seed said:

Does taking screenshots crash on your end?

 

Screenshots working fine here.

[Spectre01]

Something must've happened during the initial installation. Dragging the contents of the .zip over the main folder fixed it. I can now resume my photography hobby.

[seed]

Oh noice, good to know it was just an user error after all. Maybe you missed some files the first time around or I dunno.

 

Phew. Now we can advertise this unofficial version :D . And I might continue providing recent Win builds too.

Edited March 5, 2020 by seed

[cmay119]

Is there a way to run underneath and/or ontop of a horde of monsters in PrBoom? This works in gzdoom and is something I find quite useful when playing slaughter wads. I've played with all the what I think are relevant options and whenever I attempt to run underneath a horde of Cacodemons it's like I run into a wall. Thanks all!

[Spectre01]

@cmay119 Nope. That option is not available in PRBoom+. It only emulates vanilla behaviour, which means objects and monsters have infinite vertical collision/height.