I can imagine that might cause some unsightly issues if you move your ship up into the data that represents your bullets

it was indeed for debugging purposes

another minor update: the tank can now fire one bullet at a time and destroy a target that is randomly inserted into the map. once i implement multiple bullets i'll be sure to stick another screeni/demo up here.

yep.
right now i'm just planning on making all the enemies move first and then making all the bullets move afterwards, running each bullet's modified (x,y) positions through the enemy list to determine if there is a hit or not. this is definitely slow, but i can't think of a better way to manage it (and as long as both lists stay within a range of 3-5 at a time i think it should be fine).

i was actually planning on including them(which is why the tank is a masked sprite instead of just OR'd). my friend who is better at graphics hasn't gotten around to making any, though, and i've been busy writing code. =/

ok, i haven't really done much as far as improving this yet, as i've been really busy with school stuff, but the previous download showing the rockets was lost, so i'm uploading the current version (which has buggy and very unoptimised pseudo shooting implemented). at present, it only fires one bullet at a time =/

Sorry to hear about the data loss and the bugs. It looks very nice, though.

However, I would suggest using DispGraph only every 2 frame, because if it runs this fast on-calc, the blurriness is gonna make it hard to see anything, especially on the TI-Nspire.

EDIT: Actually nevemnind, it seems you used a very blurry WabbitEmu LCD setting. X.x I tried in Wabbitemu and it seemed rather fine.

so on the car ride back from south dakota to arizona i realised that the issues i thought i was going to have with variable length lists for bullets and enemies could be avoided by using a different method. before, when an entry was removed from the list, i was trying to copy all the bytes from that spot to the end of the list back one entry and then decrement the variable which held the list's number of entries. however, i realised that, because the order in which entries are displayed doesn't matter, i could instead just copy the last entry in the list over the one to be removed (or just do nothing if the one to be removed is the last entry) and then decrement the length variable.

armed with this new realisation, i booted up axe 1.0 on the car ride back from south dakota and did my best to implement it. i kept getting weird things, like items disappearing or being swapped with the wrong entries, and it's making me think that i've been away from axe for too long and am doing something supremely stupid.

could someone help me out with demo code?
what i would need is something that can add or subtract entries (adding at the end of the list and subtracting from any arbitrary position within it) from a variable length list that consists of 3 byte wide entries.
i promise i wont ask for someone to write the whole program for me this one bit of code has just had me frustrated for months (and i have no idea why because, in concept, it seems so simple...)

doing it that way with powder would have had an affect because the items in the list are interacting with one another, so if one moves before another they will end up in different positions than they would have if the second had moved first.