Here is the list of bugs I have discovered in Axe 0.5.3:

• 16-bit/16-bit division is broken and will always return zero! (See this post) Very bad!
• Except for bitwise operations, every mathematical auto optimization that results in no compiled code crashes when compiling! Also very bad!
• [Pre-existing] flipH() can produce a garbage sprite; see this post
• [Pre-existing] The //0 optimization (and the result of //(0) for that matter) is not mathematically correct due to being a signed operation
• [Pre-existing] The ^65535 optimization is not mathematically correct

Also, this isn't a bug, but could you add arbitrary buffer support to DispGraph^rr? I put the buffer loading at the very start of the routine and added the push hl / pop hl specifically for this awesome purpose.


EDIT:

Quote

Commands.htm still says that DispGraph^r and DispGraph^rr will not work at 15MHz.

I'll fix that.

By the next version perhaps?

I still have 0.5.2, and
pxl-command->buffer does not work
Copy(PTR,L6,SIZE) does not work
Btw, is pxl-test()->buffer supposed to work or not?

The main thing I'm concerned about with new pixel buffer commands is what I'm supposed to do about pxl-Test() which is half the reason you would use the command in the first place.  It looks too funky to have pxl-Test(X,Y)->P->A mean reading a pixel on buffer P into value A.  I guess I could have an optional 3rd argument instead so it looks like pxl-Test(X,Y,P)->A but this is inconsistent with the sprite drawing to buffers.  I would like consistency so I would rather change Pt-On(X,Y,S)->P into Pt-On(X,Y,S,P) as well if I did that, but that involves a compatibility issue.  I guess this is something to resolve before 1.0.0 because I don't want to make changes like this after.  Unless anyone is really against the change, I will probably change to the new syntax.  I never really liked the original storing syntax anyway, its not really any more intuitive than an extra argument, I don't remember why I did that in the first place.

I personally like the argument syntax as well. I think DispGraph(L₃) looks better than L₃→DispGraph, too. This would also make DispGraph(L₆,L₁)^rr a possibility. *hint hint*


EDIT: And in response to Freyaday, since Pxl-Command()→Buffer isn't supported, Pxl-On(W,0)→I not only doesn't operate on the bytes pointed to by I, but it stores a value into I, overwriting the value you want it to hold. That's probably why you're not seeing what you want from the copying.

I personally like the argument syntax as well. I think DispGraph(L₃) looks better than L₃→DispGraph, too. This would also make DispGraph(L₆,L₁)^rr a possibility. *hint hint*

That sounds awesome, and I second the DispGraph(L₆,L₁)^rr idea.

Quigibo, why don't you release a 0.5.4 or a 0.6.0 version with all of the current bugs fixed instead of pressuring yourself to have it all fixed by 1.0.0.
Edit:  Never mind:

I re-uploaded a fixed version so you won't have to wait until 1.0.0

ClrDraw
For(A,0,767)
{A+L6} and (255)→{A+L6}
EndMakes a solid black screen.  Works fine. However,
ClrDraw
For(A,0,767)
{A+L6} and ([FF])→{A+L6}
End...makes a bunch of vertical bars, when it looks like it should do the same thing.

I'm not sure if this is a bug or if there's something different about hex chars...

EDIT: nvm, need to use _EFF instead of brackets

Technically, that's an illegal use of a comment.  They're only supposed to start a line and not be put inline with other commands.  I don't check for that though because some people like to abuse it.  I guess I should either check or fix this.  There are other places that would have this problem too that I can think of.