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

"UMAPINFO" discussion

Recommended Posts

9 hours ago, Xaser said:

Some clarification on the demo-compat issue since there was some discussion about this on Discord recently: The troublesome scenario is recording a demo on a UMAPINFO-containing WAD file and then playing it back on an older PR+ version that doesn't support UMAPINFO. It's highly possible the wad will boot up fine and the demo will appear to play correctly for a bit, only to desync when it hits a UMAPINFO-caused difference (e.g. level order). Even though it's technically being played back in an unsupported version of the port, the fact the demo doesn't immediately error out is far less than ideal.

 

The proposed fix for this involves adding a "UMAPINFO version number" or somesuch to the demo header (causing old PR+'s to bomb out when they encounter an unknown header format), at which point there's now a way to handle additional backwards-compatibility. Suppose a feature is implemented incorrectly in, say, UMAPINFOv1 and the fix causes a desync; since the version number's in the demo header, the next version of PR+ with bugfixed UMAPINFOv2 is able to add a compat check and emulate the buggy behavior if the demo says it's for UMAPINFOv1. Win-win.

Ah. Thanks. I thought someone was adding a UMAPINFO AFTER creating the demo, and expecting it to work. See below:

9 hours ago, Da Werecat said:

Version should already be preserved in the header. I'm not sure what's the problem here.

Yep.

 

9 hours ago, Altazimuth said:

Because in this case, the version of UMAPINFO used and the physics shouldn't be linked. You should have separate numbers in the header for them. I can have a mapset that is vanilla except it has 33 maps, or Boom and it decides to jump from MAP13 to MAP49, and I should be able to say "cl2 with UMAPINFO 1" or "cl9 with UMAPINFO 3" if I want to.

CL2 and CL9 have, and will never have anything to do with UMAPINFO, since those compat levels precede UMAPINFO, and are designed to allow the playing of maps from dead ports.

 

5 hours ago, Graf Zahl said:

Guess why there has been virtual standstill on that front. The needs of demo compatibility trumped all other considerations and created an environment in which nothing could happen, except for ports that didn't care too much about these intricacies.

Not a standstill - just a pause. This is handled in the spec. No worries.

 

4 hours ago, TimeOfDeath666 said:

I think some of you guys are over thinking this. If someone is using a pre-umapinfo port with a designed-for-umapinfo wad, then it's their own fault and they deserve to suffer potential desyncs.

What's so hard about agreeing on a bare bones basic set of umapinfo options and then leaving it alone to maintain demo compatibility?

Yep. Left alone per version. Updates will allow new features, which are disallowed in previous ports/for previous demos.

4 hours ago, Xaser said:

A key bit some folks seem to be missing: This is a solved problem. Altazimuth knows how to implement the solution and has stated intent to do it, and Graf is willing to accept a PR. That's really all there is to it.

Again, yep, it's solvable.

 

I think many people use complevels as a way to set user options, which, so far, technically, has worked, but it's not the same thing. Setting a complevel actually bypasses user options. Currently missing is a quick way to set a bunch of user option defaults, while still allowing the user to change those settings, and allowing new features to operate.

 

PrBoom+ has never been asked to actually render features newer than MBF. UMAPINFO is clearly a new option. It will be disabled by complevels, but only enabled when a complevel, as currently known, is absent.

 

I think a lot of people tend to mis-use complevels, in general, as a "quick way to set a bunch of settings". This is a misuse (though, technically it works). Complevels are to allow a newer port to play demos from an old (dead) port. In fact, I never believed in allowing a new port to create demos for an old port, including vanilla. Those demos are NOT vanilla demos, even if they're really close. I have to support this in PrBoom+, because it's already supported, but I think it's perpetuating a falsity. To entryway's credit, he does turn off a lot of features during demo recording, even for never recordings.


 

Share this post


Link to post
On 7/31/2017 at 2:14 PM, Graf Zahl said:

 

That's up to debate who should be in control: The mapper or the end user? For some aspects I favor the end user where other developers favor the mapper. There is no "correct" here, both standpoints are valid. Just keep in mind: In ZDoom you can start a map by typing "map mapname" in the console. So there's a valid reason to show that map name to the user.

I don't think it is, ZDoom has always been modder-oriented, with a long tradition of making the user follow specific instructions to get the experience the modders have intended. If you want a port that is more user-oriented, I'd suggest sticking your dick in more purist-oriented source ports instead of zdoom.

On 7/31/2017 at 2:14 PM, Graf Zahl said:

Yet another person who should do some reading on the subject matter before making such suggestions. Sorry, that ship has sailed many, many years ago.

Oh no, no no, you are not getting away with smoke-screening this issue with veiled condescension. It's a double-standard you have with what you're telling other people to do with their format standards, and what you actually practice with your involvement in zdoom.

Share this post


Link to post
3 minutes ago, ArcheKruz said:

I don't think it is, ZDoom has always been modder-oriented, with a long tradition of making the user follow specific instructions to get the experience the modders have intended. If you want a port that is more user-oriented, I'd suggest sticking your dick in more purist-oriented source ports instead of zdoom.

 

Most of these options have been accessible to mods for many, many years. In general, if a mod requires user setup it either means it's doing something very odd or that it doesn't do its job completely. Old mods predating these options are of course excluded.

 

 

3 minutes ago, ArcheKruz said:

Oh no, no no, you are not getting away with smoke-screening this issue with veiled condescension. It's a double-standard you have with what you're telling other people to do with their format standards, and what you actually practice with your involvement in zdoom.

 

Like I said: Read up on the subject matter, especially what it requires from an engine before throwing around such stuff. Demo compatibility is not just a feature, it's a design philosophy which ZDoom had abandoned many years before I got involved, and the only way to bring it back would have been to undo ZDoom.

 

Share this post


Link to post
9 minutes ago, Graf Zahl said:

 

Most of these options have been accessible to mods for many, many years. In general, if a mod requires user setup it either means it's doing something very odd or that it doesn't do its job completely. Old mods predating these options are of course excluded.

Either that or it is an indication that more options do need to be exposed to modders. Like, for example, being able to rearrange and control exactly how a modder would like to present the options menu to the user, or creating an automap thumbnail as a HUD element. :)

 

9 minutes ago, Graf Zahl said:

Like I said: Read up on the subject matter, especially what it requires from an engine before throwing around such stuff. Demo compatibility is not just a feature, it's a design philosophy which ZDoom had abandoned many years before I got involved, and the only way to bring it back would have been to undo ZDoom.

You're assuming that I haven't. Allow me to allow a different perspective on this; This seems impossible for you, because you're constrained by your own perspective and experiences, but other coders with fresher minds and ideas will find a way eventually. It's just a matter of creativity and open-mindedness. I mean, if you want to differ on this, please do go into detail on the specifics, because that's where the interesting discussion begins and new ideas are born.

 

For example, I like Dew's ideas on how to reconcile UMAPINFO data with compat levels for demo recording. That seemed to be a creative solution that doesn't seem to sacrifice much, if any, on the user options front or the mapper's flexibility front.

Share this post


Link to post

kb1 said:


I think many people use complevels as a way to set user options, which, so far, technically, has worked, but it's not the same thing. Setting a complevel actually bypasses user options. Currently missing is a quick way to set a bunch of user option defaults, while still allowing the user to change those settings, and allowing new features to operate.


Say what you want, but mapsets are designed for specific settings in complevels, and the demo forum shows (complevel x) in every thread, so that everyone plays with the same specific settings.

If a player needs to set a new complevel just to activate the umapinfo data, it sounds to me like it would be a step backwards in demo compatibility. Whether pre-umapinfo ports bomb out immediately when trying to play a umapinfo demo, or the demo eventually deysncs, the result is the same: both don't work. But on a wad that uses umapinfo just for non-gameplay stuff, if someone records with the new umapinfo complevel then it'll bomb out on pre-umapinfo ports, instead of playing back fine without showing the non-gameplay umapinfo stuff.

Share this post


Link to post

My intuition when thinking about demos recorded in umapinfo port and played back in non-umapinfo ports:

- I'd expect movies to bomb out

- I'd expect ILs to play back fine

 

idea is to change the progression of levels, and some visual attributes of the levels, but otherwise not affect the map gameplay in any way? The only thing I notice that breaks that is the bossaction field, which IMO is unnecessary because if you really wanted to implement that there are some workarounds that don't break compat.

 

 

edit: didn't intend to muddy any waters with non-helpful commentary. fwiw I think completely bombing out in pre-umapinfo ports is also fine. (I also realize there are plenty of cases where the above wouldn't be feasible, e.g. maps outside the 01-32 range)

 

 

 

Edited by Ribbiks

Share this post


Link to post
47 minutes ago, TimeOfDeath666 said:

If a player needs to set a new complevel just to activate the umapinfo data

Where's that coming from? I think it should be available by default, and I don't remember anyone saying otherwise.

 

49 minutes ago, TimeOfDeath666 said:

But on a wad that uses umapinfo just for non-gameplay stuff, if someone records with the new umapinfo complevel then it'll bomb out on pre-umapinfo ports, instead of playing back fine without showing the non-gameplay umapinfo stuff.

If you record a Boom demo on a vanilla wad, it won't play back in vanilla Doom. The solution is to record a vanilla demo instead.

 

If you want the cosmetic stuff to always work, it should be doable. There are precedents like sky transfers and the music changer.

 

Share this post


Link to post
3 hours ago, ArcheKruz said:

You're assuming that I haven't. Allow me to allow a different perspective on this; This seems impossible for you, because you're constrained by your own perspective and experiences, but other coders with fresher minds and ideas will find a way eventually. It's just a matter of creativity and open-mindedness. I mean, if you want to differ on this, please do go into detail on the specifics, because that's where the interesting discussion begins and new ideas are born.

 

You wouldn't say this if you had an understanding of what demo compatibility implies.

In terms of ZDoom it'd mean:

 

- revert the actor definitions to info.c and not a virtual class hierarchy (Having the class hierarchy is not compatible with how Doom demos work - not even remotely!)

- revert the inventory handling to the exact mechanics as Doom originally implemented (the current system is so totally different that you cannot possibly expect it to stay in sync.)

- undo the floating point math conversion (float and fixed math produces very slightly different results, and in case of overflows of fixed point totally different ones.)

...

 

This doesn't even consider all those small changes here and there - but as things stand all of the above cannot be kept if you want to have demo compatibility as they severely change how certain things are done - the results are nearly the same but order of execution alone will put up an impassable roadblock.

The gist here is: To play Doom you need an engine that's observationally identical with the original game. To play demos you need an engine that is algorithmically identical with Doom.exe and that's an entirely different matter - every bug, every quirk, every math overflow needs to be meticulously preserved. And since ZDoom has changed a lot of things here, all those would have to be undone first, to be replaced by Doom.exe or PrBoom+ code. So, in order to make ZDoom demo compatible the only chance you have is to undo ZDoom.

 

Wanna bet that all other people with the technical know how will tell you precisely the same? ;)

 

 

 

Share this post


Link to post

Why do people record PrBoom+ demos under complevels for MBF and down, other than to make them playable in Eternity, vanilla Doom and the DOS ports? Is there anything which can't be achieved by changing menu settings? Is there any reason to record a multi-level UMAPINFO demo under low complevel if other ports (save potentially Eternity) can't play it properly anyway? Single level recordings are fine.

 

It just feels to me that inferior complevels should totally emulate how such an equivalent engine would run the megawad. The real challenge is to somehow keep UMAPINFO stable and simple enough so it can get its own complevel.

 

It's the other feature, off-topic from here, which is DECOLITE which makes me think. Doesn't PrBoom+ risk turning into another Eternity Engine, which keeps retro demo compatibility, but totally fails to keep recording compatibility with past versions of itself (because it's physically unfeasible)? I used to be a big fan of merging these two ports until I realized that PrBoom+'s main property is high conservation, incompatible with Eternity.

Share this post


Link to post
4 minutes ago, printz said:

Why do people record PrBoom+ demos under complevels for MBF and down

Complevel is not just for recording, though it was the primary motivator for it. Complevels are also there to select different game behavior, since Boom and MBF introduced changes in physics and actor logic. Some maps require Boom or MBF physics, some other maps require vanilla Doom physics. Admittedly, most maps will work fine enough regardless of complevel chosen, but Doom has plenty of exception to every rule.

 

7 minutes ago, printz said:

It's the other feature, off-topic from here, which is DECOLITE which makes me think. Doesn't PrBoom+ risk turning into another Eternity Engine, which keeps retro demo compatibility, but totally fails to keep recording compatibility with past versions of itself (because it's physically unfeasible)? I used to be a big fan of merging these two ports until I realized that PrBoom+'s main property is high conservation, incompatible with Eternity.

Yes and no. If we're going along with these DEX stuff, then anything that would hypothetically be added to PrBoom+ (or successor fork) this way would be relatively stable. Ports like ZDoom and Eternity are in constant development, so they get new features regularly and then these new features might get fine-tuned for a while before stabilizing. But for that DECOLITE thing, if it's ever part of DEX, then it would be static. Perhaps DEX-5 adds basic DECOLITE features and then it doesn't change. Once the PrB+ reference implementation is complete, it doesn't change anymore. Until, perhaps, DEX-6 adds extensions to DECOLITE. But basically you can imagine that each DEX level would get a new complevel, so the same thing would happen.

 

Basically, imagine if Eternity was developed entirely closed-source -- nobody outside the inner circle of developers get access to development builds. Official builds are released every two or three years, and only after running grueling series of regression tests to check that everything is as bug-proof as humanly possible. In that scenario, keeping compatibility with previous versions wouldn't be too hard, as long as it's a core design goal.

Share this post


Link to post

Da Werecat said:


I think it should be available by default, and I don't remember anyone saying otherwise.


I think it should too, but if that's true then why the need for a new complevel?

Da Werecat said:


If you record a Boom demo on a vanilla wad, it won't play back in vanilla Doom. The solution is to record a vanilla demo instead.


Yes, but boom changes gameplay. If you recorded on a wad that used umapinfo only for non-gameplay changes, with a port that supports umapinfo, then tried to watch the demo in a non-umapinfo port, I would think the demo should play fine and wouldn't desync and the umapinfo data just wouldn't get loaded. I would test graf's pr+ umapinfo port, but it doesn't work on winxp.

Share this post


Link to post
Just now, TimeOfDeath666 said:

I think it should too, but if that's true then why the need for a new complevel?

The plan is to explicitly not introduce any new complevels. See here for more explanation.

 

3 hours ago, Ribbiks said:

My intuition when thinking about demos recorded in umapinfo port and played back in non-umapinfo ports:

- I'd expect movies to bomb out

- I'd expect ILs to play back fine

That'd be perfect if it was somehow possible. We're limited in options on how to get older port versions to bomb out, so going to be an all-or-nothing deal without resorting to strange arcane hacks, I imagine.

Share this post


Link to post

How I'll probably tackle this:

  • Step 1: Make it so that all pre-UMAPINFO demos work correctly, hopefully whilst still respecting visual-only settings (like how sky transfers work in -cl9 demos)
  • Step 2: Try to implement the new demo header system
  • Step 3:
    • i: Test that shit to hell and back
    • ii: Deliberate on what more might be needed
    • iii. Implement whatever more is needed
    • iv: Iterate the previous few steps until everybody is happy

I'd say that step 3 doesn't need to happen until steps 1 and 2 happen. This effectively leaves me to my devices, and the conversation can be pointed back to whatever people are more keen on talking about. It wasn't my intention to bring all the discussion to this issue, merely to highlight it and make sure that it gets addressed (with me being the one doing most of the engine parts of the addressing). This all being said, I hope we can go back to prior discussion.

 

Share this post


Link to post
8 minutes ago, TimeOfDeath666 said:

I think it should too, but if that's true then why the need for a new complevel?

A new complevel = behavior without UMAPINFO. Then, when some changes are made, old behavior is compleveled again.

 

At least that's how complevels are supposed to work. People here don't seem to want that. But in any case, the most feature-rich and up-to-date behavior should be available by default, without specifying anything. That's just, like, the most intuitive thing to do.

Share this post


Link to post

Forcing a bomb-out in unsupported ports actually provides less backwards compatibility. You should be able to watch a umapinfo demo in an unsupported port if the umapinfo data doesn't change anything gameplay related. Wouldn't the header prohibit that?

Share this post


Link to post

@everybody: Lay off on attacking Graf: He created this thread, and he created UMAPINFO! This was a selfless gesture that will become central to the concept of bringing some unity to mapping across all ports. We all know that ZDoom cannot play old demos currently. The programmers amongst us know that, yes, code could be shoehorned into ZDoom that would allow it to play old demos. However, ZDoom has been totally refactored, to make it an efficient engine for modding. Vanilla Doom was built to be efficient at playing Doom on a 486, with minimal modding capability. Both are good designs, yet they cannot be efficiently combined. What makes vanilla fast is that id hard-coded everything to work exactly one way. ZDoom has shedded these assumptions to allow complete flexibility. Yet, ZDoom can render a quite effective Doom game. Dropping the demo-compatibility requirement allowed ZDoom to freely redefine structures to support many new capabilities directly and quickly. Graf sees the beauty of this approach, and appreciates the benefits that this philosophy affords, and that is his prerogative.

 

And yet, he has developed this tool, to be used in both his engine, and in engines that don't share the same philosophy, to help bridge the gap between the two approaches, and he should be commended for it. In fact, once the tool began to touch areas outside of his expertise - areas known to affect demo compatibility, he handed over the torch to allow us to hash out the demo issues.

 

So now, he's being attacked for voicing his opinion that the user should be able to see the specific map number of the map being played. This is the current deal breaker. Geez:

User Setting: [X] Show map id on automap?

Problem solved. Ok?

 

 

1 hour ago, Altazimuth said:

How I'll probably tackle this:

  • Step 1: Make it so that all pre-UMAPINFO demos work correctly, hopefully whilst still respecting visual-only settings (like how sky transfers work in -cl9 demos)
  • Step 2: Try to implement the new demo header system
  • Step 3:
    • i: Test that shit to hell and back
    • ii: Deliberate on what more might be needed
    • iii. Implement whatever more is needed
    • iv: Iterate the previous few steps until everybody is happy

I'd say that step 3 doesn't need to happen until steps 1 and 2 happen. This effectively leaves me to my devices, and the conversation can be pointed back to whatever people are more keen on talking about. It wasn't my intention to bring all the discussion to this issue, merely to highlight it and make sure that it gets addressed (with me being the one doing most of the engine parts of the addressing). This all being said, I hope we can go back to prior discussion.

 

You are going to tackle this? You're coding for Eternity, right? I think UMAPINFO needs to be defined and finalized in PrBoom+ first, if my Compatible Doom eXtensions (I went with CDX :) are to be able to be compatible across all ports. I have been assuming that I am responsible for doing that. Please let me get it solidified in PrBoom+ first. Your methodology is solid, but please recognize that PrBoom+ is a special case. PrBoom+ is to be the model for CDX, which claims UMAPINFO to be a central component to the success of the new standard. Other ports can get away with missing a few specifics, but it must be done correctly in PrBoom+ with it's various complevels and its handling of multiple demo formats. "If it can make it here, it'll make it anywhere". Since it's part of the CDX-01 spec, by definition, it will have to work across all extended ports, including ports that don't have complevel, or even demo compatibility support.

 

In addition to the demo header, PrBoom+ actually uses a demo footer to store additional info, which older ports can somewhat tolerate, much better than if the data were put in the header. Please see my reply on the previous page, in regards to our need to work together, to solve future problems that we may want to include compatible solutions for. I am afraid of the chaos that may be generated by multiple rapid implementations of UMAPINFO, yet, the way to resolve this is to rapidly get the PrBoom+ implementation published. Please, guys, let me get this rough draft out there, before a Universal MAPINFO format becomes non-universal! I'm chasing a moving target!

 

 

5 hours ago, TimeOfDeath666 said:


Say what you want, but mapsets are designed for specific settings in complevels, and the demo forum shows (complevel x) in every thread, so that everyone plays with the same specific settings.

If a player needs to set a new complevel just to activate the umapinfo data, it sounds to me like it would be a step backwards in demo compatibility. Whether pre-umapinfo ports bomb out immediately when trying to play a umapinfo demo, or the demo eventually deysncs, the result is the same: both don't work. But on a wad that uses umapinfo just for non-gameplay stuff, if someone records with the new umapinfo complevel then it'll bomb out on pre-umapinfo ports, instead of playing back fine without showing the non-gameplay umapinfo stuff.

Rebuttal: "Read what you want" (not what I type :)  <-- a joke.

 

Let me make a few statements, and see if you agree with my definitions. The concept of Complevels appears to be difficult to grasp. To be more specific: Complevels are there for one and only one purpose, but their effect has a duality about it that suggests a reversal of cause and effect (yeah, that was clear...)

 

Another attempt:

For a moment, for this discussion please ignore the fact that PrBoom+ can produce demos that look like they were created from vanilla, or from Boom. This is an anomaly that, arguably, should not have been made possible. These old-looking demos, if not built perfectly, create a very problematic situation for people working on demo sync, and falsely believing that they are looking at a vanilla or Boom demo. So, for now, let's pretend that's not possible, so I can make some declarations:

 

Here is the one (and a half), single, legitimate purpose of setting a complevel:

  • To provide information to PrBoom+, that's missing from the demo file, about how to handle various options and actions available in PrBoom+, for the express purpose of rendering the demo, as closely as possible, to the way the game was originally recorded. Essentially, it is a demo version number for demos that do not uniquely identify themselves.
  • I guess there's also the occasional map that requires a specific, old-engine user setting, that could be satisfied by setting a complevel. These aren't really supposed to happen, but, unfortunately, they sometimes do. I guess that's Gez's motivation for wanting to be able to set the complevel in a UMAPINFO. I think such a rare need should not be solved with such a blunt tool. If you can add a UMAPINFO setting, you can also fix the map. Or the user can add a complevel on the command-line. I feel that a UMAPINFO complevel is much more dangerous than helpful. I need to think about this some more.

 

The other ways complevels are currently (incorrectly) used:

  • To set lots of user options with a single setting. This effectively "breaks" the game's user options capability.
  • To force the player to play a WAD a certain way, without giving the player the ability to set options as he/she sees fit. (same as above)
  • To force the player to play a WAD a certain way, to prevent a (poorly) designed map from "breaking" when the user sets certain settings. Good intentions, but not necessarily the right approach.
  • To make sure an older map plays as intended, without having to test the map. Again, good intentions, but, not the best approach.
  • To force the engine to emulate an older port. This could be useful, for curiosity, or testing, but not in general.
  • Other uses I haven't imagined.

Here's the thing: It's my computer, my monitor, my keyboard, my mouse. It's my port. It's me wanting to play, the way I want to play. I want to choose the options I want, even if that's different than those that the author wanted. I do want to start out with the game the author wanted me to play, but then I get to decide how to alter it.

 

I do believe that there should be a way to set all the internal settings that a complevel sets, but there needs to be a distinction between that, and a complevel,, even if it's just a mental distinction, for now.

 

Here's why:

Up until this point, PrBoom+ has only been used for old to current maps, so we've been able to use complevels as a hack to set game settings. But, now we're discussing the possibility of using PrBoom+ for map sets with new features. New features don't require complevels, because PrBoom+ does not need to emulate an older engine. PrBoom+ demos will be able to store the user's settings, allowing perfect demo playback. This becomes obvious if you think of complevels as hints, supplying information to the engine that's missing from old demos.

 

PrBoom+ demos also have demo version numbers, which serve the same purpose. Essentially, a complevel is a demo version number, for demos that do not store a proper, unique version number.

 

The kicker:

If you run a map in PrBoom+ with, say complevel 2, and that map has UMAPINFO, without any special code to handle it, UMAPINFO would be ignored, because you told PrBoom+ to act like an older engine.

 

However, UMAPINFO *could* be handled in a complevel 2 PrBoom+ game, with 1 stipulation: Any demos recorded must be in PrBoom+ format, which would store either the complevel, opr, better yet, the needed user settings to run the emulation, within the demo. This is totally do-able, and would never create an incompatible demo.

 

Again, the ability to generate old-style demos is the anomaly here. Since it exists, I will reluctantly support it, if inconsistencies have been clearly prevented. What a strange predicament to be in! Entryway was careful to prevent lots of new behaviors from running when emulating older engines - it's a necessary step.

 

@TimeOfDeath666: You said it right the first time: It's not that complicated (but care must be taken). Complevels tell PrBoom+ how to play an old demo, none of which have UMAPINFOs. New demos use a demo version number (and user settings stored in the new demo) for that purpose.

 

 

5 hours ago, Ribbiks said:

My intuition when thinking about demos recorded in umapinfo port and played back in non-umapinfo ports:

- I'd expect movies to bomb out

- I'd expect ILs to play back fine

 

idea is to change the progression of levels, and some visual attributes of the levels, but otherwise not affect the map gameplay in any way? The only thing I notice that breaks that is the bossaction field, which IMO is unnecessary because if you really wanted to implement that there are some workarounds that don't break compat.

 

edit: didn't intend to muddy any waters with non-helpful commentary. fwiw I think completely bombing out in pre-umapinfo ports is also fine. (I also realize there are plenty of cases where the above wouldn't be feasible, e.g. maps outside the 01-32 range)

You'd be surprised: An extra gunshot while totalling end game percentages is enough to cause a multi-level demo to desync, without code that carefully handles it.

 

3 hours ago, printz said:

Why do people record PrBoom+ demos under complevels for MBF and down, other than to make them playable in Eternity, vanilla Doom and the DOS ports? Is there anything which can't be achieved by changing menu settings? Is there any reason to record a multi-level UMAPINFO demo under low complevel if other ports (save potentially Eternity) can't play it properly anyway? Single level recordings are fine.

 

It just feels to me that inferior complevels should totally emulate how such an equivalent engine would run the megawad. The real challenge is to somehow keep UMAPINFO stable and simple enough so it can get its own complevel.

 

It's the other feature, off-topic from here, which is DECOLITE which makes me think. Doesn't PrBoom+ risk turning into another Eternity Engine, which keeps retro demo compatibility, but totally fails to keep recording compatibility with past versions of itself (because it's physically unfeasible)? I used to be a big fan of merging these two ports until I realized that PrBoom+'s main property is high conservation, incompatible with Eternity.

Absolutely not. In fact, Eternity can continue to maintain compatibility too (see Gez's post.). It is theoretically ok to let compatibility slide a bit between official builds. This is desirable, because, each official build requires version checks to be added to that which has changed. There is a methodology you can use too. If you can avoid changing existing stuff, and do all your innovation on new things, you avoid the need to check for changes to existing functionality.

 

Eternity has changed drastically over the years, so there's a third option. If all devs can be in agreement, you can choose to restart compatibility checking at a future official build. Make vanilla, and maybe Boom, or even PrBoom level-compatibility work for the older stuff. Also, starting at this official build number, begin caring about compatibility from that point onward, making a specific decision to require old .EXEs to be used for older Eternity compatibility. This lets you start "clean", and it's much easier. You just have to decide if it's ok to drop compatibility for this range of past development.

 

2 hours ago, Gez said:

Complevel is not just for recording, though it was the primary motivator for it. Complevels are also there to select different game behavior, since Boom and MBF introduced changes in physics and actor logic. Some maps require Boom or MBF physics, some other maps require vanilla Doom physics. Admittedly, most maps will work fine enough regardless of complevel chosen, but Doom has plenty of exception to every rule.

The goal of the Boom team was for there not to be such exceptions...but they dropped the ball in a few places. The ability needs to be there, but should not inhibit innovation, if possible: "I want old...but I want new...". There's only so much that can be done to cater to this, you know?

 

2 hours ago, Gez said:

 

Yes and no. If we're going along with these DEX stuff, then anything that would hypothetically be added to PrBoom+ (or successor fork) this way would be relatively stable. Ports like ZDoom and Eternity are in constant development, so they get new features regularly and then these new features might get fine-tuned for a while before stabilizing. But for that DECOLITE thing, if it's ever part of DEX, then it would be static. Perhaps DEX-5 adds basic DECOLITE features and then it doesn't change. Once the PrB+ reference implementation is complete, it doesn't change anymore. Until, perhaps, DEX-6 adds extensions to DECOLITE. But basically you can imagine that each DEX level would get a new complevel, so the same thing would happen.

I basically agree with this, subject to later clarification :)

 

@everybodyI believe I understand the issues presented here, and I'm working to ensure that they are resolved. Wish me luck.

Share this post


Link to post
3 hours ago, kb1 said:

You are going to tackle this? You're coding for Eternity, right? I think UMAPINFO needs to be defined and finalized in PrBoom+ first

 

A prior comment asked Graf directly if he'd be willing to accept a pull request. I thought that from this, somebody familiar enough with git would understand that I am going to be doing this on a fork of Graf's PRBoom+ repository. I apologise if I didn't make that clear enough.

Share this post


Link to post

If you fork, use the UDMF-only branch. The master contains some preliminary work for actor definitions which are probably not wanted for this.

 

Share this post


Link to post

Duly noted.

 

1 hour ago, Graf Zahl said:

The master contains some preliminary work for actor definitions which are probably not wanted for this.

See the below post for my reply to this, as the content of that being here would derail the thread.

 

Share this post


Link to post
16 hours ago, Altazimuth said:

 

A prior comment asked Graf directly if he'd be willing to accept a pull request. I thought that from this, somebody familiar enough with git would understand that I am going to be doing this on a fork of Graf's PRBoom+ repository. I apologise if I didn't make that clear enough.

It's all good - sorry about getting worked up. The truth is that I can use all the help I can get. I'm just worried about potential runaway trains, if you know what I mean. Good luck! Feel free to bounce ideas off of me, if you feel the need.

Share this post


Link to post
On 8/3/2017 at 1:34 AM, Graf Zahl said:

 

You wouldn't say this if you had an understanding of what demo compatibility implies.

In terms of ZDoom it'd mean:

 

- revert the actor definitions to info.c and not a virtual class hierarchy (Having the class hierarchy is not compatible with how Doom demos work - not even remotely!)

- revert the inventory handling to the exact mechanics as Doom originally implemented (the current system is so totally different that you cannot possibly expect it to stay in sync.)

- undo the floating point math conversion (float and fixed math produces very slightly different results, and in case of overflows of fixed point totally different ones.)

...

 

This doesn't even consider all those small changes here and there - but as things stand all of the above cannot be kept if you want to have demo compatibility as they severely change how certain things are done - the results are nearly the same but order of execution alone will put up an impassable roadblock.

The gist here is: To play Doom you need an engine that's observationally identical with the original game. To play demos you need an engine that is algorithmically identical with Doom.exe and that's an entirely different matter - every bug, every quirk, every math overflow needs to be meticulously preserved. And since ZDoom has changed a lot of things here, all those would have to be undone first, to be replaced by Doom.exe or PrBoom+ code. So, in order to make ZDoom demo compatible the only chance you have is to undo ZDoom.

 

Wanna bet that all other people with the technical know how will tell you precisely the same? ;)

Who says anything about reverting progress? There are other more elegant solutions to replicating vanilla compat that doesn't involve undoing progress, all you need is a bit of lateral thinking.

Share this post


Link to post
5 hours ago, ArcheKruz said:

Who says anything about reverting progress? There are other more elegant solutions to replicating vanilla compat that doesn't involve undoing progress, all you need is a bit of lateral thinking.

Mock it up. I'm not a ZDoom dev, but I've seen enough to know what Graf means. If by 'lateral', you mean pulling in three quarters of PrBoom, renaming conflicting variables, structures, and modules, and having the code jump into "PrBoom mode", sharing a common renderer, that's not success.

 

Successful ZDoom vanilla compatibility would mean working with the existing actor systems, movement systems, weapons systems. Some arrays would have to be loaded starting at index -1. The original PRNG would have to return. All extra functionality would need to become conditional during a demo/vanilla session, which would most likely degrade performance. Garbage collection would need rewriting to keep removed actors around long enough to be read after being marked 'removed'. Multiple blockmap handlers. Multiple line-of-sight checks. The old demo load system. The old actor blocklists or equivalent.

 

Yes, anything is possible with enough time and materials. Yes, ZDoom could silently launch PrBoom, redirect its video output to ZDoom's window handle, and appear to support old demos. But, to do it properly requires ZDoom to undo its philosophy.

 

ZDoom took a stance long ago: To drop exact gameplay, to enable a massive code cleanup, a massive restructuring that better supports user mod-ability.

 

It is as if you decided to convert your gasoline-engine car to use electric motors instead, except, 15 years later, someone says "I want to be able to run the car with gasoline." So, you now have to put back/retrofit a gasoline engine, in a way that works with the electric motor system. Furthermore, any new changes had better not negatively affect either method.

 

Even if ZDoom did all that work to put back all of the removed/reworked code, structures, etc, to support old demos, they're still not done. Then, they have to test the engine against not only all the old vanilla demos, but also all the ZDoom mods, to make sure nothing is broken in either method.

 

But, wait, there's more! Even after all that work, they now have this monster which is twice as difficult to modify. ZDoom's claim-to-fame is in the ability to provide its users quick updates in functionality, as needed by modders. That becomes over twice as difficult now, because any modification now needs vanilla demo checks, and regression testing. The devs decided long ago that they did not want to work that way. So, why should they emburden themselves now?

 

Share this post


Link to post
6 hours ago, ArcheKruz said:

Who says anything about reverting progress? There are other more elegant solutions to replicating vanilla compat that doesn't involve undoing progress, all you need is a bit of lateral thinking.

It seems that you already know the right way to do all this. Why don't you share it for the benefit of us all?

Share this post


Link to post
21 hours ago, ArcheKruz said:

Who says anything about reverting progress? There are other more elegant solutions to replicating vanilla compat that doesn't involve undoing progress, all you need is a bit of lateral thinking.

ZDoom is a lost cause in this endeavor. Eternity however has you covered.

Share this post


Link to post
On 8/9/2017 at 2:51 PM, Da Werecat said:

It seems that you already know the right way to do all this. Why don't you share it for the benefit of us all?

Graf's own team seems to be doing that just fine.

 

"This is impossible because X, Y, Z." - Graf

*5 Minutes later*

"Solved." - Someone else

Share this post


Link to post
56 minutes ago, ArcheKruz said:

Graf's own team seems to be doing that just fine.

 

"This is impossible because X, Y, Z." - Graf

*5 Minutes later*

"Solved." - Someone else

If you are going to try troll Graf, can't you at least say something funny? It is not that hard, you just need to do some lateral thinking.

Share this post


Link to post
14 minutes ago, dpJudas said:

If you are going to try troll Graf, can't you at least say something funny? It is not that hard, you just need to do some lateral thinking.

...that was trolling?

Share this post


Link to post
On 8/13/2017 at 6:18 PM, ArcheKruz said:

Graf's own team seems to be doing that just fine.

 

"This is impossible because X, Y, Z." - Graf

*5 Minutes later*

"Solved." - Someone else

Like I said, mock it up - use some of that "lateral thinking" of yours. Who knows, maybe in 5 minutes, Someone else will solve it for you.

Share this post


Link to post

Been toying with the new lump for a few days, since, hell, why not, somebody might as well do so. Just a few questions:

  • Did I miss a build of Graf's PrBoom+ fork that has the curly brace syntax? The one on the Github page seems to still be using INI syntax. I mean, I'm fine developing against that syntax for now, it's more or less just a RegEx find/replace to go from one to the other; just curious. (I did try compiling my own build, but was having include/linker issues, with a file or two asserting SDL.h couldn't be found, even when the most-up-to-date versions of SDL2, SDL2_mixer, SDL2_image and SDL2_net are put into the proper places in the Include Directories and Linker Directories in the project properties for both projects in the solution - I don't even know...)
  • Though I see there's a way to skip the level stats screen entirely (a la Ultimate Doom), is there a way to skip the "entering [level]" part of said screen? It's present even when it's transitioning to an end-state (whether that's "EndGame = true", "EndCast = true" or what-have-you). I suspect it has to do with how "Next" is still defined for the map slot I'm using, even though the UMAPINFO doesn't explicitly define one, but I wouldn't know how to clear that - with intermissions, that'd be "Intermission = clear", but "Next = clear" just throws a "string expected at line n" error, so obviously it's not that.
  • On that note, that "clear" keyword seems to be case-sensitive, even when the rest isn't. "Intermission = Clear" doesn't parse.
  • I'm assuming it's intentional that BossAction only works for Things that call A_BossDeath? Not that it's a huge hardship, it's easy enough to make a BEX file to work around that for any Thing that I want to use that property on.

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
×