I do really like this approach. Figuring out how the code should work in a high level language then optimising the bits that need speeding up works well with my brain. Occasionally in assembler I get stuck in the minutiae. That's the ex-8-bit games programmer in me I suppose.
I wonder if I could somehow use this same workflow with gbdk2020 c and asm for our gb game. For the most part I can see what the equivalent asm would be, I guess my only issue is knowing the difference in efficiency, especially after the compilation/assembly phase has already optimized it. 🤔
Are you writing it mostly in C at the moment? There are obvious things I'm optimising in asm, like the line draw and using trig lookups. This is quite maths heavy, so coding in a high level language first does make a lot of sense.
It's c, but it's heavily relying on the library of functions that comes with gbdk itself, which I imagine are decently optimized already? 🤷♂️
Yeah, I would assume so. That's what I'm trying to write at the moment, the optimised library, not so much a game yet. Out of curiosity, does it work on the original Gameboy?
My game is beyond the CPU speed of the DMG, I had to bump to "2x mode" of CGB (game boy color), but we already planned to use all the color capabilities anyway. Gbdk can build for DMG though, as well as nes and master system.
Incredible! I know from experience how limited the CPU is on the DMG compared to a stock Z80.
Interesting. I guess it makes sense when you compare nes and game boy games, but I hadn't considered the "flavor" of z80 to be a factor (was more thinking about the screen limits etc), but it makes sense for it to also be power efficient.
Yeah, the Sharp CPU in the original is more like an 8080 than a Z80 so doesn’t have the index registers IX and IY or the alternate register set. Less suited for C than the Z80. But they’ve done it, and also the 6502, which is even less suited IMHO.