Another thing to keep in mind is that because a majority of the time spent rendering a tilemap is sprite drawing and not the tilemapping itself, any speed increase from this routine will be very tiny compared to if you wrote it in native Axe.  Most of the advantage will come from reduced size of code and simplicity of the programming.

Wait is your tilemapper just going to use the built in sprite display routine?  Because displaying tilemaps by looping around a sprite command is going to be just as slow as Axe (which is reallly slow).  There are much more optimized ways to do tilemapping that would be loads faster than the way you can do it in Axe.  I had a discussion with Calc84maniac earlier and he has some really good ideas and methods for making insane fast tilemappers, maybe you can talk to him?

And my preference would be:
Byte: Because limiting a tilemap to only 16 sprites seems like a bit *too* limiting to me
Smooth: Because all other types are easy and fast in Axe
RAM: Because its easy to set up, and tilemaps can span all of RAM if you really needed them to (App with appvar map)
Monochrome: Assuming you can draw to arbitrary buffers, there wouldn't be too much loss of functionality
8x8: Because 4x4 is barely ever used, and arbitrary sprite size would be way too slow.  16x16 might be a better option that 4x4 too, although I think 8x8 is still the best solution.

I generally end up using:
Byte tiles (Essence is the exception)
Smooth scrolling
Any RAM Location (this would mean pointers would work?)
Monochrome
4*4 tiles (could be just me, but pretty much every single platformer project of mine is 4*4 tiles )

Sounding epic, or should I say, "1337"
(137th page )

And Axioms could give you higher flexibility too, while still keeping speed up.  For example you could have 2 different Axioms for 4x4 vs 8x8

Huh?
Maybe you should keep your question and the answer here.

Hmm, on the smooth scrolling thought: What about having arbitrary-sized (or large but fixed) graphics buffers, which you can draw a portion of which you point to? As in:

DispGraph(X,Y,Buf) would draw a 768-byte section of Buf, starting with X,Y as the top-left. Edge detection would be in-code, or it could even loop. Whichever. That way, you could tilemap or hand draw an entire area, very easily implement smooth scrolling and parallax effects, among various other features.

BBC Basic does it that way, but only has one graphics screen. The actual buffer is somewhere in the 32768x32768 range or higher, I don't really remember.

That's too bad

Still, I liked the ability to draw as if there were. Also, it was *just* clipping, not scaling. The scaling occurs because the virtual screen res is 320*240 or thereabouts (depends on your MODE setting)

I know I said I'd release it tonight, but I think it will have to wait until the morning.  I crossed every single thing off the list that needed to be done except for one thing which came up recently, which is the tilemap sprite format bug.  That and updating the doc/commands list.  I won't have time for table stuff until the next release, but everything else should be in this one as well as some other really cool features.  One thing I just added; you can now easily write a tiny program that can print its own source code using a more general var absorption (which used to be limited to just picture vars).  No you can can import Pics, Programs, Appvars, and Strings directly into the executable!

Anyway, its past 5am here now so I have to get to bed.

Release what?

* epic7 is expecting something awesome

I think he will release a new version of Axe Parser.