I'd be worried about those extra opcodes pushing your already long codes further toward the limits of code handlers. I think the real GS only allows about 100 lines. You could circumvent this by dumping your code into unused areas, that won't be cleared by the game, using F1 codes, since they'll only execute at bootup.
I do remain sceptical, especially having seen the shit Nintendo's compiler produces (unnecessary register transfers, NOPs, etc), that a C++ compiler can produce assembly anywhere near as efficient as hand-written code, and in this field efficiency is very important. If you really have gone through the code with a fine-toothed comb and found almost no cases where it could be more efficient, then I guess I owe a high-five to the guys who wrote that compiler.
I wonder about the feasibility of a program that will go through your assembly and look for common optimization failures, maybe even fixing them automatically. I imagine they'd be fairly easy to spot, since it would make the same mistake every time.
Now, in a ROM hack of a game that falls well under the 64MB ROM size limit, and has plenty of RAM available (particularly 4MB games), optimization is not such a huge issue, but you still have to be careful your code doesn't slow the game down.
An interesting side note: recreating the game's structures in C++ like this is one of the first steps toward decompiling it back to source code... N64 games may be fucking huge, but most of that is data, and having been written in C/C++ using a common devkit, they may be easier to decompile than NES or SNES games. I've often wondered about how much of SM64 or MK64 is actually code...
|
