Large EE map. Blockmap overflow?

Hi.

I have build a large UDMF map for the Eternity Engine with some portals and a big open area in the middle of the map.

As i stacked the last portal on top of the map i have got some issues with the farthest away places from point zero.

In these places i can not press switches, Walls behave like noclip is on and enemys are not shootable and i can walk through them.

In Ultimate DOOM Builder i had changed the nodebuilders to see if it changes something. But even the "ZDBSP - Compressed Nodes (UDMF) large maps" nodebuilder does not eliminate the problem.

As far as i understand this seems to be a blockmap overflow.

The Map Data can be seen at the attached screenshot.

 Is there anything i can do except make the map smaller or is there an option in Eternity Engine i do not know to fix this? 

Thanks in advance.

Is it possible that the Eternity Engine could only handle maps that are -16384 to 16384 units tall on x and y axis from point zero?

It seems that when in game i go through that magical 16384 point that walls have no clipping, enemies are not shootable and switches or doors do nothing.

It is definitively the map size. After experimentaly scaling the map down with Ultimate DOOM Builder to a size that does not exceed an absolute 32768 map units on x and y axis, all the errors are gone.

So i have to reorganise my map that it is in a -16384 to +16384 window.

GZDOOM is more tolerant with going over 16384 units from point zero , as i tested the map with it.

It would be fine if Eternity Engine could do this sometime too, because with portals maps could quickly get big.

Make sure the linedefs aren't longer than 16384 units otherwise it will crash your nodesbuilder. I once showed my large GZDoom maps to Graf and he told me that. After dividing to smaller chunks it works with any node builders.

On 7/14/2023 at 11:01 AM, Meerschweinmann said:

It would be fine if Eternity Engine could do this sometime too, because with portals maps could quickly get big.

I wouldn't expect this to happen, as it is a fundamental trait of how the Doom engine works.

The explanation is quite simple. If the map dimension on one axis exceeds 32768 you will get fixed point overflows in distance calculations, i.e. if the distance between two points becomes larger than 32768 it will wrap around to negative values. Actually, you will get distance overflows on diagonals much earlier but these normally do not manifest themselves as outright glitches.

This will affect all engines which use fixed point math. GZDoom can handle it because it uses floats which will not overflow from this.

@Darkcrafter07 fortunately my map has no linedef with a length of 16384 units.

But good to know what a developer says about max linedef length and nodebuilders.

One of my first attempts to hopefully fix the issue even was to cut the big sectors in smaller chunks.

Unfortunately it did not solve the problem with unshootable enemies, noclip walls and unpressable switches. The complete game-physics were not present at points over 16384 map-units.

So i reorganised my map and sorted its parts in an other order. After that i had only horizontaly more than 32768 map units from the farest away points. The rest to become under 32768 map units could be achieved by minimizing the two big open areas horizontaly.

I did not notice it in game really. That was a good solution in my opinion.

Is there a maximum size a sector should have? 2048x2048 units or so?

I had read somewhere that linedefs over 2048 units could mess up the game physics in some situations, and that linedef 0 has to be shorter than that.

@Professor Hastig good to know. I had to learn this lesson hardly, because it took me some evenings to reorganise my map and shrink the big areas.

And the floating point math is an explaination why GZDoom is more tolerant with map sizes that exceed more than 32768 map units.

4 hours ago, Meerschweinmann said:

Is there a maximum size a sector should have? 2048x2048 units or so?

I had read somewhere that linedefs over 2048 units could mess up the game physics in some situations, and that linedef 0 has to be shorter than that.

No, there are no limits on sector size. You have to be careful with linedefs because they are used in fixed point math so shorter linedefs are less likely to cause overflows. Sectors themselves have no 'size' so they cannot affect math all by themselves, aside from causing a node builder to generate bad data.

8 hours ago, Graf Zahl said:

 

No, there are no limits on sector size. You have to be careful with linedefs because they are used in fixed point math so shorter linedefs are less likely to cause overflows. Sectors themselves have no 'size' so they cannot affect math all by themselves, aside from causing a node builder to generate bad data.

 

 

 

Summarized i would say, when i build maps that are made for both portal ports Eternity Engine and GZDoom, they should go from map coordinates -16384 to 16384 and no linedefs longer than 16384. The shorter the linedefs the better. By the way, this would be an extreme long linedef. And sector sizes do not matter as long as the nodebuilder can handle its lindefs without errors. Is that correct?