Nicole wrote:... I don't even believe it's a given that using a C compiler would be that much worse performance-wise than writing in ASM.
I beg to differ, though this is for a different (and substantially less limiting!) architecture:
https://stackoverflow.com/questions/250 ... erformance . Not only is the investigation and outcome itself relevant, but even more so is the fact that
one had to examine the assembly to find out the cause. And that's not even on a 90s video game console.
As an Apple IIGS user, I can tell you that C on 65816 does not particularly result in impressively fast code. We had commercial C compilers for the Apple IIGS -- specifically
ORCA/C -- which went to great lengths to do the best they could, but were always substantially slower than their pure assembly counterparts. Does speed matter? Yes, especially when doing something like implementing code run in an NMI/VBlank handler. Possible to mix C and assembly? Absolutely, and was common in the Apple IIGS days for those exact reasons -- a platform where portability wasn't a concern. Some commercial SNES games were developed this way (a mix of some C-like language and assembly).
Is C it better on the 65816 than on the 6502? Yes, mainly due to the additional addressing modes and instructions. But not substantially. The biggest problem is the lack of registers -- something that plagues the 65xxx platform in its entirety. C is better-suited for CPUs that have lots of registers and/or lots of addressing modes (68K comes to mind). There's a fairly authoritative person on the subject who I've mentioned in the past: Toshi Morita. There's
an old forum post with him discussing how he did that with lcc816 (the port generated 65816 assembly code, intended for use with ORCA/M (65816 assembler for the IIGS)), but you can see very clearly in the thread how it works under the hood -- note the reliance on large numbers of registers. Do not overlook the part discussing dags2gs2 and *.dag files.
The tarball contains a README.65816 that explains how it works.
Should I even bring up the aspect of debugging compiled C code? AFAIK there's no SNES emulator that ties into native C, unlike present-day platforms with things like Visual Studio and gdb.
My point: you're going to have to know assembly either way when working on console platforms. There are several NES/6502 threads demonstrating that already. It's funny, these aspects of development are always avoided/overlooked when discussing this subject; it's no one person's fault, but it does amuse me; it's like pragmatism/realism is thrown out the window in favour of PL fixation, no matter the realities.
Nicole wrote:I think cool stuff being made is good in general. Anything that serves to make that process easier is likewise a good thing.
I generally agree, and don't have a problem with such efforts (to make homebrew or to make tools).
But I stand firm on my opinion that lack of a C compiler isn't the reason why SNES homebrew isn't prolific. The reason is multi-faceted. There is not an influx of people coming to forums screaming "if there was a C compiler for the SNES I'd be doing homebrew!" We now have
literally 1 person saying that. And that 1 person already has existing experience with classic consoles, plus is one of those people with deep dedication to their projects. This is often not the case with people; for every 100 people who say "I wanna {do a thing} on {classic retro system}", probably 98 of those give up because they don't want to dedicate the time to learn the system (read: not the PL, the system/architecture). My point is further proven by the fact that even in the heyday of snesdev in the early 90s, where we were all doing assembly all the time, people
still weren't putting out homebrew -- and we actually had more tools and available platforms for development at the time (ex. doing SNES code on the IIGS, actively-maintained cross-assemblers, graphics file conversion tools, and an active community and mailing list. Probably 99% of those tools never got ported from MS-DOS or Amiga to newer systems (ex. PC), so they're dead tools. I still have several of them on my hard drive!). I was part of and lived through that time, so I speak literally from experience.
Nicole wrote:(By the way, to be honest, I wouldn't even bother telling people not to reply to stuff like this; if people think it's worth discussing, they will, myself included.)
Sorry about that, I didn't phrase my sentence well. What I meant to say was: think long and hard about what I say in this paragraph. Do not reply in haste, let the question roll around your (the readers') brain for a few days first.
I'm now regretting even replying to this thread now that I know the real reason behind it:
tepples wrote:It's related to something I was told in Fedora's legal issues mailing list. Unlike Debian, Fedora doesn't carry emulators because of legal threats from first-party developers, particularly Nintendo. The substantial noninfringing use argument is weak without plentiful homebrew games.
I wish this had been stated right up front in the initial post, because I wouldn't be wasting my time with it otherwise. A Linux distribution doesn't include SNES emulator packages citing legal fear... okay, that's nice.