I'm asking what's the best way to handle object/player moves and collision in an action-oriented game.
I hesitate between two methods. The first one would be to separe what would be called "main position", only this one will be checked for collision stuff. The segond parameter, the "fine position" is the low bits of the main position and aren't checked at all for all colision stuff. They're only here to animate the sprite proprely, also when the fine position overlaps and so the main one will change, the sprite/object can pass to another frame (so it's arms/legs would move).
The other solution is less innovative, but it would simply check the collision trough two variables, one is position-size and the other one position+size. The position is 8 bit wide and it's the exact one of the middle of the sprite on the screen (I use only one screen at time, like Zelda, no scrooling while the game play is on). This one seems to be simpler, but I think it isn't that good to merge the visual part with the maths part, and also it would need additional counters for any frame/mooves.
One third way to handle that is to use the first one for BG-Sprite collision, and the segond one for sprite-sprite collision.
Also, another problem comes with non-playable objects (i.e. enemies). They have to move on their own, so the programm have to handle both the move of their position and of their actucal graphics. With the first method, I simply have to decide wich direction the enemy walks, run, and maybe jump (I don't know yet how I'll do the AI), and finally apply this change unless the main position reach the exepted value. Trough the segond solution, this would be harder to handle, and I don't want to have something glitchy, typically like Castlevania 2 where you fall into invisible pits and you can grow non-existing stairs during game-play.
Does annyone have comments/ideas/notices/help/tips ? That would be cool.
I hesitate between two methods. The first one would be to separe what would be called "main position", only this one will be checked for collision stuff. The segond parameter, the "fine position" is the low bits of the main position and aren't checked at all for all colision stuff. They're only here to animate the sprite proprely, also when the fine position overlaps and so the main one will change, the sprite/object can pass to another frame (so it's arms/legs would move).
The other solution is less innovative, but it would simply check the collision trough two variables, one is position-size and the other one position+size. The position is 8 bit wide and it's the exact one of the middle of the sprite on the screen (I use only one screen at time, like Zelda, no scrooling while the game play is on). This one seems to be simpler, but I think it isn't that good to merge the visual part with the maths part, and also it would need additional counters for any frame/mooves.
One third way to handle that is to use the first one for BG-Sprite collision, and the segond one for sprite-sprite collision.
Also, another problem comes with non-playable objects (i.e. enemies). They have to move on their own, so the programm have to handle both the move of their position and of their actucal graphics. With the first method, I simply have to decide wich direction the enemy walks, run, and maybe jump (I don't know yet how I'll do the AI), and finally apply this change unless the main position reach the exepted value. Trough the segond solution, this would be harder to handle, and I don't want to have something glitchy, typically like Castlevania 2 where you fall into invisible pits and you can grow non-existing stairs during game-play.
Does annyone have comments/ideas/notices/help/tips ? That would be cool.