Update: in the description you can find a second version of the formula implementation, which requires only 50 bytes instead of 512, spending 12 more clock cycles. It depends on the circumstances: whether you need maximum performance or to save memory. And speaking of performance, you can also avoid subtracting 24 and 50 in the formula and instead do it directly in the coordinates of the contact points.

cool to see how this is done smashed the like

Grazie !!! Molto utile!!!

my only comment on this would be that for such a simple platformer (and such limited memory and cpu power) one contact(check) point would be perfectly enough. To make the game work smoother, the collision reference point needs to be reallocated when the character turns around (so that it always looks like its under the feet in front) In an environment where the movement is more refined, and needs more precision i tend to use 3 points (left, center, right) and depending on the game mechanics, check for the relevant ones to determine whether the character needs to fall, continue to fall or stop. but thats also because i am too lazy to recalculate the positions :D with wall (door) detection i tend to use a more or less acceptable collision box - but here i think the whole sprite would only need maybe 4 points to calculate front, back, feet and head bumps and then act accordingly. Also also: i don't think we need to check constant collisions while we are walking / running - what we need is check into the next move to determine if our next step would land on the filed or not - if it does, then do nothing - if it will fail then trigger a fall sequence. jump also only need to test for collision under the feet while falling (which makes the logic the same thus the code smaller) (falling and finishing off a jump is the same process) And lastly while on the commodore you have to be careful with memory, normally we shouldn't track the video memory - but rather keep an internal status of where a platform is on the screen. (this is a comment for whoever decides to do this on any more modern hardware) for example if you try to do this on a canvas in Javascript (its a good platform to practice these concepts) - reading back from the canvas comes with huge cost on performace - it makes more sense to not to :) On a C64 it has some clear advantage - as the system memory and screen memory is the same from a technical point of view, just on a different address - but all handled by the CPU therefore no performance loss there anyway, good material :)

Why do we need to supply contact points? I thought that they are the result of a collision, and used to confine to sliding and rotation. So your sprite moves 2px per frame max? Then do two game steps. So you detect any stick after one px and just go back a game step .. even at angles. Fast games like Sonic the Hedgehog are more difficult. Good explanation while sprite tile collision doesn’t work. If at least this was limited to mines and spikes .. like char >= $B0 or so Do we need a real z coordinate to jump onto platforms from the front? SuperMario bounces his head.