Linux AND Mac OS X can be bundled into a single executable (surprisingly)!
You just have to look a little closer and not be deceived by the names of projects.

Meet PyInstaller. As such, the name can be quite deceiving. But this project isn't an installer - it's a python -> EXE converter! And by EXE I mean "system executable" - yup, this isn't limited to Windows. It is truly cross-platform - able to deploy Python programs to any user without lugging Python along!

As proof, here's a standalone executable in Linux. Extract, and make sure you make the program croquette executable!
Included is the PyInstaller v1.5 archive, as well as a convenient script to build a standalone binary. I built the Python source in r13.

http://dl.dropbox.com/u/1016340/croquette_linux_x86.zip
MD5SUM: 04b64b0e6db44310187285688d29e253
Size: 15 MB (Yes, it's big, but that's what happens when you build it into a standalone binary. PyInstaller says if you build the dependencies as static binaries, it can be compressed further.)

Unfortunately, you can't build to another platform - that is, building a Windows binary on Linux, a Mac OS X binary on Windows, etc. So you will need people with those OSes to build binaries for the project.

Ooh, I see, that explains things.

I used pyinstaller to build the exes, but I only own a Windows computer...

To clarify, exes made on Linux are also compatible with Macs?

Wow, that was pretty fast.

It looks nice!

Consider highlighting some keywords like 'If', 'While', and ' Repeat'?

I made an exe, for Windows users
(I think it's suppose to work in Linux and Macs, too, but I can't confirm.)

Link (filesize was too large for Omni)

Quote from: Michael_Lee on July 28, 2011, 01:10:55 am

Couldn't you just push all the bombs out of the way to get to the flag?

And if you couldn't push the bombs away from the flag (because they're so densely packed), then wouldn't that mean that attempting to remove any bombs in the way via explosion would also destroy the flag?

Yup!  (Remember that this is a test level, and I wanted a way to test exiting before I coded the bomb explosion code.)  Real levels won't be so easy.

Ah, ok, I see.

And you should make a level editor

Are there going to be more tiles then just the solid walls and the bricks?

(Disclaimer: it's late at night, and I probably got something wrong.  Any corrections or modifications will be welcomed with open arms.)

The checksum is the sum of all the data from offsets starting from byte 55.

That means the sum of all the data in this region:

METADATA:

Sizes:
      Offset    Length  Description
<snip>
| Data
| |   55        2       Always has a value of $0B or $0D? (prefer $0B?)
| |   57        2       Length of Variable Data Section
| |   59        1       Variable type ID ($05 for programs)
| |   60        8       Variable name (padded with zeros)
| |   68        1       Version (??), usually $00.  (Present if byte 55 == $0D)
| |   69        1       Archive flag.  $80 archived, $00 if not. (Present if byte 55 == $0D)
| |   70        2       Length of Variable Data Section (repeat of bytes @ 57)
| |
| | Variable Data
| | | 72        2       Length of Actual Data / 2
| | | 74        n       Actual Data
| | End Variable Data
| |
| End Data
<snip>
...is the checksum.

For example, if I had the program,
3->A

the full 8xp (in hex) would be the following:

Packet
|
| Header
| | **TI83F*                   2A2A54493833462A
| | (part of signature)        1A0A00
| | Comment                    546F6B656E697A656420
| |                            7573696E67205449436F
| |                            6E766572742076302E35
| |                            00000000000000000000
| |                            0000
| | Length of Data section     1600
| End Header
|
| Data
| | Mystery value              0B00
| | Length of Variable Data    0500
| | Variable type ID           05
| | Variable name (TEST)       5445535400000000
| | Version (??)               00
| | Archive flag               00
| | Length of Variable Data    0500
| |
| | Variable Data
| | | Length of actual data    0300
| | | Actual data: 3->A        330441
| | End Variable Data
| |
| End Data
|
| Checksum                     D501
|
End Packet

The length of the Data section (present in the header) and the length of the Variable Data (present in the Data section) all are the number of bytes in their respective sections.  For example, if you were to count all the bytes in the Data section, you would get 22, which is 16 in hexadecimal, which, as you can see, is the the value recorded right after the comment.

The checksum, however, is the sum of all the bytes. 

0B + 00 + 05 + 00 + 05 + 54 + 45 + 53 + (etc, might have missed a few numbers there) + 33 + 04 + 41 = 1D5 (in hex).

The least significant byte goes first, so the checksum is D501.

(Random question: why is it that in the 8xp file, the least significant byte goes first, but looking at the actual data, specifically two-byte-tokens, the least significant byte goes last?  Wouldn't it be more consistent for the least significant byte to go last in the 8xp file format too?)

Ok, I see what you mean.  Yep, I think the two should be the same.

A quick comment: in your document, you have a comment delimiter at byte 53: I don't think there's actually one.  If you remove that, and shift down all the offsets accordingly, your file format should output something identical to mine.

Update!

Version 0.5
 > Detokenizing and tokenizing TI-Basic is supported!
 > You can now use special characters (like λ and → instead of lambda and ->)
 > More tokens supported!
 > Detokenize or tokenize all files in a directory!  (Drag a folder over the .bat or .exe)
 > Better documentation -- see zip file for a list of all possible tokens.

And just for ephan...
 > Made ticonverter.py functions easier to use.

Coming up next:
 > Better support for special tokens?
 > An online version!