Omnimaga
Calculator Community => Other Calculators => Topic started by: LincolnB on October 13, 2011, 10:33:04 am
-
Hey, so, in the interest of all Axe programmers who want to squeeze as much out of their calculator as possible, I think we should start a contest of sorts, to see who can make a given chunk of code as small as possible.
The way it'll work will be like this: Someone posts a chunk of Axe Parser source code that they want to have optimized. It must not be longer than about 50 lines, but 60 is the absolute max. Then, everyone will post how they would optimize it. When you post how you would optimize the code, post your source, with code tags, and post the size of the compiled executable file, in bytes. That's important. We're not optimizing to get the smallest source code, we're optimizing to get the smallest executable. Thus, optimizing out comments will help you nothing, if you're looking to win.
The winner of any given competition gets serious bragging rights, and I'm sure also more respect and lots of +1s for his post.
Important Points:
> We're trying to get the smallest possible executable. We don't really care how bloated the source code is, with comments and whatever else.
> Optimize for size, not for speed. Size optimizations can be much more accurately measured and calculated than speed optimizations.
Ok. I'll start.
prgmTEST
.TEST2
0->X->Y
Repeat getkey(15)
If getkey(1)
Y+1->Y
End
If getkey(2)
X-1->X
End
If getkey(3)
X+1->X
End
If getkey(4)
Y-1->Y
End
ClrDraw
Pt-On(X,Y,[FFFFFFFFFFFFFFFF]
Dispgraph
End
Compiled Size: 358 bytes
Compiled for No Shell, using Runer's bugfixed version of 1.0.3
You can compile for any shell you want, and using whatever version of Axe you want, whatever's smallest.
Optimize, GOGOGO! Remember, retain all the functionality of this current program. Add no features, take away no features. Simply optimize the living crap out of this thing.
-
prgmTEST
.TEST2
0->X->Y
Repeat getkey(15)
getkey(1)?Y++
getkey(2)?X--
getkey(3)?X++
getkey(4)?Y--
ClrDraw
Pt-On(X,Y,[FFFFFFFFFFFFFFFF
Dispgraph
End
356 bytes
EDIT:Nvm. 358 bytes
EDIT2: Can this be optimized at all?
-
Here's a small optimization (355 bytes):
prgmTEST
.TEST2
0->X->Y
While 1
getkey(1)?Y++
getkey(2)?X--
getkey(3)?X++
getkey(4)?Y--
ClrDraw
Pt-On(X,Y,[FFFFFFFFFFFFFFFF
Dispgraph
End!If getKey(15)
-
Here's a small optimization (355 bytes):
prgmTEST
.TEST2
0->X->Y
While 1
getkey(1)?Y++
getkey(2)?X--
getkey(3)?X++
getkey(4)?Y--
ClrDraw
Pt-On(X,Y,[FFFFFFFFFFFFFFFF
Dispgraph
End!If getKey(15)
Fixed 8)
-
Yeah, I just noticed that :P
Also, now 342 bytes:
prgmTEST
.TEST2
and 0->X->Y
While 1
getkey(1)?Yr++
getkey(2)?Xr--
getkey(3)?Xr++
getkey(4)?Yr--
ClrDraw
Pt-On(X,Y,[FFFFFFFFFFFFFFFF])
Dispgraph
EndIf getKey(15)
-
what is that and and r for?
-
what is that and and r for?
Only the low byte of sprite X and Y is significant, so I work with only the low byte.
Edit: 340 bytes!
L1→°XPOS
L1+1→°YPOS
0→XPOS
While 1
getKey(1)?YPOSr++
getKey(2)?XPOSr--
getKey(3)?XPOSr++
getKey(4)?YPOSr--
ClrDraw
Pt-On(XPOS,/256,[FFFFFFFFFFFFFFFF])
DispGraph
EndIf getKey(15)
-
/me has arrived on the scene!
Here's the best I could do while fitting the exact constraints. It's 321 bytes, so it's 19 bytes smaller than the previous best attempt (by calc84maniac) and 37 bytes smaller than the original. Compile for no shell with Axe 1.0.5.
Data(0ʳ)→°XPos
Data(0ʳ)→°YPos
While 1
DispGraphClrDraw
Pt-On(getKey(3)-getKey(2)+XPos→XPos,getKey(1)-getKey(4)+YPos→YPos,[FFFFFFFFFFFFFFFF])
EndIf getKey(15)
Return
The next block of code starts to stray from the original constraints a bit. It still draws the same sprite and it wraps at the boundaries, but it completely abandons regular sprite drawing to a buffer and then updating the screen in favor of using Bitmap() for a large size savings by completely removing the need for two routines. It also wraps much faster because frames when the sprite is offscreen are substantially faster. It's so much faster that the wrapping almost looks instantaneous, but it's not, so it technically wraps correctly. It's 183 bytes, for a massive savings of 138 bytes over my previous solution and nearly half the size of the original code! Again, compile for no shell with Axe 1.0.5.
Data(⁻1ʳ)→°XPos
Data(⁻1ʳ)→°YPos
ClrHome
While 1
If getKey(3)-getKey(2)+XPos→XPos+9^ᴇ100<105
If getKey(1)-getKey(4)+YPos→YPos+9^ᴇ100<73
Bitmap(XPos,YPos,[0A0A00007F807F807F807F807F807F807F807F800000])
FnOff .Sneaky optimized way to disable the run indicator
End
End
EndIf getKey(15)
Return
Finally, the most optimized solution I was able to produce. This bends the rules in the same way as the last block of code, but it also stops the sprite at the edges of the screen instead of letting it wrap. Somewhat surprisingly, restricting the sprite's movement actually made the code smaller (due to lack of otherwise necessary clipping). This may be considered breaking the original challenge, or it may be considered adding a useful feature for free. It's 177 bytes, 6 bytes smaller than the previous solution and slightly less than half the size of the original code! Compile for no shell with Axe 1.0.5.
Data(1ʳ)→°XPos
Data(1ʳ)→°YPos
ClrHome
While 1
Bitmap(min(getKey(3)-getKey(2)+XPos(Bump()),89)→XPos-2,min(getKey(1)-getKey(4)+YPos(Bump()),57)→YPos-2,[0A0A00007F807F807F807F807F807F807F807F800000])
FnOff .Sneaky optimized way to disable the run indicator
EndIf getKey(15)
Lbl Bump
ReturnIf
Return +1
-
Runer wins. :) Unless anyone else can beat 177 bytes?
Anyone have any other code to optimize?
-
How about a line clipping routine?
.CLIPPER
40→X→Y
48→S
32→T
Repeat getKey(15)
X+getKey(3)-(getKey(2))→X→N
Y+getKey(1)-(getKey(4))→Y→O
If N>>95
95→N
(95-S)//(N-S)*(O-T)→O
O+T→O
End
If O>>63
63→O
63-T//(O-T)*(N-S)→N
N+48→N
End
If N<<0
-1→N
~S//(N-S)*(O-T)+T→O
.the squiggly ~ is the negative sign
End
If O<<0
-1→O
~T//(O-T)*(N-S)+S→N
End
Line(S,T,N,O)
DispGraphClrDraw
Pause 20
End
-
/me has arrived on the scene!
<snip Insanity>
This is how the rest of the optimization competitions will generally go :P
-
/me has arrived on the scene!
<snip Insanity>
This is how the rest of the optimization competitions will generally go :P
...I think I have been scarred for life:'(
Obviously, I need to look over the docs again...
-
Before I saw that he'd already arrived, I was gonna ask if there was a rule that Runer112 can't compete or something lol
-
Before I saw that he'd already arrived, I was gonna ask if there was a rule that Runer112 can't compete or something lol
I vote yes!
On a more serious note, I find it amazing that you can do so many things in Axe equally many ways. That is one of the reasons reading runerfied optimized code is so fun. I have been thinking about larger sprite routines, so I might post later about a 16*16 sprite drawer.
-
Yeah, I agree. Anyone have anything on Darl's Line Clipping code? Runer, let a couple other people answer first, mkay? ;)
-
I knew Runer112 was going to win.
-
I wonder if Runner's example could be expanded upon by using a lookup table because the if values are all consecutive. maybe, maybe not but that's all I got.
-
Win? :(
Also, I hate reading optimized code like the axe examples. they should actually not be optimized.
-
.CLIPPER
40→X→Y
48→S
32→T
Repeat getKey(15)
X+getKey(3)-(getKey(2))→X→N
Y+getKey(1)-(getKey(4))→Y→O
If N>>95
95→N
(95-S)//(N-S)*(O-T)→O
O+T→O
End
If O>>63
63→O
63-T//(O-T)*(N-S)→N
N+48→N
End
If N<<0
-1→N
~S//(N-S)*(O-T)+T→O
.the squiggly ~ is the negative sign
End
If O<<0
-1→O
~T//(O-T)*(N-S)+S→N
End
Line(S,T,N,O)
DispGraph
ClrDraw
Pause 20
Enddispgraphclrdraw is said to be very huge.
-
It's smaller than DispGraph and ClrDraw called separately as long as they're not used elsewhere already IIRC.