Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Graf Zahl

PrBoom+/UMAPINFO v 2.5.1.7

Recommended Posts

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.

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post

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?

Share this post


Link to post
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.)

 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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 by Ferk

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post
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.

 

 

ZDL_2020-09-20_14-37-18.png.676f72263c00bfc868f6148527e53222.png
Me about to launch PrBoom+ v2.5.1.7 (glboom-plus.exe) with ZDL.

Idle_2020-09-20_14-37-58.png.7e1c2c85ccf2b2f6f14a20d0275ebd46.png
I have video mode set to OpenGL...

Idle_2020-09-20_14-37-49.png.233f656476516c2c60f343955c523d1d.png
and the widescreen HUD is not working. I even tried the Unity port's IWAD and this happens...

Idle_2020-09-20_14-43-29.png.e7276459304ae955693e600a538ebdee.png

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

wideyouask.png.08e2c500678d9adc7cbbbd5df6056f85.png

Share this post


Link to post

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?

Share this post


Link to post
23 hours ago, SiFi270 said:

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

wideyouask.png.3fdc29d3683528ffdc67810b5e6c3d54.png

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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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 by seed

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×