r6655 | bug in generation of .dist | XS / C++ expert needed
Posted: 26 Jan 2009, 11:56
Diagnostics
Utils::old_makeDistMap generates a usable .dist from the fld2 (edge fix included) so its not fld2 specific. (for the non believers)
To confirm the actual bug i have made a fld2 file with walkable blocks and non walkable blocks swapped as if it were a fld1 file (edge fix not applied).
(walkable block [fld1:0], [fld2:1])
The outcome was exactly the same .dist file as fld1 -> dist, wich is normal.
Tho, when you do a normal fld2 -> dist (with the needed changes in the makeDistMap cases for walkable),
the outcome is different, wich is not normal.
Walkable / non-walkable blocks stay the same. So the dist isn't supposed to change.
Practically
data == 3
(walkable water [fld1:3]) is somehow never true when the rawMap has a 3 on index i.
(this goes for every number but 0)
data == 0
This , unlike the previous, is true when the rawMap has a 0 (walkable block [fld1:0]) on index i.
Cause
Why is only 0 recognized? (and not 1, 2, 3, ...)
Is this because of a mismatch between datatypes?
Could anyone with knowledge of .xs take a look at this?
Because that is the only thing thats stopping us from using the new fld2 format.
The best would be doing a bitwise AND operation on data with 1,
wich will return 0 when the block is not walkable and 1 when it is walkable.
snippet with relevant code (src\auto\XSTools\misc\fastutils.xs):
Utils::old_makeDistMap generates a usable .dist from the fld2 (edge fix included) so its not fld2 specific. (for the non believers)
To confirm the actual bug i have made a fld2 file with walkable blocks and non walkable blocks swapped as if it were a fld1 file (edge fix not applied).
(walkable block [fld1:0], [fld2:1])
The outcome was exactly the same .dist file as fld1 -> dist, wich is normal.
Tho, when you do a normal fld2 -> dist (with the needed changes in the makeDistMap cases for walkable),
the outcome is different, wich is not normal.
Walkable / non-walkable blocks stay the same. So the dist isn't supposed to change.
Practically
data == 3
(walkable water [fld1:3]) is somehow never true when the rawMap has a 3 on index i.
(this goes for every number but 0)
data == 0
This , unlike the previous, is true when the rawMap has a 0 (walkable block [fld1:0]) on index i.
Cause
Why is only 0 recognized? (and not 1, 2, 3, ...)
Is this because of a mismatch between datatypes?
Could anyone with knowledge of .xs take a look at this?
Because that is the only thing thats stopping us from using the new fld2 format.
The best would be doing a bitwise AND operation on data with 1,
wich will return 0 when the block is not walkable and 1 when it is walkable.
snippet with relevant code (src\auto\XSTools\misc\fastutils.xs):
Code: Select all
SV *
makeDistMap(rawMap, width, height)
SV *rawMap
int width
int height
INIT:
STRLEN len;
int i, x, y;
int dist, val;
unsigned char *c_rawMap, *data;
bool done;
CODE:
if (!SvOK (rawMap))
XSRETURN_UNDEF;
c_rawMap = (unsigned char *) SvPV (rawMap, len);
if ((int) len != width * height)
XSRETURN_UNDEF;
/* Simplify the raw map data. Each byte in the raw map data
represents a block on the field, but only some bytes are
interesting to pathfinding. */
New (0, data, len, unsigned char);
Copy (c_rawMap, data, len, unsigned char);
for (i = 0; i < (int) len; i++) {
// 0 is open, 3 is walkable water
switch (data[i]) {
case 0:
case 3:
data[i] = 255;
break;
default:
data[i] = 0;
break;
}
}