For a hobby project, yes. Anything that can speed up development is a plus. And, there are a lot of people that can program in C, but don't understand asm, and 65816 asm isn't probably the easiest assembly language to learn. And, a good part of a game can be written in C without hurting performance. Game logic is much easier to write in C. Look at the TG-16 development, HuC opened it up to a lot of people.
But unlike HuC, with a generic 65816 compiler hardware isn't abstracted and you still need to "bit bang" registers little different than you would in an assembly game. I agree that prototyping with C is faster/better since program flow and logic with C are no-brainers, but if you're going to take the time to really work out your algorithms (I try to do this for even the smallest projects), implementing them in assembly shouldn't take much longer. I understand in your situation where you're porting a game to the SNES, but for those starting from scratch? Solely relying on an obscure compiler without any libraries seems quite limiting. I also understand that assembly is not for everyone, which IMO is sad since it's just as important in the scheme of things as learning OOP. Is it possible to really know what a pointer is without learning something about hardware/assembly? I'm not so sure.
I think it will be just a matter of time before someone writes a decent set of libraries (in asm) to work with this compiler. I've provided a very basic set of routines. And, if nothing else, this is a nice assembly language development environment. Start off with stuff in C, and convert to asm as needed. I had to do this with a lot of the Frog Feast routines to get the speed needed (under the lcc658 compiler). I am in the process of converting Frog Feast to this compiler. Luckily the stack isn't corrupted enough to break the program, at this point. The biggest problem I've ran into is the pascal calling convention (which is just plain stupid). The compiler returns values using the accumulator, lcc658 used X. The WDC compiler uses the data register to keep track of local variables. which breaks zero page variables, unless the data register is reset in the routine. Everything else is a pretty much changing the assembler directives (.incbin to INSERT, .I16 to LONGI ON, etc.) The example program provided earlier is horribly broken, due to the calling convention.
The limitations on the Free versions are pretty limiting. Stuff like XDEF and XREF count against the 2k object limit. And, since the C compiler uses the assembler, this also affects C generated code. The compiler, as it stands, is only really good for small demos. Frog Feast does compile and work, with a 'modified' version of the compiler and assembler. I will post the source to Frog Feast, if anyone is interested.
I'd love to see any SNES source code. I'm currently messing around in ASM on SNES though. I can't really see C code for game loop coding though in something that is action based. But for other things like slow bits of loading, menu, organization is nice. I'm no wizard at ASM but it's fun to learn, I don't get why people are so afriad of it.
C code is like managed assembly, it's not terribly inefficient, ESPECIALLY for loops, and shouldn't hurt performance very much unlike C++. You've gotta write some assembly though in places where time is tight like during Vblank. In most cases, a C compiler for a 16-bit system will generate unintelligent code, but will still pass function arguments in registers as if you were writing the code by hand since that's what makes sense with 16-bits.
