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

4 minutes ago, Arctangent said:

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.

That's not a factorial - a factorial would multiply the numbers, not add them. This is just a sum of numbers up to N.

6 minutes ago, Arctangent said:

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.

The formula for a sum of numbers up to N is "S = N*(N+1)/2". Computing N from S only requires solving a quadratic equation, which is only slightly harder than computing a square root, so quite very easy.

1 person likes this

Share this post


Link to post

Well, so it is. Does have a proper name beyond just "sum of numbers up to N," though - arithmetic progression, to be precise, albeit that's not just 1-to-N in integers but also any sort of addition number sequence with the same interval between each number.

 

Still, it wouldn't really make sense to use any interval that isn't 1 for something like this, anyway, since that's the interval that determines the apex height under normal circumstances.

Share this post


Link to post
2 minutes ago, Arctangent said:

Well, so it is. Does have a proper name beyond just "sum of numbers up to N," though - arithmetic progression, to be precise, albeit that's not just 1-to-N in integers but also any sort of addition number sequence with the same interval between each number.

I believe Gez already used the proper name for these: triangular numbers.

Share this post


Link to post
2 minutes ago, Shadow Hog said:

I believe Gez already used the proper name for these: triangular numbers.

Seems like a bit of a square-rectangle situation, where triangular numbers are an arithmetic progression, but not all arithmetic progressions are triangular numbers - namely, those with a non-1 interval.

 

In the end, I'm ... probably not going to remember either of these by the end of the week, which I'm pretty sure counts as irony in some ways.

Share this post


Link to post

Hi, another mapper here. I don't particularly care if I have to type 1.0 or 8 or 9 or SELECT 64 * JUMP_FACTOR AS JUMP_HEIGHT FROM MAGIC_NUMBERS_TABLE WHERE GAME_NAME = 'DOOM'; I'd just really like for the feature, and UMAPINFO in general, to exist and work across ports in some consistent manner. That is all.

5 people like this

Share this post


Link to post
15 hours ago, Graf Zahl said:

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

Agreed. I said 8.5 to avoid choosing 8 or 9 in this thread, period. Not that we should actually use 8.5. It was an attempt to avoid a lengthy discussion on which number should be the standard. What a mistake that was...

 

15 hours ago, Graf Zahl said:

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

Good enough. I had no idea what the 0 was representing. Makes sense now that it's actually been described - thanks for that.

 

15 hours ago, Graf Zahl said:

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.

Yes we are! But will we be allowed to - that's the question.

 

4 hours ago, Xaser said:

Hi, another mapper here. I don't particularly care if I have to type 1.0 or 8 or 9 or SELECT 64 * JUMP_FACTOR AS JUMP_HEIGHT FROM MAGIC_NUMBERS_TABLE WHERE GAME_NAME = 'DOOM'; I'd just really like for the feature, and UMAPINFO in general, to exist and work across ports in some consistent manner. That is all.

Heh - Doom Database Engine. I like it!

 

 

Wow, a full page of Doom Math 101 - God help us. I can tell that building this spec is going to be a lot of fun.

Share this post


Link to post
1 minute ago, kb1 said:

Yes we are! But will we be allowed to - that's the question.

I haven't seen anyone saying we can't, really. Just use Gez's implementation, have the spec say "0 is default (no jumping), use 8 to match ZDoom/Strife's jump height, use 9 to match Boom/Crispy Doom/Hexen's jump height", and we won't have to argue about defaults in here any further.

 

My only concern is if there's a way to define a jump strength once, early in the file, and have it apply to all the maps thereafter, akin to ZMAPINFO's "defaultmap" option. UMAPINFO, at present, doesn't have this, to my understanding. Otherwise you'll be defining this for every single map, and not be able to jump if you mistakenly forget it somewhere. (That said, not being able to jump is a better error case than being able to jump at a subtly different height than expected, as it would be much quicker to identify what went wrong.)

Share this post


Link to post
3 hours ago, Shadow Hog said:

I haven't seen anyone saying we can't, really. Just use Gez's implementation, have the spec say "0 is default (no jumping), use 8 to match ZDoom/Strife's jump height, use 9 to match Boom/Crispy Doom/Hexen's jump height", and we won't have to argue about defaults in here any further.

 

My only concern is if there's a way to define a jump strength once, early in the file, and have it apply to all the maps thereafter, akin to ZMAPINFO's "defaultmap" option. UMAPINFO, at present, doesn't have this, to my understanding. Otherwise you'll be defining this for every single map, and not be able to jump if you mistakenly forget it somewhere. (That said, not being able to jump is a better error case than being able to jump at a subtly different height than expected, as it would be much quicker to identify what went wrong.)

Check out the reply count (heh heh):

Replies.jpg.cc4355e8bc875b9fbe0f230ba4781e54.jpg

 

It's a good point about having to apply an option, like 'jump_strength' (or whatever) for each map via UMAPINFO, and it highlights a greater point:

In a super-moddable, fully-featured hypothetical port, a setting like "jump_strength" has various scopes:

  • jump_strength, modified via a script, during a game: map scope
  • the jump_strength setting in UMAPINFO: also map scope
  • some as-yet-indetermined lump "UGLOBAL" that sets the default jump_strength level for all maps: whole game scope
  • A user setting, applied when no jump_strength setting can be found in the U* lumps: whole game scope
  • A hard-coded per-port default jump_strength, when no other option exists: port scope

Now, I am not suggesting that this needs to be done, especially for jump_strength. But I agree that, in every enhanced port, defaults should kick in when settings are not explicitly set in, say, a UMAPINFO entry. I believe that the spec should describe and provide mechanisms for handling such situations in a compatible way.

 

Care must be taken to avoid over-engineering a solution. But some real thought must be given to this situation.  Because if we do nothing, compatibility issues will arise. You start getting bug reports: "When I play this megawad in port A, map01 plays ok, but, in map 02 I cannot jump to grab the red key. But, in port B, it works fine."

 

The map author should have mechanisms in place to make the maps play as advertised, and, with UMAPINFO, those mechanisms will exist. But, if the map author forgets to set, say, jump_strength, in map 02, worrying about how we handle that is actually important. If nothing else, all ports might choose their own default jump_height in this situation, which would cause a discrepancy, but should we worry about it? After all, the map author did not fill out UMAPINFO properly.

 

I mean, you could provide a place for the map author to supply a global jump_strength, to be used when the UMAPNIFO parameter is blank. But, what if the map author forgets to do that too?

 

You could make the engine use the setting from the previous map, but what if the user -warps to a map? That doesn't really work.

 

Idea:

I could get behind the idea of having a "UGLOBAL" lump, formatted identically to UMAPINFO lumps. In fact, your port's Port.wad file could have a UGLOBAL lump that contains all the defaults for Doom/Doom II/TNT/Plutonia. A custom wad could supply its own UGLOBAL which would be used instead of the Port.wad UGLOBAL lump.

 

Loading a map would follow this logic:

1. Read the UGLOBAL lump, and fill in the port's internal mapinfo structure with the standard defaults.

2. Read the map's UMAPINFO lump (if it exists), and overwrite fields in the mapinfo structure (previously filled in in the above step) as they are encountered.

 

This would allow a single function to handle hard-coded engine mapinfo default settings, PWAD-specific default mapinfo settings, and PWAD-map-specific settings. One function does it all. And, if different ports want to have slightly different default settings, they simply supply a different UGLOBAL lump in their port.wad file. This is a simple solution that provides mappers access to all settings, while also allowing them to omit repeated values in their UMAPINFO files. It doesn't really allow for a user-controllable jump_strength config file setting, but do we really want to supply such a setting anyway?

 

Comments?

 

 

Replies.jpg

Edited by kb1

Share this post


Link to post

Wait, what? Velocity of 8 is 36 peak height? I thought it was 32. (IIRC, velocity squared / 2)

Share this post


Link to post
6 hours ago, Shadow Hog said:

My only concern is if there's a way to define a jump strength once, early in the file, and have it apply to all the maps thereafter, akin to ZMAPINFO's "defaultmap" option. UMAPINFO, at present, doesn't have this, to my understanding. Otherwise you'll be defining this for every single map, and not be able to jump if you mistakenly forget it somewhere. (That said, not being able to jump is a better error case than being able to jump at a subtly different height than expected, as it would be much quicker to identify what went wrong.)

Good point. Yes, it would make sense to have a default record all following maps will get initialized with.

 

1 person likes this

Share this post


Link to post
3 hours ago, Blastfrog said:

Wait, what? Velocity of 8 is 36 peak height? I thought it was 32. (IIRC, velocity squared / 2)

That is the answer under the physics of the real world, where gravitational acceleration is applied in discrete lumps so small that on a classical scale the behaviour is apparently continuous.

 

Under the overtly discontinuous physics of the Doom world, where gravitational acceleration is applied in discrete lumps 35 times per second, you get a different answer that has been explained in-thread. Discrete approximations to continuous functions will always tend to contain systematic errors.

Share this post


Link to post
3 hours ago, Blastfrog said:

Wait, what? Velocity of 8 is 36 peak height? I thought it was 32. (IIRC, velocity squared / 2)

Doom physics, yo.

 

Velocity of 8 means you climb 8 in the first tic. Gravity strikes and reduces your velocity by 1.

So you climb 7 in the second tic. Gravity strikes again and reduces your velocity by 1 again.

So you climb 6 in the third tic. Gravity strikes again and reduces your velocity by 1 again.

So you climb 5 in the fourth tic. Gravity strikes again and reduces your velocity by 1 again.

So you climb 4 in the fifth tic. Gravity strikes again and reduces your velocity by 1 again.

So you climb 3 in the sixth tic. Gravity strikes again and reduces your velocity by 1 again.

So you climb 2 in the seventh tic. Gravity strikes again and reduces your velocity by 1 again.

So you climb 1 in the eighth tic. Gravity strikes again and reduces your velocity by 1 again.

So you climb 0 in the ninth tic. Gravity strikes again and reduces your velocity by 2 this time because Doom physics.

So you fall 2 in the tenth tic. Gravity strikes again and reduces your velocity by 1 again.

So you fall 3 in the eleventh tic. And so on.

 

Anyway, given that your apex is 8+7+6+5+4+3+2+1, if you don't want to do all the additions, it can be computed as (initial velocity) * (initial velocity +1) / 2. And that's 36. Which is why I linked to triangular numbers, because the sequence of triangular numbers is precisely that.

Share this post


Link to post

In that case, the ZDoom wiki is flat out wrong. I know how gravity works mechanically in Doom (and really it's the same method a lot of old games use), but I had never bothered to do the calculations as I just took the ZD wiki's word for it and didn't give it a second thought.

Share this post


Link to post

It was an approximation that kinda works, I mean n*n/2 isn't very far from n*(n+1)/2. (It's just n/2 away, really.) But I've fixed it and added the important bit about MaxStepHeight kicking in.

Share this post


Link to post
18 hours ago, Graf Zahl said:

Good point. Yes, it would make sense to have a default record all following maps will get initialized with.

 

Ok, if there's no opposition, I'll write it up that way.

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