You're welcome

Together, #defines (even fairly simple ones) and #includes can have the same positive effect on maintainability as they have in C/C++ or, say, LaTeX. Splitting a program / document across multiple files, having parametrized values repeated (and simplified) multiple times in a program so that they can be changed at a single place.

hokay, those both seem like they'll be easy enough to manage. i'll add them on to the end of the todo list.

#if calculator=84+ then (89? nspire?)
<code>
#else
<code>
#end

just a thought

this is only for the 8x series, though. EDIT: hmm, #if (compile option = blah ) would be really useful for debugging purposes, though...

speaking of which, what changes have there been to the token set for the 84+SEC? are there any new 2-byte regions?

EDIT2: xeda and runer? i don't really trust myself to make sure all the grammer and axe tokens are defined correctly, so, once i write those, do you think you could take a look at them and make sure i'm not missing anything important?

things like kerm's Source Coder 2 or merth's TokenIDE are all well and good for converting an 8x program between plaintext and link formats, but there are a few limitations to both: namely that they require graphical environments and cannot be scripted. to achieve these two purposes, i've started writing a tokeniser/detokeniser of my own (github). it's already functional, with the only remaining tasks being adding in full token sets (right now it only contains a very small subset of the axe tokens which i was using for testing purposes), implementing the option to skip comment lines, optionally writing to stdout, and writing the detokeniser (which is much simpler than its counterpart). have a screenshit!

ubuntu is not particularly representative of "Linux systems". that aside, though, what reason would a system administrator have for choosing your distribution over red hat, assuming he wants support for updates, or a "configure once to work exactly how he wants and then mirror across the other thousand machines" arch/debian/gentoo install? furthermore, how do you plan on providing a system with better out of the box support and better performance with such out-dated software?

perl is really easy to get into, and the benefits of easy string manipulation and extensive regex support would be helpful in a tokenizer to the extent of making it probably more worth your time to learn how to use it and then write the program rather than trying to use java

hmm, the only suggestions i can think of would be to swap out the landing skids for wheels, as that would make a little more sense with the constant take-off/landing and sliding on the ground, and, if it wouldn't slow things down too much, add a greater vertical area for flying.

ooh, brilliant!
that's quite the motivator for making things =)

a routine like that wouldn't really be necessary when you have so few tiles to keep track of, unless you start using nibble values for things rather than full bytes, and you do run the risk of slowing things down (although it can be done quickly enough to be imperceptible if you only draw the map on the first frame and just store/recall from the back buffer). one thing that you could do to ease the whole process would be to make yourself a map editor that lets you place walls all as one tile and then uses this method to convert them dynamically to the values you'd need for the separate sprites that dj made.