Hayleia :

Assuming that each image is 8*8 (thus 8 bytes long) and that x and y go from 0 to tilemap_width-1 and tilemap_height-1 respectively (in number of sprites, not pixels) and X and Y go from 0 to 11 and 7 respectively

Here are your For loops.
And I don't think a Menu( command really is a good idea. I'm afraid that it could make beginners lazy, since they would have a command to do everything.

Can the fill( function be auto opted when the byte it should fill with is a predetermined constant?
And can it be optimised even further if the size is less than 256?
I think it would look like this:
0<size<256:
bytesize: 7
ld b,*
ld(hl),*
inc hl
djnz -5

size>=256
bytesize: 15
xor a
ld bc,**
ld(hl),*
inc hl
djnz -5
ld b,255
dec c
cp c
jr z,-11

and I think the current code has a size of 18 bytes.
I don't know if the code I gave is as optimised as it can be (nor have I tested it yet), but it is smaller.

A prefix version of ++ and -- that returns the in/decremented value instead of the previous one.

As of now, the ++ and -- operators don't actually have defined return values. Technically, any code that does currently use their return values is a hack, and would no longer work if ++ and -- were properly implemented. There are numerous programs that take advantage of the current implementation, and I don't want to break them, at least not for the moment.

I believe the main reason ++ and -- were never set up to properly return the new/old value exactly is for optimization reasons. If they were all fully implemented, VAR++ would be 1 byte larger, VAR^r++ and {EXPR}++ would be 4 bytes larger, and {EXPR}^r++ would be 3 bytes larger. And it's not uncommon that the return value isn't actually needed, so those would be wasted bytes. It was kept in mind that programmers could use the "undefined" return values to get the real return values if they wanted them. For the first two cases, which I believe are the most common, it actually costs the programmer nothing to do this; the assembly implementations would be the same as VAR++-1 for the first and {VAR^r++}-1 and {{EXPR}++}-1 for the second (pre-increment would be the same as well, just without the -1's). It does get a little hairy with the two-byte pointed increment/decrement, though.

Don't get me wrong, I do eventually want real ++ and -- implementation. However, I would like to save it for when Axe has a more powerful optimizer and can intelligently see if the return value is actually used, and then decide whether to use the smaller undefined return value code or the larger defined return value code.

Can the fill( function be auto opted when the byte it should fill with is a predetermined constant?
And can it be optimised even further if the size is less than 256?
I think it would look like this:
0<size<256:
bytesize: 7
ld b,*
ld(hl),*
inc hl
djnz -5

size>=256
bytesize: 15
xor a
ld bc,**
ld(hl),*
inc hl
djnz -5
ld b,255
dec c
cp c
jr z,-11

and I think the current code has a size of 18 bytes.
I don't know if the code I gave is as optimised as it can be (nor have I tested it yet), but it is smaller.

Fill is absolutely a command I'd like to optimize, and I like your ideas. But on a note related to my response to Freyaday above, Axe's optimizer is unfortunately too simple at the moment to allow for such optimizations. It doesn't provide for any way to supply optimized versions of multiple-input functions for which some set of the inputs are constants.

When Axe gets a more powerful optimization engine, I certainly would like to see things like this added.

---

I think I'm seeing a theme here...

also, i think I've found a smaller code for ee14 (if it isn't changed already).
now it takes 7 bytes, but it can be done with 6 bytes only too with as code:
xor a
add hl,hl
add hl,hl
ld h,a
rla
ld l,a

I thought I found a better way for ee15 too, but it seems the auto opts file was wrong about that.

I don't know whatever this is possible, but I was thinking about an option where you can precompile a file, so that if it is called by another file that is being compiled, it compiles faster.
so you can precompile everything, except the level design part and then only recompile that for faster testing.

Using external data and DrDnar's excellent RunPRGM are the best solution for that IMO.

I wonder if there could be a command to force a program to be compiled for a certain shell and also constants that give info on the build (machine model, extra RAM or not, shell it's being compiled for...). That would make things a little easier to manage in certain cases (i. e. 15MHz only code or app only code).

wait, i just got a good idea....maybe adding like a optional 2nd line header which tells axe for which shell to compile, that way you don't always have to switch from app to noshell when you want to make an appvar.

Exactly what I suggested.
Also an appvar "shell" could be nice.