IMPORTANT UPDATE!

Unfortunately, or fortunately depending on how you look at it, one of the new optimizations will change the way you optimize your code.  When saving to a pointer at a static location, the return value will now be the value stored rather than the address that is being saved to.  This rule does NOT apply to locations with variable addresses like {A} or {B+L1+8}, those will remain the same as before.  Its when you save to pointers like {L1+4} or {Str1-16} that this will affect.   Both 1 byte and 2 byte storage are affected the same way.

The advantages vastly outweigh the inconveniences however.  Realize that after this release, saving to static addresses will have the EXACT SAME efficiency and code size as saving to a regular variable.  {L1+9}^r+1->{L1+9}^r for instance will be the same size code as A+1->A in the executable.  That saves about 4 bytes for every time you read a static pointer and 3 bytes every time you save to one.  The speed increase might be noticeable too if you use these in loops a lot.

If you still want to do tricks like this: Fill(0->{L1},100)  You can still write Fill(0->{L1}^rL1,100) and it should be the same sized code in the executable.  The double byte storage is actually smaller and faster than single byte storage when using static locations by the way.  Just making sure I warn everyone first before anyone panics if their executable doesn't work right in the next version.  This is the second wave of major optimizations and the first REAL look-ahead parsing with actual backtracking and I've still got many more to go.

No you can't, unfortunately. I've been thinking it could be a good idea to have some file reading functions that work regardless of whether it is located in Archive or RAM. The way I'm thinking it could work is that you open a file for reading, and it internally stores a pointer and page number. Then you would call the file read functions, which could read a byte, read two bytes, or copy a chunk of data (given the offset from the beginning of the file).

The update seems nice, altough I don't really get it much, still

Could you give an example of code that will require to be changed after the update? I mean, post the code compatible with Axe 0.2.5 and how it should be written for Axe 0.2.6.

Unless I am misunderstanding your post?

So far I have never used any static pointer location, though, so even if your update changes some syntax when using static pointers, it shouldn't make much differences for my current programs.

Can't wait for the update, though ^^

I think language apps also does something like Omnicalc fonts. With the German/Deusthce app, one of the char changes to a weird german-B-like char

Darn that 3D racing game was epic ^^

Nice update Quigibo!

There doesnt seem to be any documentation on them o.O for now all i can see is use with the Stop command

Also that 3D game kicks Ass

Thanks!  I made the game in about 4 hours when I was bored, which I think is pretty good because it would have taken much much longer if it was in assembly.  I figured that since so many other people used Axe to made a tunnel clone, I would do the same... only differently.

The interrupt commands are fairly useless right now.  All of them are 1 byte each and so the Stop command is really efficient for quick pauses.  Each one is around a Pause 40ish and you can do :Stop:Stop:Stop:Stop up to about 8 times I think and still be less bytes than the normal pause command.  Make sure you have enabled interrupts first!

EDIT: By the way, is the new version working right for everyone's code?  I only tested it with the example programs, they all seem to work, but since I rewrote so many routines there is bound to be something I missed.  Just want to make sure I didn't make any stupid mistakes before I update the one on ticalc.