I have a suggestion that would make it a lot easier to make source code that compiles both to RAM and to Flash Apps. I think that nib{}r should be changed from a "read from flashapp" routine to a "read from executable" routine. That is, use the default nibble read routine when compiling to a RAM program, and the flash nibble read routine when compiling to an App.

I have a suggestion that would make it a lot easier to make source code that compiles both to RAM and to Flash Apps. I think that nib{}r should be changed from a "read from flashapp" routine to a "read from executable" routine. That is, use the default nibble read routine when compiling to a RAM program, and the flash nibble read routine when compiling to an App.

I would do that, except what about reading nibbles from appvars etc. from an app?  Those still need the other command and it would be way too complicated to auto-infer that during compile time.

Oh, I see what you mean... I misunderstood.  Although that could work, I can imagine somebody somewhere might want to read a nibble from the app page from a program and there could even be future uses with the Axe Fusion page.  However, it probably benefits more people right now to change it, and it wouldn't have compatibility issues except in extremely rare cases.  But even with a change like this, programs being ported to apps still need to make fundamental changes due to self-modifying code issues.

But I like the idea.  I will probably make the change unless anyone needs to access a nibble in the $0000 - $7FFF address range from a ram program.  Otherwise it'll be impossible to do without assembly so please let me know if you need to do this and object to the change.

Can we have a signed modulo operator?

Quote from: Darl181 on February 20, 2012, 08:30:38 pm

Would it be possible to, when axe is compiling/zooming a program and it encounters an error, go in and edit the program then when you quit the editor go back to continue or restart compiling/zooming?

This might not be practical for large bug fixes or whatever, but for things like physics tweaking and the like t would be useful
Not sure if it would be a compile option or certain key, tho..

I'm about 90% sure that this is impossible without Axe installing extra hooks, which Quigibo does not want to do. I know that you originally suggested this idea in the zStart thread, and I believe that was the correct place to request a feature like this. I also believe that thepenguin77 is already planning to implement this feature in zStart. He is just waiting for the next version of Axe, which should handle compile errors better from API calls, and then he can add this.

To access directly to matrixes :

GetCalc("var[A]") -> A
{A-1} Number of rows of the matrix
{A-2} Number of columns of the matrix
float{N*X+Y*9+A} To access directly to [A](X,Y), where N is the number of rows
Not much more complicated than TI-Basic, right ?

It may be a small request but wouldn't it be much easier to be able to directly access matrices using the actual [A] matrix token. and if theres any way to directly access them please someone tell me because i feel like ive tried everything

I could do that, sort of like how I use "Ans" in Axe to represent the BASIC Ans.  But its a bad idea because then programmers get confused from BASIC and try to use it the same way even though it has a totally different meaning.  I kind of wish I hadn't done that with Ans for the same reason.  Also, I'm considering using the matrix tokens to represent tables eventually.

Quote from: boot2490 on February 23, 2012, 05:55:16 pm

Line clipping support!

This is going to be coming in an Axiom that is under development.

Frankly, if you get decent line clipping, I think Quigibo would want to include it in Axe itself. The only reason Axe doesn't have proper line clipping currently is because he hasn't gotten around to making a decently small/fast solution himself.