r6655 | bug in generation of .dist | XS / C++ expert needed

Forum closed. All further discussion to be discussed at https://github.com/OpenKore/

Moderators: Moderators, Developers

Super Moderators
Super Moderators
Posts: 801
Joined: 06 May 2008, 12:47
Noob?: No

r6655 | bug in generation of .dist | XS / C++ expert needed

#1 Post by Technology »

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.

data[i] == 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[i] == 0
This , unlike the previous, is true when the rawMap has a 0 (walkable block [fld1:0]) on index i.

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[i] 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
   STRLEN len;
   int i, x, y;
   int dist, val;
   unsigned char *c_rawMap, *data;
   bool done;
   if (!SvOK (rawMap))

   c_rawMap = (unsigned char *) SvPV (rawMap, len);
   if ((int) len != width * height)

   /* 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;
         data[i] = 0;
Last edited by Technology on 29 Jan 2009, 07:28, edited 1 time in total.
One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...

Mount Doom awaits us, fellowship of OpenKore!

OpenKore Monk
OpenKore Monk
Posts: 474
Joined: 04 Apr 2008, 10:10

Re: r6655 | bug in generation of .dist

#2 Post by kali »

Our .xs is just C++ (or was it C) that have perl bindings. You can treat it just like any other C/C++ code.

I'll look into that a bit later.
Got your topic trashed by a mod?

Trashing topics is one click, and moving a topic to its proper forum is a lot harder. You expend the least effort in deciding where to post, mods expend the least effort by trashing.

Have a nice day.