Quote from: Runer112 on July 30, 2011, 04:00:28 pm

Well that's a whole other problem entirely.

Really? It just seems like it's skipping a byte. I can replace minY with, say, +^r and it still ignores that first byte. (That is, it does the same thing as the code I gave earlier.)

That certainly does explain why there's an error with ++, and also why n r's are parsed as n-1.

There's a bug in 1.0.2 that I can't place very well. In my game The Slime, there is a bit of code that adjusts the scrolling view window for the tile environment. The code worked perfectly in 0.5.3b, but in the newer version, scrolling goes beyond the right and bottom of the view, revealing the other side of the level on the right and garbage on the bottom:
{L1} = level width
{L1 + 1} = level height
X & Y = slime's top left coordinates
U & V = camera's top left coordinates

Lbl GAM
...update the slime...
sub(CAM
...draw everything...
Return

Lbl CAM
X-41?U:Y-30?V
U>=>=0*U?U
V>=>=0*V?V
If {L1}-12*8<U
{L1}-12*8?U
End
If {L1+1}-8*8<V
{L1+1}-8*8?V
End

I tried changing the If blocks to min( expressions that did the same limiting (min(VAR,CAP)?VAR), and I got the exact same problem. And I know that it isn't a problem with the level boundary definitions, because the slime collides with where they are supposed to be, even in the new version of Axe. Do you know what is happening?

EDIT: Here's the link to the topic: http://ourl.ca/11736/232631

It might be the same problem as above. Axe 1.0.2 seems to skip a byte after dereferenced constant addresses.

Yup, that's it! The goalpost also uses dereferenced addresses to store its position, and it is always drawn at 8-U,8-V!

It might be good if Axe is open-source it might be good that someone else double-checks the compiling code and stuff to be certain the bug is totally gone.

Btw Quigibo Fishbot edited the 3 Axe 1.0.x release posts to add red warnings about calc damages and using it at their own risk, because it seems it can damage calculators with no way to recover.

Well, p2 tried a rom clear, mem clear, the testing flash thing with ON+MODE, OS reinstall, etc. None of them worked. As for Zeldaking, after messing up his calc, it caused TI-Connect to no longer recognize his calc anymore, but it could just be TI-Connect being bad. As of now a Mem clear didn't fix his problem.

As for 1.0.2 I heard it still happened, to a lower extent, but maybe it was a different bug that does something else.

I'm also having some issues, though not as serious as p2 or zeldaking.

I'm not sure if the culprit is Axe 1.0.2 or zStart 1.2.013, as when zStart was the only thing installed on my calc after a ROM clear and fresh OS installation, the run on RAM clear feature worked perfectly. I then proceeded to send my other apps back, though Axe was the only one I installed. I wrote a simple program, just drew a few rectangles, inverted some text, and XOR'd a sprite, compiled and ran it. No issues. Then, when I RAM cleared, zStart did not kick in, and I've had some interesting issues when I tried to uninstall and reinstall the run on RAM clear feature, such as a ERR: MEMORY when I went to the memory clear menu, or my contrast value being 104. If run on RAM clear is not installed, I have no issues.

I'm also going to post this in the zStart topic, as I don't know which app is at fault.

Run and pray, that sounds like what happened to me. After the memory issues I had no issues and then *whambo* I got hit.

Did you have Axe 1.0.? or zStart installed when your calculator bricked itself? 

I hope this problem is solved so that no other projects are lost and no more calcs have to break