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

PrBoom+ 2.6.1um (Aug 16, 2021)

Recommended Posts

32 minutes ago, fabian said:

Is everybody fine with this?

in 1.3, "interbackdrop" is 2-arg key, not 1-arg as it was before. i think this should be mentioned in changelog. otherwise it looks ok, thank you!

Share this post


Link to post
Posted (edited)
11 minutes ago, ketmar said:

in 1.3, "interbackdrop" is 2-arg key, not 1-arg as it was before. i think this should be mentioned in changelog. otherwise it looks ok, thank you!

 

Oh, no, it's not meant to be two arguments. It's one or the other. If the given lump name is not available in the ns_flats namespace then it will be treated as a patch.

 

Edit: Should I change this to "graphic" to make this clear?

Edited by fabian

Share this post


Link to post
1 hour ago, fabian said:

Oh, no, it's not meant to be two arguments.

but the specs says this:

interbackdrop = "flat", "patch"
                            ; Backdrop to be used for intertext and intertextsecret. If it does not specify a valid flat, it will be drawn as a patch instead. If not specified the FLOOR4_8 flat will be used, regardless of which map it is used on.

two arguments. at least it was like that several days ago when i wrote my complaint about versioning (and that was the reason i wrote it -- "stealth argument injection" ;-).

Share this post


Link to post

Sorry, that was my fault. I accidently added "patch" as a second argument, whereas it was meant to be "either flat or patch". I'll change this to "graphic" when I append the revision tracker to the document.

Share this post


Link to post

thank you! (now i have to revert my fix to umapinfo parser. god bless "git revert"! ;-)

Share this post


Link to post
Posted (edited)

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

 

Whacked together some translation tables. The current green blood is very bright, often brighter than fireballs if the room isn't too dark. Also, both green and blue gibs have pink spots due to the font tables being tuned to a very specific set of graphics.

 

Darkening the former comes at a price of introducing color loss, since the range is shrinking, so a compromise between tone and quality had to be found. I don't mind the result though.

 

5mMsx00.png

 

Pink spots were replaced by less saturated greens, mirroring how POL5A0 always looked in red. Caco gibs were kinda interesting though, so not a whole lot was changed other than the primary color affecting the entire palette.

 

OGKghNn.png

 

In the wad, the tables are named the same as the font tables for testing purposes, and the interface graphics survive reasonably well from what little I saw. Still, not the best idea to use this as a permanent replacement.

Edited by Da Werecat

Share this post


Link to post

I have also compressed the green range a bit in Crispy in order not to have it too bright. However, I have left most of the desaturated red ranges intact, so the gibbed sprites still have some red in them - just as the regular corpse sprites. 

Share this post


Link to post

Any chance this version will get the extended HUD implemented in the DSDA fork? The option to show kills/items/secrets above the status bar.

Share this post


Link to post
1 hour ago, Spectre01 said:

Any chance this version will get the extended HUD implemented in the DSDA fork? The option to show kills/items/secrets above the status bar.

 

If this happens I will use this port exclusively. I love that feature.

Share this post


Link to post
5 hours ago, Spectre01 said:

Any chance this version will get the extended HUD implemented in the DSDA fork? The option to show kills/items/secrets above the status bar.

 

@kraflab ?

Share this post


Link to post
4 hours ago, fabian said:

 

@kraflab ?

Some things about dsda-doom's exhud:

- it's a wip still

- the values in the hud are based on speedrunning rules for the uv max category - that information isn't currently tracked in pr+. If you're looking for the same numbers, then pr+ would also need to adopt the changes to monster and kill tracking that dsda-doom has. If you're not, then the code is a bit different from what you'll need in pr+ (it's referencing attributes that don't exist in pr+ in its calculations).

- the exhud has a percent sign, which isn't in pr+. You'd need to update pr+'s wad file.

 

The exhud code is in dsda/hud.c, but you wouldn't be able to just copy paste things and have it work in pr+. For example, hud colors are abstracted in dsda-doom because heretic and doom have different palettes, but in pr+ the colors are hard-coded.

 

If the goal is just to put kills / items / secrets in that position in pr+, that's not too much effort (i.e., to do something like the dsda-doom hud but not exactly the same). You can copy paste code from the advanced hud and set it to render under the same conditions as the status bar. That's not something I'll invest time in myself, but it shouldn't be too bad for anyone who wants such a feature in pr+ 🤠

Share this post


Link to post
On 3/9/2021 at 1:13 PM, kraflab said:

- the exhud has a percent sign, which isn't in pr+. You'd need to update pr+'s wad file.

 

That shouldn't be a problem. Though, do we even need percentage information in Doom? I mean it's a Heretic thing after all...

 

On 3/9/2021 at 1:13 PM, kraflab said:

If the goal is just to put kills / items / secrets in that position in pr+, that's not too much effort (i.e., to do something like the dsda-doom hud but not exactly the same). You can copy paste code from the advanced hud and set it to render under the same conditions as the status bar. That's not something I'll invest time in myself, but it shouldn't be too bad for anyone who wants such a feature in pr+ 🤠

 

Yes, probably. Most of the logic is already in the adv. HUD code. We would probably just have to adjust the positioning.

Share this post


Link to post

The exhud in dsda-doom shows kill% (mainly relevant to uv-respawn runs), that's why it uses the percent symbol. It's probably not relevant for 99% of users of pr+ and 95% of dsda-doom 😄

Share this post


Link to post

Hey, with the blood color discussion, is it possible to define the actual blood actor which an actor will bleed? Could you in that case define a new one with extended DeHacked, and apply it to whichever actor you wanted? Or would that complicate things for compatibility?

Share this post


Link to post

If the dsda hud stats thing is implemented, it should probably be disabled while using the automap overlay mode. (heard this complaint in decino's videos.)

Share this post


Link to post
7 minutes ago, maxmanium said:

If the dsda hud stats thing is implemented, it should probably be disabled while using the automap overlay mode. (heard this complaint in decino's videos.)

In the latest versions of dsda-doom, the map title is hidden to avoid overlapping with the extended hud. (You can still see the title by toggling overlay mode off.)

Share this post


Link to post
Posted (edited)

Latest Win32 dev build, as of commit c170d63 (March 17 2021).

 

Noteworthy changes since last dev build (March 5 2021):

* appended revision tracker to UMAPINFO spec document
* extended range of maps reachable via -warp and IDCLEV:
   from E1M1-E4M9 to E1M0-E9M99 for D1
   from MAP01-MAP33 to MAP00-MAP99
  Limitations:
   E0My does not work, since episode must always be >0
   -warp x 0 does not work, because zero passed to -warp as map number is used for
   warping to first changed map in PWAD
* evaluate mouse motion only once per tick
* show Time/STS widgets above status bar

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

prboom-plus-20210317-w32.zip (FileDropper)

 

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

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

 

NB: this build may finally fix the mouse issues many users complained about for a long time; you may have to adjust the mouse sensitivity in options to take full advantage of the fix, though.

Share this post


Link to post
Posted (edited)
2 hours ago, maxmanium said:

 

Why tho? It shouldn't affect demos, right?

I don't get it either. I mean, you can switch it on and off in the menu, so why force it off upon users?

 

Could you please file a request on github? 

Edited by fabian

Share this post


Link to post

Hello there!  I've tried out the latest version of this port to see if the new UMAPINFO features were working as advertised, and I'm not sure they are.  What I was curious to see was if the special level graphics for Eviternity would display when the next level is loaded, so I put the Eviternity UMAPINFO file from the ZIP I found advertised (https://www.bountysource.com/issues/92317279-feature-request-umapinfo-files-for-popular-wads) into the PWAD using Slade.  However, in going from Map 01 to Map 02, after seeing the end-level stats I only saw a brief black screen with the "Loading Sprites..." status appear at the bottom before the map loaded, which is the same behavior I was seeing before.  I'm probably doing something wrong, but I'm curious if anyone else can replicate this or might be able to determine a step I missed.

Share this post


Link to post
17 hours ago, Bytefyre said:

Hello there!  I've tried out the latest version of this port to see if the new UMAPINFO features were working as advertised, and I'm not sure they are.

 

If with "as advertised" you mean "according to the specs", it is compliant. Fullscreen graphics instead of flats as intermission backgrounds have only been added to the spec after the feature has been implemented in PrBoom+ after the 2.6um release. Sorry, but you'll have to wait for 2.6.1um or use one of the unofficial builds provided here.

Share this post


Link to post

Sorry for the ignorance, but do you know if UMAPINFO allows to see the episodes and intermission screens of wads like Valiant, Ancient Aliens or Eviternity, or is it something impossible to implement for this source port?

Share this post


Link to post

Are there any plans to improve the netcode for this port (since it's apparently bad)?

Share this post


Link to post
40 minutes ago, maxmanium said:

Are there any plans to improve the netcode for this port (since it's apparently bad)?

I mean, you can always use odamex or zandronum, no?

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
×