search

cyborgar / Petaxian

C64 Galaga type game implemented in Prog8
GNU General Public License v3.0
16 stars 3 forks source link

possible optimizations #6

Closed irmen closed 2 years ago

irmen commented 2 years ago

The newer prog8 compiler versions generate smaller and faster code than before (and I think the C64 version is no longer "a bit too slow"? as mentioned in the readme).

But there are a few easy optimizations that can be made in the code I think.

For starters I notice that you do your own number printing routine (binary to decimal conversions). Prog8 provides some built in routines for this in the library (these are used by prog8 itself as well when using txt.print_uw() for instance).

See the conv module. You can probably use conv.str_uw(number) and then conv.string_out variable to retreive the decimal string form.

Also repeatedly calling txt.setcc with a list of non-trivial arguments will result (for now) in slow parameter evaluations, so maybe there's a lot to gain there as well if we precalc the arguments? or write a custom routine that's smarter

cyborgar commented 2 years ago

Good point with the conv module. I didn't look into this since it's not covered by the documentation. I've updated the code to use the str_uw0 function most places I've done binary to decimal conversion. There is a couple of places where I skipped this for now.

I'm considering adding a "boolean reverse" param to PrintNumber. That would allow me to merge printNumber and printScore as well as use this for printLives and printStage (both using a reversed number chars). Though it might possibly be worth keeping printScore as a faster and less generic function since this is called a bit more frequently.

I do think txt.setcc may be one of the slower parts of the code. If I'd like to speed of this I could certainly find a way to make this faster. This isn't high on my list of priorities at the moment.

BTW, the new update doesn't compile for C64 :

Assembling file:   .\petaxian.asm
.\petaxian.asm:3116:13: error: general syntax
 +           plx
             ^

I get the same error with 7.1 and 7.2. This compiles and runs fine on CX16.

irmen commented 2 years ago

What a weird error !

I quite regularly check the compiler against your codebase and have not yet seen this error occur. (plx is a 65c02 instruction that should only be generated when the target is cx16)

Also I can successfully compile the game with 7.0, 7.1 and 7.2 releases myself...

edit: OOPS!!! I've left some 65c02 instructions in the conv.p8 module that is shared with the c64 target and until now they were in routines that were unused... But not anymore. I'll fix this straight away for prog8 7.4 !!

cyborgar commented 2 years ago

I sort of suspect it was something like this. I'll check this out when the next version is ready. No rush for me to get this one fixed btw.

irmen commented 2 years ago

I understand, but it was wrong since 7.0 already :(

and yeah perhaps I should start documenting the default libraries better, but that's a lot of work and I hope users can refer to the source code for now ....

irmen commented 2 years ago

7.4.1 is out, petaxian now compiles to 18004 bytes. I tried my best but couldn't get it under 18000 ;)

edit 7.5 manages it! 17996 bytes :tada: edit currently down to 17905 bytes edit currently down to 17491 bytes :muscle:

irmen commented 2 years ago

btw, what are those (unused) game[] and over[] arrays in game_over.p8? Was that an old defeat screen or something? In any case, the compiler is giving warnings that they are unused and removed

cyborgar commented 2 years ago

Yes, that is exactly what this is. I have just not removed this from the source yet. There is also a "spawn_bomb_new" that is unused (it wasn't better than the original function).

irmen commented 2 years ago

now i'm curious how they looked like ;)

cyborgar commented 2 years ago

Like this

game_over

cyborgar commented 2 years ago

Most of the suggestions have been implemented. I've even done a few others as well. And I've had a look at the setcc code and to be honest this function doesn't look bad when it comes efficiency. Even using a lookup table for row index positions to avoid multiplications.

irmen commented 2 years ago

Regarding setcc, it's mostly the overhead of setting the parameter values every time for every call, I think. Setting a whole lot of characters at once could perhaps be done more efficiently with a specialized routine. But seems like its not needed - game runs smooth on x16.