Closed DBJ314 closed 5 years ago
I'll try to integrate the LiDAR with the comport so the output of GET_MAP gets written in the 'internal buffer' instead of RAM. I'll also make it so it outputs the number of tiles in the B register.
I think it should use the X and Y registers to give the exact dimensions of the room. 200 tiles could be 200 by 1 or 100 by 2 or 20 by 10 (or any other valid factorization of 200).
the code currently does not allow non-square world sizes, I think it would be wiser to save a register.
At least give the size of one side rather than the total words written. Square roots are not fun to do in assembly.
yes that would be a good option
Might as well do the same thing for GET_PATH.
The LIDAR hardware has 2 big problems with vaults.
The first is that there is no way for a cubot to figure out the size and type of the world one is in. This makes it hard to have effective pathfinding algorithms.
The second problem is best explained with this code:
It counts to 10, and then will call LIDAR_GET_MAP once every tick while continuing to count. At least, that is what it does if you run it in the main world. In a vault, it counts to 10 normally and then stops doing anything at all.
The LIDAR hardware was designed for a 16 by 16 world. It writes 1 word for each block in the world. This is 0x100 words in a 16 by 16 world. A vault is 20 by 20, so it ends up writing 0x190 words if called in the vault.
The map is written at 0x100. In a 16 by 16 world it writes 0x100 words, so the last value written is at 0x1FF. In a vault, the last word written is at 0x290. This is 144 words into the stored program space, and the IP starts at 0x200 each tick.
The start of the program is overwritten with random garbage when LIDAR_GET_MAP is used on a map larger than 16 by 16. Vaults are 20 by 20, so it is unsafe to use that function in a vault.