Map Crashing
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
- Quantum_Dranger
- Posts: 18
- Joined: Fri Jul 22, 2016 10:29 am
Map Crashing
http://www.mediafire.com/file/pzf1u4xge ... plane2.wad
Hey,
When I try to run this in gzdoom, it crashes on start. Could someone let me know what is wrong and how to fix it? I have a feeling it might be the nodes but I'm not sure and I don't know how I would fix that.
Hey,
When I try to run this in gzdoom, it crashes on start. Could someone let me know what is wrong and how to fix it? I have a feeling it might be the nodes but I'm not sure and I don't know how I would fix that.
- Kappes Buur
-
- Posts: 4120
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: Map Crashing
Your map is too large,
To build your map in the corner of the editable area is not advisable, build from the center outwards.
Spoiler:scale it down to perhaps 95% or smaller in both directions, x and y.
Spoiler:Tip:
To build your map in the corner of the editable area is not advisable, build from the center outwards.
Re: Map Crashing
It's an overflow in internal node builder indeed. However GZDoom shouldn't crash in such case.
The topic needs to be moved to Bugs subforum. The given map can be loaded in PrBoom+ by the way.
The topic needs to be moved to Bugs subforum. The given map can be loaded in PrBoom+ by the way.
Re: Map Crashing
This can be accomplished by reporting the leading post of the topic in question. The "other" reason allows you to communicate any message to the moderator handling the report - be it positive or negative or neither._mental_ wrote:The topic needs to be moved to Bugs subforum.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Map Crashing
I don't think this can be fixed without an entire rewrite of the node builder to use higher precision values.
The map is built right to the negative edge of the coordinate space and the fixed point math cannot deal with that because it got no headroom left to work with - and somehow those -32768 x-coordinates end up as a value on the other edge of the value spectrum.
The map is built right to the negative edge of the coordinate space and the fixed point math cannot deal with that because it got no headroom left to work with - and somehow those -32768 x-coordinates end up as a value on the other edge of the value spectrum.
Re: Map Crashing
IMHO the current limits are enough to create virtually any imaginable map.
At the same time it will be nice to add some checks to prevent this crash.
The question is what are those min/max coordinates exactly?
At the same time it will be nice to add some checks to prevent this crash.
The question is what are those min/max coordinates exactly?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Map Crashing
What happened here is that the map put a vertex right on the outermost edge of the coordinate system at -32768. This caused problems because there is no more room for adding a safety margin. The node builder is trying to do that and overflows.
With -32767 the thing should still work.
With -32767 the thing should still work.
Re: Map Crashing
Even if the map will be fixed to do not use edge case coordinates by replacing -32768 with -32767, it's still trigger assertion failure here.
FVertexMap::BlocksTall is 133 ans so BlocksTall * BLOCK_SIZE - 1 is below zero leading to negative MaxY.
Nodes seem to be build correctly with that assertion removed. Should BlocksWide / BlocksTall be limited to 128?
FVertexMap::BlocksTall is 133 ans so BlocksTall * BLOCK_SIZE - 1 is below zero leading to negative MaxY.
Nodes seem to be build correctly with that assertion removed. Should BlocksWide / BlocksTall be limited to 128?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Map Crashing
I'd just rewrite the VertexMap to use 48.16 fixed point numbers instead to get rid of the overflows. I think any other approach may compromise robustness.
Re: Map Crashing
I was thinking about the same, just without the exact precision for fixed point numbers. I will try with 48.16 which seems reasonable.
Re: Map Crashing
Pull request. The given map works fine out of the box.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Map Crashing
What's the point of this:
In the end it just throws away the added bits without ever making use of them. Is there any reason this is in 64 bit?
Code: Select all
+ fixed64_t vx = Vertices[seg->v1].x;
+ fixed64_t vy = Vertices[seg->v1].y;
+ vx += fixed64_t(frac * double(Vertices[seg->v2].x - vx));
+ vy += fixed64_t(frac * double(Vertices[seg->v2].y - vy));
+ newvert.x = fixed_t(vx);
+ newvert.y = fixed_t(vy);
Re: Map Crashing
Yes, because with 32-bit fixed_t values are silently overflow/wrap. This was the cause of assertion failures.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Map Crashing
I think for that it would have been sufficient to change the 'double' cast to only cover the first part of the subtraction that's currently being performed as integer. Once the subtraction is done in floating point such overflows should be gone.
Re: Map Crashing
Yes, this works too. I force pushed the change.