I was experimenting with and testing the SDK C API through the Nim bindings I'm developing and I found that
playdate->sprite->moveWithCollisions always sets
actualY starting from the top left corner of the sprite, but the
goalY values you pass to the function refer to the center of the sprite.
So, moving a 32x32 sprite using:
playdate->sprite->moveWithCollisions(sprite, 100, 100, &actualX, &actualY, &length)
without collisions, sets
actualY to 84.
That's not very intuitive, I want the sprite to reach
goalY but the function then says it reached another coordinate.
Furthermore, I didn't find an API to set the center point of a sprite, while there is in Lua.
Is there something I'm missing?
I think what happened here is I didn't originally add x,y and center properties to the low-level sprite objects, just bounding rects, thinking more abstract would be better. Turns out that was a terrible idea! I don't remember now why we added the center parameter to the Lua sprite wrapper and not the underlying C sprites, but that's why there's no C API for it. But I've since moved the center x/y values from the Lua wrapper down to the C struct, so yes, we should add setCenter() and make moveWithCollisions respect that value.
Thank you for pointing this out!
oh, looks like the moveWithCollisions() offset problem isn't just in the C API: playdate.graphics.sprite:checkCollisions(x, y) ignoring self:setCenter(1,1)? Seems like a fix there would break existing behavior though..
Mhh, that is unfortunate.
Seems like breaking existing behaviour would be the "right" thing here...
Sure, not the nicest thing to do since a few games will have to be patched.
But let's also say that the sooner this is addressed, the better.