drfrag Posted September 13, 2020 (edited) 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. 0 Share this post Link to post
GoneAway Posted September 13, 2020 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. 0 Share this post Link to post
Spectre01 Posted September 14, 2020 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? 0 Share this post Link to post
tchkb Posted September 14, 2020 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. 2 Share this post Link to post
fabian Posted September 15, 2020 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? 0 Share this post Link to post
ChopBlock223 Posted September 18, 2020 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? 2 Share this post Link to post
Alper002 Posted September 18, 2020 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.) 1 Share this post Link to post
Ferk Posted September 18, 2020 (edited) 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. 2 Share this post Link to post
Alper002 Posted September 18, 2020 (edited) 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. 0 Share this post Link to post
Ferk Posted September 18, 2020 (edited) 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. 4 Share this post Link to post
Da Werecat Posted September 18, 2020 Having legacy OPTIONS would be sweet. However, new features would require a different lump to preserve compatibility with stock MBF. 3 Share this post Link to post
ChopBlock223 Posted September 19, 2020 Is there any other linedef action or sector function which is broken, by the way? 0 Share this post Link to post
Ferk Posted September 19, 2020 (edited) 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. 1 Share this post Link to post
Shadow Hog Posted September 19, 2020 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. 1 Share this post Link to post
Da Werecat Posted September 19, 2020 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? 0 Share this post Link to post
Ferk Posted September 19, 2020 (edited) 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 1 Share this post Link to post
Demion Posted September 19, 2020 I would love to see bordeless windowed mode implemented for this source port. Thank you for keeping this fantastic port alive. 5 Share this post Link to post
AmethystViper Posted September 20, 2020 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. 1 Share this post Link to post
SiFi270 Posted September 20, 2020 Widescreen status bars have been supported since before the addition of umapinfo, but only in OpenGL mode. 0 Share this post Link to post
AmethystViper Posted September 20, 2020 (edited) 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... 1 Share this post Link to post
seed Posted September 20, 2020 (edited) 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. 1 Share this post Link to post
SiFi270 Posted September 20, 2020 Well I don't know what I'm doing differently. 0 Share this post Link to post
seed Posted September 20, 2020 (edited) 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. 0 Share this post Link to post
SiFi270 Posted September 20, 2020 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. 1 Share this post Link to post
El Juancho Posted September 20, 2020 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? 0 Share this post Link to post
AmethystViper Posted September 21, 2020 (edited) 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. 0 Share this post Link to post
SiFi270 Posted September 21, 2020 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. 1 Share this post Link to post
AmethystViper Posted September 22, 2020 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. 0 Share this post Link to post
TheDemonatorLol Posted September 24, 2020 (edited) 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. 0 Share this post Link to post
seed Posted September 24, 2020 (edited) 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 3 Share this post Link to post