Defining a new enhanced source port standard (Boom+/MBF+)

[Gez]

If you put a jump option in UMAPINFO it could be a good idea to make it a value (for the vertical speed boost you get, typically 8 or 9) instead of a binary flag. Because otherwise, "allowing jumping" will mean different things in different ports, with PrBoom+ letting you climb on a 64-tall crate while ZDoom won't. See discussion here:

If you set it to 0, you disable jumping entirely. Set it to 8 for ZDoom/Eternity behavior, 9 for PrBoom+/Crispy behavior.

[Jon]

7 hours ago, kb1 said:

So, what do you say? 2nd week of January?

 

Fine by me! But don't kill yourself to hit the deadline. It's more important to me that you're happy and healthy than we get this done fast.

[Graf Zahl]

43 minutes ago, Gez said:

If you put a jump option in UMAPINFO it could be a good idea to make it a value (for the vertical speed boost you get, typically 8 or 9) instead of a binary flag. Because otherwise, "allowing jumping" will mean different things in different ports, with PrBoom+ letting you climb on a 64-tall crate while ZDoom won't. See discussion here:

If you set it to 0, you disable jumping entirely. Set it to 8 for ZDoom/Eternity behavior, 9 for PrBoom+/Crispy behavior.

Good idea, I never thought about doing it this way.

Of course, extending the system will require a change of how the player class based jump velocities work to be able to combine both options.

 

[Jon]

I'm sure this was discussed before, but is the intention that the UMAPINFO lump expresses the Wad author's preference i.e. "jumping permitted (inertia X) or jumping not permitted", but the user could override that (i.e. users' wish trumps wad authors)?

[Gez]

UMAPINFO should allow to express the author's preferences, that's pretty much the entire point. Then if some ports allow users to override that, it's not a problem IMO, as long as the default is "use UMAPINFO settings".

[Graf Zahl]

The ultimate decision lies with each port author, of course. The important thing is that the map starts out with the given settings.

 

[Jon]

Makes sense. Thanks!

[kb1]

14 hours ago, Graf Zahl said:

Good to hear that. To be honest, I was somehow expecting something along those lines.

 

I think my UMAPINFO fork is a good point to start for this, right?

UMAPINFO will probably require a bit of fixing before being ready, though. At the end I just ran out of time to finish it, unfortunately. But this should be the first thing to do, considering that both Eternity and GZDoom have already adopted it.

 

(And as a note to myself, what absolutely should be there is a 'jump' flag. IIRC even PrBoom+ supports jumping as a feature, so being able to control this would come in handy in many cases.)

 

 

Yes, absolutely the UMAPINFO fork is an excellent starting point, and, in fact, UMAPINFO is part of the standard. There was another unrelated PrBoom+ fix, if I recall, related to SR50 - that should be kept up with as well.

 

10 hours ago, Gez said:

If you put a jump option in UMAPINFO it could be a good idea to make it a value (for the vertical speed boost you get, typically 8 or 9) instead of a binary flag. Because otherwise, "allowing jumping" will mean different things in different ports, with PrBoom+ letting you climb on a 64-tall crate while ZDoom won't. See discussion here:

If you set it to 0, you disable jumping entirely. Set it to 8 for ZDoom/Eternity behavior, 9 for PrBoom+/Crispy behavior.

Probably a good idea. I would insist that, at least one specific setting should work exactly the same in all engines, for compatibility.

 

10 hours ago, Jon said:

 

Fine by me! But don't kill yourself to hit the deadline. It's more important to me that you're happy and healthy than we get this done fast.

Thanks for considering my well-being! I don't know about happiness (maybe when my projects are done), but I think I can stay healthy. I'm at the stage in my life where, instead of just cranking out code, I am trying to build reusable libraries. It's what everyone wants, but the reality of it is that it's just not easy to do. It's difficult, because you have to find a way to contain all of the little custom things that come naturally otherwise. You must build stable, self-contained interfaces, which means that you have to be clever to avoid requiring 50 parameters for each function call, and yet remain powerful enough to handle all of the custom stuff you want your library to accomplish. It's easy to get carried away. You must know how big the box needs to be, and you must try to keep it small, and simple.

 

What all this means is that it takes me a lot longer than it used to, to complete my projects. The tradeoff is that I produce much better code these days. New projects should be able to take advantage of all of this preparation work. But, for now, I'm drowning in sub-projects!

 

I was hoping to be much closer to completion at this point. Regardless, I will devote the time to get a very rough outline done. Unfortunately, most of what I've developed so far exists only in my head. I have to go through the process of getting it on paper. Thanks, everyone, for your continued patience. As a result, I'll do my very best! I am actually eager to get the plan out in the open, where those smarter than me can scrutinize the ideas, and initiate a dialog, with a common frame of reference.

[Gez]

7 minutes ago, kb1 said:

Probably a good idea. I would insist that, at least one specific setting should work exactly the same in all engines, for compatibility.

My idea would have every possible settings work exactly the same in all engines.

[Shadow Hog]

Is there a reason we even care what the jump height PrBoom+ uses, when we're making our own fork of PrBoom+ anyway for a baseline, and can thus fix it to be more in line with whatever value we want? I can understand ZDoom being less flexible, as enough maps have been built around its specific movement physics that changing things would break compatibility, but we're already superseding PrBoom+ with this. Likewise, I'm not sure how many Boom-format maps that expect you to jump using PrBoom+'s specific jump physics have been made (though of course, I can't say "absolutely none", knowing this community...).

 

EDIT: Oh, Crispy Doom. And vanilla Hexen, I guess. I somehow missed that. (Hey, I answered my own question.)

[kb1]

1 hour ago, Gez said:

My idea would have every possible settings work exactly the same in all engines.

Yes, of course. I was not clear with that statement - I was referring to the proposed jump = 8 or 9 setting. What I meant was that there should be a setting that effectively resembles: "jump like PrBoom+" in ZDoom, and/or a "jump like ZDoom" in PrBoom+. I am not familiar of the significance of 8, or 9. You describe a 'vertical speed boost'. Are you suggesting that using, say, a '9' in ZDoom would today allow ZDoom to exactly emulate a PrBoom jump (and vice versa for '8')? If so, I think we're on the same page.

 

1 hour ago, Shadow Hog said:

Is there a reason we even care what the jump height PrBoom+ uses, when we're making our own fork of PrBoom+ anyway for a baseline, and can thus fix it to be more in line with whatever value we want? I can understand ZDoom being less flexible, as enough maps have been built around its specific movement physics that changing things would break compatibility, but we're already superseding PrBoom+ with this. Likewise, I'm not sure how many Boom-format maps that expect you to jump using PrBoom+'s specific jump physics have been made (though of course, I can't say "absolutely none", knowing this community...).

 

EDIT: Oh, Crispy Doom. And vanilla Hexen, I guess. I somehow missed that. (Hey, I answered my own question.)

We don't want to create a demo desync in PrBoom+. A major goal of this effort is cross-port compatibility. Compatibility requires effort. Unfortunately, vanilla Doom has very few in-place mechanisms to support cross-port compatibility, because it didn't need it.

 

Ports have been independently modified for many years, and they will continue to be modified in the future. The spec should not hinder port uniqueness. Instead, hopefully, it will provide a clear path that encourages compatible development.

 

Gez's idea takes compatibility one step further: Instead of a simple Yes/No flag, by providing a 'vertical speed boost' setting, values hard-coded in different engines can now become easily-user-editable, as if they always were. Not only does this setting allow both ports to provide exact jump mechanics, it also allows cross-port-compatible low-gravity jumping, if desired, in a map-author-configurable way. New maps that use the setting will be cross-port compatible, and older maps will play as they always have - slightly different in each port, but compatible to how they played when the map author tested them. It's a win-win.

 

This decision tree is the basis for how I envision the spec to function: Older maps function as they always have, and newer maps can be made to work the same in all participating ports, with the advantage of more modding capabilities.

 

I will thoroughly outline my ideas on this in the upcoming spec, but, in a nutshell:

• Old maps should function in new ports
• Port authors should be able to customize their ports without breaking compatibility
• New port features may become standard features at some point (and can be built as such)
• Many new maps, with new features, should be playable in multiple ports
• Some maps will be port specific, either forever, or until a new feature is standardized
• All of this should be possible, without confusing the players, the map authors, or the port authors

This is a tall order, indeed. But it's actually what we all want in the end, and it's do-able. It will require a rock-solid spec that considers all of these points and more, for each and every feature added. Each mistake we make might require another compatibility hack, another fuzzy rule, another kludge. I hope I'm being clear - it's not easy to explain.

 

 

 

[Shadow Hog]

3 hours ago, kb1 said:

Not only does this setting allow both ports to provide exact jump mechanics, it also allows cross-port-compatible low-gravity jumping, if desired, in a map-author-configurable way.

Interesting idea, though I'll note that it'd actually be more like a High Jump ability, since the actual gravity part would be exactly the same - unless that were also a new UMAPINFO parameter. (Might as well be, both ZMAPINFO and EMAPINFO have it - though their parameters are different, with ZDoom using multiples/fractions of 800 to define gravity, and Eternity using multiples of 65536 - fixed point, presumably.)

[Graf Zahl]

ZDoom's odd choice of value is owed to ancient history when user friendly values were not even thought of. Of course it's hard to change now, but with UMAPINFO I'd define 1.0 as the default value for gravity. Not 800 and not 65536.

[Gez]

6 hours ago, kb1 said:

I am not familiar of the significance of 8, or 9. You describe a 'vertical speed boost'.

Jumping gives you an increase in vertical velocity (momz value) of 8 or 9, times FRACUNIT. Then normal gravity rules apply. It means the first tic you climb up, say, 8 units, then gravity starts gnawing your momentum so the second tic you only climb up 7 units, then on the third you climb 6 units, and so on. Eventually your momentum is reduced to 0 and then you start falling back down. How high you climbed is the eighth triangular number if you jumped 8, or the ninth if you jumped 9: 36 or 45. To that value, you add the Doom step-up of 24 units, and you get 60 or 69. Therefore, with jump speed 8 you can climb up to 60 units, and with jump speed 9 you can climb up to 69 units.

 

As for why 8 or 9 in the first place? Strife uses 8, Hexen uses 9. Why Rogue and Raven chose these values I do not know, but the hypotheses that it's somehow related to player sprite height might have merit: PLAYA1 is 58 pixels tall in Strife, 66 pixels tall in Hexen (MAGEA1: 64; CLERA1: 67). That makes each game allowing their players to climb up to a bit above their height with a jump.

 

[fabian]

On 28.11.2017 at 0:27 PM, Gez said:

9 for PrBoom+/Crispy behavior.

Please note that meanwhile both ports offer a choice between jumping with 8 or 9 momz units.

[kb1]

15 hours ago, Graf Zahl said:

ZDoom's odd choice of value is owed to ancient history when user friendly values were not even thought of. Of course it's hard to change now, but with UMAPINFO I'd define 1.0 as the default value for gravity. Not 800 and not 65536.

Normalizing the value to 1.0 for the user makes a lot a sense. Maybe something similar for jumping? The most important thing is for 1.0 in Port A to mean exactly the same thing to Port B. Beyond that, you're right - values should be scaled so that the standard value is 1.0, or even 100, which equals 100%. Either is fine by me. We could even allow the parser to understand the percent symbol, and convert 85% to 0.85, if we wanted to.

 

13 hours ago, Gez said:

Jumping gives you an increase in vertical velocity (momz value) of 8 or 9, times FRACUNIT.

Nice analysis! I never even knew Hexen provided a Jump action. So it's really that simple (8 * FRACUNIT), or (9 * FRACUNIT). So the number does mean the same thing in the different ports, it's just that the default value is 8 in some, and 9 in others, right? That's manageable. At some point, we're going to have to be able to distinguish between "Old Map" and "New Map". Maybe the presence of a UMAPINFO lump, or a setting within, can make that determination. My point is that, if the map is identified as "Old Map", each port can use its default value of 8 or 9. But, if the map detects as "New Map", we are free to provide a new set of defaults that match across ports. Maybe "1.0" = (8.5 * FRACUNIT) for jumping, as a default value for new maps.

 

This is an important spec point: I think it is important for us to decide upfront that we need a solid, well-defined way to mark a map "New". This solves a lot of problems down the road. Like the above. By having a rock-solid way to say "New Map", we can normalize and equate A LOT of hard-coded discrepancies amongst all the ports. This provides a way to "clean the slate", and start out with a compatible set of defaults, and settings that are normalized, and in a sensible range. Anyway, it'll be in the rough draft.

[Gez]

29 minutes ago, kb1 said:

Maybe "1.0" = (8.5 * FRACUNIT)

Nah. The game is meant to work with integral multiples of FRACUNIT for momz.

#define GRAVITY		FRACUNIT

    else if (! (mo->flags & MF_NOGRAVITY) )
    {
	if (mo->momz == 0)
	    mo->momz = -GRAVITY*2;
	else
	    mo->momz -= GRAVITY;
    }

I don't see merit in using a half-baked "compromise value". Standard should be 0 anyway.

[kb1]

2 hours ago, Gez said:

Nah. The game is meant to work with integral multiples of FRACUNIT for momz.

#define GRAVITY		FRACUNIT

    else if (! (mo->flags & MF_NOGRAVITY) )
    {
	if (mo->momz == 0)
	    mo->momz = -GRAVITY*2;
	else
	    mo->momz -= GRAVITY;
    }

I don't see merit in using a half-baked "compromise value". Standard should be 0 anyway.

I don't know who's value to pick as the default. Which port is willing to give up their 8 or 9? 8.5 let's me discuss the matter without pissing off the port authors (but not everyone :)

And, what is half-baked about 0x8000? What's integral about fixed-point? 8.5 * FRACUNIT = 0x88000. Anyway, what do you mean by 0? I don't see 0 making a lot of sense to anyone: Vertical speed = 0? jump = 0?? I guess you could say ExtraJumpBoost = 0, whereas you'd have to make it negative to reduce the jump amount. Problem is, that doesn't directly control the jump value of 8 or 9 or whatever. Using 0 requires you to research the range. The beauty of starting with 1.0 is that you can use intuition to guess that 0.5 is a half-height (or velocity or whatever) jump, and 2.0 is a double-height (or velocity or whatever) jump. Using 0 gives you no idea of what the range is: 0 to 255? -128 to 127? -32768 to 32767?

 

I really have no desire to debate this. Before these posts, I didn't know the significance of 8 vs. 9. Besides, this can be ironed out at a later time. I was kinda hoping the discussion would revolve around some of the more important, significant points vs. how to scale a value. That will certainly become important later, but, for now, I was hoping that we could consider the idea of normalizing presented values from a lot of categories. For example, making map authors understand the internal power-of-2 representation of numbers seems unnecessary to me. "100%", or "1.0" seems more presentable than "255" or "65535" to me.

 

More on point: "8" or "9" has no meaning to anyone, unless they've researched the subject. I tend to prefer when things are self-discoverable. To me, "1.0" is almost self-documenting.

 

I'm not real hung up on this, no matter how it goes, but I think it's worth discussing.

[Shadow Hog]

Using a decimal multiplier for gravity scaling makes sense. Using the same for jumping, at present, does not, as it assumes a single default value when we presently have two (discounting that the default probably should be 0, for no jumping at all - that wouldn't work for a scale, though!).

 

If you wanted my two cents on which should be default, I'd be more inclined for ZDoom/Strife. My thinking is, going by Gez's suggested metric (jumping just slightly higher than the player is tall), Doom Guy being 56 units tall in-engine is closer to Strife Guy (literally the same, in fact) vs. Hexen's Baratus, Daedolon and Parias (who are all 64 units tall). Plus, if we had to do a decimal multiplier, it'd be easier and cleaner to go from 8 to 9 (1.125) than from 9 to 8 (0.88888888888888888888888888888889).

 

Whatever it is, I'd much rather we not settle on an default jump impulse that neither engine uses (8.5) as the default - one or the other, please. I'm not very comfortable with having to use ugly scales like 0.94117647058823529411764705882353 to get ZDoom/Strife jumping (8) or 1.0588235294117647058823529411765 to get Crispy/Hexen jumping (9).

 

All that said, Gez's solution would eliminate the need to choose a single value, and makes perfect sense to me (it's how fast you're moving, vertically, the instant you press the jump button). I'd honestly prefer just using that.

[Arctangent]

3 hours ago, kb1 said:

Anyway, what do you mean by 0?

0 means 0. As in, what you get when you try to jump in vanilla Doom: you don't.

[Graf Zahl]

 

For jumping, setting a default is a bit difficult, due to how these things were handled in the past and many, many maps assuming that the feature will be present if no info is given.

 

4 hours ago, kb1 said:

I don't know who's value to pick as the default. Which port is willing to give up their 8 or 9? 8.5 let's me discuss the matter without pissing off the port authors (but not everyone :)

 

No port should give up anything. The port's default still will apply if no UMAPINFO is present.

But I guess with UMAPINFO as a still unused feature we can clearly say that if a map has an UMAPINFO record, its jumping value will be absolute, disregarding user-side overrides. Which should end the discussion

 

4 hours ago, kb1 said:

And, what is half-baked about 0x8000? What's integral about fixed-point? 8.5 * FRACUNIT = 0x88000.

 

 

We are defining a format for end users here, so why using machine-native values to begin with? Fixed point has no meaning for the end user, and it also has no meaning anymore for some ports which entirely floatified the game code. For those it's just an artificial value. Worse, relying on hexadecimal is strongly discouraged because non-techy people cannot make sense of it. Using a decimal factor like '8', '8.5' or '9' is clearly the best option because it directly translates to the value being applied in the most Human-readable way.

 

Jumping should be expressed as a vertical velocity value, i.e. 8 means that vertical velocity gets 8 added. This is how ZDoom currently defines jumping for player classes. Scaling factors are ok for modifiers that get applied as scale, a good example here would be ZDoom's gravity scale property for actors. (which literally means 'gravity for this actor is 0.25x as normal' - and please don't tell me that this isn't how gravity works - but it's needed to emulate air friction for low mass objects which the engine does not have)

 

4 hours ago, kb1 said:

 

Anyway, what do you mean by 0? I don't see 0 making a lot of sense to anyone: Vertical speed = 0? jump = 0?? I guess you could say ExtraJumpBoost = 0, whereas you'd have to make it negative to reduce the jump amount. Problem is, that doesn't directly control the jump value of 8 or 9 or whatever. Using 0 requires you to research the range. The beauty of starting with 1.0 is that you can use intuition to guess that 0.5 is a half-height (or velocity or whatever) jump, and 2.0 is a double-height (or velocity or whatever) jump. Using 0 gives you no idea of what the range is: 0 to 255? -128 to 127? -32768 to 32767?

 

0 is 0. Meaning that jumping is disabled. Which is what everybody would expect.

 

 

4 hours ago, kb1 said:

I really have no desire to debate this. Before these posts, I didn't know the significance of 8 vs. 9. Besides, this can be ironed out at a later time. I was kinda hoping the discussion would revolve around some of the more important, significant points vs. how to scale a value. That will certainly become important later, but, for now, I was hoping that we could consider the idea of normalizing presented values from a lot of categories. For example, making map authors understand the internal power-of-2 representation of numbers seems unnecessary to me. "100%", or "1.0" seems more presentable than "255" or "65535" to me.

 

I think aside from you nobody ever saw this as an issue. Read my first paragraph for a suggestion how to handle this. We are in the fortunate situation where we can define how this works in the most unambiguous way possible and close all the loopholes that opened up in the past because this all depends on a feature that nobody had been using so far.

 

 

 

4 hours ago, kb1 said:

 

More on point: "8" or "9" has no meaning to anyone, unless they've researched the subject. I tend to prefer when things are self-discoverable. To me, "1.0" is almost self-documenting.

 

Yes and no. But what is 1? momz==8 or momz==9? If we just use the literal value (i.e. 8 or 9), there is no interpretation issue that people equal '1' with the default for one of the existing settings.

 

[Jon]

Climbing 64 units with a jump  always seemed too high to me. I'd suggest zdoom/strife value as default 

 

from an editor/author POV I don't think 1.0 is much more intuitive than 8 or 9. It still means you have to know what the default means. The most informative way to express it would be in terms of max height achieved/tallest height transition that can be travelled over assuming default gravity. That's the matter of concern for editors (can the player jump onto/over this?)

[Arctangent]

11 minutes ago, Graf Zahl said:

Jumping should be expressed as a vertical velocity value

Strictly speaking, defining the height of a jump's apex in default gravity would also be a good, if not better, way to express it, though that obviously is not something particularly simple to translate to the engine, not with Doom's gravity physics anyway.

[Bauul]

Remember all of this will have documentation that mappers will happily read. A variable doesn't have to be completely self explanatory, as long as it's simple enough to understand by reading the wiki (or wherever).

 

If the UMAPINFO wiki page had a table that simply listed what each momz value translated to in terms of map unit jump height (and which values are used by other games/ports), that's more than enough.  If it's best expressed in UMAPINFO in momz, then leave it like that.

[Szymanski]

8 hours ago, Bauul said:

 A variable doesn't have to be completely self explanatory

 

Personally if I'm going to set a jump height I'd prefer to think in map units, i already know the value I want and there's no ambiguity or decimal points to confuse. The engine can then modify the value into whatever oddball format it needs.

Edited November 30, 2017 by Szymanski : decimal pint! no such abomination

[Graf Zahl]

20 minutes ago, Szymanski said:

Personally if I'm going to set a jump height I'd prefer to think in map units, i already know the value I want and there's no ambiguity or decimal pints to confuse. The engine can then modify the value into whatever oddball format it needs.

 

The problem here is, of course, that if you alter gravity the entire system will get thrown out of the window, because jump height is a function of both gravity and jump velocity and not a simple unambiguous value. And changing gravity is one of the next logical steps in development because it's relatively easy to accomplish.

[Arctangent]

1 hour ago, Graf Zahl said:

 

The problem here is, of course, that if you alter gravity the entire system will get thrown out of the window, because jump height is a function of both gravity and jump velocity and not a simple unambiguous value. And changing gravity is one of the next logical steps in development because it's relatively easy to accomplish.

Like I said previously, this is just a matter of changing the context from "jump height at current gravity" to "jump height at default gravity."

 

There's still the matter of translating jump height to jump force, however, esp. considering it requires figuring out a factorial that'll get you the value.

[Gez]

12 hours ago, kb1 said:

And, what is half-baked about 0x8000? What's integral about fixed-point? 8.5 * FRACUNIT = 0x88000.

Normal Doom physics only get integer multiples of FRACUNIT, and there is a check specifically for when momz reaches 0. Not 0.5 or -0.5. You don't use an integer multiple of FRACUNIT, you lose the gravity boost in the first falling tic, which -- as weird as it can be from a simulationist standpoint -- has always been a part of Doom physics.

 

12 hours ago, kb1 said:

I don't know who's value to pick as the default.

I do. 0. The default should be "jump disabled" because there's no jumping in vanilla Doom. For the rest, it's a simple matter of referring to documentation. Here's a neat little chart.

╔═══════╤════════╤═══════╗
║ Speed │ Height │ Climb ║
╟───────┼────────┼───────╢
║   * 0 │      0 │    24 ║
║     1 │      1 │    25 ║
║     2 │      3 │    27 ║
║     3 │      6 │    30 ║
║     4 │     10 │    34 ║
║     5 │     15 │    39 ║
║     6 │     21 │    45 ║
║     7 │     28 │    52 ║
║   * 8 │     36 │    60 ║
║   * 9 │     45 │    69 ║
║    10 │     55 │    79 ║
║    11 │     66 │    90 ║
║    12 │     78 │   102 ║
║    13 │     91 │   115 ║
║    14 │    105 │   129 ║
║    15 │    120 │   144 ║
║    16 │    136 │   160 ║
╚═══════╧════════╧═══════╝
* recommended values

 

Basically what I'm saying is please don't make this overly complicated. Please don't bikeshed to death a relatively minor optional feature because you want the bikeshed to be a SmartShed 3000™ with touchscreens and social network connectivity. All we need is a thing with a roof so that we don't have to sit on a wet saddle when it rains.

[Szymanski]

4 hours ago, Graf Zahl said:

 

The problem here is, of course, that if you alter gravity the entire system will get thrown out of the window, because jump height is a function of both gravity and jump velocity and not a simple unambiguous value. And changing gravity is one of the next logical steps in development because it's relatively easy to accomplish.

As a mapper I'd like an easy way to set the result eg jump 32 units high at X units gravity and at Y velocity (if running speed is alterable by script etc). I'd then know the player can reach a 56 high ledge (24 unit step plus 32 jump). Let the software tune the internal values for its physics engine. I imagine you'd want values for Gravity, Mass, Velocity and Jump force and thats fine but ultimately I need to know the player wont jump over a barrier because of a rounding error.

[Arctangent]

44 minutes ago, Szymanski said:

(if running speed is alterable by script etc)

I can't think of a single port that increases your jump height based on your current xy velocity.

 

44 minutes ago, Szymanski said:

general idea

As I've said multiple times at this point, as much as it is the most user-friendly method it doesn't play well with Doom's physics. As you can see from Gez's chart, there's no way to actually get 32 jump height with integer values. That's because jump height is the factorial of the upwards velocity given via jumping - e.g., 8! = 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1 = 36, 9! = 9 + 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1 = 45, which we can both confirm using the chart.

 

As far as I'm aware, there's no simple method of using a number to find a factorial that'll make it, so you just have to iterate through all possible factorials until you find something that meets your number. Considering that factorials only use integers ... yeah, there's not really any way to get 32 jump height even with a setting that directly sets the jump height.

 

It'd be a different story if, say, any port implemented jumping as a linear rise until you've reach a certain height. But ... none do, or at least none that anyone remembers.