What about imag()?

Could that work?

I think Quigibo is already planning to use IS>() and DS<() for increasing and decreasing with a specified "wrap" value

The If counter commands, IIRC. He explained it in a post somewhere but I don't remember in which thread. (Darn this sub-forum is getting big)

Also try to not use too many two byte tokens for commonly used Axe commands, such as ANOVA(

Would LordConiupiter routine work as well too? He posted some weird sprite routines that apparently displays 16x16 sprites, using some _r commands. Which one would be faster and which one would be smaller (in ASM form)?

http://ourl.ca/4129/83923

Ah ok thanks for the info. To me, such routine would most likely be for both tiles and sprites, so having to align it might be an issue if I wanted smooth movement

Ok good ^^


Regarding features, there's something I wonder... would support for 4 bits integers be something very hard to implement? In the cases where people use one byte for two tiles in a tilemap data, for example, maybe it would make it easier for people to work with the data, as they wouldn't need to remember how to write routines to split it.

Also, when Axe final version (or the one where old commands will have almost no more chances of changing) is out, do you think it may be best to split Axe routines into their own sub-forum and put them in a new sub-forum between TI-BASIC routines and ASM routines? As for now, they are getting harder and harder to find through the 1400+ posts in this sub-forum, even if a topic dedicated to them was made, but for now I would wait a bit to do such thing, though, since you said Axe syntax for some commands may change (unless this is not the case anymore?)

Thanks I guess that works too and I didn't knew about the later , I guess it might be a good thing to add to Optimizing Tips.txt.

As for A^16, I assume afterward it may be best to redivide it with A*16/256 (or A/16) afterward, right? I worry about having to use more If/then conditions for sprite/tiles displaying then (since that sprite number would be multiplied by 16 unlike the one initially extracted with

Btw I would also find half bytes much easier to read than full bytes in map data since each tile would be one single character instead of two and as you know I am so used to work with text for sprites, so if I need to do a quick edit without wanting to dig up a tile/map editor, I can simply just edit the data directly easier.

yeah that might be a good idea too, even if it means slower compiling

Yeah, Axe compiles super fast.  I love it.
Also, I would like to be able to retrieve the pointers to a label for normal math.  This could be useful in the Half Life game engine.  For instance:
AB->A
Disp A>Dec   ; Display the address of AB
Return
Lbl AB
Disp "Hello World"