Objective:
Reduce file size, increase program speed, and general optimizations.


Does space organizing your program cost space?
Example:
For(A,0,10)
    If A=1
         **
    End
EndVersus:
For(A,0,10)
If A=1
**
End
End

How can I avoid repetitively storing empty sprites without losing the tile-maps sprite synchronization?
Using level 3 gray-scale, I store my sprites into two pointers. One for front buffer and the other for the back.
When a sprite only uses one buffer I store [0000000000000000] in the opposite pointer so that they remain in sync.


Is it possible to shrink down my map size while maintaining the same tile map?
Example:
[00000000]
[01000001]
[00010100]
[01000001]
[00000000]
Versus:
[40]
[112011]
[102110]
[112010]
[40]
I remain unsure how to begin with something like this.


I'll post my code here so you guys can spot any easy optimizations:
[sprites front buffer] ->Pic0
[sprites back buffer] ->Pic1
[character both buffers] ->Pic2

.64x64
[map]->GDB1

ClrDraw
Pt-On(0+20,26,[E0E0E0E0E0F8F8F8])
Pt-On(6+20,26,[F8F8D8D8D8D8F8F8])
Pt-On(12+20,26,[70F8D8F8F8D8D8D8])
Pt-On(18+20,26,[E0F0F8D8D8F8F0E0])
Pt-On(24+20,26,[F0F000F0F0F0F0F0])
Pt-On(30+20,26,[98D8E8F8F8B8D8C8])
Pt-On(36+20,26,[F8F8C0C0D8D8F8F8])
Pt-On(42+20,26,[0000000000E0E0E0])
Pt-On(46+20,26,[0000000000E0E0E0])
Pt-On(50+20,26,[0000000000E0E0E0])
DispGraph

For(A,0,4096)
If (({GDB1+A})=1) and ((rand^25)=1)
If (rand^2=1)
10->{GDB1+A}
Else
If (rand^2=1)
11->{GDB1+A}
Else
7->{GDB1+A}
End
End
ElseIf (({GDB1+A})=2) and ((rand^15)=1)
If (rand^2=1)
  8->{GDB1+A}
  Else
  9->{GDB1+A}
  End
End
End
ClrDraw
0->P->Q->V->H->I->J->theta

Repeat getKey(15)
sub(MOVE)
sub(ACTION)
sub(RENDER)
End


Lbl MOVE
Z->Y
Q*64+P+262→Z
If (I=0) and (J=0)
If getKey(3) and (({Z+1+GDB1}=0) or ({Z+1+GDB1}=1) or ({Z+1+GDB1}=2) or ({Z+1+GDB1}=7) or ({Z+1+GDB1}=8) or ({Z+1+GDB1}=9) or ({Z+1+GDB1}=10) or ({Z+1+GDB1}=11))
    1→I
ElseIf getKey(2) and (({Z-1+GDB1}=0) or ({Z-1+GDB1}=1) or ({Z-1+GDB1}=2) or ({Z-1+GDB1}=7) or ({Z-1+GDB1}=8) or ({Z-1+GDB1}=9) or ({Z-1+GDB1}=10) or ({Z-1+GDB1}=1))
    ~1→I
ElseIf getKey(1) and (({Z+64+GDB1}=0) or ({Z+64+GDB1}=1) or ({Z+64+GDB1}=2) or ({Z+64+GDB1}=7) or ({Z+64+GDB1}=8) or ({Z+64+GDB1}=9) or ({Z+64+GDB1}=10) or ({Z+64+GDB1}=11))
    1→J
ElseIf getKey(4) and (({Z-64+GDB1}=0) or ({Z-64+GDB1}=1) or ({Z-64+GDB1}=2) or ({Z-64+GDB1}=7) or ({Z-64+GDB1}=8) or ({Z-64+GDB1}=9) or ({Z-64+GDB1}=10) or ({Z-64+GDB1}=11))
    ~1→J
    End
End
If (getKey(1)) or (getKey(2)) or (getKey(3)) or (getKey(4))
theta++
Else
    0→theta
End

  H+I+I→H
V+J+J→V
If (H=8) or (H=~8)
  P+I→P
    0→H→I
  End
If (V=8) or (V=~8)
  Q+J→Q
    0→V→J
  End
Return


Lbl ACTION
If getKey(54)
If ({Z+GDB1}=8) or ({Z+GDB1}=9)
2->{Z+GDB1}
ElseIf ({Z+GDB1}=10) or ({Z+GDB1}=11)
1->{Z+GDB1}
ElseIf ({Z+GDB1}=7)
1->{Z+GDB1}
End
End
Return


Lbl RENDER
Q*64+P→Z
For(B,0,9)
For(A,0,13)
Pt-On(A*8-8-H,B*8-8-V,((B+Q->D<64?A+P->C<64)?{D*64+C+GDB1}*8,Pic1-Pic0)+Pic0->C)
Pt-On(A*8-8-H,B*8-8-V,C-Pic0+Pic1)^^r
End
End
Pt-Off(40,24,Pic2+8+(theta/4^2*8+8*(theta!=0)))
Pt-Off(40,24,Pic2)^^r
DispGraphClrDraw^^r
Return
Also, looking at the 'Move' section, testing for what tiles the player is able to move on looks too big, maybe I can sort the tiles and make a loop for testing? Is that better?

Thanks in advance.

Thanks, I'll take look at that thread.

The Pt-On calls are called once in the program and that is to display' LOADING...' I don't see the point in wasting ram space to save something I won't use again.

Objective:
Reduce file size, increase program speed, and general optimizations.

I love optimization!

Does space organizing your program cost space?

Nope (although in the source file, of course). The project's original name of "Axe Parser" is a pretty bad misnomer, since it suggests that Axe is an interpreted langauge, but it's actually compiled.

How can I avoid repetitively storing empty sprites without losing the tile-maps sprite synchronization?

Instead of having one tileset that's a mix of tiles with different color depths/palettes, I'd suggest segregating the tiles into different tilesets based on the colors used. For tilemap purposes, continue to treat these tilesets as if they were one, so tile values for eeach subsequent tileset continue to count up from where the last tileset left off.

As an example, say you have a white-black tileset of size x, followed by a white-gray tileset of size y, followed by a white-gray-black tileset of size z. Then a tile index t:

• Between 0 and x-1 corresponds to the white-black tile t
• Between x and x+y-1 corresponds to the white-gray tile t-x
• Between x+y and x+y+z-1 corresponds to the white-gray-black tile t-x-y

Is it possible to shrink down my map size while maintaining the same tile map?

Map compression is absolutely possible, and definitely suggested once you have a lot of map data. Many programs store their maps in a compressed form and, when that map is entered, decompress it to somewhere in RAM for quick accesses.

Your example shows a form of run-length encoding, which is a basic but fair map compression algorithm. However, Axe doesn't have any built-in compression routines, so you have to supply one. Perhaps you'd be interested in Iambian's Pucrunch decompression Axiom? It implements one of the better general data compression algorithms, in a similar class to the kind of compression used for .zip files.

---

Regarding specific optimizations to your program, I may come back and look for some later. But I'd like to at least post my general answers first.