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.
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.
Statistics: Posted by jacnowak — Tue Oct 01, 2024 12:42 pm