Sorry, yes, you. That was quick how you noticed those things. I wonder how much could be optimized in this game. It took me a long time but even a newbie to assembly like me could notice some stuff arent great in the code.
Hehe. I was just making a random guess based upon decades of experience and ZERO knowledge about hacking and/or writing games. It's just where I'd go look if I saw the behavior you mentioned.
Given what little I've learned from a few hours of reading code (that's the total sum of my experience on this subject), it just popped to mind. The code generation is horrible, from what tiny experience I've had reading code so far.
It is pretty clear that a C compiler was involved. (That's easy to spot, if you've ever written a C compiler yourself. It's easy to spot even if you haven't.) And it was clearly a very terrible quality C compiler. Truly and unbelievably bad. I didn't know anyone wrote C compilers that primitive, except perhaps as a class final in college. It did nothing at all more than simply do a direct conversion, without any optimizing analysis I can find. Zero peep-hole analysis, and not even the simplest of constant folding? I'm still kind of amazed at how little it did. Shocked, actually. Even the open-source and freely available SDCC for the 8051 does so much more, including odd-ball things like call-frame static overlaying to save on stack usage. The compiler clearly did support all the C features, though. I did see place where an array of function pointers was accessed, and because the 65c816/6502 doesn't have any instructions that can be used to call a function via a register value, they had to do some interesting stack manipulation together with an RTS in order to make the calls work out. So the C compiler wasn't entirely brain-dead. But just about.
What parly annoys me about that is that I'm also getting the sense (from responses here and elsewhere) that there is insufficient interest and/or pressure from compiler consumers. So I'm curious what the current spate of compilers actually handle, today. CC65 and snes-sdk have both been mentioned to me and I need to look them over. (Though someone said that CC65 generates 6502, not 65c816, code.) Back when game development was active, when professional teams were writing SNES game code, when they were paying a decent price for access and compiler tools, and when getting good code generation might really make a difference as to whether or not the resulting product was competitive enough to survive, .... well, I just can't explain what I'm seeing in this ROM! If all that wasn't enough to get a decent C compiler back then, what possible hope is there today? A hope is that good people used gcc's source and did a yeoman's job of shoveling in 65c816 knowledge into the code generation. But then, they'd need to add call branch analysis, which so far as I'm aware no one has added to gcc for any reason, to get really good code generation. (Call stack analysis is more useful where recursion isn't an issue.) There are a lot of specialized techniques, available in quality free and professional compilers for other microcontroller cores, that would need to be worked out in gcc. I wonder if anyone would go there. Another hope is that someone wrote one from scratch and applied themselves well to the task.
I'm just not yet sufficiently motivated to go look, just yet. I'm spending what time I have on assembly and helping my son (where he wants to accept it) with his current project. I will go look, someday, though. But for now, what I see in the game code is terrible and I just cannot explain it with any reasonable logic. No sane development team would ACCEPT this crap I see. Not unless they had NO OTHER CHOICE, at all. And even then? I might simply refuse to use my capital to develop a game, if Nintendo forced me to use C compilers this badly done. I would feel that Nintendo might be putting me and my team "at risk" in competing with other developers who may be using assembly-only for their development. The problems you've identified are an example of how my product might fail in the market and do so partly because Nintendo forced a crappy C compiler onto their developers wanting to use C. I don't like it when they don't care enough to deal with the basics, like that. It's not as though Nintendo didn't have enough time. The SNES didn't arrive in a vacuum. There was the NES before it. So they had plenty of time and reason to do up a decent C compiler.
Anyway, I've a lot yet to observe here. A few hours' effort in no way makes me any kind of expert. But the little bit I've seen looks scary. And I also know just how low the skill levels are for many embedded developers who'd be using the C compiler as a tool to generate code. I've met such folks, worked with them, been able to measure how few are truly good at their work and care about it deeply, and have seen how barely most of them manage to "scrape by" and how often they don't and, as a result, seen how it is that companies not infrequently lose huge investments in new product development because they hired people who had very thin levels of skills and background. (It's one of the ways I market myself, in fact.)
But it seemed pretty obvious from your description where I'd start looking. I gather from your post that others have thought similarly, too. I guess that suggests my instinct formed out of a few hours of looking around here might have been close to the mark.