The last screeny should be it except for the machine guns.

I couldn't do much on this, I've been working on another "scientific useful" project for some time now, but nonetheless here is an update:  

Added:

• Automatic Archive/Unarchive safe file (no big deal, but was missing before)

Changed:

• Fixed phantom grenades / grenades exploding much too late / grenades disappearing (occurred when both players throw a grenade the same time)
• Downgraded the machine gun: only 9 shots, fire rate reduced from 200% to 150% (recommended by a friend)
• Reduced grenade timer by 20% (explodes after 80 frames)

Since it isn't an update with changed graphics / major changes on game mechanics, I won't add a screeny.

Download:

If you have a second memory location to store the sorted array, this might be useful:

Pseudocode:
ptr = 0
For each element
Look for largest element
Write that data to (ptr)
Make original element 0
ptr++
Next element
Copy new array to original array

Ooh, thanks, it works now, Time to go see If i can remove flicker now.

What flicker? There shouldn't be any flickering except when your loop is two slow. Can you post your code?

Here is a more in-depth how-to:

The TI-83 series doesn't support grayscale natively, but axe has some functions to alternate checkerboard patters, but that is so fast (and the screen is blurry too), so that it looks for the human eye like it is gray.

Because one buffer can only store data for two colors, you'll need two buffers for 2² = 4 level grayscale. Depending on the pixel combination of both buffers you can get black, dark gray, light gray and white. The easiest way (for me) to remember the combinations is, that the main buffer has a higher "priority" or "level" than the back buffer, so if you change a pixel on the front buffer, it'll cause the result to change more than when you do it on the back buffer.
Here are the combinations for 4 level grayscale:

Front buffer:  Back buffer: Result:

off off white

off on light gray

on off dark gray

on on black

In order to display a 4-level sprite, you have to create two 8x8 sprites, one for the front buffer, one for the back buffer. With the table above as reference, you can make your 2 sprites out of the one desired gray sprite.

To display them, you need two Pt-commands:

[Hex for Front buffer]→Pic1A  ; you can use other names for pointers if you want
[Hex for Back buffer]→Pic1B
...
ClrDrawrr  ; clears both buffers at the same time
While 1
...
Pt-Off(X,Y,Pic1A)   ; X and Y are the coordinates
Pt-Off(X,Y,Pic1B)r
...
DispGraphClrDrawrr   ; for 4 level you need two radian r's
...
EndIf getkey(15)

For 3 level grayscale you need DispGraph^r, for 4-level you need ^rr. Same when you use the DispGraphClrDraw.

Every time the DspGraph^rr is passed, the checkerboard pattern is changed.

That should be it.

Only applies if the pointer is not a constant! L₂ is a constant, so that part of his code is fine.

Whoa, didn't know that! 

Remember, the syntax to create a list of data in Axe is different from that in TI-BASIC:
Data(0,1,4,9,16,25,36,49,64,81,100,121,144,169,196,225)→GBD1

Stupid mistake 

And for the "3"-key mistake: I just copied from the source, but you can blame me for not checking it

Thanks runer, you make me always learn new things!

I might actually do this, given I have enough time, It seems simple enough.

I think the most difficult part is to check whether a move is possible or not. (Right player's turn, piece can move in that pattern, no other pieces are in between (except for the knights))

Oh I see, should I use the Fill( command to zero out the ram?

No, just do 0→{L2}

What is a LUT and what does inData do?

LUT stands for Look-up-table. It is basically just a constant array with values. You can get each value by accessing the data with an index. That is usually a lot faster than having a calculation for it.

Example:
{0,1,4,9,16,25,36,49,64,81,100,121,144,169,196,225}→GBD1  ; a LUT with the squares of 0-15
...
instead of a calculation like
A²→B
you can use the LUT:
{A+GBD1}→B

The speed difference isn't that big in such an easy example, but with the complexity of the calculation you can avoid it gets more notable.
Other examples for LUTs: Frequencies for Music, characteristics/properties of different weapons/armor/enemies, ...

You have to make sure that the index doesn't get out of range, otherwise is it'll do weird stuff, e. g when A is 16 or larger, it'll still read the data after the LUT.

You can use an LUT also the other way round. Axe provides the function inData() for that.

inData(BYTE,PTR)     Searches for BYTE in the zero-terminated data. If found, it returns the position it was found in (starting at 1). If not found, 0 is returned.

Zero-terminated means, that the last value of the LUT has to be 0 respectively the first 0 in the LUT is considered as the end.

Say, at the beginning of the code we have a LUT with our keys, ending with 0:
{33,34,26,16,0}→GBD1at the point where we need the data, we use inData().
If inData(K,GBD1)→F   ; if the key is one of the weapon selectors
F-1→L         ; take this value (1-4) and subtract 1 (then we have 0-3) and store it in L.
End
optimized to save a variable:
If inData(K,GBD1)   
-1→L   ; that is the subtraction minus sign, same as above. It subtracts from the last evaluated expression, which is "inData"
End


I never knew about the "+" and "*" operations

I'm sure you know them "+" does add and "*" does multiply. 

But for conditions they can be used as well:
"+" is "or"
(cond 1) + (cond 2)
When either of the conditions is non-zero, the sum will be non-zero. (non-zero means "true", zero is "false")
Attention! If one of the conditions is negative, they might add up to 0 too!

"*" is "and"
(cond 1) * (cond 2)
When either of the conditions is zero, the product is zero. So all the conditions have to be non-zero, to make the whole statement non-zero.

I hope that cleared things up a bit.