How quick is Axe?

[Hot_Dog]

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!

[Deep Thought]

BASICally, it's like C, but for a calc.

[AngelFish]

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.

[Quigibo]

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.

[Hot_Dog]

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

[Quigibo]

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.

[DJ Omnimaga]

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.