That looks great! I was in town earlier today with no obligations, so I programmed for a bit and converted my BASIC code to Axe and then modified it a little. It currently only does one bullet at a time, but I am going to add in code to have a bullet buffer. I managed to figure out a way to make sure bullet movement was not bugged except for one case with an acceptable bug (I think). Shooting vertically will cause it to shift 1 pixel off course, but I don't think that should be a problem. Anyways, see the screenshot

EDIT: Updated the code, now it uses a bullet buffer. It currently handles 64 bullets on screen at a time and it is still at 6MHz. Feel free to use any of the code or look at it or whatever!

Hmm, I recognise the problem, but I did not see the issue in your source code immediately. Hopefully I will take a look at it tomorrow and possibly figure out the issue.

I would also like to point out that you can do signed comparisons. For example, {J-6}<<0 to see if it went below zero. I think Axe probably does an auto-optimisation for that.


I tried my attempt above and found that it doesn't work (I forgot some of the nuances of Axe ). I did get it to work in BASIC, though.

Hey LemonDrop, I am not sure if this is the Bresenham method, but this is a line drawing algorithm I came up with a few years ago that is fast and easy to implement in Axe, Assembly, BASIC, Grammer -- you name it. Modified, instead of drawing a line, you can make a bullet follow a trajectory. This will also work smoothly using the the inflated coordinates that shmibs was referring to (this is an excellent technique, especially when you start doing physicsy things) or just the regular 96x64 pixel area. Anyways, the basic pseudo-code looks like this:
;Given : (x1,y1) and (x2,y2)
x2-x1 → width
y2-y1 → height
1 → xinc
1 → yinc
If width>0
1 → xinc
Else
-1 → xinc
-width → width
If height>0
1 → yinc
Else
-1 → yinc
-height → height
If width=0
y1 → count
while count <= y1+height
plotpixel(y1,x1)
x1+1 → x1

else
width → accumulator
width*2 → width
height*2 → height
0 → count
while count < width
plotpixel(y1,x1)
y1+yinc → y1
accumulator - height → accumulator
while accumulator < 0
x1 + xinc → x1
plotpixel(y1,x1)
accumulator + width → accumulator
plotpixel(y1,x1)
While that may look complicated, it actually simplifies quite a bit when put in use. To describe the algorithm, there is an accumulator that starts at 1/2 the width (because we are using integers, I store the width to the accumulator and then double width and height, so the accumulator is half the width). Then at every cycle, a much more general algorithm might increment y and add height/width to to x. However, we cannot use non-integers, so we need to be more clever. This is why I have an accumulator. What we could do is add height to the accumulator and if the acc>width, then we need to increment the x coordinate. To determine how many times we need to increment, just subtract accumulator-width until accumulator<width, each time incrementing x and plotting a pixel. In the algorithm above, it is more optimised for assembly and instead of doing accumulator+height, I do accumulator-height until accumulator<0 (which the processor automatically recognises without needing to do a compare).


Anyways, now for some actual Axe code! (Note: I am not a very knowledgeable Axe coder, so there may be many optimisations to be had!) The first thing we are going to need to take note of is that we aren't drawing a whole line at once (unless you are making a laser effect) so it will be more useful to make a subroutine that returns the coordinates of the next pixel. As well, in the event that we have multiple bullets on screen, we might want to make the routine even more flexible to work with a buffer of bullet data so that we don't tie up variables.
Here we go:
Lbl BNEXT
.IN: Ptr
.accumulator,dir,x,xinc,w, y,yinc,h,counter
{r1}→r3
!If {r1+1}
r1+4→r1
{r1++)→r2+{r1++)→r2
r3-{r1++}→r3→{r1-8}
r3<<0→{r1-7}
Else
r1+1→r1
{r1++)→r2+{r1++)→r2
r3+{r1++}→r3→{r1-5}
r3<<0→{r1-4}
r1+3→r1
End
{r1-5}→X
{r1-2}→Y
If {r1++}--
Return
End
r1-8→r1


Lbl DELB
.REMOVE THE BULLET
Return!If {GDB1)
Exch(GDB1Z,r1,9)
{GDB1}--
Return

Lbl ADDB
.IN: (x1,y1,x2,y2)
ReturnIf {GDB1}=10
{GDB1}++→r6*2*2*2+r6+GDB1-9→r6

r3-r1→{r6++}→r5=0→{r6++}
r1→{r6++}
0→{r6++}
If r6>0
1→{r6}
ElseIf r6>32767
-1→{r6}
-r5→r5
End
r5→{r6++}
r5→{r6+4}

r4-r5→{r6++}→r5=0→{r6++}
r2→{r6++}
0→{r6++}
If r6>0
1→{r6}
ElseIf r6>32767
-1→{r6}
-r5→r5
End
r5→{r6++}
Return

I have not tested that code, so I doubt it will work, but just in case it does, GDB1 should point to a buffer large enough to hold the bullet data (in the code above, it limits to 10 bullets, so 9*10+1 = 91 bytes). This buffer should be zeroed, and GDB1+9*9+1→GDB1Z should be defined (GDB1Z points to the last bullet).
The 3 routines, if they work, are:

BNEXT(ptr) : ptr points to 9 bytes of bullet data. Returns X,Y as the coordinates of the bullet.
DELB(ptr)  : ptr points to the 9 bytes of the bullet data to remove from the bullet buffer.
ADDB(x1,y1,x2,y2) : If there is room on the bullet buffer, the bullet trajectory is added.

As a note, BNEXT automatically removes the bullet if it reaches its destination coordinate. If you want it to continue past the destination until it goes offscreen, the code can be modified.


I hope it works, but I am too tired to test it tonight. I need sleep

Yeah headphones might be a concern if someone writes a counterfeit copy of an existing program allowed at a test that actually tells the test answers with headphones plugged in or something. However, no headphone support might be annoying for other students who constantly hears a calc talking.

Oh, I hadn't even thought of that o.o I was more thinking about during math tests, without headphones your calculator would be telling all of your answers out loud.

I haven't added in any of the shell parts that I wanted to add in, yet, but I did rewrite parts of the graphics code. I am emulating the screen with a different approach and that allowed me to make a slightly faster LCD update routine and a much faster clipped sprite routine. The end product is about a 23% speed boost in my pong example

Also, going through the code, I think I can try to give it much better organisation and possibly reduce the size and increase the speed. It is quite a mess at the moment.

Oh my gosh, I totally want to learn enough ARM assembly to do that on my NSpire o.o

Hmm, maybe something like this? :
SortA(L1,L2
sum(not(ΔList(L1) or ΔList(L2

EDIT: This assumes the lists have more than 1 element. Also, nice idea with the matrixfeytontias stuff.