prgmTEST
.TEST2
0->X->Y
Repeat getkey(15)
getkey(1)?Y++
getkey(2)?X--
getkey(3)?X++
getkey(4)?Y--
ClrDraw
Pt-On(X,Y,[FFFFFFFFFFFFFFFF
Dispgraph
End
356 bytes
EDIT:Nvm. 358 bytes
EDIT2: Can this be optimized at all?

Here's a small optimization (355 bytes):
prgmTEST
.TEST2
0->X->Y
While 1
getkey(1)?Y++
getkey(2)?X--
getkey(3)?X++
getkey(4)?Y--
ClrDraw
Pt-On(X,Y,[FFFFFFFFFFFFFFFF
Dispgraph
End!If getKey(15)

Fixed

what is that and and r for?

Here's the best I could do while fitting the exact constraints. It's 321 bytes, so it's 19 bytes smaller than the previous best attempt (by calc84maniac) and 37 bytes smaller than the original. Compile for no shell with Axe 1.0.5.
Data(0ʳ)→°XPos
Data(0ʳ)→°YPos

While 1
  DispGraphClrDraw
  Pt-On(getKey(3)-getKey(2)+XPos→XPos,getKey(1)-getKey(4)+YPos→YPos,[FFFFFFFFFFFFFFFF])
EndIf getKey(15)

Return


The next block of code starts to stray from the original constraints a bit. It still draws the same sprite and it wraps at the boundaries, but it completely abandons regular sprite drawing to a buffer and then updating the screen in favor of using Bitmap() for a large size savings by completely removing the need for two routines. It also wraps much faster because frames when the sprite is offscreen are substantially faster. It's so much faster that the wrapping almost looks instantaneous, but it's not, so it technically wraps correctly. It's 183 bytes, for a massive savings of 138 bytes over my previous solution and nearly half the size of the original code! Again, compile for no shell with Axe 1.0.5.
Data(⁻1ʳ)→°XPos
Data(⁻1ʳ)→°YPos

ClrHome

While 1
  If getKey(3)-getKey(2)+XPos→XPos+9^ᴇ100<105
    If getKey(1)-getKey(4)+YPos→YPos+9^ᴇ100<73
      Bitmap(XPos,YPos,[0A0A00007F807F807F807F807F807F807F807F800000])
      FnOff    .Sneaky optimized way to disable the run indicator
    End
  End
EndIf getKey(15)

Return


Finally, the most optimized solution I was able to produce. This bends the rules in the same way as the last block of code, but it also stops the sprite at the edges of the screen instead of letting it wrap. Somewhat surprisingly, restricting the sprite's movement actually made the code smaller (due to lack of otherwise necessary clipping). This may be considered breaking the original challenge, or it may be considered adding a useful feature for free. It's 177 bytes, 6 bytes smaller than the previous solution and slightly less than half the size of the original code! Compile for no shell with Axe 1.0.5.
Data(1ʳ)→°XPos
Data(1ʳ)→°YPos

ClrHome

While 1
  Bitmap(min(getKey(3)-getKey(2)+XPos(Bump()),89)→XPos-2,min(getKey(1)-getKey(4)+YPos(Bump()),57)→YPos-2,[0A0A00007F807F807F807F807F807F807F807F800000])
  FnOff    .Sneaky optimized way to disable the run indicator
EndIf getKey(15)

Lbl Bump
ReturnIf
Return +1


How about a line clipping routine?
.CLIPPER
40→X→Y
48→S
32→T
Repeat getKey(15)
X+getKey(3)-(getKey(2))→X→N
Y+getKey(1)-(getKey(4))→Y→O
If N>>95
95→N
(95-S)//(N-S)*(O-T)→O
O+T→O
End
If O>>63
63→O
63-T//(O-T)*(N-S)→N
N+48→N
End
If N<<0
-1→N
~S//(N-S)*(O-T)+T→O
.the squiggly ~ is the negative sign
End
If O<<0
-1→O
~T//(O-T)*(N-S)+S→N
End
Line(S,T,N,O)
DispGraphClrDraw
Pause 20
End

Quote from: Runer112 on October 13, 2011, 09:44:10 pm

* Runer112 has arrived on the scene!

<snip Insanity>

This is how the rest of the optimization competitions will generally go

...I think I have been scarred for life:'(
Obviously, I need to look over the docs again...

Before I saw that he'd already arrived, I was gonna ask if there was a rule that Runer112 can't compete or something lol

I vote yes!
On a more serious note, I find it amazing that you can do so many things in Axe equally many ways. That is one of the reasons reading runerfied optimized code is so fun. I have been thinking about larger sprite routines, so I might post later about a 16*16 sprite drawer.