Doom map scale

[Blastfrog]

I feel that 32 units vertically is 4 feet and horizontally is a meter. Several internal documents (Doom Bible, alpha readmes) refer to 8 units vertically being a foot. If taking aspect ratio into account, this would mean that 8 units is approximately 25cm.

[dew]

Hey lady, watch me grow an inch! *aligns vertically with the grid*

[Voros]

^ I don't get it.

[Dragonfly]

Doom Wiki said:

It is difficult to translate the size of a Doom map unit into a real-world unit, since the dimensions of various objects in the game are inconsistent. Very roughly, one could attempt to translate 32 map units as 1 meter (3.28 feet) based on the height of the Doom guy. Due to aspect ratio correction, the width of objects would be 0.75 m (2.4 ft) each 32 units. With this interpretation, the Doom guy would be 1.75 m (5.7 ft) tall and the smaller doors 2.25 m (7.3 ft) tall.

Source

[Koko Ricky]

5' 7'' WITH a helmet and boots seems short.

[40oz]

It seems funny to imagine that an average 24 unit step is a giant vault of three feet, when the standard height of a step is seven and a half inches.

[scifista42]

I like to imagine 1 map unit as vertically 3 cm and horizontally 2 cm - roughly 0.1 foot and 0.066 foot, respectively. That's only in the context of measuring dimensions of map structures, though - not dimensions of textures. I better don't think about the width-to-height ratio of textures in this way, because obviously square-shaped textures (those with 64x64 or 128x128 etc. dimensions) would become non-square then, and I prefer seeing them as square. I admit, this way of thinking leads to some paradoxes when such textures appear in the maps.

[printz]

If you accept 1 metre = 32 map units, then it means that the maximum Doom distance that doesn't overflow is 1 km. Go figure.

[scifista42]

The maximum distance that doesn't overflow is a distance between point [-32768,-32768] to point [32767,32767], which is 92680 map units, which is 2.9 km. If you mean distance along one axis only, it's still 2 km.

[cybermind]

An interesting document from '94

[Maes]

scifista42 said:

The maximum distance that doesn't overflow is a distance between point [-32768,-32768] to point [32767,32767], which is 92680 map units, which is 2.9 km. If you mean distance along one axis only, it's still 2 km.

And even that will require a port with extended blockmap support -plainly, a fix for the 256 x 256 blockmaps limit AND for the PWAD limit of 128 kb for the BLOCKMAP lump.

Edit: typo, blockmap limit is 256x256, not 128x128. Extended is 512x512 (which covers the entire map area).

[VGamingJunkie]

scifista42 said:

The maximum distance that doesn't overflow is a distance between point [-32768,-32768] to point [32767,32767], which is 92680 map units, which is 2.9 km. If you mean distance along one axis only, it's still 2 km.

I guess he meant the distance from the exact center of the map, so 1 km would be the maximum radius.

[scifista42]

Maes said:

And even that will require a port with extended blockmap support -plainly, a fix for the 128x128 blockmaps limit AND for the PWAD limit of 128 kb for the BLOCKMAP lump.

Unless you were willing to have such a blockmap that wouldn't actually cover the entire area between the borderline points. For example, if the map was a giant rectangle on the very borders of possible 16-bit coordinates, the borderline linedefs wouldn't have to be included into the blockmap (I'm under an impression that if the player approached those borders, some glitching would happen anyway). There could still be linedefs somewhere in the middle of the rectangle (all of them within a small-enough area) that would be included into blockmap, though.

[printz]

scifista42 said:

The maximum distance that doesn't overflow is a distance between point [-32768,-32768] to point [32767,32767], which is 92680 map units, which is 2.9 km. If you mean distance along one axis only, it's still 2 km.

Wroooooong. 92680 is greater than 32767. Definitely an overflow.

[scifista42]

OK, I thought this was about (hypothetically-)overflowed vertex coordinates, rather than... What property or function is this even, that stores or returns distances between what thing and what thing as 16-bit numbers?

[Maes]

scifista42 said:

Unless you were willing to have such a blockmap that wouldn't actually cover the entire area between the borderline points.

Even then, you'd have to be limited to 256 blockmap lengths in either direction. Even if you make a very thin horizontal W-E corridor that stretches 257 blockmap lengths, that still would break the blockmap. Even the actual placement of the map's origin may trigger erratic behavior way before reaching the 256 blocks per axis limit. In fact, such a map was what triggered the development of the extended blockmap handling. Gory details here.

As to what happens over distance calculations, hitscan aiming gets broken if the line crosses an "overflow" or "underflow" map block (esp. one that results in a negative index relative to the blockmap's start), and approximate distance calculation in Doom get broken way before 32K (somewhere around 19K, if I recall), and beyond that it kinda wraps around periodically, leading to phenomena like unusually loud sounds, telescratching, etc.

The map elements themselves (vertices, lines etc.) OTOH can support the full -32/32k range.

[Quasar]

Maes said:

Even then, you'd have to be limited to 256 blockmap lengths in either direction. Even if you make a very thin horizontal W-E corridor that stretches 257 blockmap lengths, that still would break the blockmap. Even the actual placement of the map's origin may trigger erratic behavior way before reaching the 256 blocks per axis limit. In fact, such a map was what triggered the development of the extended blockmap handling. Gory details here.

As to what happens over distance calculations, hitscan aiming gets broken if the line crosses an "overflow" or "underflow" map block (esp. one that results in a negative index relative to the blockmap's start), and approximate distance calculation in Doom get broken way before 32K (somewhere around 19K, if I recall), and beyond that it kinda wraps around periodically, leading to phenomena like unusually loud sounds, telescratching, etc.

The map elements themselves (vertices, lines etc.) OTOH can support the full -32/32k range.

Is there somewhere I can find a unified diff of all the changes that were necessary for this in PrBoom+ ? That thread is hardly a substitute.

[Blastfrog]

40oz said:

It seems funny to imagine that an average 24 unit step is a giant vault of three feet, when the standard height of a step is seven and a half inches.

Look no further than the 0.4 readme:

ALPHREAD.ME said:

you can't climb up higher than 3 feet

[BigDickBzzrak]

Doomguy is 56 units tall.
185 cm / 56 units = 3,3 cm/unit.
(for the American folks, 3,3 cm is 1,3 inches.)
24 units = 79,2 cm, seems legit.

Doomguy's height might not be 185 cm, but as the Doomguy is YOU...

[fraggle]

Blastfrog said:

vertically is 4 feet and horizontally is a meter.

_{fraggle was losered for 1 month for this post.}

[Blastfrog]

I don't think collision boxes are the best reference, they're more for governing gameplay than being representative of the actual sizes of things. Doomguy's sprite implies he'd be more like 48 units tall, and we all know the revenant sure as hell isn't really 56 units tall despite his collision box being so.

Look at PLAYA1, it's 56 pixels tall, but sunken by 5 pixels into the ground. If we were to take 5 off the top as well, we're left with 46, very close to 48. The viewheight being 41 means it's at about 5 feet off the ground. A human's eyes are about 6 inches from the top of their head, so that would mean that he's slouching by about 6 inches. It's also not natural to fully extend your back at all times, it's natural to slouch a little, especially when holding a weapon.

[SaladBadger]

not that I actually care about it in most leveling projects, but when I was screwing around with "real" places at one point I found I actually quite liked using 1 MU as one inch (on the xy plane, its 1.2 inches on the z axis of course). Some things are a bit weird, like the marine height (the view point would be 4.1 feet), but it makes the environment feel a bit more sane. at 8mu per foot, a keypad on your average console texture is nearly a foot long. its still kinda huge with this, but not as much. Overall the answer to this particular question is "there is not an answer", as I seriously don't think id was thinking "8mu? that's one foot!" when making the doom graphics

Stairs are still an anomaly. if it wasn't for aspect ratio, an 8mu tall stare would actually fit the standard stair 40oz posted, at least in height. I imagine the "run" would still be elongated though since short stairs tend to look a little weird in doom, but then again, maybe if everything was scaled right it might look okay.

[Doomkid]

The scale in Doom is so inconsistent - depending on what you use as a point of reference you can get all kinds of answers. It's plain to my eyes that 8 units is absolutely nowhere near a foot. If that's the case, Doomguy is barely tall enough to see over a 4-ft countertop, yet his sprite is 56 units, making him 7 feet? No way.. Plus, those UAC boxes are not 8 feet tall.. No way. Doomguy's viewheight is way too short, as if he has eyeballs on his chest. They clearly weren't pedantic (like, at all) about scale when designing the game. I suppose a mapper can be though if they want a headache but there's really no sensible/consistent point of reference.

[VGamingJunkie]

Blastfrog said:

I don't think collision boxes are the best reference, they're more for governing gameplay than being representative of the actual sizes of things. Doomguy's sprite implies he'd be more like 48 units tall, and we all know the revenant sure as hell isn't really 56 units tall despite his collision box being so.

I'm assuming 56 units tall is how tall the Revanant is supposed to be but Doom lacks the ability to scale sprites and they wanted to keep detail.

[Maes]

MetroidJunkie said:

Doom lacks the ability to scale sprites

O_o

Quasar said:

Is there somewhere I can find a unified diff of all the changes that were necessary for this in PrBoom+ ? That thread is hardly a substitute.

That thread is by now 5 years old and that feature is a part of prBoom+ since then (even though it's kinda hidden). I'm hardly the one to ask specifically about what entryway did to his port, but I'd start by looking for commits around the date of that thread, since IIRC the feature made it shortly thereafter into prBoom+.

[Agentbromsnor]

It would be great if we could settle on using the metric scale instead of imperial for measuring units in Doom. It would make drawing comparisons between sprites and other objects easier, since meters are easily divided.

[Maes]

^ ^ Kinda hard when the game was designed by a bunch of Yankees (Texans, no less, can't get more Red-Blooded All-American (TM) than that). If they were Canadians, maybe ;-)

[printz]

scifista42 said:

OK, I thought this was about (hypothetically-)overflowed vertex coordinates, rather than... What property or function is this even, that stores or returns distances between what thing and what thing as 16-bit numbers?

Doom uses 32-bit integers, but they're interpreted as "fixed point", so the integral part will be restricted between -32767.999... and 32767.999...

An example of this "fixed point" system is if you look at Dehacked DEH files: projectile speeds and thing sizes are expressed in some huge numbers which need to be divided by 65536 to obtain the values you know. Multiplying 65536 by 32767 will already get next to the (signed) 32-bit limit.

[scifista42]

I know about fixed point. I was just talking about the (implicit) distance between the 2 most possibly distant points in a map (bounded by the size limit of vertex coordinates), while you were apparently talking about the maximum "distance" value that is (explicitly) expressible in some variable. And in my last post, I've realized that you're not talking about an implicit distance, but an explicitly stored one, and so I've asked you which particular variable that stores "distance" value in the Doom engine did you have in mind, and if it's any important, because I don't know why the Doom engine should be trying to store "distance" between some points in the map in some variable at all.

[Maes]

Due to the fixed point arithmetic, distances greater than 32K units cannot be represented, neither computed nor stored, not even as intermediate results at any point (the only exception are blockmap-based calculations, during which distances greater than 32K units CAN be represented somewhat gracefully, but in order for the results to be interpreted correctly a port with extended blockmap support is needed anyway).

However, for actual distance-based calculations, the P_AproxDistance function, which is used by, among others, sound and hitscan calculations:

//
// P_AproxDistance
// Gives an estimation of distance (not exact)
//

fixed_t
P_AproxDistance
( fixed_t	dx,
  fixed_t	dy )
{
    dx = abs(dx);
    dy = abs(dy);
    if (dx < dy)
	return dx+dy-(dx>>1);
    return dx+dy-(dy>>1);
}

is not only non-Euclidean (therefore grossly inaccurate), but because of the way it's written, it's really easy to overflow. If the sum of the absolute values of both coordinates exceeds 32K, the function has already failed. So if you have two objects separated by dx+dy > 32K, the function will fail miserably (BTW, when called, the caller must perform their own dx and dy calculations, e.g. p2.x-p1.x, p2.y-p2.x). And not only will it fail, it will actually wrap around (making large distances appear shorter, periodically).

Now, in most regular-sized maps, it's rare that a distance calculation between two such widely separated monster/player objects is ever performed, but it's quite common for sound sources towards the player in large maps. This can lead e.g. to hearing distant sound sources as if they were nearer, and it can also lead to telescratching phenomena (players getting melee'd by monsters which are far away in an unreachable sector), but that also requires a fucked up sector configuration, e.g. both the player's and the monsters' sector having the same number.

A fix should be easy, in theory, by allowing more internal precision for internal calculations even without using a fully euclidean distance function, like it was done for blockmap extension.