PrBoom+ 2.6.66 (Jun 20, 2023)

[JadingTsunami]

48 minutes ago, T-117 said:

Out of curiosity, is Decorate support something that would ever be supported by PRBoom+?  I realize ZDoom ports support it but they can suffer from performance issues sometimes.  Is this something that could be added if someone were to submit a PR or is this something that we don't want PRBoom+ to support?

 

My quick take is that would be a new port rather than a PrBoom addition.

 

There's already DECOHack which bridges some of the gap between DECORATE and DeHackEd/BEX.

[ketmar]

On 1/8/2022 at 6:43 PM, T-117 said:

Out of curiosity, is Decorate support something that would ever be supported by PRBoom+?  I realize ZDoom ports support it but they can suffer from performance issues sometimes.

add DECORATE to PrBoom, and it will start having performance issues too. there is simply no way to have your cake and to eat it too. alas.

[fabian]

[ChopBlock223]

On 1/8/2022 at 5:43 PM, T-117 said:

Out of curiosity, is Decorate support something that would ever be supported by PRBoom+?

A hypothetical 'DecoLite' was talked about a while back. Wouldn't necessarily be a copy of Decorate, but the concept was that, instead of building further on DeHacked, which apparently is an absolute pain to add and maintain as is on the developer side, and which the user can't realistically read anyway, one would start from scratch with a new coding language which is straightforward on the dev side, and easy to read and write for the user, and then add new features and functionality via that instead.

 

I guess a shorter answer is that, no, support for just Decorate itself isn't very likely.

Edited January 17, 2022 by ChopBlock223

[Ludi]

I personally really hope this doesn't happen. Decorate is honestly more trouble than it's worth from my end, and I'd hate to see PrBoom+ turn into a slightly better GZDoom

[ChopBlock223]

On 1/21/2022 at 7:51 PM, Sr_Ludicolo said:

I personally really hope this doesn't happen. Decorate is honestly more trouble than it's worth from my end, and I'd hate to see PrBoom+ turn into a slightly better GZDoom

If a new coding language was made for ports like PrBoom+ or DSDA (emphasis on if), even if it was derivative of GzDoom's Decorate, it would be nowhere close to what GzDoom can do with it.

 

As long as something like that doesn't get off the rails, I don't see how it would be "more trouble than it's worth", you're never getting anywhere close to being able to do something like Brutal Doom or whatever.

It'd be much more like current DeHacked derivatives except you wouldn't need a separate program to understand or write it.

Edited January 24, 2022 by ChopBlock223

[Sectorslayer]

Hi there, @Graf Zahl! I had troubles recording demos. My controls where all lagging. By accident I figured I need to run the recording with an seemingly undocumented ‘-longtics’ flag. Although nobody seems to use it in command line examples. 🤷‍♂️

[PBeGood]

1 hour ago, sectrslayr said:

Hi there, @Graf Zahl! I had troubles recording demos. My controls where all lagging. By accident I figured I need to run the recording with an seemingly undocumented ‘-longtics’ flag. Although nobody seems to use it in command line examples. 🤷‍♂️

-longtics ignores the 256 angle limit the player has when recording demos.

If you are making demos for dsdarchive, do not use this parameter.

[GoneAway]

It's not lag. By default the resolution of the player angle is lower when recording demos, so there are more clearly quantized notches. That behavior (which is vanilla) is overriden by longtics as PBeGood4 mentioned. You can reproduce the demo behavior when playing normally with -shorttics as well.

[Sectorslayer]

5 hours ago, PBeGood4 said:

If you are making demos for dsdarchive, do not use this parameter.

Good to know. I just use it to prepare viddump at the moment. 
 

2 hours ago, kraflab said:

 

It's not lag. By default the resolution of the player angle is lower when recording demos, so there are more clearly quantized notches. That behavior (which is vanilla) is overriden by longtics as PBeGood4 mentioned.

 

Oh ok. It takes out quite some movement precision. Good to know it’s not a bug. 
 

Thanks for the explanation, @PBeGood4 and @kraflab!

[fabian]

For some more background:

https://doomwiki.org/wiki/Turning_resolution_is_lowered_when_recording_demos

 

[st0jan]

Hello, can someone please help me load dtwid-le in prboom+ umapinfo fork (one of the last master branch version)? I put the umapinfo.lmp in autoload folder, make a .bat with wad and deh file launch, gives me the "1:4:invalid map name e5m1" error. Thank you.

 

PS: ok, figured it out, was loading it with doom2.wad shit, should have with doom.wad

 

 

Edited February 9, 2022 by st0jan

[Never_Again]

Latest Win32 dev build, as of commit e2ef111 (February 10 2022).

 

Noteworthy changes since last dev build (November 19 2021):

* Launcher: identify IWADs either by IWAD tag, or by PWAD tag and matching filename
* Portmidi: fix freeze after song change
* fixed scaled time interpolation when changing game speed
* fixed wrong pitch of SFX when MIDI Player is set to SDL
* v1.2 compat:
   - do not use sfx_getpow for powerups
   - do not render powerups and attacking Spiderdemon fullbright
* UMAPINFO: fixed par times not showing
* fixed demo playback warp consistency
* added SKILL cheat to display current skill level
* fixed calculation of interpolation frac value
* guard against screen buffer underflow
* fixed crash at startup by properly closing IWAD file handle
* added vanilla_keymap option à la Chocolate Doom
* added 'run' as a mouse-settable control (mouseb_speed)

+ console output

 

prboom-plus-20220210-w32.zip (Mediafire)

prboom-plus-20220210-w32.zip (Google Drive)

 

Includes the 40 required DLLs. See the accompanying TXT file for details.

For a complete list of changes since last official release look here.

 

[fabian]

The latest version 2.6.2 of PrBoom+ with UMAPINFO support has been released on Feb 11, 2022.

 

Source tarballs and the changelog can be found here:

 

https://github.com/coelckers/prboom-plus/releases/tag/v2.6.2

 

Windows 32-bit binaries are available here:

 

https://github.com/coelckers/prboom-plus/releases/download/v2.6.2/prboom-plus-262-w32.zip

[nobleflame]

Getting a strange bug in the latest version of PrBoom+ UMAPINFO (2.6.2).

 

Example: in Ancient Aliens some monster teleporters aren't functioning so that the monsters don't wake up and therefore do not teleport into the map when triggered. You can see this in map 23 during the secret zombie men fight in the tower. 

 

I've tested this map in Eternity and GZDoom with no issues. 

 

I've noticed this behaviour in other large maps too. 

 

Any thoughts? 

[Dimon12321]

@nobleflame Would make sense to record a replay (-record demo_name) and try to watch it on elder versions to see if it plays back fine.

[fabian]

Might be a matter of complevel. 

[nobleflame]

1 hour ago, fabian said:

Might be a matter of complevel. 

 

I'm using complevel 9 (recommended for AA). 

I'll try this on older version to see if there's the same problem.

 

Edit: I tried it on prboom-plus-20211106-w32 and I'm still getting the same issue. 

 

Not sure what to try next. It works without issue on GZDOOM.

Edited February 19, 2022 by nobleflame

[Shepardus]

Try playing back an existing max demo from DSDA and see if it plays back correctly.

[nobleflame]

4 hours ago, Shepardus said:

Try playing back an existing max demo from DSDA and see if it plays back correctly.

Just tried this and it seems to play back correctly - no line defs are skipped / monster spawn in correctly e.g. AA map 23 zombie man secret fight triggers as it should.

 

I've tried running a completely clean version of the latest PrBoom+umapinfo version with just AA.wad and no additional mods (like the sprite fixing mod) and I'm still getting the above issue.

[nobleflame]

Okay, sorry about this, but I've found the issue.

 

I didn't shoot in the opening area of AA map 23, which essentially meant that a whole load of monsters didn't wake up. 

 

Basically, my fault; false alarm. Apologies for the erroneous error reporting! 

[st0jan]

Thanks for the latest release. Can we please get a x64 build with all the latest neccessary windows system dependencies?

Edited February 22, 2022 by st0jan

[Never_Again]

Latest Win64 dev build, as of commit 1bc98e2 (February 18 2022).

 

Noteworthy changes since last dev build (February 10 2021, the last one before the official v2.6.2um release):

* sort resolutions by width first and associated fixes
* fixed integer overflow that caused jagged motion after running for about 26 minutes
* UMAPINFO: fixed par times not loading for finale levels

+ console output

 

prboom-plus-20220218-w64.zip (Mediafire)

prboom-plus-20220218-w64.zip (Google Drive)

 

Includes the 40 required DLLs. See the accompanying TXT file for details.

For a complete list of changes since last official release look here.

[st0jan]

Is it possible to scale the hud size according to screen resolution and retain the aspect in some way? the hud is just too large, i'm on fit to width setting and 1920x1200 display. I would like it to look more like in zdoom ports where i can scale it down simply with hud scaling slider so it doesn't take so much space on the display.

Edited March 6, 2022 by st0jan

[Fluuschoen]

Did something change in v2.6.2's mouse code? Software renderer feels a bit more responsive than before.

[fabian]

Frame interpolation calculation has been improved, maybe that's what you see.

[Fluuschoen]

11 hours ago, fabian said:

Frame interpolation calculation has been improved, maybe that's what you see.

Nice! This should find its way into DSDA, because it's getting close to Crispy feel! <3

I'm no programmer at all, so maybe I'll ask something dumb, but at the current state, can it be improved further? What always threw me off in PrBoom is the laggy mouse feel (literal input lag, not fractional ticks), then came DSDA, which feels the same (a bit better, but not too much) in software, though in OpenGL is fine (but that's OpenGL, not software 8 bit, even with shaders), and this new version of PrBoom surprised me in a good way.

Edited March 12, 2022 by Fluuschoen

[liPillON]

hi, I'm interested in creating a new custom hud layout

 

is there some -PRBHUD- documentation I could refer to?

 

 

[ForeskinJohn]

Can anyone help me out here? I cant seem to run TNT:Evolution with this source port, it gives me an "exiting on signal 11" error, ive tried 3 different copies of the IWAD to no avail, any help is appreciated in advance. maybe this will be fixed in the next update? ive heard it works for some people but why not me? Ive even tried loading it with doom2.wad but I get the same error. not that that would help anyways.

Edited March 28, 2022 by ForeskinJohn

[Never_Again]

27 minutes ago, ForeskinJohn said:

Can anyone help me out here? I cant seem to run TNT:Evolution with this source port, it gives me an "exiting on signal 11" error, ive tried 3 different copies of the IWAD to no avail, any help is appreciated in advance. maybe this will be fixed in the next update? ive heard it works for some people but why not me? Ive even tried loading it with doom2.wad but I get the same error. not that that would help anyways.

 

Four questions:

1) which release package of prb+ do you run?

2) what is the CRC-32 of your TNT.WAD?

3) how do you load/run it?

4) at what point do you get the error?

Edited March 28, 2022 by Never_Again
added quote