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

@Graf Zahl Will Episodic format for Doom 2 be available in future. TheMightyHeracross posted the UMAPINFO for Eviternity above but he said it doesn't work.

Share this post


Link to post
Posted (edited)

Might as well just get this example WAD out before I go to bed even if it's not exactly "later today" like I promised. Here's my base resource WAD stripped down about as bare as I can make it. "UMAPINFOBugExample.wad" is the main WAD here; it's without "Episode = Clear", but there's a separate WAD file in the same ZIP file (with the not-at-all-longwinded filename "UMAPINFOBugExampleAddon_EpisodeEqualsClear.wad") whose only lump is a copy of the UMAPINFO with "Episode = Clear" added, which you can load after the main WAD to force that line's presence. This way you can see that the episode selection isn't working in either case, but the difficulty selection also breaks down when "Episode = Clear" is present.

 

There's some GZDoom bugs exhibited in this sample WAD too, but I'll open tickets for that on the relevant forum tomorrow.

20190617_UMAPINFOBugExample.zip

Share this post


Link to post
31 minutes ago, ReaperAA said:

@Graf Zahl Will Episodic format for Doom 2 be available in future. TheMightyHeracross posted the UMAPINFO for Eviternity above but he said it doesn't work.

 

Of course it will be available, it's probably just a minor oversight in that convoluted menu code that went all the wrong way implementing the differences between Doom 1 and Doom 2.

 

Share this post


Link to post
1 hour ago, Graf Zahl said:

I wouldn't call it "bonked". It's roughly 20% slower when I tested Frozen Time, i.e. 27 fps vs. 34 fps in 1920x1080. And that map's probably the worst case scenario out there. For comparison, ZDoom's software renderer manages less than 10 fps on the same map.

 

The main problem here is not the MIDI players but the cheap-ass sound interface SDL provides. GZDoom uses OpenAL as its backend which isn't a primitive raw stereo buffer but an actual 3D sound API with good support for modern standards and a professional quality mixer.

 

TBH, the only way I see to 'fix' the sound would be to rip out the current sound system and put in GZDoom's, but that's not only a huge undertaking but also would require quite a bit of work on the resource management and introduce a large amount of C++ code into the project (don't even think about backporting that code to plain C, that's simply not possible - it makes full use of polymorphism and abstraction.) and that seems to be sacrilege if some people were to be believed.

 

I actually haven't checked, it may even use an older version from 2.5.1.4.

 

Thanos for the info.

 

Definitely not the case of using the SDL from 2.5.1.4. Just checked the archive and there's SDL2 libraries insine.

 

2.5.1.4 is SDL1. Which is good because if 2.5.1.4 and other SDL1-based ports are of any indication, that would have meant borked mouse support on newer Windows versions.

 

To be honest I would f*cking love to see Hexen support in the future, and a better sound system, but that's understandably well out of the scope of the project for the time being.

Share this post


Link to post
6 hours ago, seed said:

To be honest I would f*cking love to see Hexen support in the future, and a better sound system, but that's understandably well out of the scope of the project for the time being.

 

Eternity Engine has a better chance of implementing Hexen support in future. Heretic is 95% working (beatable from start to end) in Eternity dev builds and I believe Hexen would be next.

Share this post


Link to post

Do any of you get the issue with this version of PrBoom+ when you exit the game the game will go into a windowed mode and freeze there for around 5 seconds before the window closes?

Share this post


Link to post

No. When I quit it shows the ENDOOM screen and when I click into that it closes immediately.

 

Share this post


Link to post

Just to follow up on what I was saying earlier about opening bug reports on the UMAPINFO implementation in GZDoom, I've gotten around to making the bug reports. Five of them, in fact:

Obviously not entirely relevant to PrBoom+/UMAPINFO 2.5.1.7 discussion, but relevant to UMAPINFO discussion as a whole, I suppose.

Share this post


Link to post
Posted (edited)

Why not limit UMAPINFO to PrBoom+current? It's a new feature, unavailable in older engines, it should not be available in legacy complevels. If you still want to play vanilla-like, you have all the MBF compatibility options in the menu which you can turn off. No need to use "-complevel 2" all the time. Just consider the wad designed for PrBoom+ and other MBF+UMAPINFO compatible ports (this should be Eternity if you want demos). I guess I should fix EE to actually run PrBoom+current demos…

 

Speaking of user configurations, it would be super nice to add support for the OPTIONS lump in PrBoom+. MBF has it, Eternity too, but PrBoom skipped inheriting it for some unknown reason. Several MBF and Eternity wads use it to make sure the gameplay works as intended.

 

I saw some ramblings about Eternity and demo headers in this thread. Do I need to do anything to be compliant? I'd love to see some PrBoom+UMAPINFO demos to test in Eternity…

 

I'm planning to add support for UMAPINFO in Eternity. It's very tempting to just integrate it into EDF, but I'll have to be wary about namespacing: UMAPINFO is not our creation, so we need to steer clear of collisions. Probably anything added by Eternity for Eternity to UMAPINFO will have to be prefixed with something (e.g. "ee-").

 

Does GZDoom support UMAPINFO? (I guess it does, seeing the post above)

Share this post


Link to post
2 hours ago, printz said:

Why not limit UMAPINFO to PrBoom+current? It's a new feature, unavailable in older engines, it should not be available in legacy complevels. If you still want to play vanilla-like, you have all the MBF compatibility options in the menu which you can turn off. No need to use "-complevel 2" all the time. Just consider the wad designed for PrBoom+ and other MBF+UMAPINFO compatible ports (this should be Eternity if you want demos). I guess I should fix EE to actually run PrBoom+current demos…

 

Because it'd block playing mods with older complevels. Imagine BTSX came with an UMAPINFO and someone wants to record demos on it using strict vanilla gameplay settings. Currently this is doable, but with your approach it wouldn't be.

Share this post


Link to post

Peculiar, I'm not seeing the game still running in the taskbar.

Share this post


Link to post

The game freezes like this for a few seconds then the games shows up in the task bar after a few more seconds

Share this post


Link to post
On 6/22/2019 at 3:08 PM, Graf Zahl said:

 

Because it'd block playing mods with older complevels. Imagine BTSX came with an UMAPINFO and someone wants to record demos on it using strict vanilla gameplay settings. Currently this is doable, but with your approach it wouldn't be.

Technically, PrBoom+ should not allow the recording of a Doom v1.9 demo when interpretting UMAPINFO. The idea is that a 1.9 version demo should be able to be played back in vanilla Doom.

 

That provides 3 choices for PrBoom+:

  1. Record the demo, but apply a different version number.
  2. Disallow the creation of a 1.9 demo, and force a PrBoom+ demo.
  3. Record a v1.9 demo, and disable UMAPINFO.

Entryway worked pretty hard to prevent the recording of v1.9 demos anytime a non-vanilla option is in effect, so that effort should probably be continued.

 

Share this post


Link to post

That's why the presence of UMAPINFO is an added flag. But it is independent of the active complevel. You cannot play an UMAPINFO-based demo with an incompatible engine.

 

Share this post


Link to post
2 hours ago, Graf Zahl said:

That's why the presence of UMAPINFO is an added flag. But it is independent of the active complevel.

Can you elaborate? What kind of flag are you describing?

 

2 hours ago, Graf Zahl said:

You cannot play an UMAPINFO-based demo with an incompatible engine.

What do you mean by that? Does the port prevent v1.9 demos from being recorded? Does it force PrBoom+ to write PrBoom+ demos only when the UMAPINFO flag is set?

 

If so, that sounds like a solid plan. What we don't want are v1.9 demo files being generated that don't play in, say, vanilla, or Chocolate Doom, etc. In other words, if the demo is stamped "19", it must be compatible with some version of vanilla 1.9. The situation is already messed up, since a 1.9 demo could be from Final Doom, Ultimate Doom, etc.

 

Id Software should have changed the version number when they altered the game logic, and released different versions of 1.9. So, it's already a mess...and we need to make sure that we don't create a bigger mess!

 

PrBoom+ demos contain a footer that has lots of info about the loaded IWAD and PWADs, game settings, etc. Maybe the UMAPINFO flag could be added there (it's not strictly necessary, since the loaded PWAD contains the UMAPINFO lump.)

 

KBDoom demos contain the loaded WADs, as well as MD5s for each WAD, which would ensure that the exact WADs are properly loaded. I don't know if PrBoom+ does this.

 

Anyway, Graf, it sounds like a nice, proper implementation - good job! It would have been easy to implement badly. I appreciate your diligence and your approach.

 

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
×