By the way ztrumpet, you still have yet to mark off fixed point multiplication and sprite rotating/flipping as being covered by Axe. I made a post a short while ago saying that they were outdated, but it looks like you must have missed that post. Don't miss this one!

I have a question/feature request that would be quite helpful: Will Axioms be able to implement token replacements? Perhaps have the user put any Axioms used in their program on the second line, like includes, and add any token replacements defined in those Axioms to the ones already used by Axe?

The main reason I'm asking this is because I feel that once full Axiom support is added in 1.0, anyone could write Axioms for a good deal of feature additions. This would help to not only relieve the burden of feature requests on you, but also get features out much more quickly. But it's often very hard to find a fitting token for something as it is, and with an influx of more commands, I'm sure it would become even harder. Additionally, the fact that Axioms aren't standard parts of Axe and wouldn't be in the command list would make it even harder to remember/look up the right tokens for commands.

I realize that signed overflows wrap like that natively, but for this purpose it isn't the desired outcome. Multiplying two positive numbers and getting a negative number seems less practical than getting a clipped positive number.

This is what disassembly is for

;getKey stuff here
ld hl,($8700) ;$8700 = K
ld a,l ;K=4 check
sub 4
or h
ld hl,$01
jr z,$+3
dec l
ld a,h ;Standard If statement code
or l
jp z,EndIf
ld hl,string ;If statement contents
ld ($870A),hl ;$870A = P
EndIf:
;Other stuff


string:
.db "Up", 0


Also, the contrast sets itself to 45 when you exit that mode, which I find to be a decent number.  If you don't like that, please tell me (note, for those of you inexperienced in axe/asm, reading the contrast value is not possible, so no maintaining it, sry) (at least not in axe without hex codes)

It's actually very simple to return the contrast to the value it was previously set to, without any need for assembly. To change the contrast value to what the user had it set to:

Shade({ᴇ8447}ʳ+24)

Double-clicked?

Anyway, that's a pretty clear explanation, thanks!

Whoops... someone delete the first one lol. I must've done something weird when editing it and instead created a second post instead of just editing the first one.

Here's the description from the commands list:

inData(BYTE,PTR) Key: inString()

Searches for the byte in the zero-terminated data. If found, it returns the position it was found in (starting at 1). If not found, 0 is returned.

The first argument accepts a byte value. Because Axe variables and math functions return two-byte values, this means that the high byte will be discarded. This argument essentially accepts whatever you enter mod 256.

The second argument accepts a pointer to data. In this data should be a series of byte values which will be stepped through one by one and checked to see if they are equal to the first argument (mod 256). The end of the data is signified by a zero so the search doesn't continue infinitely. For this reason, zero has to be reserved for the terminator and cannot be a value you want to compare.

---

Breaking down a more specific example, like: If inData(A+1,Data(2,7,17,0))

In the first argument, A represents whatever 0-based number, say an item ID, that you want to check. However, because 0 is reserved for the terminator of the data, we add 1 to it to shift all the item IDs to essentially be 1-based.

The second argument isn't really data itself. The data is defined somewhere in the bottom of the program, and this argument is instead given the value of a pointer to that data. As noted earlier, this data that is pointed to should be a list of nonzero byte values to check if the first argument is equal with, and the data should be terminated with a 0. Because 1 was added to our first argument to account for the fact that 0 is reserved for the terminator, 1 would also be added to the values we want to compare against. In this case, I wanted to compare against the values 1, 6, and 16, which turn into 2, 7, and 17 when 1 is added to them.

Finally, when the routine is run, the data is stepped through byte by byte, checking to see if a byte from the data equals the first argument (mod 256). Let's say we wanted to check if a selected item was a consumable potion, and item IDs 1, 6, and 16 were the potions present in our game. If the selected item ID (A) was 16, this value would be increased by 1, giving 17 for the first argument. This would then be checked to see if it equals 2, 7, or 17, which are the item IDs of the potions all plus 1. It doesn't equal 2 or 7, but it does equal 16. The routine would return the position of the match value, in this case 3, because the third element matched. For our purposes, all we really needed to know is whether or not a match was present, but inData() returning the match position works for this. Any match position returned will be greater than or equal to 1, which will make our IF statement true. If the item ID were 5, it wouldn't match any of the three values in our list. Once the routine hit a zero byte, it would know the searching was done and return a 0 for no match, making our IF statement false.


I hope this helps clarify things a bit