i remember when i was trying to learn builderboy's concept it was helpful to think of it in base 10:

think of the number 48. two digits, just like a hex pair. now divide 48 by 10 and truncate the remainder. you get 4, the first digit. now mod 48 by 10, and you get 8, the second digit. it's the same for hex. if you have a pair 5F you can get the 5 separated by dividing 5F by 16, and you can get the F separated by moding 5F by 16. in axe 1.0 i think there's going to be a nib{} command which will basically do this for you.

aww it is? are you just titling it portal again? or something else, but you don't know what yet?

Eh, builderboy? i decided to let you modify the icons to your liking, but i added a few things to it.

edit: picture not showing up?

edit2: nevermind, re-attached as a .png

very fast. slower than asm; granted; but axe is compiled into z80 ASM code... it's just that axe is built to be general-purpose, for all sorts of games, while an asm game would use routines designed specifically for the type of game their making. axe can be as fast as ASM, though.

here are some basic ideas about axe:

data is generally defined as hex in [] brackets. [112233010203] defines 6 bytes of data in hexadecimal with the decimal equivalents 17,34,51,1,2,3. data can be defined with the command Data(). Data(17,34,51,1,2,3) is equivalent to [112233010203]. note that you cannot define a number greater than 255 with this method. though, Data(256^r) would work, but it would also take up 2 bytes in memory.

pointers are central to axe. for example, [112233010203]->GDB1. GDB1 is a pointer to the start of the 6 bytes of data. you can access a certain byte of data at a pointer by using {} braces. so {GDB1} = 17. {GDB1+1} = 34, and so on. variables A-Z + theta are pointers. they are 2 bytes, therefore hold values 0-65535. if you subtract 1 from 0, you get 65535. if you add 3 to 65534, you get 1. rarely if ever do you use curly braces {} with just A-Z or theta inside.

here's a basic program that displays a basic 5x5 tilemap:
.AXE .This is the header, it describes the program's title. periods denote comments in axe.
[0101010101->GDB1  .GDB1 points to the beginning of the hex data.
[0101000101            .GDB1+5 would retrieve the first byte of this line, because it is 5 bytes after the start of the data.
[0100020001
[0101000101
[0101010101
[0000000000000000]->Pic1 .this is 8 bytes defining an 8 pixel by 8 pixel white square, which Pic1 points to.
[FFFFFFFFFFFFFFFF]          . this is an 8x8 black square.
[3C7EFFFFFFFF7E3C]          .This is a black circle represented by hex data.
For(Y,0,4 . 5 tiles high
For(X,0,4 . 5 tiles wide
Pt-On(X*8,Y*8,{Y*5+X+GDB1}*8+Pic1
.Y*5 is a vertical offset. when Y = 0, the byte retrieved by the curly braces {} is in the first line we defined.
.When Y=1, 5 is added to the offset, meaning the byte retrieved is now in the second row.
.X is the horizontal offset. You'll notice in our defined data, the values range from 0 to 2.
.Since Pt-On takes a pointer to an 8x8 sprite (which is 8 bytes of data), we multiply by 8.
.this means that if the byte in the tilemap is 0, the sprite displayed is the 8 bytes after Pic1. which is a white square.
.If the byte in the tilemap is 1, the sprite displayed is the 8 bytes after Pic1+8, which is a black square.
.and lastly, if the byte in the tilemap is 2, the sprite displayed is 8 bytes after Pic1+16, or the black circle.
End:End
DispGraph  .This updates the screen
if you put the DispGraph into the nested for() loops, you'll notice a significant slowdown, but you'll see the drawing of the sprites 1 by 1.

I'd start by learning hex and binary if you aren't *very* familiar with them already. I'd start by displaying a simple tile map.

The syntax is similar, but the semantics are much different. It's like c vs java. Similar syntax, but oriented for different things.

Oops. Those aré typos. Treat the ( as {