/vr/ - Retro Games

>>8066404
how much overhead do you expect lmao
you're mainly just going to be doing a bunch of arithmetic and occasionally calling some functions (which will likely get inlined by the compiler anyway), often things that aren't hard for the compiler to optimize
even in the absolute literal worst case, you can just take another vblank to do whatever you're doing, it's not like you're going to enter slideshow territory

yeah, you'll have some functions that'll need to be in asm, but most of those can (and will) just be library calls, stuff cc65 actually does for you
like, fuck, this isn't some theoretical thing, and cc65 isn't some shitty 80s compiler either
https://shiru.untergrund.net/articles/programming_nes_games_in_c.htm

people massively overestimate the overhead of high-level languages, and commercial NES software isn't even hyper-efficient (because the devs had a deadline to hit)
fuck, there are high level languages available for the fucking 2600, and that's a system where you have to count cycles to draw anything at all

>>8066337
It is a hurdle, but it's not insurmountable. It's just annoying to deal with, and you'll need to remember to use the volatile keyword a lot so the compiler doesn't optimize certain things out.
In the literal worst case scenario, the compiler is entirely unaware of the bankswitching method and your code has to fit in the non-bankswitched area of ROM. But, you can easily still just throw in some tables and level data and whatever there post-build and you can trigger the bankswitching in C, and it matters even less if you're bankswitching CHR instead of parts of PRG.

you were doing some awful dance like that in asm anyway