In retrospect, maybe it would have been better to make Fix # turn an option on and Fix #^r turn the option off. But that would definitely break compatibility now

What if the old syntax was left in for compatibility, but a new syntax of Fix LETTER / Fix LETTER^r was added? Letters might be easier to remember than numbers anyways.

It would be nice if a negation followed by an addition was auto-optimized as a subtraction.

For example, ⁻(expr1)+(expr2) should be compiled as
 ;expr1 evaluate here
  push hl
  ;expr2 evaluate here
  pop de
  or a
  sbc hl,de
A more optimized example would be something like ⁻(expr)+A, like so:
 ;expr evaluate here
  ex de,hl
  ld hl,(axv_A)
  or a
  sbc hl,de
And of course, the classic subtract-HL-from-constant, like ⁻+96
 ex de,hl
  ld hl,96
  or a
  sbc hl,de

Variables can move around in RAM, so I believe that Axe should have built-in access to asm_data_ptr1 and asm_data_ptr2 for pointer storage. Eiyeron had big problems with this here, but the solution is as simple as having variables that point to these address to hold OS variable pointers. However, I would not expect the average Axe user to figure this out and know to add something like ?84EB?°V1 to their program and then use that custom variable.

So the solution should be as simple as having two default Axe variables that point to asm_data_ptr1 and asm_data_ptr2. I would suggest Y_1T and Y_2T; they're literally perfect. They're in a menu right next to their closest relatives, the archived variable pointers. And they share similar names, except with an added _T for "Tracker." You could even have X_1T and X_2T point to asm_sym_ptr1 and asm_sym_ptr2. The only Axiom I know of that uses these as Axiom variables (MemKit) would not only still work, but it would work better.


EDIT: Fixed the second copy of the suggested variables (the sym pointers) to be X variables as they're supposed to be. I hope this didn't cause too much confusion.

Whenever variables are rearranged in RAM (for instance, deleting any variable that's not the last variable in RAM), the pointers at these two locations are adjusted according to where the variable they point to/into has moved. asm_sym_ptr1 and asm_sym_ptr2 act similarly, except they track VAT entries.

What do you mean by dictionary?  Like a list of all Axe commands?

Honestly I'm not sure this (probably large) feature is worth adding... It's a pretty high-level feature, and Axe is a pretty low-level language. A big issue I see is that it would require dynamic memory allocation for adding entries, and dynamic memory allocation does not work terribly well on our platform. Another issue I see is that Axe is a type-less language, so it would be challenging to properly handle the different types the dictionary could contain (it doesn't have to be <string, int>). Also, I'm not really sure what applications it would have to most users. Axe's main design purpose was to make games, whereas this sounds more like a feature that complex utilities would use.

The final reason why I don't believe it would be worth the size/difficulty of adding: if you really need a dictionary, you could actually implement it yourself in Axe. Since you're making it yourself and know what data types it will contain, that passes the hurdle of a type-less language keeping track of types. If you know it won't pass a size of 768 bytes, you could even skip the dynamic memory allocation and throw the dictionary into L₁ or L₃. But if you do need the dynamic memory allocation, you could still do it by putting the dictionary into an appvar and using MemKit to resize it as necessary when adding/removing entries.

How about Pt-Mask(X,Y,PicF,PicB[,Buff]) ?
This could allow for some flexibility, ie with small variations you can re-use one part to save space.


Also bump for non-8*8 sprite drawing (read: 4*4)