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 )
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

Ok, thank you Ashbad...
I'll wait for other posts...

That's a question for Runer112^^

actually, i have a question to ask as well. which is more optimised?

Code: [Select]

if getkey(3)
+x->x
end
or

Code: [Select]

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. 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


I don't get it work

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.

Really!?

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.