right! well, then it will become really very tricky I see...

Why would animated tiles be any slower than regular tiles?  Don't you have to display them every frame anyway?

I think this is very difficult to accomplish.  In order to run a program, it must be copied into 959C.  Unfortunately that is where the current program already is, so you would need a 3rd piece of code that would copy the original program back into its original RAM space, copy the second program into 959C, PUSH a piece of its own code onto the stack so that when the program exits, it is able to copy the original program back onto 959C

I think this is handled completely by the BCALL. A copy of the program is inserted at 9D95, and then it is run. When the program returns, the copy is deleted and the program running beforehand should be exactly where it used to be, so the BCALL will return properly.

It should be located directly after the newly executing program in memory (since the memory insertion shifts it over)

I'll definitely check out that bcall.

@Runer
If the sprite is 16x16 (and aligned to an 8x8 grid no clipping), you can actually write your own sprite routine in Axe itself that would be more efficient than drawing 4 8x8 sprites by copying the sprite data to the L6 buffer directly.  I'm pretty sure I've seen someone do that before but I can't recall the thread...  For 8x8 sprite drawing routines though, the speed would not be that significantly increased since the sprites are automatically not shifted when aligned to the grid anyway and clipping is a relitively small portion of the actual time it takes to draw a sprite.  Aligned sprites draw fastest with Pt-Off() whereas unaligned sprites draw fastest with Pt-On() and Pt-Change().

How about an 8*n sprite display routine that would be just like the regular ones but with an extra argument (default is at ?

Ex:
Pt-Off(0,0,Pic1,12) would display the 8*12 sprite pointed to at Pic1 at (0,0).

<From IRC Logs, calc84 talking about the Gameboy's sprite routines...>
<@calc84> all sprites are 8x8
<@calc84> well
<@calc84> unless you select 8x16 mode
<@calc84> in which case two tiles are used per sprite
<@ztrumpet> Why isn't there an 8*16 mode in Axe?
<@calc84> lol
<@ztrumpet> I'm serious
<@ztrumpet> I've wanted that for a while and keep forgetting
<@calc84> I don't know why there isn't an 8xN sprite display in axe
<@ztrumpet> yeah
<@calc84> it's pretty much the standard for asm
<@calc84> and quigibo can make a default height=8
<@calc84> so existing code doesn't have to change
<@calc84> just add an extra height argument to the end
<@calc84> he would only really need to slightly change the clipping code

a feature that I would like is to use the "goto" command as this:
224->X
goto{X}
end

this is much faster as
if X=224
goto 224
end

what does the omnimaga community think about this???