One thing that bugged me slightly about the aiming system is that multiple angles produce the same aim guide line. This could be remedied by using a custom line drawing routine that, instead of taking integer inputs, takes fixed-point inputs. Such a routine written in Axe would possibly be in the ballpark of 3-5x slower than the standard line routine, but since the line being drawn isn't very long and you're not doing much other computation, the extra time consumed shouldn't be a problem.

Alternatively, you could probably just play with the length of the guide line and find the minimum length that gives a different endpoint for every allowed angle (of which I believe there are 64, so 16 per quadrant?).

What is BLOCK_SIDE, and why does it consume 8 bits?

You can insert the \ symbol in the middle of any multi-character token in TokenIDE to prevent its tokenization; for instance, if you wanted a label named End, you could do that by typing E\nd. If you take this approach, I highly recommend saving the file as a .txt file rather than a .8xp directly, as the text form retains the source as it appears in TokenIDE with the \ characters.

Alternatively, as others have suggested, you can simply edit the AxeTokens.xml file (or make a copy and edit that) to your liking.

Is the purpose of this precisely to make an ASCII table? Or is it simply to convert the data into a more standard tabular format? Because you mentioned that converting it to CSV that can be imported into Excel would suffice, but I would like to point out that the input data can be imported into Excel just fine as-is, in which case my solution would be to do nothing.

It looks like you haven't yet been made aware of the distinction between constants and variables in Axe. Tokens like GDB2 can only represent constants, which are evaluated at compile time and hold that value for the entire runtime duration of the program. To have a variable value, you need to use just that; a variable (like A-Z).


EDIT with more information: A common way to achieve the kind of multi-level logic you're aiming for might take advantage of the facts that (a) data in Axe is added in the order it is specified in the source, with no breaks in between, and that (b) each of your tilemaps is 6*7 bytes large. So you could specify the tilemap data like this:

.MAPSRC
[]→GDB0
.Level 1
[222222222222]
[200000000002]
[200020000002]
[200000000022]
[200000020002]
[200020000032]
[222222222222]
.Level 2
[222222222222]
[200000000002]
[200000000002]
[200000000002]
[200000000002]
[200000000032]
[222222222222]
.et cetera

And then you could access the Nth tilemap (0-indexed) with N*6*7+GDB0.

I'm adding a shop now . Also I really need help with Appvars....

The best way to get whatever specific answer(s) you're looking for is to ask specific questions.

And sorry for this slight thread hijacking that's been going on... which I will now continue!

For example, if you want to create a game save, you just store the content you want in a list, such as L1->LSAVE. Of course you can't use appvars, but you can still create external files or read from them that way. As for reading from a save list, you do LSAVE(1) for element 1, LSAVE(2) for element 2, and so on (so you can do stuff like 18+LSAVE(2)->A).

With Celtic you can interface with appvars directly but the syntax doesn't look much better than in Axe. (IN axe, I think just making appvar save use a different token than appvar reading rather than have them use the same would already help).

You can basically treat external variables in Axe just like a zero-indexed, fixed-size list. For instance, if a variable's data pointer is in L, you could read the first 1-byte value with {L}, read the second 1-byte value with {1+L}, or write to the third 1-byte value with →{2+L}. You could also do the same operations, but treating the values as 2-byte values instead, about as easily: read the first 2-byte value with {L}ʳ, read the second 2-byte value with {1*2+L}ʳ, and write to the third 2-byte value with →{2*2+L}ʳ. Note that the *2 is because each element is 2 bytes.

Also, there isn't really any special command to "save" external variables, barring archiving it with Archive "appvNAME". The two primary commands for interacting with appvars are to locate existing ones, GetCalc("appvNAME"), and to create them, GetCalc("appvNAME",SIZE). The former might be used like GetCalc("appvHiScores")→S to locate a high scores appvar. If it simply held 2-byte score values, the Nth high score could be read with {N*2+S}ʳ or written with →{N*2+S}ʳ. The latter might be used like GetCalc("appvHiScores",10*2)→S to create a high scores appvar with 10 2-byte score entries, which you would commonly do if the fetch attempt returned zero for S, meaning it wasn't found.

After comparison, I see what you mean. It's a bit choppier, although that gif is making it look choppier than it really is.

Quote from: Eiyeron on May 19, 2014, 03:22:52 pm

For walls at the side of the map, can't you really just get the worm *disappears* when it gets out? Dommage

Well, I tried, but my collision routines really make things too difficult. I gave up after 8 RAM clears.

If you could share the relevant bits of code, people (likely me) could try to help debug it and get it working.