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

## Recommended Posts

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.

Arctangent likes this

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.

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.

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.

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.

Fonze, Bauul, Doom64hunter and 2 others like this

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.

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.)

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):

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.

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?

Edited by kb1
PaquoCastor likes this

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

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.

Xaser likes this

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.

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.

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.

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.

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.

If you want low-gravity jumping, you should really change the gravity instead.  Otherwise the player does not fall off ledges or fall back down at the related speed.   It would not be low-gravity.

There could be port compatibility settings.

But, for mappers who have to have a certain height jump, it would be simpler to have them specify the jump height needed and let the port take it from there.  There is less looking up port specifics.

I am still 2 pages behind reading this.

By the way, I think I'll be ready to release what I've got on this next week. I am nowhere near where I would like to be, but it's time to get the ideas out there and get some feedback. And, realistically, with my current life situation, if we want to see something come out of this anytime soon, I'm going to need massive help.

jerk-o, PaquoCastor, Urthar and 1 other like this

Jumping discussion:

If a mapper specifies a jump height then it does not matter at all what all the ports have as their defaults.

It does not matter if it matches any of them.

If the mapper does not specify a jump height then the port can use its default.

Jump height should be an integer, related somehow to a height range.

This then can be used to index a table of fixed point impuses to apply as momentum.

Using a table this way makes it easy to tune the jump heights.

Then just share that table with all the port authors.

The mapper does not care about momentum impluses.  They have a ledge at 14 units and want to specify

that the jump can get the player up there.  If the specified number is the actual jump height needed,

then that saves the mapper from having to translate their needed jump height to some arbitrary index.

What I would do in DoomLegacy is to have additional tables for difficulty.  So at EASY, I give them a little more jump height.

2 hours ago, wesleyjohnson said:

Jumping discussion:

It's my hope that, first, we can devise a framework, a "best practices" method that we use over and over, when defining extraneous values and abilities, perhaps using previous implementations as a guide. This type of discussion will occur at lot, and I want to avoid the 10-developers, 10-solutions scenario. With some good research and common sense, making decisions about things like jumping, might get a lot easier. How we discuss implementations is a topic in the current draft, because it's going to become very important.

Briefly, I like the mapper being able to determine what the player can jump on - that seems pretty darn important vs. trial-and-error :)

On 1/12/2018 at 4:18 PM, kb1 said:

By the way, I think I'll be ready to release what I've got on this next week. I am nowhere near where I would like to be, but it's time to get the ideas out there and get some feedback. And, realistically, with my current life situation, if we want to see something come out of this anytime soon, I'm going to need massive help.

Sorry to be pushy, but since it's been well over a week - how's this coming along?

Quasar and jerk-o like this

6 hours ago, Shadow Hog said:

Sorry to be pushy, but since it's been well over a week - how's this coming along?

Honestly, I was hoping no one noticed :(  Health issues, and life in general have been kicking my ass. Getting old is not for pussies! I'm kinda down in the dumps over the whole thing. Like most of my projects, it's very close, but it's that last 10% that kills.

I don't blame anyone for being frustrated, and even starting without me. I have 2 sections to finish. I will resume working on it after work, and hopefully I'll be able to keep up a steady pace. I don't foresee it taking much longer, but I am no longer going to make any promises - that has always gotten me in trouble in the past, and I haven't gotten any better at estimating my time. Admittedly, the real life issues I'm dealing with threw me for a loop. I was not expecting to be having this much trouble getting this thing out. It's not a super huge document, or anything. But finding serious time to do serious work is hit-or-miss.

I sure haven't forgotten about it. It's a daily point of frustration, and a daily reminder of troubles. Sorry about the soap opera. I'm doing my best. Sorry to everyone for the delays. I'm not proud of them. Maybe something good will come out of it. I'll provide progress reports in this thread - I owe that to everyone waiting.

Ah, nah, don't sweat it. Health comes first!

31 minutes ago, Shadow Hog said:

Ah, nah, don't sweat it. Health comes first!

Thanks for saying that, I really appreciate it. But, I am sweating it. I said I was going to do it, and I gave out times, and I dropped the ball. That's just not cool, you know? If anything, that'll help motivate me to press on, so that's what I'll do. I think it'll be worth the wait. With a few good moves, we can make a big difference. I'm still very excited about the possibilities. Thanks for understanding.

jerk-o and Ferk like this

Progress Report: Got about 3 hours of work done on this, after leaving work. I also got some sleep. I've been burning both ends of the candle for a long time, and, it's been difficult to realize the toll that has had on my abilities. Mental exhaustion can be worse than physical exhaustion, I think. I'm going to try to maintain a steady pace without pushing it, from now on, and make sure I get enough rest as well. I feel better today than I have in a long time, so, maybe that's the key.

Bauul, axdoomer, Fonze and 3 others like this

I hope this is not too offtopic, but I've been wondering: how doable would it be to extend BEX in such a way that it can be used as a bridge between Doom and Heretic?

A Doom port wanting to support Heretic might have to add several things that a pure Doom port might not want to add (status bar changes, inventory system, etc), but I was wondering if it would be viable to toggle some of the differences in weapons, states, things, etc. through new BEX extensions (and setting maybe some of gameinfo_t through BEX), so that at the same time it'll improve the BEX standard for further modding possibilities (which is why I was posting in this thread).

Admittedly, I haven't dug that much in source engine code yet, but I was actually considering giving it a go at trying to bring some level of Heretic support to PrBoom libretro core. Doing it while extending BEX seemed like a cleaner way to go. But it would be great to have some feedback first, specially from those interested in extending Boom.

Edited by Ferk
Fonze likes this

The sane thing is to fork a Doom source port and make it support Heretic. But if you want to act insane, sure, extend BEX so you can implement Heretic support (especially the inventory system lol) through it.

Assuming it's not currently possible, how difficult would it be to add support for taller or longer textures? (eg 256 high or 512+ long) so that tiling is less obvious

I think PRBoom+ already supports that.

2 minutes ago, Altazimuth said:

I think PRBoom+ already supports that.

Cool, I'll try and find the specs

Just now, Szymanski said:

Cool, I'll try and find the specs