What about more graphing commands?

A filled circle or an outline box?
And using Fix5, you can define the buffer the text is drawn to.

For an outline box there is already IRect (combine two of these, one to the outer size and one to the inner size centered in the first).
Or if you need speed, HLine/VLine

Oh that sounds cool. Don't forget rounded corners then.

Slight necropost:

Will Axe ever be updated? Or at least some more axioms be released, particularly for tilemapping, especially scrolling maps?

The last update was on 2013-10-25 and I'm sure when there are some other big bugs out there Runer112 will update it again. Axioms are meant to be released by third parties for the most part. So release of Axioms would depend on people actually making one.

Like when defining a static pointer you say on which page it is

* Sorunome prods multi-page app support

Like when defining a static pointer you say on which page it is

As I've said in the past, multi-page apps would require a lot of internal redesign. Although it would be a very worthwhile feature, I dread the idea of trying to force that capability into Axe in its current state; it would be more trouble than it's worth. That's why this is a feature I've deferred to the hypothetical Axe 2.0.

If you really want to get crazy, it would be possible to build some system which appends the data onto the end of Axe-compiled applications computer-side. If you can assure that no data crosses a page boundary, you can then hackily read/copy it with files.

Yeah at least for data multi page apps would be awesome.
Just make it so that we can add a new page with a token and all the data following will be on that page. And a function to swap the first memory bank of course.

Although Axe is pretty low level, I don't want it to be so low level as to making users manually swap memory banks to access data in multi-page applications. So I don't think I'd add such a command to native Axe. There's also still the problem of simply generating the multi-page application in the first place, which Axe's internals really can't handle.

Hi ! I've been using Axe for one year now (since version 1.0.0), and I love it !
It's way much faster than TI-Basic, and it's even easier to use ! Thanks for making Axe Parser !
I have some little ideas to improve it... Here's my contribution !


First of all, Axe Parser should check if there's any backup kept in RAM and either 1] show it in the "Compile" list or 2] ask to archive it. Because one day, just after compiling, it asked me for "Garbage Collect" like it does sometimes, and I answered "no" by mistake. I then thought my source was lost, because the source program was removed and its backup wasn't shown in the compile list (as it wasn't archived). I spent one hour to write the full source code again from memory, beause I didn't know the backup was kept in RAM !


I have an idea to improve the drawing functions... I think that games made with Axe Parser are sometimes slow, especially when they use grayscale graphics on a TI-83+, without the "Full" mode. So why not adding new drawing functions like "Pt-On(", "Pt-Off(", etc. but wich draws sprites only on full bytes of the buffer, each 8 pixels, for 0<=X<=11 ? These functions could be accessed by adding a letter to the other drawing functions' name, "C" for example (stands for "column" and "clipped"), and could be named "CPt-On(", "CPt-Off(", "CPt-Change(", "CPt-Mask(", "CPt-Get("... Also, you could add "CHorizontal +/-" and "CVertical +/-" to move the screen by 8 pixels. I wrote all these drawing functions in assembly if you want (although they may not be fully optimised).


And to improve the datas, I think it could be great if we were able to make datas with binary values. To differentiate them with hexadecimal values, you could add the prefix "pi" to the data, like "pi[0101101010011001]->GDB1".


I imagined others features and functions, but they will be much more complicated to do...

This is already possible with Data(pi00101001,pi11010011)→GDB1

Indeed, that's right, I didn't think of it... Thanks !

I am not really convinced that the slowness only comes from the drawing commands. Or more, I am not convinced that changing them to be more specific would improve the speed that much. Watch for example Robbox running, I don't think it is that slow even though it uses 4 lvl greyscale, and runs at 6 MHz (without Full).

You're right, I know that slowness hardly ever comes from a lack of optimizations by the programmer, and I didn't want to say "Axe Parser is slow" either - it's definitely not the case ! Nevertheless, it's always better (for the speed and for the program's size) to have the exact function needed. See spoiler :


By the way, Robbox seems to be a good game I'll try it. EDIT : It is !