I thought 16x16 was actually faster than 12x12? (that's assuming of course you don't use 16x16 as some sort of cheat)

As for speed I was more worried since in the demo the FPS was like 8 or something and grayscale suffered when scrolling. Was that improved?

Ah i didn't know Axe could only do multiples of 8. It's kinda silly since it's super easy to draw extra Y tiles, unless there's some weird trick he's using. One of my projects now has a 16x16 sprite drawing routine i've written for it. Changing one number turns it into a 16x12 sprite drawing routine It could easily be a 16 x any number routine. I don't know how to write an Axiom and it's likely what i write ends up being less optimized than what Runer wrote. Ah and i am clueless when it comes to grayscale, are you using grayscale? And really, for a tilemap, it's usually more efficient to implement the sprite drawing into the mapper itself, not keeping the x and y coordinates on the screen but rather your position in the buffer, that way you don't have to recalculate your position in the buffer each time you go to draw a tile.

And squidgetx, unpacking the sprites would take the same space in RAM, but it would save space in your program. And it wouldn't even take up the user's RAM, just saferam. And you wouldn't have to have every map's set of sprites unpacked at the same time, just your current set. It might not be worth the trouble, but it'd save you 6 bytes (or 8, if you're using 16x16 sprites) per sprite.

@DJ: I think 16x16 is generally faster since you don't have to do as many calculations (it's faster to draw one 16x16 sprite than it is to draw 4 8x8 sprites)

This is the basic code. First however, you'll need to calculate where to draw the sprite on screen and put that into hl, +2 bytes (since it draws from right to left, we start with the right side of the sprite and draw leftward). I'm not really sure how Axe handles inputs to routines, so if i got a little more information i could add that in for you too. The first line loads the x offset, that is, how many pixels away from 0 we are. If you are drawing at an aligned position (a multiple of 8) b will equal 0. If you are drawing at X=1, b = 1. If X=19, b=19%8=3. C should be how many rows you want to draw. Here it's 16 (10h). If you want 12, you would change 10h to 0Ch. And the address of the sprite should be in ix. I also wrote a quick small aligned 16x16 tilemapper, i'm not sure how you draw your tilemaps. None of this uses grayscale, however, so i don't know how useful it is to you. I'd be happy to help write something for you, though. So:
b = x offset (how many pixels away from being aligned the sprite is)
c = number of rows to draw, this could be changed easily to a variable height sprite routine.
ix = address of first byte in sprite
47 -  -  -   ld b,a
 0E 10 -  -   ld c,16
 -  -  -  -  
 -  -  -  -  drawPlayerLoop:
 C5 -  -  -   push bc
 DD 56 00 -   ld d,(ix)      ;sprite
 DD 5E 01 -   ld e,(ix+1)
 AF -  -  -   xor a
 B8 -  -  -   cp b
 CA 71 A0 -   jp z,skipSpriteClip
 CB 3A CB 1B F9 srl d \ rr e \ rra \ djnz $-5   ;rotate sprite
 -  -  -  -  skipSpriteClip:
 B6 -  -  -   or (hl)
 77 -  -  -   ld (hl),a
 2B -  -  -   dec hl
 7E -  -  -   ld a,(hl)
 B3 -  -  -   or e
 77 -  -  -   ld (hl),a
 2B -  -  -   dec hl
 7E -  -  -   ld a,(hl)
 B2 -  -  -   or d
 77 -  -  -   ld (hl),a
 DD 23 -  -   inc ix
 DD 23 -  -   inc ix
 11 0E 00 -   ld de,14
 19 -  -  -   add hl,de
 C1 -  -  -   pop bc
 0D -  -  -   dec c
 C2 5E A0 -   jp nz, drawPlayerLoop
 C9 -  -  -   ret
EDIT: This routine will also slow down a little the further away from being aligned you go. We could unroll the shifting loops which, although taking up more space, would be slightly faster and have a more even runtime, or something like a 12x12 version of what i posted over here:
http://ourl.ca/15050 :)

I'm not sure how parameters are handled in Axe. That routine there requires that the position in the gbuf be calculated beforehand.

I think this should work:
26 00 -  -  ld h,0
54 -  -  -  ld d,h
6B -  -  -  ld l,e ;hl=de
29 -  -  -  add hl, hl ; 2
19 -  -  -  add hl, de ; 3
29 -  -  -  add hl, hl ; 6
29 -  -  -  add hl, hl ; 12
 -  -  -  - 
 -  -  -  -  ; x / 8
78 -  -  -  ld a,b
CB 38 -  -  srl b
CB 38 -  -  srl b
CB 38 -  -  srl b
58 -  -  -  ld e,b
19 -  -  -  add hl,de ; A present on a le decalage dans hl
11 42 93 -  ld de,gbuf+2 ; Prendre le debut du graphbuffer
19 -  -  -  add hl,de ; Puis ajouter le decalage
E6 07 -  -  and $07Though the best would be to have a specific 12x12 tilemap routine rather than recalculate the position in gbuf every time you draw a tile.

EDIT: Added opcodes.

Yeah, that's exactly it. If your buffer is 12 bytes wide and you want to draw on the 4th row, you'll need to add 4*12 to the buffer address. The other code i posted above will calculate that for you with e=y, b=x. However, if you can save your position in the gbuf each time you draw a tile, you can save quite a few clocks by not having to recalculate your location in the buffer again.

16x16 is the same speed as 12x12, it's just that the bits on the edges are kind of wasted space and time. Axe can only draw sprites in multiples of 8, so 16 would be the natural choice when working with 12x12 tiles.

Ah ok I thought that to draw in 12x12 that most older tricks just tried to cut the sprites at 12x12 rather than using 16x16 with unused/wasted space and that it was actually slower that way.

*Documentation update*

(see first post)
The project is now (almost) officially moving out of spec-writing stage , just going to tighten up the memory allocation meta