a few suggestions

[irmen]

Hi! Pretty impressed with how this is coming along! I decided to scan through the code for a bit to see how it's built. There are a few things that I noticed that you can perhaps try to improve a bit more:

base_c64.p8:

@($d020) = $c you can use c64.EXTCOL = $c

clear_screen() you can probably use txt.clear_screen() or txt.fill_screen()

base_cx16.p8: same about clear_screen() if not, I think the y loop is off by 10 (30 should be 40?)

enemy.p8: I think the move_xxx() assembly code can sometimes be optimized a bit more by using inc a/ dec a instructions rather than adc 1 / sbc 1 . These inc a/ dec a are new for the 65c02 cpu

petaxian.p8: wait_dticks() can be replaced with sys.wait() i think. line 102 and 208: "may need to find a better timer" maybe you can use sys.waitvsync() ?

Various files:

while (..) -> you can omit the parenthesis for the while condition

while 1 { } -> you can use repeat { }

txt.setcc() -> you use this a LOT, which is fine ofcourse but it is a bit inefficient this way because on every call it's going to calculate the memory addresses to change, which involves a multiplication by 40 on the C-64 (done via a lookup table so it's not that terrible). However I THINK if you're looking for a big speedup, writing customized routines that set the characters for the moving entities could potentially give a significant performance boost if you do this in a way that doesn't require recalculating/repositioning the memory location for every individual character.

There are several tiny subroutines that you may want to declare as inline. Experiment with this as it doesn't always yield a performance increase and often blows up the code size.

Joystick issue at start: I noticed this too and for my work-in-progress game I have the loop at the start that checks for fire button to start the game, as follows:

    sys.wait(30)
    repeat {
        ubyte joy = lsb(cx16.joystick_get2(0))
        if joy and (joy & %11110000 ^ %11110000)
            return
    }

it tests for the value to be non-zero as well. (this is not required afterwards anymore) note: use cx16.joystick_get2() if you don't need that single status byte it drops, because it works around a kernal bug that has to be fixed still, where the joystick status can get corrupted when a system irq takes place during the call.

I've noticed you're using byte arrays for screen text output. If it's just text you're printing, you can perhaps also just use str with screencode-encoding @"hello"

[cyborgar]

Thanks for taking the time to give me feedback. I've already done some of the quick ones

• Use EXTCOL (I actually still remember the hardware address for screen and border color so I didn't even look in the lib files)
• Using repeat instead of while 1
• Removed () for while (and most if's). I'm just so used to C style syntax these get added automatically :-)
• I now use txt.clear_screen() so I don't have to implement my own
• And I switched to using sys.wait() instead of my own (not so great) wait function

I've only recently taken closer look at the lib files and will make sure I use function from there when appropriate. I didn't really do that initially.

I'm probably not going to use any 65c02 assembly as long as I aim for C64 support. I did scan through the new commands for this processor and there are a few nice improvements.

As you suggest I will sooner or later have a look at custom function instead of setcc. Though at the moment this is fast enough for CX16 and it's only on C64 I have a bit of lag.

I will take a closer look at the joystick stuff. That is a slightly annoying issue.

[cyborgar]

I've added my own workaround now (just checking if "all keys are active" and skipping "retrieving" this value) and uploaded a new "working" version of the game.

I have not checked out the other bug you mentioned yet but will take a closer look later.

I may also want to take a look at the waitvsync as well later, but currently the setcc speed is likely the main limiting factor (as long as I want this to run on C64).

[irmen]

feel free to close this issue if you think you worked through the suggestions enough 👍

[cyborgar]

Yes, I think I can remember the main remaining suggestions anyway (optimization suggestions). I'm mostly testing with the X16 emulator and there is no slowdowns there. And it's basically a lot easier to work with Prog8 code than assembly anyway.