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


That looks awesome. However I'm guessing many other people are going to run into the problem I did: it requires library files that most people probably don't have (e.g. QtGui4.dll). If these files are absolutely necessary, why aren't the files or a link to download them included? Because I'm finding downloads that are upwards of 200MB, and that hardly sounds right.

It's only more optimized to use Text(Y*256+X) if the two coordinates are constant.

Why line drawing doesn't have clipping is something that has baffled me and I think many other Axe coders for quite some time. I know of multiple great games just off the top of my head that don't look quite right because lines don't clip if partially offscreen. I know coding the clipping is definitely doable, so that's not the issue. The only issue might be the added size and speed overhead of the clipping. But even if this is a big issue, this could be solved easily enough by keeping the current line command as-is while adding a separate line command that clips and then calls the standard line routine. Either way, I'm sure many Axe programmers would be very happy to see line clipping implemented.

Reverse the order of the height and width bytes.

It should be easy to modify values like that. The map and tiles are your standard fare and should be easy to edit. I think the only important map dimension is width, which can be changed in Lbl TIL (currently 16). The player's/camera's x position (2 bytes) is in X, y (2 bytes) is in Y, Z (1 byte) is in H, and angle of rotation (1 byte) is in Z.

You can store your picture as a bunch of 8x8 sprites, then draw 13x9 of them to the buffer. Like a tilemapper, except without the tile lookup.

Edit:
This reminds me, why doesn't Axe support 8xN sprites yet?

For that matter, why doesn't Axe support m*n sprites yet?

Logical not is =0.