It will not collide perfectly because your sprite will move more than 1 pixel per frame, ex. if your sprite is 1 pixel from the object to collide and your FPS is 60 than, 120*1/60 = 2 pixels, it will move 1 pixel inside the collision object, with lower FPS is even wrost try to put it fixed aroud 15 fps and test, try it on unlimited too and you will see it work perfectly because it will move lower than 1 pixel per frame.
The way i discribed, using loops, will always move the exact pixels before collide with the object.
The "is moving" i mean to be your way to detect this, in your case you have to do "On keyboard: Left button is down", move to left, and so on...
Hehehe, i thought so, i felt dumb thinking there was an "is moving" event that i'd skipped over! anyways that question HAD to be asked <img src="smileys/smiley36.gif" border="0" align="middle" />
anyways, are either fixed or unlimited FPS recommended? i thought v-sync was optimal.
I had tried it on unlimited, and collision-wise it worked great, but i had that sprite tearing almost, that i reference before, like for example, if the sprite is 32x32, it'll show up as that size, but within its own 32x32 bounding box, it'd be moved say to the right, and the left border would be drawn into the X0 and X1 columns, weird.
and i thought fixed FPS was supposed to hinder your TimeDelta
i'm looking forward to implementing a loop as you suggested, it looks like i'll have to clean up the game structure first, in order to replace it neatly hahahaha <img src="smileys/smiley4.gif" border="0" align="middle" />
as for now, while i'm restructuring it, i got around the collision enough to work with it with something like this:
B pick closest to A.left\right\top\bottom
+ if A.left\right\top\bottom >\< B.left\right\top\bottom -\+ speed*TimeDelta
-> then move at speed*TimeDelta
extremely summarized but in essence that's what i got around to enough for it to work until applying loops, if it helps anyone in the future.