The player can never be *between* two tiles (well, depending on the program of course). In my case the position of the player is the position of the upper-left corner of its image. Now, this point is always on a tile, and never inbetween two tiles; when you move from one tile, you always end up on another tile.
Of course, the image of the player can be in two tiles at the same time (or 4 tiles even) when you are moving near to the border between two tiles. But this is why for collision detection, you have to check the tile you are technically in *and* the adjacent tiles to take overlap into account (the player image could stick out onto an adjacent tile, and likewise, enemies could also be sticking out onto your tile).
I don't know how the 'shifted grid' method works. In general I would think that the trick is to somehow have a link from location (tile) to objects on that location. That way, you check for nearby locations, and through these locations you find the nearby objects. That is what I do using the linked lists. Is 'shifted grid' something similar?
Of course, the image of the player can be in two tiles at the same time (or 4 tiles even) when you are moving near to the border between two tiles. But this is why for collision detection, you have to check the tile you are technically in *and* the adjacent tiles to take overlap into account (the player image could stick out onto an adjacent tile, and likewise, enemies could also be sticking out onto your tile).
I don't know how the 'shifted grid' method works. In general I would think that the trick is to somehow have a link from location (tile) to objects on that location. That way, you check for nearby locations, and through these locations you find the nearby objects. That is what I do using the linked lists. Is 'shifted grid' something similar?