Hmmm 3x3 boxes didnt solve the Portal problem, i was mistaken...  Hmmmm and the 3x3 is harder to simulate than i thought.  Requires 2x the pixel testing to simulate accurately without error...  Hmmm i hope i can make it work

ouch, sorry to hear , I hope you can get it figured out soon.

One thing I wonder: I forgot if you were planning to make a level editor once the game is finished?

yay!

I have a version of Axe that compiles the App, so memory isnt a problem anymore.  I have just been using MirageOS because it has a faster compile time, and as of now my program is still small enough to be run.

On a different note, i discovered that my game engine spent roughly 18% of its time multiplying by 18 o.O Since i was multiplying by 18 in my collision code, things were slowing down.  Soooo i changed

A*18
to

A*2*2*2*2+A+A
And almost 18% of the computational time has been removed .  Also, Quigibo, correct me if im wrong, but boolean expressions in Axe are actualy slower than their corospondinf If Statements right?  So

X-51->D
If A>30000
D+307->D
End
is faster than

A>30000*307-51+D->E
Right?  Since one multiplies by 307 and the other does not.

Nope, it compiles to about 9100 bytes so noStub isnt possible right now.  Lucky for me the 9100 contains enough data so that it still works in MirageOS. 

Yeah for Nostub the limit I think is 8100 bytes about including data.  Silly TI

Yeah for Nostub the limit I think is 8100 bytes about including data.  Silly TI

Actually that's not entirely correct. You can have approx. 8100 bytes of executed code, but your data can extend beyond that limit. As long as you don't execute across the 8100 line ($C000), you're fine, so reorganizing data sometimes pays off. (i.e. putting it all at the end of the program binary)

EDIT for the nitpickers: This holds in the standard memory mapping. If you swap in an uneven-numbered RAM page in the $C000 bank, you'll be safe to execute code, but that's not really the best way to deal with the problem (cue OS freakout on every interrupt => CRASSHHHH)

Offtopic edit: this semi-useful post is my #400. I'm still the staff member with the lowest postcount, though.

quigibo, is there a list of auto-optimized mulitiplication/division/signed division etc. numbers?

Actually that's not entirely correct. You can have approx. 8100 bytes of executed code, but your data can extend beyond that limit. As long as you don't execute across the 8100 line ($C000), you're fine, so reorganizing data sometimes pays off. (i.e. putting it all at the end of the program binary)

Thats true for MirageOS or other Shells, but for asm program run from the home screen, data counts.  try this in Axe:

.Axe
Zeros(9001)->Str1
Output(0,0,"OHAI
you get an Asm program thats mostly data, and yet the TiOS throws an Error Invalid upon execution.  The limit on the home screen is about 8100 of program size.  The limit for shells is about 8800 of executable.

And thanks Quigibo I need to check the auto optimizations list more often, and stop being a silly programer thanks!