Why no SNES homebrew scene?

[Oziphantom]

Oh look a "commercial" new game written for the SNES using C https://collectorvision.com/shop/snes/s ... -of-death/ pity about the glitches ....

If the only thing that stops you is not having a C compiler, then you probably don't want to make a SNES game. Writing 65816 is a means to an end, if you want to make a SNES game then you make a SNES game, using the 65816 is just the tool to make it. As koitsu points out you have to be fluent in 65816 to debug and work on the game, once you have crawled and walked in ASM then you can take the taxi that is C for the bits you can. This is still somewhat true today, Being able to read MIPS really helped when developing for the PSP, PS2. Yes it gives you C++ level debugging but sometimes you just get a random crash and being able to look at the ASM to work out what and where was critical. With iOS knowing ARM really really helps as the iOS debugger is rubbish.

Games don't have to be as good as SMW, people don't want SMW they expect DKC3

What might help is making conditions that drop the entry expectations. For example in C64 land we have a 4K crap-tastic game compo, then we have 16K cart compos this drops the concepts and expectations for games, so more get made as people can commit enough time to bash out a 4K game or 2, but to make a 512K cart top of the line game takes 3 years. Maybe a 32K SNES game compo?

[Bregalad]

But I stand firm on my opinion that lack of a C compiler isn't the reason why SNES homebrew isn't prolific.

Just my $2, but I wanted to say I fully agree with Koitsu. If someone really wants badly to make a SNES game they will use whathever tools are available, and possibly make their own if that's possible and makes the work easier. They'll use whathever language is available for the platform, it's just a tool to get the game done. Needed to code the game specifically in C seems ridiculous to me.

If the only thing that stops you is not having a C compiler, then you probably don't want to make a SNES game.

Exactly.

[koitsu]

What might help is making conditions that drop the entry expectations. For example in C64 land we have a 4K crap-tastic game compo, then we have 16K cart compos this drops the concepts and expectations for games, so more get made as people can commit enough time to bash out a 4K game or 2, but to make a 512K cart top of the line game takes 3 years. Maybe a 32K SNES game compo?

This actually sounds like a great idea!

[calima]

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.

Hey, I've also been saying that, probably a few pages back in this very thread, as well in others. I don't want to reiterate everything I said before, but there's plenty of reasons supporting the need for a C compiler.

Oh look a "commercial" new game written for the SNES using C https://collectorvision.com/shop/snes/s ... -of-death/ pity about the glitches ....

The glitches in Sydney Hunter are not the fault of C, but mostly just programming bugs. I had higher expectations given alekmaul's reputation.

As for my current SNES project, it was shown at Too Many Games at Mega Cat's booth recently, and will soon be available on the website. It uses cc65, and we're all familiar with cc65's quality; however it's currently the best option for a SNES C compiler. It even supports some of the 816 constructs, generating slightly better code than for 6502. Unlike tcc816, it's not absolutely unusable quality, and the codegen bugs are few and known. OTOH it does not support the SNES banking scheme nicely, which would be a requirement to do bigger SNES games.

[dougeff]

Has anyone tried the official WDC C compiler? The website claims it to be free.

http://www.westerndesigncenter.com/wdc/tools.cfm

[Oziphantom]

also worth noting that the 65816 has 6502 emulation mode but also in its native with a/x/y as 8 bits it has most of the extra R6502 opcodes. So you could use the PCE compiler, you won't have its fancy Test/set bit opcodes but they should be easy to mitigate in you c code?

[elseyf]

Has anyone tried the official WDC C compiler? The website claims it to be free.

http://www.westerndesigncenter.com/wdc/tools.cfm

I tested it some time ago. Unfortunately it produced wrong code when using arrays of chars (if I remember correctly). I gave up on it assuming more errors were waiting.

[Stef]

But I stand firm on my opinion that lack of a C compiler isn't the reason why SNES homebrew isn't prolific.

I don't understand why many of you are fighting against that idea... Of course not having a good C compiler is a problem.
That is not the *only* problem but definitely it closes some (a lot of) doors.
Generally speaking i think the lack of good development tools / library plays for a big part in this situation, and lack of good C compiler is one of the major issue. Myself i wanted to do some development for the SNES but i didn't pushed it for 2 reasons:
- the lack of GCC toolchain for the 65816 CPU (preventing compiling my own dev env for it)
- the convoluted hardware (i was terribly disappointed when i started to read documentations after having played with MD hardware).

If we can get a decent SDK with a good C compiler then i would do some coding for the SNES as it would "resolve" these 2 problems.
PVSnesLib is a good start imo but it need some polishes (easier installation), probably a better C compiler (at least one where you don't have to care about banking issue and be able to use basic 8/16/32 bit data type) and higher level methods to have a bit more abstraction with the hardware (which is quite complicated to deal with).
I would even say that having a good C compiler isn't much of a problem, as you can always use 65816 assembly when you require it. The problem for me isn't having to use 65816 assembly, i think that at some point you may need it but i just don't want to do 100% assembly code, that is imo terribly painful and a complete waste of time... Ideally i would stay with as much C code as possible (90%) and only put assembly on critical sections (10% at most) when i need it, and I think that is possible even with an average C compiler.

The SNES is more popular than the PC Engine and the Sega Megadrive however it receives much less homebrew than these 2 systems... there is probably a good reason (or several) for that.

[Bregalad]

Ideally i would stay with as much C code as possible (90%) and only put assembly on critical sections (10% at most) when i need it, and I think that is possible even with an average C compiler.

Why would do need C specifically ? You could just as well code 90% in any other language and the critical 10% in assembly.

[TOUKO]

Ideally i would stay with as much C code as possible (90%) and only put assembly on critical sections (10% at most) when i need it, and I think that is possible even with an average C compiler.

Why would do need C specifically ? You could just as well code 90% in any other language and the critical 10% in assembly.

You're right, but C is a well know language,and you can also code easily in basic on Md,but the SDK is less powerfull than SGDK .
For a starter it's more easy to learn only a coding language and after the whole machine than both at the same time,mainly on snes which is a bit complicated to learn for a non experienced coder .
For me a high level language is a good and easy way to learn how to manage datas for a specific system, like graphics,sounds, etc .. without the complexity of the assembly that can scare a newbie,and later permit him to migrate slowly to the assembly .
On PCE, this was the main purpose of Huc,and not to code complex games .

[tepples]

Ideally i would stay with as much C code as possible (90%) and only put assembly on critical sections (10% at most) when i need it

Why would do need C specifically ? You could just as well code 90% in any other language and the critical 10% in assembly.

Because C compilers targeting 65816 are known to exist. Or which "high-level" language other than C do you recommend that compiles to 65816 assembly language?

[psycopathicteen]

What kind of hardware abstractions does it need? I know it probably needs a DMA function, but what if that ends up being very speed critical?

[Stef]

When i said hardware abstraction, i speak about low level stuffs in general. In the end the library / API still need to fit the hardware design in some ways, but for instance it would be nice to not having to know that the OAM is split in 2 parts. At higher level i would say you won't even need to know you need to fill a OAM.

I don't necessary want to promote my work but let take an example with SGDK (which is for the MD system).

You have 2 sprites API, the first one is a low level API close to the hardware:
https://github.com/Stephane-D/SGDK/blob ... /vdp_spr.h

This API is really close to the hardware design and you really need to know how sprite hardware is working to use it correctly, still it provides advanced feature as "dynamic" allocation of hardware sprite to make easier usage of it, and of course as it's low level you can get really good performance out of it if you use it correctly

Then you have the advanced sprite engine which is much higher level (as the one you're designing on SNES):
https://github.com/Stephane-D/SGDK/blob ... rite_eng.h

With the sprite engine you don't really need to know how hardware sprite work internally, it will do all the heavy stuff for you (meta sprite, handling resource allocation, depth sorting, easy animation...). Still the sprite engine is flexible enough to allow more control which can be useful to optimize resource allocation and performance in general. With the sprite engine you won't get 100% of what the hardware can do but it will make your life much much easier to display and animate sprites in general. And it will be good enough for 90% of the use case (as you can always use static allocation when needed)... i really believe that kind of high level API / library which can bring more developers to a platform: you just need to be familiar with C language (which a lot of developers already known) and understand a bit about how old 2G game systems were working to start developing on the system. And when you get more familiar with the system hardware you can try to go on lower levels parts...
Starting immediately with very low level and assembly is just too much for a lot of people, we don't want to spent 3 weeks just to understand how to display a simple "hello world" string on the screen.

[Bregalad]

Starting immediately with very low level and assembly is just too much for a lot of people, we don't want to spent 3 weeks just to understand how to display a simple "hello world" string on the screen.

If they don't want to spend 3 weeks for "hello world", then they probably won't ever spend the time to make a full game for the system. I spent probably well over 3 weeeks when I wanted to do a "hello world" on NES back when I started this activity in 2002 at age 13 without any knownledge of the english language back then.

[FrankenGraphics]

While good C tools may be an inclusion factor for additional devs, i don't think language choice is the main problem here. It's assets, and scope (you need more content for the same measure of playtime, and buyers will expect more playtime). Developing a new product identity with all-original content from scratch for the SNES is well beyond the pain threshold for many devs and artists alike. I do hope to get there one day, but not before i've established a good product identity for the NES first that just might be viable for expansion, which is still a significant task. Once i have one that might fit the bill, stepping the assets up won't be as large a leap as creating all-new. Tilesets can be drawn over and expanded. Music can be rearranged. For me at least, that's the most sensible route: to make a nes game good enough to maybe warrant a follow-up with a super prefix.

65816 assembly is principially more convenient than 6502 assembly. You can be more wasteful with resources, and you have convenience instructions that reduce the human error factor. The 5A22 has additional convenience features beyond that. But if all you have is "programmer art", then what purpose is there developing for the SNES in the first place? You're probably doing it for the specifics of its visuals, sound and controller interface.