Yes, this is the right place to ask. I didn't actively debug the code, but I suspect the problem has to do with the bullet logic. My suspicion is that, as the result of a few code issues, the number of bullets is getting decreased when it's already zero, wrapping around from 0 to 65535 and then causing a great big mess. Here are the three culprits that appear to me:

• For(I,0,B : This loop will parse one more "bullet" than you want: the "0th" bullet. The fix for this is simply to increase the lower bound of the loop to 1.
• Copy(J,K,3)ʳ : Copy() copies data from the first pointer argument to the second, but you want to copy from K to J, so they need to be switched around.
• When a bullet is removed during the bullet processing loop by copying a bullet from the end of the list over it, the copied bullet still needs to be processed, but the loop counter will increase for next iteration and skip it. The usual way to fix this is to decrease the loop counter by one when a bullet is removed/overwritten to negate the next iteration's increase.

Here's your bullet processing code with the above fixes applied:
For(I,1,B
I*3+L1->J
{J-2}-1+{J}->{J}
If {J}=57 or ({J}=0
B*3+L1->K
Copy(K,J,3)^^r
B-1->B
I-1->I
End
End

I quickly tested plugging that into your code, and it seemed to work great. I've also attached the working source program; not that it's really needed, because the changes made were quite minimal and should be easy to apply directly to your copy of the source.

Good luck expanding this code out, I'd love to see a full-fledged game result from it! If you have any other questions with your project in the future, you can always post them back in this thread and they should hopefully be answered swiftly as well.

Also note that Axe is not Basic. The main difference being that Axe is compiled while Basic is not. This means that "forgetting" parentheses in Basic saves space in the executable and in the source (since they are the same), but in Axe, that doesn't save anything for the executable. And saving space in the source only is not useful except if you have a 83+ non-SE. Otherwise, I'd advise you to close your parentheses to avoid mistakes such as writing A+(C=1→A which you understand as A+(C=1)→A but which the parser understands as A+(C=1→A).

Ah yes. I've been coding with ti-basic for a while and its sorta confusing because my brain is still thinking on how I'd do a program in ti-basic when here things like speed dont matter as much.

Yea I came across another thing I wanted to ask about here, With some code like:

0->{I-2}->{I-3} The {I-3} dosent work for some reason when something like 0->A->B would. Is there any way to do that with the value of a pointer thing?

Quote from: LemonDrop on August 01, 2013, 04:23:19 pm

Quote from: Hayleia on August 01, 2013, 03:27:35 pm

Also note that Axe is not Basic. The main difference being that Axe is compiled while Basic is not. This means that "forgetting" parentheses in Basic saves space in the executable and in the source (since they are the same), but in Axe, that doesn't save anything for the executable. And saving space in the source only is not useful except if you have a 83+ non-SE. Otherwise, I'd advise you to close your parentheses to avoid mistakes such as writing A+(C=1→A which you understand as A+(C=1)→A but which the parser understands as A+(C=1→A).

Ah yes. I've been coding with ti-basic for a while and its sorta confusing because my brain is still thinking on how I'd do a program in ti-basic when here things like speed dont matter as much.

Even when you code in axe, it's bets to try limit the size of the executable as much as possible and making it as fast and optimized as possible. Axe is a great and powerfull language, but the calc's hardware is very limited. When you have to handle a lot of objects at once, that work really pays off.

Yeah, it is a good thing to optimize the executable for speed and size, but there is no point optimizing the source (except if you have a 83+ non-SE and have very little space).

Sorry for asking a lot of questions here but I think its better than making new threads. So I was wondering about a few things:
1. Are axe programs in the Full 15mhz mode by default
2. Is using things like rotC, flipH and flipV instead of making sprites for different angles better (speed/space wise)
3. I heard that separating if statements (If A:If B) is faster than combining them (If A and B), is this true? Which one uses less space also
and finally
4. Whats the risk of using L3 for data, or is it safer to just use a pseudo list (L2+250 being the start of it) if you know the data in L2 wont extend that far
edit:
Oh yea does sound with the freq command play synchronously (meaning if its told to play for 1 second will it wait 1 second to go to the next command or does it play as stuff is happening)

(also this is what I have so far for my game thing, ignore the completely terrible explosion sprites and stuff)

1. Nope, all assembly programs should start at 6MHz.

2. Using the sprite rotate/flip commands will always be slower than not using them. flipV() takes 339 cycles, flipH() takes 1908 cycles, and rotC() and rotCC() take 2661 cycles. All four rotate/flip subroutines take up 73 bytes of space in total, so if you only have a few sprites that have rotated versions and the extra data isn't much larger than that, it would probably be smaller (and faster) to just include the rotated sprites as data. With more sprites, it begins to become more of a trade-off between size and speed. But if you want the speed of not using flip/rotate commands when sprites are drawn without the size of including extra copies of lots of sprites, you can still get the best of both worlds. Just include one copy of each sprite and then producing the flipped/rotated copies at startup time and save them in a static RAM area like L?-L? or a temporary OS variable.

3. In that direct comparison, separating the if statements does not save space. In fact, it costs 2 bytes. However, it does have two advantages. The first is that by breaking multiple conditions up into multiple if statements, if any condition is not true, none of the following conditions are even reached, thus saving time. The second advantage, and probably the more common reason why this is done, is that it works when one or more of the conditions doesn't actually depend on a boolean being zero or one, but on an integer being zero or nonzero. The and operator is an 8-bit bitwise AND, which works just like a logical AND for boolean values. But it doesn't work like a logical AND for integer values. (In case bitwise AND needs a bit of explanation, here's the wikipedia entry for it)

4. The Commands.html file included in Axe releases explains fairly well how large and how "safe" the L?-L? areas are. If you don't use any grayscale drawing commands or StorePic/RecallPic, L? should be safe to use.

5. The Freq() command in Axe is fairly primitive, so program execution doesn't continue while the tone plays. Having notes that play in the background requires fairly complicated interrupts and timing logic, so it hasn't been enough of a priority to find its way into Axe. However, I'm keeping an eye on Iambian's interrupt-based audio solution, which seems quite good. It might eventually be available as an Axiom (an external library for Axe programs).

On line 92, should If J>6 be If {J-2}>6 instead?

Getting a second set of eyes can greatly increase debugging ability. Sometimes you're just completely blind to a certain error for no apparent reason.