Author Topic: Optimisation help request  (Read 4728 times)

0 Members and 1 Guest are viewing this topic.

Offline starfighter

  • LV0 Newcomer (Next: 5)
  • Posts: 2
  • Rating: +0/-0
    • View Profile
Optimisation help request
« on: July 26, 2018, 01:26:24 pm »
This is a thing I did yesterday in an hour or so, and I was wondering if anyone had the time and knowledge to help me get some speed out of this thing, if possible. Sorry if the code is bad. The .8xp is also attached.
The "game" uses CelticIII.

Copied from TokenIDE's .txt file for x.8xp:
Code: [Select]
"C082031818400101→Str1
"0140481200200400→Str2
"0000000000000000→Str3
identity(8,Str2,0,0,0,0
While 1
real(8→|N
X→W:Y→Z
X-(|N=2)+(|N=3)→X
Y-(|N=4)+(|N=1)→Y
If |N=7
Then
X-1→X
Y-1→Y
End
If |N=8
Then
X+1→X
Y-1→Y
End
If |N=6
Then
X+1→X
Y+1→Y
End
If |N=5
Then
X-1→X
Y+1→Y
End
If X≤0:0→X
If Y≤0:0→Y
If X≥88:88→X
If Y≥48:48→Y
If W≠X or Y≠Z
identity(8,Str2,0,0,0,0
If |N=54
Then
identity(5,"0040FC40",X+8,Y+8,1,4,2,0,1
1→θ
End
If |N≠54 and θ
identity(5,"0040FC40",X+8,Y+8,1,4,3,0,1
identity(5,"FFFFF1EBE1E3FFE1E1D3D3D3818181FF",X,Y,1,16,1,0,0
identity(5,"3F7F71EBE1E2FEE1E1D25252818181FF",X,Y,1,16,2,0,0
det(19
End

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Optimisation help request
« Reply #1 on: August 02, 2018, 01:32:36 pm »
It takes a little longer for BASIC to process a direct string versus, say, Str3. So the first order of business is putting any strings used in the loop into a String var!

You only actually draw anything new when the player moves or when [MODE] is pressed. What I like to do is wait for user input with a Repeat loop, this way we aren't needlessly reupdating the screen. In this case:
Code: [Select]
Repeat Ans
real(8
End
Ans->|N
Furthermore, I like to draw sprites with XOR logic. Erasing them is then a matter of redrawing them with XOR logic. As well, the identity(5) command allows you to update the LCD. First I'll draw with XOR logic and update the LCD at the same time, then re-XOR without updating the LCD. That code looks like:
Code: [Select]
identity(5,Str1,X,Y,1,16,3,0,0
identity(5,Str1,X,Y,1,16,3,0,1
Repeat Ans
real(8
End
Ans->|N

As well, we can use some BASIC trickery to combine movement and boundary checking on X and Y:
Code: [Select]
max(0,min(88,X-max(|N={2,7,5})+max(|N={3,6,8→X
max(0,min(48,Y-max(|N={4,7,8})+max(|N={1,5,6→Y

I ended up with my final code as:
Code: [Select]
:"X-TEST
"3F7F71EBE1E2FEE1E1D25252818181FF->Str1
identity(8,"0000000000000000",0,0,0,0
Repeat |N=15
identity(5,Str1,X,Y,1,16,3,0,1
If theta
identity(5,"0040FC40",X+8,Y+8,1,4,3,0,1
0->theta
identity(5,Str1,X,Y,1,16,3,0,0
Repeat Ans
real(8
End
Ans->|N
max(0,min(88,X-max(Ans={2,7,5})+max(Ans={3,6,8->X
max(0,min(48,Y-max(|N={4,7,8})+max(|N={1,5,6->Y
|N=54->theta
If Ans
identity(5,"0040FC40",X+8,Y+8,1,4,3,0,0
End

If you are looking for speed, I highly suggest Axe or Grammer.
Axe compiles source code to a stand-alone assembly program and is very fast. However, it generally has larger file sizes due to needing to include all of the routines (unless you use Axe Fusion, but that requires Axe to be on the user's calc).
Grammer, like BASIC, is not a compiled language. It is comparable in speed to Axe, but programs are usually smaller. On the other hand, the user must have the Grammer app on their calc.

I included sourcecode for this BASIC version, as well as Axe and Grammer.

Personally, I really like both. I like Axe because it produces very high quality code in a stand-alone program. Grammer is better for debugging and offers more powerful resources. For example, in Axe, if there is a bug, you need to change the source and then recompile the program, then run it. For Grammer, like BASIC, you just press [ON], change the source, and it is ready to run again. Grammer also includes menus and Input, popups and other useful routines.

I think Axe and Grammer are easy enough to learn-- you just have to learn how pointers work. You can get a program up and running in minutes. However, to use Grammer like a pro, it can be a steep learning curve.

Offline starfighter

  • LV0 Newcomer (Next: 5)
  • Posts: 2
  • Rating: +0/-0
    • View Profile
Re: Optimisation help request
« Reply #2 on: August 02, 2018, 08:38:29 pm »
Xeda you are awesome! The Axe version is blazingly fast  :o! Thanks for the reply, and for such a thorough optimisation. I'll be studying these to learn your tricks =D.

So really then, time to decide between Grammer and Axe. Your Axe example was incredible in speed (though not to say that Grammer one wasn't fast either!), however like you said I'll have to recompile each time, which isn't too much of an issue -- I'd prefer to do all the legwork to spare my end user any hassle --  but does complicate development process a tad. I am attracted to the prospect of more and useful routines too, though, so again I find myself on the fence.

Regardless, thank you for the reply and the code. I'll get to studying these immediately =D.

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Optimisation help request
« Reply #3 on: August 02, 2018, 09:28:26 pm »
I'm glad I could help! And I'll admit, I am a little biased with Grammer :P Realistically, it is kind of a toss up. For intensive games, Axe can really outperform Grammer, if only for the fact that you can directly compile your own assembly into it. But for things like RPGs, Grammer is probably better since it has support for tilemapping, menus, and a nice Input routine.

Grammer has the advantage that the routines are in the app, so I could optimize for speed instead of smaller code, and I could afford to add in more higher-level functions than Axe. But Axe is faasst.