PrBoom+ 2.6.66 (Jun 20, 2023)

[drfrag]

Seems this is the classic vanilla demo desync when accesing the menu, Boom? fixed it with a sophisticated silent pause and in Crispy you get a pause when playing back the demo. I fixed it in RUDE just preventing menu access when recording and showing a message about it, those don't cause demo desync.

[GoneAway]

This suggestion was sent to me but I haven't tested it yet:

 

g_game.c:1205:

 

change

if (paused & 2 && gamestate != GS_LEVEL)

 

to

if ((paused & 2 || (!demoplayback && menuactive && !netgame)) && gamestate != GS_LEVEL)

 

If someone wants to work on that feel free, otherwise I will get to it when I get a chance.

[Spectre01]

So just to get this straight: this is an issue related to pressing Esc during the intermission screen between maps and not during the actual level?

[tchkb]

7 hours ago, Spectre01 said:

So just to get this straight: this is an issue related to pressing Esc during the intermission screen between maps and not during the actual level?

 

More specifically, your demos will have broken sync if you press esc before the %s and timer finish counting down. If you press use/fire to instantly end the countdown and then bring the menu up, everything will be fine. I've done this numerous times in my multimap runs to shorten the breaks I take between maps on demo playback (the time you spend in menu doesn't get recorded), but my demos are fine because I've always done it in fire->esc order, not the other way around.

[fabian]

On 9/14/2020 at 1:45 AM, kraflab said:

If someone wants to work on that feel free, otherwise I will get to it when I get a chance.

 

Looks reasonable, could you please try this approach and report back?

[ChopBlock223]

Just popping in to say that I'm very glad that this is being done.

Will there be a way to fix things like some of the broken linedef functions (generalized walkover crushers, for instance), and the janky mouse turning you get with Windows 10, all while maintaining demo compat?

[Alper002]

3 hours ago, ChopBlock223 said:

 

(generalized walkover crushers, for instance) ...all while maintaining demo compat?

I wonder if a UMAPINFO map property should be able to be used in order to fix generalized walkover crushers and such... Doing that doesn't seem like it'd break demo compat in the long run, since a new demo compatibility standard is being considered for UMAPINFO anyway.

 

I have some other things that I've wanted to say for a while, but didn't think to until now:

According to the UMAPINFO.txt there's no map property to enable/disable the monster telefrags that are hardcoded to occur on MAP30. Feels like an omission worth filling in.

Also, since the bossdeath monster names are based on names from zdoom's actor list, how is one meant to refer it to the DEHEXTRA extra things, if at all? (UMAPINFO.txt also mentions a list "below" the explanation on the classnames, but no list ever comes up in the text file.)

 

[Ferk]

Quote

I wonder if a UMAPINFO map property should be able to be used in order to fix generalized walkover crushers and such

 

Personally I don't think UMAPINFO would be the right place to add compatibility flags. It's meant to be a cross-port standard.

 

For preserving demo compat it would be better to use the new demo format extensible header for which there's an open PR.

[Alper002]

2 hours ago, Ferk said:

 

Personally I don't think UMAPINFO would be the right place to add compatibility flags. It's meant to be a cross-port standard.

That is a very fair point, I was sure there was something wrong with my suggestion.

However, now I'm wondering... where and how should/are these kinds of compatibilty flags going to be handled, then? Some sort of way to set these kinds of flags on the modder's side would be very helpful, I think.

[Ferk]

One idea could be having support for the OPTIONS lump which Eternity and MBF already support: https://eternity.youfailit.net/wiki/OPTIONS

This would allow PWADs to set some preferred default values for several settings, including fine-grained compatibility flags.

But these should just be defaults, the user should still have freedom to change the settings, imho.

[Da Werecat]

Having legacy OPTIONS would be sweet. However, new features would require a different lump to preserve compatibility with stock MBF.

[ChopBlock223]

Is there any other linedef action or sector function which is broken, by the way?

[Ferk]

10 hours ago, Da Werecat said:

Having legacy OPTIONS would be sweet. However, new features would require a different lump to preserve compatibility with stock MBF.

 

Eternity added many new features to its OPTIONS that are not compatible with MBF.

When an option is not recognized it's ignored. At least that's what PrBoom does when parsing prboom.cfg and I would expect the same from eternity.cfg and mbf.cfg, many options are already the same since all three are descendants from the same family of ports.

[Shadow Hog]

21 hours ago, Alper002 said:

Also, since the bossdeath monster names are based on names from zdoom's actor list, how is one meant to refer it to the DEHEXTRA extra things, if at all? (UMAPINFO.txt also mentions a list "below" the explanation on the classnames, but no list ever comes up in the text file.)

As of writing, this appears to be the full list (from umapinfo.cpp):

 

Spoiler

static const char * const ActorNames[] =
{
	"DoomPlayer",
	"ZombieMan",
	"ShotgunGuy",
	"Archvile",
	"ArchvileFire",
	"Revenant",
	"RevenantTracer",
	"RevenantTracerSmoke",
	"Fatso",
	"FatShot",
	"ChaingunGuy",
	"DoomImp",
	"Demon",
	"Spectre",
	"Cacodemon",
	"BaronOfHell",
	"BaronBall",
	"HellKnight",
	"LostSoul",
	"SpiderMastermind",
	"Arachnotron",
	"Cyberdemon",
	"PainElemental",
	"WolfensteinSS",
	"CommanderKeen",
	"BossBrain",
	"BossEye",
	"BossTarget",
	"SpawnShot",
	"SpawnFire",
	"ExplosiveBarrel",
	"DoomImpBall",
	"CacodemonBall",
	"Rocket",
	"PlasmaBall",
	"BFGBall",
	"ArachnotronPlasma",
	"BulletPuff",
	"Blood",
	"TeleportFog",
	"ItemFog",
	"TeleportDest",
	"BFGExtra",
	"GreenArmor",
	"BlueArmor",
	"HealthBonus",
	"ArmorBonus",
	"BlueCard",
	"RedCard",
	"YellowCard",
	"YellowSkull",
	"RedSkull",
	"BlueSkull",
	"Stimpack",
	"Medikit",
	"Soulsphere",
	"InvulnerabilitySphere",
	"Berserk",
	"BlurSphere",
	"RadSuit",
	"Allmap",
	"Infrared",
	"Megasphere",
	"Clip",
	"ClipBox",
	"RocketAmmo",
	"RocketBox",
	"Cell",
	"CellPack",
	"Shell",
	"ShellBox",
	"Backpack",
	"BFG9000",
	"Chaingun",
	"Chainsaw",
	"RocketLauncher",
	"PlasmaRifle",
	"Shotgun",
	"SuperShotgun",
	"TechLamp",
	"TechLamp2",
	"Column",
	"TallGreenColumn",
	"ShortGreenColumn",
	"TallRedColumn",
	"ShortRedColumn",
	"SkullColumn",
	"HeartColumn",
	"EvilEye",
	"FloatingSkull",
	"TorchTree",
	"BlueTorch",
	"GreenTorch",
	"RedTorch",
	"ShortBlueTorch",
	"ShortGreenTorch",
	"ShortRedTorch",
	"Slalagtite",
	"TechPillar",
	"CandleStick",
	"Candelabra",
	"BloodyTwitch",
	"Meat2",
	"Meat3",
	"Meat4",
	"Meat5",
	"NonsolidMeat2",
	"NonsolidMeat4",
	"NonsolidMeat3",
	"NonsolidMeat5",
	"NonsolidTwitch",
	"DeadCacodemon",
	"DeadMarine",
	"DeadZombieMan",
	"DeadDemon",
	"DeadLostSoul",
	"DeadDoomImp",
	"DeadShotgunGuy",
	"GibbedMarine",
	"GibbedMarineExtra",
	"HeadsOnAStick",
	"Gibs",
	"HeadOnAStick",
	"HeadCandles",
	"DeadStick",
	"LiveStick",
	"BigTree",
	"BurningBarrel",
	"HangNoGuts",
	"HangBNoBrain",
	"HangTLookingDown",
	"HangTSkull",
	"HangTLookingUp",
	"HangTNoBrain",
	"ColonGibs",
	"SmallBloodPool",
	"BrainStem",
	//Boom/MBF additions
	"PointPusher",
	"PointPuller",
	"MBFHelperDog",
	"PlasmaBall1",
	"PlasmaBall2",
	"EvilSceptre",
	"UnholyBible",
	NULL
};

 

 

I don't see anything for extra actors as yet. Maybe it's still on the todo list, maybe it's an oversight, IDK.

[Da Werecat]

37 minutes ago, Ferk said:

When an option is not recognized it's ignored. At least that's what PrBoom does when parsing prboom.cfg and I would expect the same from eternity.cfg and mbf.cfg, many options are already the same since all three are descendants from the same family of ports.

I thought syntax changed in PrBoom from MBF?

[Ferk]

34 minutes ago, Da Werecat said:

I thought syntax changed in PrBoom from MBF?

 

True, the syntax is slightly different, but I don't think the same syntax from the cfg needs to be used for the lump. And the port just needs to read the lump, not write it, so things like help comments being different would not matter much, any line that isn't a known option can just be ignored.

I meant many of the options themselves and their names are the same.

Edited September 19, 2020 by Ferk

[Demion]

I would love to see bordeless windowed mode implemented for this source port. Thank you for keeping this fantastic port alive.

[AmethystViper]

Is it possible for widescreen assets like ones featured in the Unity ports' IWADs and NightFright's Widescreen HUD patches to be supported for this fork of PrBoom+? I am also noticing that the uncapped frame-rate for PrBoom+ doesn't seem smooth in motion (it feels kinda juttery), with or without V-sync enabled.

[SiFi270]

Widescreen status bars have been supported since before the addition of umapinfo, but only in OpenGL mode.

[AmethystViper]

58 minutes ago, SiFi270 said:

Widescreen status bars have been supported since before the addition of umapinfo, but only in OpenGL mode.

I've tried that with OpenGL mode and it's not working for me.

 

 

Me about to launch PrBoom+ v2.5.1.7 (glboom-plus.exe) with ZDL.


I have video mode set to OpenGL...


and the widescreen HUD is not working. I even tried the Unity port's IWAD and this happens...

[seed]

The status bar being broken with the Unity IWAD is no surprise, it needs to be drawn different for that version, otherwise you end up with garbage like this.

[SiFi270]

Well I don't know what I'm doing differently.

[seed]

I see you have a doom_wide addon loaded, that's what. Containing just the graphics I guess.

 

When using just the Unity IWAD the way it renders is screwed since it needs to be drawn differently.

[SiFi270]

But AmethystViper also tried doom_wide.wad, as the ZDL screenshot shows. I've also copied the Unity IWAD's statusbar into its own wad, and the only problem there is that the offset needs to be changed to 53, 0.

[El Juancho]

for some reasons i have tearing in this sourceport having fastsync turned on in nvidia control panel, maybe is cuz the full screen is not exclusive fullscreen and is actually borderless fullscreen?

[AmethystViper]

23 hours ago, SiFi270 said:

Well I don't know what I'm doing differently.

I think my issue could be how my doom_wide.wad file was being loaded. I was using ZDL and my doom_wide.wad file was in a different location and maybe there might be something with ZDL that is causing the issue with this version of PrBoom+. If I load the wad by using a command-line with a *.bat file it works with the OpenGL executable with OpenGL video mode, though strangely it doesn't recognize the wad if I even try using ZDL's own command-line parameter field. Not sure why this is an issue since ZDL is able to load PWADs into my games and source ports that are compatible with seem to work fine.

[SiFi270]

I'm looking at your screenshots again, and I think those lines on the ceiling mean you're still in software mode somehow. I couldn't make it look like that with any of the four sector light modes.

[AmethystViper]

9 hours ago, SiFi270 said:

I'm looking at your screenshots again, and I think those lines on the ceiling mean you're still in software mode somehow. I couldn't make it look like that with any of the four sector light modes.

Other than changing the lighting mode in the OpenGL version of PrBoom+ while running video mode to OpenGL, I don't know how it's still thinking I'm still using software mode when I'm telling it to use OpenGL.

[TheDemonatorLol]

Hi,

 

I am posting a small bug report on here, instead of on GitHub, since my reports are not appearing in Issues.

I am using the Stripped release build posted by Never_Again on Page 13, and playing in the prboom-plus executable.

 

• Using SDL as the preferred MIDI player, setting Music Volume to the lowest possible setting results in the game / application becoming entirely muted.
• The "Reset to Default" option under Options>General is non-functional.

 

Thank you.

[seed]

7 hours ago, TheDemonatorLol said:

• Using SDL as the preferred MIDI player, setting Music Volume to the lowest possible setting results in the game / application becoming entirely muted.

 

This one cannot be fixed until the sound backend is either migrated to GZDoom's, complete with the internal MIDI players, as it is planned, or if someone makes a midiproc executable for it like other ports have.

 

This is due to an issue in Windows that first surfaced in Vista and was never fixed, causing certain applications to tie the music volume to the master volume, as a result, lowering the music too much results in the game getting muted entirely. As a workaround, choose a different MIDI player, like PortMidi and Fluidsynth.

Edited September 24, 2020 by seed