O_o and what is it ?

Then the machine you code is false :p if the coordinate arrive to 65565, the sprite make 63 with your calculs :p

actually, Y+r2 and 63 is correct, cause the pxl-on routine do a ^256 on the Y coordinate.

yep  . So classement change, and I am out (lol I always knew that I am not really good at optimize code for size  )

Oops, forgot this thing was ending! Anyways I guess here's my prize code, coming in at 317 bytes in the memory management menu (309 bytes in Axe compile screen). You could argue that there is one slight glitch, in that the very first frame displayed is whatever was in the main buffer before the program started, but I see that everyone else cut that corner too so nobody got an unfair gain from it.

The source is in the code box below and attached.

.S

ᴇ847A→°SX
ᴇ8481→°SY

FnOff

While 1
DispGraphClrDraw
(Select((getKey(3)+SX+1-getKey(2)??96)-97,PutSprite())?+96)PutSprite()
getKey(1)-getKey(4)+SY→SY
EndIf getKey(15)

Lbl PutSprite
→SX
64
While 1
If pxl-Test(-1→r₁, and 0,[AA55AA55AA55AA55])
Pxl-On(r₁ and 7+SX,r₁*32/256+SY and 63)
End
End!If r₁
Return


/256 is 3 bytes (6C2600) and /2 is 4 bytes (CB3CCB1D if I remember correctly). Do the calculation yourself. And 0 is like /256*256.

/2 is 4 bytes, so dividing by 8 with /2/2/2 would be 4+4+4=12 bytes, whereas *32/256 is 5+3=8 bytes (of course this only works if you can afford to lose the top 5 bits with *32). Dividing by 256 with /2/2/2/2/2/2/2/2 would be pretty wasteful, 4*8=32 bytes versus /256, which is only 3 bytes.

The and 0 is effectively just 0, but one byte smaller because it doesn't set the high byte. I used it because the pixel operations throw out the high byte of coordinates anyways (and as Hayleia pointed out, even if the high byte was used, it would already be 0 because r₁ is between 0 and 63).