Is there a reason why the Megadrive/Genesis gets more homebrew and or demos than the SNES/SFC?

[SNES AYE]

So basically Technical Reasons.

Ah, I could have phrased that opening sentence better. What I meant was something like, "I don’t see technical limitations of the SNES hardware as the key reason more people aren’t creating homebrew games and demos." I can see how my original wording might have come across differently than I intended. That phrasing also ties better into the next point: "As far as I'm concerned, this really isn’t about a lack of interest or the complexity of the SNES itself—it’s that any remotely curious people who simply want to tinker, even casually, [can’t do so without jumping through some pretty major hoops]."

Does that make the point clearer? If not, I wouldn’t dwell on it too much—I think you get the gist: in principle, I believe that, more than any other factor, "If you build the right tools, they will come."

Castlevania: Symphony of the Night for the SNES

https://www.youtube.com/watch?v=VxnjMUI_4BA

I’m not convinced that’s real, but I’d be happy to be proven wrong. A .sfc or .smc demo would be great to try out, and it would certainly put any doubts to rest.

I don't see anything impossible for SNES hardware to do there. The background and things visible through the glass window could fit in three layers. The trail behind the player is opaque, but using a darker palette to suggest transparency.

I also don’t see anything there that the SNES hardware couldn’t handle—at least not at a quick glance—but I just don’t trust this particular example as something that’s actually been programmed and running on real SNES hardware. For whatever reason, it feels off to me. That said, I’d be more than happy to be wrong about this. In fact, I hope I am.

[segaloco]

Only a small nit but the whole modal nature of the m and x bits on the 65816 I find kinda annoying. Not that it's a show stopper in any sense but compared with the 68000 I could see that being an annoying adjustment. That does however give you the 6502 backwards compat...which helped with code reusability for Nintendo licensees. You're not liable to be reusing SMS code on the MD outside of maybe some sound logic driving the PSG.

The audio subsystems were brought up, and while indeed both use a secondary microprocessor as part of their sound core, the MD uses a Z80, Yamaha FM chip, and Ti PSG, whereas Nintendo uses their custom stuff. Open components means more information available. Sega's consoles generally were a bit more "off the shelf" than Nintendo's stuff, plus iirc Sega wasn't as hostile towards third-party developers, so perhaps openness in the system's past had a domino effect on the homebrew community then being larger, hard to say.

[Oziphantom]

So basically Technical Reasons.

Ah, I could have phrased that opening sentence better. What I meant was something like, "I don’t see technical limitations of the SNES hardware as the key reason more people aren’t creating homebrew games and demos." I can see how my original wording might have come across differently than I intended. That phrasing also ties better into the next point: "As far as I'm concerned, this really isn’t about a lack of interest or the complexity of the SNES itself—it’s that any remotely curious people who simply want to tinker, even casually, [can’t do so without jumping through some pretty major hoops]."

Does that make the point clearer? If not, I wouldn’t dwell on it too much—I think you get the gist: in principle, I believe that, more than any other factor, "If you build the right tools, they will come."

I'm also guilty of being obtuse.
My point is, the reason we don't have that is because of the 65816 and other layout and rules of the PPU. I.e "technical reasons". C doesn't work very well, because technical reasons, Asm can't really be bolted together, but on 6502 its not too bad, but on 65816 is very much "can't be bolted together" and to do said bolting you have to have a very strong grasp of the 65816 or you are in for pain and suffering. So "technical reasons". Sprites have have to be within a 16K block in the PPU, you have to set and tiles and screen formats and layouts and plan your VRAM around the technical requirements which you have to learn upfront, so again "technical reasons".
I.e the reason those tools don't exist and won't really ever exist is because "technical reasons". The libs "get close" which is about as close and friendly as they can get.

[Oziphantom]

Only a small nit but the whole modal nature of the m and x bits on the 65816 I find kinda annoying. Not that it's a show stopper in any sense but compared with the 68000 I could see that being an annoying adjustment. That does however give you the 6502 backwards compat...which helped with code reusability for Nintendo licensees. You're not liable to be reusing SMS code on the MD outside of maybe some sound logic driving the PSG.

The audio subsystems were brought up, and while indeed both use a secondary microprocessor as part of their sound core, the MD uses a Z80, Yamaha FM chip, and Ti PSG, whereas Nintendo uses their custom stuff. Open components means more information available. Sega's consoles generally were a bit more "off the shelf" than Nintendo's stuff, plus iirc Sega wasn't as hostile towards third-party developers, so perhaps openness in the system's past had a domino effect on the homebrew community then being larger, hard to say.

The MD was not open, and Sega were very hostile. Which backfired horribly for them when a "large popular game making company"" took their bluff and undermined them. Some companies had to send people over to America to "visit a large popular game making company" and then smuggle hardware back in a suit case and hope customs didn't ask too many questions.To get some form of development system and get started on the system. Then once you got far enough along sent a cart to Sega with a "we know we know" here is a game please publish or we will go with "large popular game making company". The "Sega were nice and Nintendo were jerks" narrative is false. Sega wanted to be Nintendo levels of jerks just they got blocked and stuffed up so they had to start to play nice so they didn't loose everything. Then they made the MK2 and tried to get full control back again.

The largest factor, is the MD is popular in Europe while Nintendo is unpopular in Europe. And the MD has a lot of cross over with devs from the Amiga and ST groups. While the C64 devs just stick to the C64 and are not really looking for something "better". I feel if the SNES was popular in Europe we would have a lot more of a SNES scene left. But the SNES scene hasn't resurrected unlike the other scenes. Maybe we should try and form a SNES scene again and use that as the catalyst, or do more of a C64 scene promotion. Just the MD will take an enhanced C64 game and love it, on a SNES its going to look out of place.

[Zonomi]

. I feel if the SNES was popular in Europe we would have a lot more of a SNES scene left.

Still, some of the best homebrew for the SNES were made by germans.

[SNES AYE]

So basically Technical Reasons.

Ah, I could have phrased that opening sentence better. What I meant was something like, "I don’t see technical limitations of the SNES hardware as the key reason more people aren’t creating homebrew games and demos." I can see how my original wording might have come across differently than I intended. That phrasing also ties better into the next point: "As far as I'm concerned, this really isn’t about a lack of interest or the complexity of the SNES itself—it’s that any remotely curious people who simply want to tinker, even casually, [can’t do so without jumping through some pretty major hoops]."

Does that make the point clearer? If not, I wouldn’t dwell on it too much—I think you get the gist: in principle, I believe that, more than any other factor, "If you build the right tools, they will come."

I'm also guilty of being obtuse.
My point is, the reason we don't have that is because of the 65816 and other layout and rules of the PPU. I.e "technical reasons". C doesn't work very well, because technical reasons, Asm can't really be bolted together, but on 6502 its not too bad, but on 65816 is very much "can't be bolted together" and to do said bolting you have to have a very strong grasp of the 65816 or you are in for pain and suffering. So "technical reasons". Sprites have have to be within a 16K block in the PPU, you have to set and tiles and screen formats and layouts and plan your VRAM around the technical requirements which you have to learn upfront, so again "technical reasons".
I.e the reason those tools don't exist and won't really ever exist is because "technical reasons". The libs "get close" which is about as close and friendly as they can get.

Just to make sure I understand you: you’re saying these tools don’t exist mainly because of technical hurdles—I follow you there. But are you also saying that even if such tools did exist (in the hypothetical scenario I’d like to see become reality), they still wouldn’t make a meaningful difference in encouraging more SNES homebrew development? I ask because I’m not entirely sure where you stand on that second point.

From my perspective, far more user-friendly and accessible tools would lower the barrier significantly and attract many more people to tinkering. That’s really the key point I was trying to get across from the start.

On that note, I’d be curious to hear your thoughts on the “SNESMaker” component of the upcoming Retro Game Forge. Do you think it could encourage more of the SNES homebrew community to at least experiment—similar to how the likes of NESmaker and GB Studio sparked activity on those platforms—or do you expect it’ll be largely ignored, with output from the SNES scene staying about the same as it is now?

[Oziphantom]

On that note, I’d be curious to hear your thoughts on the “SNESMaker” component of the upcoming Retro Game Forge. Do you think it could encourage more of the SNES homebrew community to at least experiment—similar to how the likes of NESmaker and GB Studio sparked activity on those platforms—or do you expect it’ll be largely ignored, with output from the SNES scene staying about the same as it is now?

It will boost the SNES development amount, we will probably get a rush of ports of NES and GB maker games to the SNES, and probably get "also exports". It will be a good test for the "increased effort" is a hurdle, in that it will make everything else the same but will require more artwork at a higher quality. But maybe the ability to make 16 colour art rather than 4 colour art will make "grab some artwork and convert it down" more plausible so we will get a faster conversion. So to this end the SNES will be an easy power upgrade for the them. Basically becoming the NES'es GBC, and then the halfway home between the GBC and the GBA.

Do we have any cases of people starting on Game Maker and then moving to actual dev though? Does this form a pipeline or do people stay in the box?

[SNES AYE]

On that note, I’d be curious to hear your thoughts on the “SNESMaker” component of the upcoming Retro Game Forge. Do you think it could encourage more of the SNES homebrew community to at least experiment—similar to how the likes of NESmaker and GB Studio sparked activity on those platforms—or do you expect it’ll be largely ignored, with output from the SNES scene staying about the same as it is now?

It will boost the SNES development amount, we will probably get a rush of ports of NES and GB maker games to the SNES, and probably get "also exports". It will be a good test for the "increased effort" is a hurdle, in that it will make everything else the same but will require more artwork at a higher quality. But maybe the ability to make 16 colour art rather than 4 colour art will make "grab some artwork and convert it down" more plausible so we will get a faster conversion. So to this end the SNES will be an easy power upgrade for the them. Basically becoming the NES'es GBC, and then the halfway home between the GBC and the GBA.

Do we have any cases of people starting on Game Maker and then moving to actual dev though? Does this form a pipeline or do people stay in the box?

Yeah, I think that’s a solid take on how things could play out. It’ll definitely be interesting to see what happens—if and when Retro Game Forge finally releases and gives the community another option, ideally one that’s easy to install and start experimenting with.

On that second point, I’m not sure. GameMaker doesn’t support SNES development, so I doubt many people would approach it with the intention of moving to SNES. More likely, they’d jump into whatever actual SNES development tools are available just to experiment at first, and—if they can push past the initial hurdles—eventually start working on proper games or cool demos once they feel more comfortable and ready for bigger challenges. But it doesn’t seem like many people are getting that far yet, which I can understand.

That’s still the role I hope PVSnesLib might grow into as it matures, and hopefully Retro Game Forge will be a nice option there as well—sooner rather than later.

[Oziphantom]

sorry by Game Maker, I mean the retro game forge "game makers", GB studio, NesMaker et al rather than https://gamemaker.io/en nobody is going from https://gamemaker.io/en to the SNES

[SNES AYE]

sorry by Game Maker, I mean the retro game forge "game makers", GB studio, NesMaker et al rather than https://gamemaker.io/en nobody is going from https://gamemaker.io/en to the SNES

Retro Game Forge hasn’t been released yet. However, while working there, they would already be creating SNES games using the 'SNESmaker' section. I assume the workflow would be to develop your SNES project in Retro Game Forge and then release it in ROM or physical form, similar to how people currently use NESmaker. That’s just my interpretation, though.

[Oziphantom]

okay I will make a very specific question set then.

Is there any evidence of people who have used NESMaker ditching NESMaker and starting from scratch ASM development.
Is there any evidence of people who have used GBStudio ditching GBStudio and starting from scratch ASM development.

[SNES AYE]

okay I will make a very specific question set then.

Is there any evidence of people who have used NESMaker ditching NESMaker and starting from scratch ASM development.
Is there any evidence of people who have used GBStudio ditching GBStudio and starting from scratch ASM development.

I honestly couldn’t say. But I do know many people have used, and are still using, NESMaker and GB Studio to develop games or demos—personally, I got a simple scrolling background with my own assets running in GB Studio in just a few minutes (didn’t take it further since SNES is my focus). There have even been quite a few physical releases made with both NESMaker and GB Studio, which is great. It’s possible some of those projects started in the tools and were later finished with more ASM coding, though that’s just speculation. I also recall—though I might be misremembering—that the creator of NESMaker mentioned you can still use ASM within it. From what I understand, the tool mainly provides surface-level features most people rely on to get started, but also offers options for those who want to go deeper. Apologies if I’ve got that wrong.

On a personal level, I’m not expecting much more from the wider SNES community right now than some fun experiments and small tests. Over time, I’d love to see people progress to really digging into the hardware with ASM to squeeze out every bit of performance—but I don’t expect that at the start. I’d be thrilled just to see more people experimenting on SNES in general: ripping backgrounds and sprites from other games or using free premade assets, setting up simple scrolling backgrounds, and moving a few sprites around. Even this kind of tinkering is still relatively rare on SNES compared to other retro systems (ignoring the actually very active Super Mario World ROM hacking scene for a moment), and in my view it all contributes to the bigger goal of eventually leading to more cool new games.

So simply encouraging more experimentation, small test projects, and sharing within the wider community would already be a solid step forward and help build enthusiasm. My hope is that a tool like Retro Game Forge (specifically its ‘SNESmaker’ module) will make this much easier, and that one day we might even see one or two other genuinely user-friendly SNES tools as well—ideally with PVSnesLib being one of them too.

[TakuikaNinja]

Is there any evidence of people who have used NESMaker ditching NESMaker and starting from scratch ASM development.

I started out with NESmaker before pivoting to independent ASM projects. I mainly contributed music to that community but I could tell that people were fighting the incomplete, buggy, and infrequently updated software/codebase more often than they were making progress in game projects. I tried alleviating that by providing any tweak or bugfix I could think of - but at some point, I realised that it would be better to work on my own things instead of maintaining a mess I wasn't responsible for in the first place. I pivoted to learning NESdev through hacking SMB1 (i.e. smb1-bugfix) and other games before falling into the current rabbit-hole that is the FDS.

There are probably a few others who moved on from NESmaker for similar reasons as myself. I try not to be hostile about it but I am not a fan of how the NESmaker community has essentially been deprived of official software updates for years now (remember: this is paid software), with Retro Game Forge (originally NESmaker version 5 + SNESmaker) being "the next big thing" the development team is putting all their effort into. No real engagement with their own community outside of the occasional YT updates and Byte-Off competitions. It has unfortunately been a repeating pattern ever since Mystic Searches/Origins.

Compare this to GBStudio, which is as an actively maintained open-source project with an actual code-less (yet customisable) workflow and strong community. I don't have to use it to know that the difference in quality is night and day. Why else would someone fork it for NES support?

Okay, that's a load off of my shoulders. Sorry to those still using NESmaker and have been looking forward to Retro Game Forge.

[SNES AYE]

Is there any evidence of people who have used NESMaker ditching NESMaker and starting from scratch ASM development.

I started out with NESmaker before pivoting to independent ASM projects. I mainly contributed music to that community but I could tell that people were fighting the incomplete, buggy, and infrequently updated software/codebase more often than they were making progress in game projects. I tried alleviating that by providing any tweak or bugfix I could think of - but some point, I realised that it would be better to work on my own things instead of maintaining a mess I wasn't responsible for in the first place. I pivoted to learning NESdev through hacking SMB1 (i.e. smb1-bugfix) and other games before falling into the current rabbit-hole that is the FDS.

There are probably a few others who moved on from NESmaker for similar reasons as myself. I try not to be hostile about it but I am not a fan of how the NESmaker community has essentially been deprived of official software updates for years now (remember: this is paid software), with Retro Game Forge (originally NESmaker version 5 + SNESmaker) being "the next big thing" the development team is putting all their effort into. No real engagement with their own community outside of the occasional YT updates and Byte-Off competitions. It has unfortunately been a repeating pattern ever since Mystic Searches/Origins.

Compare this to GBStudio, which is as an actively maintained open-source project with an actual code-less (yet customisable) workflow and strong community. I don't have to use it to know that the difference in quality is night and day. Why else would someone fork it for NES support?

Okay, that's a load off of my shoulders. Sorry to those still using NESmaker and have been looking forward to Retro Game Forge.

I feel your pain.

In a different but related way, that’s been my experience with PVSnesLib and the SNES development scene in general. It seems well suited to a handful of people who learn, code, and interact in a certain way—and that covers not only the tools but the particular community sites and styles of collaboration. For me, it’s often felt more like a barrier than a pathway to progress. Of course, that’s just my perspective, shaped by my own approach and experiences to date, and I’m sure it’s been ideal for others.

Interestingly, despite what you said, my brief experience with NESmaker and its creators still leaves me personally far more optimistic about the “SNESmaker” module of Retro Game Forge than about anything else happening in the SNES development tool space right now.

That said, most of my outlook is rooted more in hope for alternatives to what’s currently available.

[RT-55J]

I don't see romhackers really care about the console past just that it happens to be the platform the game they want to hack was made for.

Oof. Guilty as charged.

Hacking a popular, well documented game with a working editor (Super Metroid in my case) brings a certain kind of instant gratification. All the base mechanics you like are already their, other people have already solved the hard problems, there's loads of community resources to build off of, there's a guaranteed audience for it, etc.

However, the further I get into things, the more frustrations build up. Regardless of the quality of the disassemblies, tooling is almost never built under the assumption that you're actually building the game itself. The various subsystems of the game can be annoyingly overengineered or underengineered for your purposes. Finding freespace and placing hijacks is a constant bugbear. And your ambitions eventually start to run orthogonal to the base game's design (Super Metroid is not a good base for an Igavania starring an original character, for one). (And let's not even get into music.)

Now, with all of that said, A friend of mine in the SM hacking community has been taking a break from hacking to do some homebrew and, after about 6 months, has something that resembles a game at this point. Their success (combined with my gripes) is almost enough to get me to pivot towards homebrew.