133794m3r,

In Axe, the ONLY data type there is is the 16 bit (and sometimes 8 bit) integer. Why? It's the hardware. The biggest register is 16 bits...so yeah. There are different ways of reading this number (signed, unsigned, char, etc.) but it is still only a number. Fixed point notation is just that- notation. It is a different way of representing a 16 bit integer. As such, all the limitations that come with dividing and multiplying integers still exist.

Let's take a look at the example 1.0/*10.0. Runer explained it up above, but I'll attempt to explain a little differently since you didn't seem to get it the first time.

First, understand that that all that the decimal point does, is convert the value from fixed point notation to an integer. Remember fixed point notation means this: high byte is the integer portion, low byte is a fraction of 256. So, 0.5 in fixed point will become 128 (because 128/256 = 0.5). Similarly, 1.0's integer representation is just 256. 10.0's is 2560.

Anyway, the fixed point division returns 1/10, which is actually the integer 25. Why? Because 1/10 of 256 is 25.6, but that's a no no because everything is still integers really, so you just get 25. Then it goes on to **10.0 which just takes your 25 and fixedpoint multiplies by 2560. Which is the same thing as regular multiplying by 10, which is why you get 250.

So basically, what you have to keep in mind when doing math in Axe are two things: one, divisions will always truncate the decimal part. That's just the way it is, you can ask around and explore the ins and outs of writing an integer division routine. Using fixed point can lessen the impact of this  phenomenon, but it won't eliminate it, especially as you work with smaller and smaller numbers (like 1/10). Second, all Axe operations move left to right. The only order of operations cue there is are parentheses. That might be why you were having trouble with 2/10*65535; Axe saw 2/10, which is 0, and then multiplied 0 by 65535, which is still 0.

Depending on your numbers, you should (mostly) be able to play around with the way you write your statements to achieve a respectable degree of accuracy. Typically you want to try to get as large a number as you can before performing a division. For example, you can get 1.0/*10.0**10.0 to return 256 if you do 1.0**10.0/*10.0. Unfortunately, you have to be careful not to get a number larger than 65535, otherwise everything will break. So, 2/10*65535 becomes a little trickier. But you can still do it; while 2*65535/10 is not going to help us (because 2*65535 goes over 65535), 2*32767/5+1 gives you 13107. You can play around with the numerator and denominator a bit to try to get optimal results. This is the down and dirty truth of Axe and z80 asm in general. If you want something more accurate and/or larger range than 65535 (or -128 to 128 with x256 accuracy), get ready to write some really complicated routines.

I've found a better way, instead of keeping track of letter arrangements, would be to keep track of the key values. That way you can have one uninterrupted array of key values, the first element being the getKey that matches the letter A, and so on. Then you can just simply use inData(getKey,data(...))+65 to retrieve the ascii value of the letter

I've now made enough progress on this to start a thread on it. Basically, the goal of this side project is to be able to easily generate content for the game. Right now, warp tiles, NPC positions, items, moves and such have to be coded in by hand (ugh).

It's coded in Java, and so far I've got most of the drawing routines done, the GUI layout, and lots of asm/hex/int conversion routines written. Tilefile support is pretty much done, the tricky part is next going to be importing the map files.

Features list (planned, some implemented already)
-Tile Editor
--24x24 mode for creating large tiles as 4 12x12s
--Double click to edit tile
--Copy/Paste at least
-Map Editor
--Display of entire game map on the side for better map design
--Right click to add NPC, trigger, or warp
-Save and load as z80 source

In memory, there is no difference between "actual data" and "strings" in Axe. "HELLO WORLD" is literally equivalent to [48454C4C4F20574F524C44] which is also equivalent to Data(72,69,76,76,79,32,87,79,82,76,68)

I think that Axe moved A-Z a few versions ago; L1 is 768 bytes. Also, L2 is perfectly safe, I think now just as safe as L1 in 1.2.1 (used to be interrupts used that area, but no more).

Edit: Actually, i just remembered that MirageOS uses L2 for its custom interrupts. Used to be you could put an FnOff at the beginning of your program to disable MOS interrupts, but I don't know if that still works (I'm 60% sure that it should)

For some reason the TI docs list L2 (statVars) as being only 531 bytes, but other areas of free ram start right after where L2 ends for at least a few hundred more bytes, so basically L2 is a lot bigger than 531 bytes.

Edit2: L2 points to 871 bytes of free ram, but you may have to zero (using Fill or something) the extra 340 bytes of RAM starting at 8C4D at the end of your program. Source: http://ourl.ca/16406

@stevon8er, your method uses a different one than mine That code is good if you want the screen to scroll only if the player is near the edges; mine keeps the camera centered on the player. Also my code there is barely optimized lol, though I took the liberty of quick-optimizing yours for you (Didn't go crazy here, tried to keep the same overall layout and readability.)

...

0->C->D+8->X->Y

.till [clear] is pressed
While 1
MOVE()
MAP()
.2 subroutines are called
Pt-on(X,Y,pic1)
DispGraphClrDraw
EndIf getKey(15)

Lbl MOVE
getKey(3)-getKey(2)+X
!If +1   //if x = -1
->x   //make x = 0, since the !If +1 statement left a 0 in hl
C--  //decrement C
Else!If -89  //otherwise, check if x is 88 (actually, we're checking if x+1-89=0, but it's the same thing right?)
C++
88->X
End

getKey(1)-getKey(4)+Y
!If +1
->Y
D--
Else!If -57
D++
56->Y
End   //and same stuff for Y. Halved the number of getKeys here.

Return

Lbl MAP

.Okay, so the main driving force behind the optimization logic here is that we want to move as much stuff as we can outside of loops.
.So for example, C and D will never change while we're in the loop so...
.I made up some variable names but you can use whatever you want.
D/8->tileY*15+GDB0->tilePointer
C/8->tileX
-(C^8)-8->offX
-(D^8)->screenY

For(9)  //for the 9 rows to be drawn
tileX->tileX0
offX->screenX
For(A,0,12)
Pt-on(screenX+8->screenX,screenY,{tilePointer+A}*8+pic0)
End
screenY+8->screenY  //move the Y "pen position" down a row
tilePointer+15->tilePointer  //next row of tiles
End
Return


Nice work on the NPCs. Does the background sun flicker that much on real hardware?