Omnimaga
Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: Raylin on September 13, 2010, 07:18:14 pm
-
I think a lot of my Axe programming may be limited by my tendency to use BASIC.
Could someone just tell me how fast Axe is?
Thanks.
-
Extremely Fast. I wish you luck on learning it. :)
-
very fast. slower than asm; granted; but axe is compiled into z80 ASM code... it's just that axe is built to be general-purpose, for all sorts of games, while an asm game would use routines designed specifically for the type of game their making. axe can be as fast as ASM, though.
-
So fast that if you use getKeys (to increment an number, for example), you have to use delays to make sure that you don't overshoot by pressing too long.
You know, for example.
-
A lot of stuff is pretty much the same speed as z80 assembly, or very close. The code in general is a bit larger than BASIC, but data is considerably smaller. The reason why it's so fast is because the compiler translates the code to something extremly close to optimized ASM and the fact it is compiled instead of interpreted makes it even faster than something like BBC Basic, for example.
-
Much of Axe's speed is not just because of its being compiled into asm, but also because of its efficiency. What this means that it you convert a basic game directly to axe with no modifications to the code, it will be faster. If you recode it from scratch using axe concepts, it will be many more times faster.
That being said, Axe is crazy fast ;D
-
So fast that there's no reason to learn ASM if you have trouble with it. I wouldn't be surprised if half the new games on ticalc.org were written in Axe
-
Amazingly fast
0->A
While A<1000
Output(1,1,A
A+1->A
End
Try that in basic and with Axe try
.Some name that you don't have a program named already
0->A
While A<1000
Output(1,1,A >Dec
A+1->A
End
See what happens
-
Ya, it's crazy fast. It's basically what Nemo said though. Axe is technically just as fast as assembly since it is compiled into it. The reason it can appear to be a little slower is because the routines are generalized for overall game making, again like Nemo said. What could take a few lines in assembly (this is strictly concept, not example) since it is directly for the purpose of the game might take a twice as much in Axe since the manipulating is using multiple things to create the effect.
-
Do not refresh the display every sprite, though. Refresh it once per loop, else prepare for extreme slowness, thanks to TI crappy LCD driver. I am sure if TI-BASIC didn't update the display everytime something gets displayed it would be much faster (although not even close to Axe)
-
Yeaah, i once had an idea to write hooks that overwrote the graphics commands (there really arnt that many) to draw only to the buffer, and use another token to refresh. And with very small modification Basic programs could run even faster! And if it was a token like real(0), the Basic program could even be run without the hooks for normal effect, and then if you wanted to, you could install the graphics hook and much faster :D
-
Craaazy fast. It's basically unoptimized ASM speed.
-
I wouldn,t say unoptimized, personally. I am sure Axe games for the most part could run much faster than most old ASM stuff on ticalc.org
-
I wouldn,t say unoptimized, personally. I am sure Axe games for the most part could run much faster than most old ASM stuff on ticalc.org
Unoptimized means you didn't make sure your program could run as fast (and as small) as possible. If an Axe game runs faster than an old ASM program on the same calculator, the ASM program was not optimized. I'm afraid I have to agree with Deep Thought here.
-
Yeah but I mean, I am fairly sure that for a RPG, you can get much faster speed than Joltima for smooth scrolling. In Joltima, it scrolls by 2 pixel interval instead of 1. Axe won't be as fast as ASM but it will sure be faster than some old stuff I saw back in the days, made back when there was little z80 documentation available.
-
Yeah but I mean, I am fairly sure that for a RPG, you can get much faster speed than Joltima for smooth scrolling. In Joltima, it scrolls by 2 pixel interval instead of 1. Axe won't be as fast as ASM but it will sure be faster than some old stuff I saw back in the days, made back when there was little z80 documentation available.
Agreed. When you had little at your disposal, ASM programming was more of a nightmare, so there was only so much you could do before you gave up on a project. Axe does do better in that case. Again, stuff like Joltima was not edited for being as fast as possible.
EDIT: I'm now a veteran!
-
BASICally, it's like C, but for a calc.
-
I think a lot of my Axe programming may be limited by my tendency to use BASIC.
Could someone just tell me how fast Axe is?
Thanks.
When I first switched to Axe, I converted a program I had written in BASIC to Axe. The program ran between 30 and 40 times faster in Axe with a 1:1 conversion between the languages. If I had optimized the Axe code, I could easily have doubled that.
However, I determined that a god portion of that lag was the LCD driver. When I eliminated the differences in Driver time, it slowed down to about 20 times the speed.
-
It depends on what you're trying to do. Somethings take almost the same amount of time like "Disp", "Output", and "ClrDraw" for instance because they are basically the same routines. The only speed increase there is the absence of the interpreter.
Other things like storing to variables, math, and reading from lists are hundreds of times faster than BASIC becasue you are dealing with 16-bit integers instead of 72-bit floats. Native assembly is even faster still because you can use registers for temporary storage and decide when you need the faster 8-bit operations instead of the 16-bit ones, but the difference is only 1.5 to 2 times the speed generally.
The rest of the commands like sprite drawing, grayscale, copying data, etc. are pretty much the exact same speed as regular assembly because its literally replacing those with the same routines you would use if you were programming in regular assembly except I've spent the time to optimize them to be as fast as possible.
I can't really compare Axe to BASIC much more than the math commands becasue things like sprite drawing don't exist in BASIC. Pixel drawing is the same speed in BASIC and in Axe if you're updating the screen after every pixel. But if you draw all the pixels first and then update the screen when you're done, you can fill the entire screen in about half a second since updating the LCD is so slow. The best way to see "how fast it is" is to just try running some programs like "How long does it take to draw 10,000 sprites?" (about 3 seconds) "How long does it take to do 10,000 multiplications?" (about 2 seconds) etc.
-
"How long does it take to draw 10,000 sprites?" (about 3 seconds)
If that's without refreshing the screen every sprite, I remember than in unoptimized ASM it's about .5 seconds...
-
That includes aligning and clipping in every direction which sometimes is not used in regular assembly when you don't need those and I have a feeling a lot of that time actually went into the for loop I was using since it took almost a second even with nothing in the loop.
-
I posted screenshots of speed difference when updating the screen everytime you turned a pixel on, everytime an entire row was turned on and once it was done. When updating every pixel, it looked like I was running a BASIC program.
Home screen functions are also very slow (TextShadow?), because it uses TI's routines, which are already slow. Text() isn't too fast either. I think even with a pure ASM game, you won't get much more than 10 FPS if you make a home screen game with maps and stuff.