Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: GreenFreak on July 10, 2011, 07:52:48 am
-
Hi!
I often write that, if I want to move a sprite, that can't leave the screen (you know what I mean?):
If getKey(1) and ({38+L1}^r≠48)
{38+L1}^r++
ElseIf getKey(4) and ({38+L1}^r≠0)
{38+L1}^r--
End
If getKey(2) and ({36+L1}^r≠0)
{36+L1}^r--
ElseIf getKey(3) and ({36+L1}^r≠63)
{36+L1}^r++
End
(It's for a 16*32 sprite ;D)
x position: {36+L1}^r
y position: {38+L1}^r
But this code looks very unoptimized...
Do you know a more optimzed code to do the same?
Can you explain, how it works, too?
Thanks ;)
BTW: I searched for the "≠" a long time :P
-
Well, runer is reading this and will have a better solution than me and most likely even ninja me, but I can say that you should put things like X>0 and then later X<63 instead of using inequality signs.
For optimization, I'll let runer do his lingo, Im not in the mood to think about the different opts right now.
-
Ok, thank you Ashbad...
I'll wait for other posts...
-
actually, i have a question to ask as well. which is more optimised?
if getkey(3)
+x->x
end
or
if getkey(3)
x++
end
the ++ and -- commands are a bit new, so i'm not sure how to go about using them yet. is there a difference in Inc vs. add in the way these are compiled?
-
That's a question for Runer112^^
-
For 16-bit values, blah++ is the same as blah+1->blah. Incrementing 8-bit pointers are where it actually gets optimized.
-
actually, i have a question to ask as well. which is more optimised?
if getkey(3)
+x->x
end
or
if getkey(3)
x++
end
the ++ and -- commands are a bit new, so i'm not sure how to go about using them yet. is there a difference in Inc vs. add in the way these are compiled?
The second one is more optimized, 7 bytes and 38 cycles versus 8 bytes and 47 cycles. And as calc84maniac said, for 16-bit variables V++ is exactly the same as V+1→V.
Back on topic, here's the most optimized code I could produce. It's 90 bytes versus the original code's 142 bytes. It will look a little messy, but that's to be expected of very optimized code. :hyper: Also, when the user presses the left and right keys or up and down keys at the same time, instead of moving in one of the directions, you simply do not move. Hopefully this is an acceptable change. If not, tell me and I'll try to produce some slightly less optimized code that accounts for this. This code also assumes that you haven't reallocated the Axe variables. If you have, change the blank #Realloc() on each of the first two lines to point to that reallocated section.
min(getKey(1)#Realloc(38+L₁)+A#Realloc()-getKey(4)sub(CN1)-1,48)→{38+L₁}ʳ
min(getKey(3)#Realloc(36+L₁)+A#Realloc()-getKey(2)sub(CN1)-1,64)→{36+L₁}ʳ
.Correct negative 1
Lbl CN1
ReturnIf +1
+1
Return
-
wow O.o
It's soo optimized that i don't understand it...
And what do you mean with "haven't reallocated the Axe variables" ???
Thanks ;)
EDIT: I replaced my code above with your code, but if I run the programm, the up and down key both move the sprite down, and the left and right key both moves the sprite to to right... :-/
EDIT2: .Correct negative 1
Is this a task for me or the job of the subroutine?
-
I don't get it work :(
-
Wait, so +{const}r isn't optimized automatically? :O
-
I don't get it work :(
Oh sorry, I typoed when copying that code from my calculator to here. +getKey(4) and +getKey(2) should be -getKey(4) and -getKey(2).
Wait, so +{const}r isn't optimized automatically? :O
Nope. It bugs me a bit that Axe doesn't recognize those and parse them just like variables. I'm guessing Quigibo hasn't included them because he would need some sort of look-ahead parsing for that, which he hasn't implemented.
-
I think I can add this since I do have simple look-ahead routines now. I just forgot about it.
-
Really!? :w00t:
-
Ah! Now it works better!
But there a new problem :-\
If I go up or left, I'm on the other side...
Do you understand me? :P
Sorry, but is it a problem, if I don't understand that?
What advantage would this have?
-
I'm probably stating the obvious here, but since the getkey(num) routine returns 1 or a 0, you can use it do something like this:
Instead of :
If getkey(1)
Y+1->Y
End
use:
getkey(1)+Y->Y
which could be extended to
getkey(1)(Y<63)+Y->Y
if you didn't want to go off the screen, and
Y+(getkey(1)(Y<63))-(getkey(2)(Y>0))->Y
if you also wanted to go down, and
Y+(2*(getkey(1)(Y<63)))-(2*(getkey(2)(Y>0)))->Y
if you wanted to go faster.
(forgive me if i'm abusing my parentheses rights)
However, I'm sure you can see that this can be continuously extended forever and ever, worlds without end, amen, until it becomes a formless mass with no appearance of readable code whatsoever. So be careful. Use Boolean Logic to your advantage, especially if you're into optimization and you comment your source code well enough that code readability isn't a huge deal.
-
Ah! Now it works better!
But there a new problem :-\
If I go up or left, I'm on the other side...
Do you understand me? :P
Oh sorry, I found the problem and corrected it. I needed to check if the position became negative one before performing the min function. Check the code again, hopefully it should work now.
-
Works great :D
Thanks Runer ;)