| 3 | | Coordinates: We swapped the coordinates appropriate to 2D behavior (X is the same as in simulation, Y is the same as Z in simulation) in the rmgen area. This is documented here: [http://trac.wildfiregames.com/wiki/Rmgen_Library#MapCoordinateSystem] and the code that does that is in the file map.js, function `Map.getMapData`, line 330. This was mainly done because height is not supported in rmgen (yet, but not meant to be AFAIK, ask quantumstate) and rotation was done in 3D (X/Z plane: growing angle -> clockwise rotation) not as usual in 2D, which me and quantumstate found confusing (Discussion: http://www.wildfiregames.com/forum/index.php?showtopic=15817). I don't really know why anyone should use Y for the hight though the "action" takes place in the 2D plane then called X/Z (leading to clockwise rotation |
| | 3 | Coordinates: We swapped the coordinates appropriate to 2D behavior (X is the same as in simulation, Y is the same as Z in simulation) in the rmgen area. This is documented here: [http://trac.wildfiregames.com/wiki/Rmgen_Library#MapCoordinateSystem] and the code that does that is in the file map.js, function `Map.getMapData`, line 330. This was mainly done because height is not supported in rmgen (yet, but not meant to be AFAIK, ask quantumstate) and rotation was done in 3D (X/Z plane: growing angle -> clockwise rotation) not as usual in 2D, which me and quantumstate found confusing (Discussion: http://www.wildfiregames.com/forum/index.php?showtopic=15817). I don't really know why anyone should use Y for the hight though the "action" takes place in the 2D plane then called X/Z (leading to clockwise rotation and growing Y means burrow things). It seams to be widely used practice but I don't like it (mainly because I don't like to have 2 positive rotation directions in 2D that differ, clockwise and mathematical right handed positive). |
