Please correct me if I'm wrong, but shouldn't that greater than sign be a less than sign? The addition carried if the 16-bit result is less than a 16-bit input.

Also, I think you need an ^r modifier on the end of the last line.

Also, optimization: (Me optimizing Quigibo's code? It must be backwards day!)
:Lbl ADD
:{r₁}ʳ→r₅+{r₂}ʳ→r₄
:<r₅+{r₁+2}ʳ+{r₂+2}ʳ
:→{r₄→{r₃}ʳ+1}ʳ
:Return
You could also optimize it a bit more by restructuring the inputs to be in the order of (result,input1,input2):
:Lbl ADD
:{}ʳ→r₅+{r₂}ʳ→r₄
:<r₅+{r₃+2}ʳ+{r₂+2}ʳ
:→{r₄→{r₁}ʳ+1}ʳ
:Return

BUG:  Don't Quote Me!

I show best by example.


Text(5,10,"HELLO"
Text(5,30,"WORLD!"


When compiled it will give an ERROR: BAD SYMBOL  at the 2nd Text(

I fiddled around with it for a while, and to make it work, you have to change it to this V

Text(5,10,"HELLO
Text(5,30,"WORLD!

What is that about?

At first, I had no problem with this bug because it stems from not closing parentheses, which is understandable. However, I just discovered a more problematic instance of this bug. The "Text " command (Non-Axe token: "DrawF ") actually has a hidden opening parenthesis. In similar fashion of closing quotes but not closing parentheses, the following line of code will produce errors:
Text "HELLO WORLD!"In this case, adding a closing parenthesis will resolve any errors again, but it doesn't logically make sense to do so based on the command not containing an opening parenthesis. Could you please either look into this issue or assign a new name to the "Text " command that contains an opening parenthesis?

EDIT: By random chance, briefly after posting this I discovered that this problem also exists when using inline data in square brackets as the argument. Also, "DelVar " has the same affliction.

What happened to this?

One feature I'd love is to be able to move the image around, like the select tool in some image software.  I know it's possible from experience, but I'm not sure you could implement it efficiently.

That sounds really hard to implement... Let's try it anyways! *Puts on list*

EDIT: I also added palette changing, as I thought about it before but it seems to have missed making the list. By palette changing I mean things like changing all dark gray pixels to light gray and changing all light gray pixels to dark gray. This could also be used to invert images.

Sorry, I couldn't help myself. For some reason when I saw this thread I impulsively decided to try to optimize to oblivion whatever code I saw.

761 bytes → 486 bytes

.SPRWKTWO
[7E81A58181DB423C]→Pic0
[7E81A581A599817E1866A5A5BD24246C]→Pic1
[1866A5A5BD242436]→Pic2
[4949414149494141]→Pic3
[FF0000CC0000FF00]→Pic4
[90D8B681BD81FE88A8A8A8A8A8A884FE]→Pic6
[091B6D81BD817F11151515151515217F]→Pic7
[030404043F40807F]→Pic8
[C0202020FC0201FE]→Pic5
[80502070888888889090505050505020]→Pic9
[]→GDB0
∆List(0,0,Pic0-Pic0)
∆List(0,10,Pic1-Pic0)
∆List(0,18,Pic1+8-Pic0)
∆List(0,30,Pic1-Pic0)
∆List(0,38,Pic2-Pic0)
∆List(10,0,Pic3-Pic0)
∆List(10,8,Pic3-Pic0)
∆List(10,16,Pic3-Pic0)
∆List(10,24,Pic3-Pic0)
∆List(10,32,Pic3-Pic0)
∆List(10,40,Pic3-Pic0)
∆List(0,50,Pic4-Pic0)
∆List(8,50,Pic4-Pic0)
∆List(16,50,Pic4-Pic0)
∆List(24,50,Pic4-Pic0)
∆List(32,50,Pic4-Pic0)
∆List(20,0,Pic6-Pic0)
∆List(20,8,Pic6+8-Pic0)
∆List(20,18,Pic7-Pic0)
∆List(20,26,Pic7+8-Pic0)
∆List(30,1,Pic8-Pic0)
∆List(38,1,Pic5-Pic0)
∆List(50,0,Pic9-Pic0)
∆List(50,8,Pic9+8-Pic0)
ClrDraw
conj(GDB0-1→P,ᴇ9900+GDB0-Pic0-1,GDB0-Pic0)ʳ
While -ᴇ9407
Pt-Change(sub(PP1),sub(PP1),sub(PP1)+ᴇ9900)
End
DispGraph
Text(40*256+50)
DrawF "David Gomes
Repeat getKey
End
Return
Lbl PP1
{P+1→P}

This sounds really cool!  How about different size tools for the point on/off?  Like a 1x1, 2x2, 4x4 space by each.

I completely forgot about that. I'll definitely want to make sure that you can change the pen size for all drawing commands.

Maybe the user could set it as an animation and, after they've drawn the sprites, he could preview it?
Wait--is that already planned?

Already planned.

I know this one would be hard, but how about this:
Pressing [On] and [Vars] at the same time would launch the sprite editor if you were editing a program.  When finished editing sprites, you would return to the same spot in the program you were editing.
Sounds like fun to code.

I'll probably end up writing this in Axe, so hooks are probably out of the question. Not to mention I know nothing about hooks in the first place. But you never know. If I figured out how hooks could work it might be possible to code the hook in assembly and just insert it into the rest of the Axe source.

I noticed that bug/flaw too and tried to correct it, but it didn't work right for me.

I noticed another part of your code that could be improved upon, though. And this may actually be the cause of the above fix still not looking right. (Possibly not, though.) When you advance the ray, it doesn't always return a very accurate distance to the wall it collided with because of the relatively large, constant step system you use to advance the ray. You could reduce the step size, but then calculations would be much slower.

The method most commonly accepted as the quickest and most accurace raytracing method is to track where the ray hits cell boundaries. I'm not really sure how to explain it accurately without confusing both you and myself, so I made a picture instead.

The ideal method of tracing infinitely small steps is on the left. Your method of following a constant step size is in the middle. As you can see, the two illustrated rays will return the same length, although they clearly are not the same length. And the method that seems to be generally accepted as the best raytracing method is on the right. I've always had trouble wrapping my head around how to correctly implement that, but if you succeed, it should work quite well and speedily.

Well that's at 15MHz, so it runs really fast. But I did some rough testing and my modification makes it run about twice as fast at either 6MHz or 15MHz.

I figured that the slowest part of the engine was probably drawing the lines, so I decided to work on that. I did cheat a bit, though, because the speed boost was from a hand-written assembly routine. It took me a few hours, but I managed to make a special case vertical line drawing routine. For drawing vertical lines, it's on average probably 5-10x faster than the normal line drawing routine. I might submit it to Quigibo so he can add it as a built-in feature, although I don't know if it has enough circumstances in which it would be useful to warrant its addition into the standard command set. But then using it wouldn't be cheating any more.

Anyways, I don't think Axioms are working right now so I had to sort of hack together a method to use it as a fake Axiom.
.X coordinate
Z-{L1}+40Asm(E5)
32/E→H
.Y1 coordinate
32-HAsm(E5)
.Y2 coordinate
H+32sub(VL)
... Later in the code, as a subroutine:
Lbl VL
Asm(D1C1EBE3C501A0FF093856E3AFCB7C2803676F3CCB7A2805B72046575FAF0EC00930033D676FEB093005B72034626A7B953003ED44EB3C012C8F545D29192929095FC13E0747A157A90F0F0F4F094204AF3F1F10FD4F43110C0079B6771910FAC9E1)
Return


EDIT: I just realized that you could draw rectangles of width 1, too. It's slower than this routine, but it's built-in, simpler to use, and still a good deal faster at drawing vertical lines than the line routine.