thanks for the response. i am also quite enamored by the idea of carrying around a motherlode-type beat on this humble console one day so i hope you or i or someone can make it work out !
How would your control go? Press B once to go into a menu and then navigate with the crank or hold B down?
for sure it was tricky. first I thought about simply mapping B to swing the axe but that meant the crank wouldn't be used in alot of places until the player gets the drill. and i found cranking to axe to be more enjoyable with just the fast enough rotation.
so with B left over I was thinking about holding B + crank to select item or second tier menu like Casual Birder does. also i tested a thing where the player can dock the crank to put away the current item. could be neat if holding the item causes a speed penalty so the player can feel like docking is a useful behaviour.
It's a bit of a difficulty ramp compared to Lua but it's doable. There's another solution you could look into: making specific parts of your code in C so you can limit the amount of code done in C while still programming the most of your game in Lua.
hum, i don't know much C but i do know a bit of Rust having programmed some simple tools before. i think there was a guy that wrote this whole Rust toolchain for playdate that was busted in places. only issues is i rely on a bunch o' lua libraries to do heavy lifting like platforming logic and i don't wanna to rewrite it all so soon.
think what i'll do is, figure out what's actually fun in Lua first regardless of FPS, since C or Rust will be higher difficulty as a programming wizard i am not. then when FPS is really a concern, but otherwise the game is fun, port everything over...somehow. if i was sure about finishing this (which, i'm not to sure honestly).
main issues right now is i'm not really sure where the bottleneck is yet, and the CPU sampler wasn't terribly enlightening since it just declares field update [C] (in playdate.sprite) to absorb the most frames. i think it is a limitation of the current sampler - if there is a sprite callback it doesn't cross the C barrier to profile the Lua inside ? but i am not so sure. regardless it is likely to be a sprite issue i think, probably just too many on screen at once (~230 when underground)
So, you did do chunks in Lua?
at first yes, however i found in practice setting the chunk size to 1 gave the best performance. anything above 2 causes too much hitching on real hardware. at that point i think i'd be better off just checking screen bounds and unloading tiles outside the camera
how it works is - the world is divided into N x N chunks. inside a given radius all chunks that must be displayed on screen are loaded. if a new chunk is about to be shown but is missing, first any chunks that are off-screen are "reallocated" by moving all their tiles to the new coordinates and repurposing each sprite with a new image etc. (so no allocations) each tile is represented as both a table of "definition" data in the world and (when onscreen) a sprite with a collision box colliding with the player. the world itself can be pretty large (mine is 48 x 300 currently)
so the chunking is really for just "the subset of tiles visible on screen". it has evolved into being used more like a culling mechanism. so i think i may need to replace it. i was very curious about how yours worked by the way.
for allocating sprites themselves i use a resource pool that keeps a set of sprites loaded in memory upfront. when a new tile is needed its taken from the pool and given the correct image/ID.
so those are the metrics kept track of. alloc/realloc for tile's sprites, calloc/crealloc for "chunks". ideally keep "alloc" as small as possible. but even with this system in place and hardly any allocs beyond initial load i still get alot of hitching when running around.
and thank you for the bundle of luck, i will probably need it 
