ZDoom

Hi there,

I found some old posts (from 2014) that say that there shouldn't be any two points in the map that are more than 32768 units apart as strange things may happen because of overflows and that it's best to stay within -16384..16384 range or even less as we are talking about distances in 3 dimensions.

Does that information still hold true?
Or because GZDoom now uses floating point math I can use the whole coordinate range (so can safely go up to +/-32768 in either dimension)? Or maybe I can go even further than 32768 in UDMF format?

Asking partly out of curiosity and partly because I'm planning a map with a large outdoor area that uses portals to slice the whole area into multiple layers - I'm not yet sure how big the map will be so I'm just thinking how to lay out these layers and whether I can assume all coordinate space can be used or not.

Thanks

Jacek

jacnowak wrote: ↑Wed Sep 18, 2024 2:58 pmDoes that information still hold true?
Or because GZDoom now uses floating point math I can use the whole coordinate range (so can safely go up to +/-32768 in either dimension)? Or maybe I can go even further than 32768 in UDMF format?

Yes, that should be a thing of the past. There's no practical limit anymore. (Which isn't to say there's no limit at all; floating point values have their own issues with loss of precision as the value gets larger; but you should still have a lot more room to play with than with the 16.16 fixed point values; after all it's a jump from 32 bits of data to 64 bits per coordinate.)

Thank you, that sounds good

A follow-up on this.
I discovered that if you use sector portals, the distance between lower and upper sector must be less than 32768 units, otherwise the map gets completely messed up.
Looks that 16 bit signed integers are used in some portal code instead of floating points.

Test map showing this problem: https://jaceknowak.net/storage/portaltest1.wad
If you load that map in GZDoom it's completely broken (you get a black screen and you can't move).
If you move the sectors a bit closer together (so that the distance between upper and lower sector is smaller than 32768) everything works fine.
Tested in GZDoom 4.12.2.

If you use sector portals to slice your map into multiple layers vertically, that effectively limits the size of each layer which limits the surface of the playable area. Not sure exactly if it's the distance between anchor line that matters or the distance between furthermost points in the geometry - if it's the latter that would limit the surface of a multi-layer map with sector portals to something along the lines of 16k squared, if it's the former, the limit would be 32k squared.

That has nothing to do with the portals, though. If you remove the portal and run the map you'll have the same result.

Yes, you're right @boris, it's not to do with portals.
Interestingly, when you add a sector rougly in the middle between "top" and "bottom" area, the map starts to work again.
I did some digging in the source code and here's what I found:

Even though GZDoom uses floating point for map data and most of the playsim, the nodes still use fixed point values with the range of roughly -32768..32767.

That in itself limits the map coordinates to be within that range (so you definitely can't go further than -32k..+32k even in UDMF as you wouldn't be able to build nodes for such map) but additionally code that GZDoom uses to traverse the BSP tree restrits it even futher.

Offending function is here:
https://github.com/ZDoom/gzdoom/blob/ma ... ity.h#L103

This basically means that you can't have any point in the map that is further away in X axis or Y axis from the split line of the root node or any other node on the path in the tree to the subsector that point is in.

Because line splits can't exist outside of level geometry, in the example map that I attached root node split needs to be either on the top linedef of the bottom sector or on the bottom linedef of the top sector, so if these sectors are further than 32k away, we have an overflow in the function above.

So if the geometry is rougly uniformly distributed across the map, you can probably cover an area that is significantly larger than -16k..16k, at least in one axis (because root node split will be roughly in the middle) but it highly depends on where the nodebuilder decides to place the splits and it's not really easy to tell if the map is bug free. I did some testing with different layouts and sometimes only one or two sectors in the map were broken, so to be on the safe side you need to either do very thorough testing or you need to stay within -16k..16k coordinate range.

If function R_PointOnSide was changed, I think it would be possible to cover whole -32k..32k area so basically 4x bigger maps (unless there is another place in code that does something similar). It may be tricky to not impact performance though. For even bigger maps, node format would need to be changed.

Interestingly Crispy Doom uses a different implementation of R_PointOnSide function and doesn't suffer from that problem - the attached map works fine under Crispy Doom (of course when converted to Doom format and without portals, but you can have two sectors more than 32k away without glitches). Crispy probably has other issues due to gamesim using fixed point though but at least it can traverse the BSP tree without overflows.

So unfortunately as of now, it's still best to stay within -16384..16384 range or "strange things may happen" and the change to floating point didn't have a big impact on the potential are of the map.