There is something incredibly refreshing about looking at C64 optimizations. Today we throw gigabytes of RAM at simple CRUD apps, while these developers were counting every single cycle and byte. It’s a good reminder that 'efficiency' used to be a core requirement, not an afterthought.

From another post on their blog:

> having tried to sabotage its Kickstarter campaign back in 2018 by viciously attacking me and attempting to have me "cancelled" for opposing his hysterical far-left views supporting the LGBT agenda and the degenerate filth of unfathomably evil "trans people" aka demonic monsters (views which, for the record as a conservative Christian, I unapologetically find utterly vile and abominable).

Flagged because people like this don't need attention

> However, you can save 1 byte of RAM by using the branch instructions instead, as long as you know which flag(s), if any, are guaranteed to be on or off at the jump point.

> For example, if you know the carry flag will always be clear at the jump point, and if the jump distance is within branching range, you can replace JMP with BCC.

However if the BCC crosses a page boundary it'll take 4 cycles, one cycle longer than a JMP.

Ah so with splites you can have a 24 pix wide column of arbitrary data that can be slid around left to right....and may act as an "echo" of the players movement like in this game...or possibly even different physics...

I love the stacking of boolean ops before branches, too.

Interesting stuff! Regarding game sales, other developers have had more success putting their games on physical media (particularly cartridges).