Isometric grid movement and grid based collision

[dwmitch]

After weighing the pros and cons of grid movement, I have decided to utilize it, as I don't have the time to perfect the collision detection with a non grid system. However, I have run into a few problems.

1) When I try to get the character to move in a direction other than the cardinal direction (relative from the end user's perspective) it won't snap to the grid. When you press right to get the character to move at a 315 degree angle he will keep moving.

I have an object that prints out the coordinates of the player, and when he starts moving it's always a float. It never displays an integer.

2) Using the cardinal directions (north, south, east, and west) I'm having trouble with collisions. I've given the player a mask and set the collision event with the box to set the speed to 0, but then it goes off the grid. I then set it to snap to the grid, but that causes him to bounce back on a 16 x 16 grid, and he gets stuck on a 32 x 32 grid.

I've tried doing a check to make sure that the next grid space is free, but it does absolutely nothing.

[IsmAvatar]

well, for starts, don't rely on the Room Editor's iso grid to do most of your iso work for you. All it really does is give you a different perspective on placing objects in the room editor.

Of course, your probably knew that already, and my iso-inexperience isn't helping you much.

make sure the walls are solid. When in doubt, Check Resource Names (under the scripts tab).

That's my 2 cents (that's all it's worth when it comes to me and ISO)

[dwmitch]

I'm aware of the limitations of the isometric grid in the editor, but I'm still lacking a way to keep the movement restricted to whole numbers.

On the overhead file (i.e. Final Fantasy view) I'm messing around with, I'm still having collision problems. I can get it to work if I abandon my desire to achieve the illusion of depth, but that would alter game play, since there will be items, enemies, and doors hidden behind walls.

[IsmAvatar]

It depends on what code you're using to move. If you use direction and speed, it's gonna be a float, because sine and cosine tend to do that to you. I suggest you try to just use setting x and y relative. Or you play around with the game speed and set his speed out to a number that will make him have an integer number.
Then again, you can always just round his coordinates off, if you must.

[dwmitch]

I've given up on the isometric, but I've solved the collision problem.

I shall explain my mistake, but I would like to point out that it was an example from IsmAvatar that alerted me to the problem.

The box I was using for collision tests was rendered in Blender, along with the sprite I was using as the mask. Consequently, the bounding box of the player mask wasn't colliding with the bounding box of the box's mask until it had already left the grid. Since the player object can only react to a key event when it's on the grid, the object was stuck. Also, I was using a single line for the player mask.

The remedy was to make my own mask for the box to fill the grid space(s), and then adjust the offsets of the box and mask accordingly.

The next step was to give the player a mask of equal size to the grid spacing (was 32, had to drop it to 16 to allow for the tileset) and set as the offset the inverse of the mask height (for example, -32 for a 32 pixel high mask).