Maximum Map Dimensions

Hitscans don't use P_CheckPosition. The problem is most likely in Trace.cpp as I already mentioned.

Seems that you need the P_PathTrasverse fixes in place too, see post above. This reminds me of when I researched the problem, and how many trials & errors I did before finally solving it. I'm surprised you have to go through the same pains with the code already there, though :-/

Edit: remember, hitscan attacks go through PathTrasverse before being "launched", and certain calculations require greater-than-32-bit precision in order to produce 9-bit unsigned blockmap indexes (instead of signed -256...255 ones). Again, something already detailed in great lengths in that other thread.

Maes said:

I'm surprised you have to go through the same pains with the code already there, though :-/

The ZDoom codebase has changed a lot. For example, P_PathTraverse()? Doesn't exist anymore. It's replaced by an FPathTraverse class and, for hitscans, by FTraceInfo::TraceTraverse().

There's also a lot of other changes (such as for slope physics and 3D floor support). That makes it harder to just copy changes.

Edit: found a place in FTraceInfo::TraceTraverse() where it overflows in Memorial -- but it doesn't in test272, and addressing the overflow doesn't fix the bug.

jute said:

Perhaps the problem is something else then. My map is smaller than these max dimensions and I've added some extra vertexes to subdivide the lines, but I'm using the line horizon effect and still getting idclip-style visual glitching. Is there some limit to ZDoom's line horizon feature?

Any ideas about this?

Try centering the map around the origin (0, 0). Your map might be within the width/height limits, but one side of the map might be trailing out too far.

Line_Horizon, as far as I know is just a rendering effect (like flat bleeding caused by missing textures) and should have no bearing on collision detection. Remove the special from the lines and you'll still have the same problem.

That helped. Thanks!

To further the other discussion, I agree that it would be nice if ports would support larger maps. When I drew out a sector of maximum size on the map I was kind of underwhelmed.

jute said:

I agree that it would be nice if ports would support larger maps.

Without the recently discovered blockmap hack, it was impossible to fully use even use the "standard" map limits allowed by the -32K~32K coord space, and AFAIK only Mochadoom and prBoom+ (so far) have that it in place. Maybe (hopefully?) it will become the standard for "vanilla-like" and "boom-like" ports in the future, who knows. Its advantage is that it's easy to apply to codebases not too divergent from vanilla/boom, so even Chocolate Doom could adopt it.

But even with that hack in place, the maximum blockmap size is "only" 512 x 512 blocks. To truly go beyond that, you'd need much more radical changes, starting from the map format on-disk: you'd need a map format able to store coords > -/+ 32K units, and a port that is not bound to 16.16 arithmetic, at least for map stuff. As of current, only Eternity kind of does the latter (uses floating point arithmetic for almost everything), but still there are no "super maps" it could load, and the only map format that could support them is UDMF.

Maes said:

As of current, only Eternity kind of does the latter (uses floating point arithmetic for almost everything), but still there are no "super maps" it could load, and the only map format that could support them is UDMF.

Eternity only uses floats in the renderer. The playsim is still bound by the limitations of fixed point.

Also I am curious if this blockmap fix being discussed can be adapted to Eternity. I have missed a lot of this discussion and therefore I really don't know what is going on or what I should change to implement it.

Maes said:

starting from the map format on-disk: you'd need a map format able to store coords > -/+ 32K units, and a port that is not bound to 16.16 arithmetic, at least for map stuff.

UDMF will work perfectly fine for that.

Maes said:

As of current, only Eternity kind of does the latter (uses floating point arithmetic for almost everything), but still there are no "super maps" it could load, and the only map format that could support them is UDMF.

You have to be very, very careful with this. If you aren't aware of the many implicit underflows the engine depends on you'll get the most strangest things you can imagine because certain values never become 0. So a switch to floating point has to be planned very, very carefully.

The last time Randy tried for ZDoom it ultimately failed because he didn't consider may implications of the changes he made (replacing Doom's broken 2.5D arithmetics with true 3D, for example) and he tried to do it all at once. The code was quickly forgotten even though he worked on it for roughly half a year (half a year without any serious testing at all!) and it never saw an official release.

Quasar said:

Eternity only uses floats in the renderer. The playsim is still bound by the limitations of fixed point.

You'd have to completely sacrifice demo compatibility with vanilla and Boom otherwise. Either that or keep two different playsim codebases, one fixed point and the other floating point; which isn't an attractive thing to do from a maintenance point of view.

Quasar said:

Also I am curious if this blockmap fix being discussed can be adapted to Eternity.

I'd think so, given that it's been adapted to Mocha, PrBoom+ and to ZDoom.

This might get shot down for dumbness, but how about using 64-bit fixed point and not (64-bit) double precision floating point, to avoid the fuzzy nature of floating point?

EDIT:

Graf Zahl said:

You have to be very, very careful with this. If you aren't aware of the many implicit underflows the engine depends on you'll get the most strangest things you can imagine because certain values never become 0. So a switch to floating point has to be planned very, very carefully.

How about using a class with a set of overloaded comparison operators that allow a tolerance? "Equal to x" will actually mean "Between x - eps and x + eps".

In Doomsday 1.9.7 maps are not limited to this range. Doomsday uses floating point coordinates throughout (will be 64bit come 1.9.8) and the blockmaps have all been replaced with integer "block coordinate space" quadtrees (in other words our blockmaps support maps far larger than the map coordinate space can define).

Obviously this approach is not immediately suitable for any port that wishes to retain demo support. Such ports would need to massage the values in the appropriate places with range clamps, epsilons etc.

printz said:

This might get shot down for dumbness, but how about using 64-bit fixed point and not (64-bit) double precision floating point, to avoid the fuzzy nature of floating point?

On 32 bit systems this will cause a significant performance hit and really isn't worth the consequences. How many maps are there that exceed reasonable boundaries? I'd rather invest my resources elsewhere where I can make them count.

DaniJ said:

In Doomsday 1.9.7 maps are not limited to this range. Doomsday uses floating point coordinates throughout (will be 64bit come 1.9.8) and the blockmaps have all been replaced with integer "block coordinate space" quadtrees (in other words our blockmaps support maps far larger than the map coordinate space can define).

Interesting. Will there be a map format for Doomsday that lets you use large coordinate values?

printz said:

Interesting. Will there be a map format for Doomsday that lets you use large coordinate values?

Yes, UDMF in fact. 1.9.7's BSP Builder already supports the UDMF vertex spec and post 1.9.8 I intend to implement a UDMF map converter plugin.

boris said:

DB2 doesn't show the grid and doesn't allow you do draw outside the possible map boundaries. That can be changed through the config files, though, if ports ever start to support bigger maps.

The Zeth editor for DOS allowed you to draw with pixel precision right to the edges of the 32768 square, that was useful for making a corridor that was 32768 units long, making it infinite. That is what I miss about using that editor.