Casual SNES development

[SNES AYE]

[Staff edit: This discussion has been split off from this post in the thread Anyone wanna help me make a SNES → C code converter? (yeah, for real).

SNES Decompilation is basically impossible.

Does “basically” mean literally impossible, or just extremely difficult? If it’s the latter, I’d like to encourage anyone willing to take on such a huge challenge in the SNES development community.

There are some games on the SNES that were written in a C compiler. Earthbound for example, which you could do the de-compilation for. Mortal Kombat also has some really weird stuff going on, I think Sim City was also C. So those games you can. Mario Paint, Picross games. You are probably looking at ~20.. 50 tops.
Some games will be basic bitch enough that a C decomp would be possible for the vast majority of it. Then a small percentage of games will be at best "yes this is a giant single function with gotos everywhere and a bunch of global variables that make registers rather than actual C functions" "decomp" and then a lot of games will be "here be dragons, not going to happen" of which Capcom games would be an example.

I think I may have misunderstood what he was proposing. I assumed the goal was to support new SNES game development by letting you work mostly in C without worrying too much about pure assembly, and then having the tool convert that code back into something that runs optimally on the SNES. Since he was talking about doing game-to-PC code conversion, I figured the long-term idea might be to eventually make the reverse possible: develop primarily in C, use the tool to automatically convert it to assembly, and have it run efficiently on the SNES. I also imagined you could go back and forth during development to create a more efficient and practical modern workflow.

It sounds like I got that entirely wrong. If that’s the case, then what is the benefit of converting existing SNES game code into C?

[Oziphantom]

so you can have SNES version of games like these https://www.youtube.com/watch?v=FczCmT1xos8 which give higher framerates, better support for machines, easier to mod and hack and almost anybody with basic programming knowledge can change and improve.

I.e get your fave snes game and add widescreen support, hires assets, more save slots, fix bugs in them etc

[SNES AYE]

so you can have SNES version of games like these https://www.youtube.com/watch?v=FczCmT1xos8 which give higher framerates, better support for machines, easier to mod and hack and almost anybody with basic programming knowledge can change and improve.

I.e get your fave snes game and add widescreen support, hires assets, more save slots, fix bugs in them etc

OK, so it’s basically a similar idea, but only for existing SNES games? Do those games actually end up running on the SNES again after conversion, or is the goal just to extract, modify, and then play them on other hardware?

Do we know if anyone in the SNES scene is working on something closer to what I originally had in mind—tools that would help more people create new SNES games, especially those who aren’t hardcore assembly programmers and would prefer something more like modern, accessible game-development environments, while still allowing the finished games to run as efficiently as possible on the original hardware?

I’m just curious about that, and even more so after this thread.

[Myself086]

Do we know if anyone in the SNES scene is working on something closer to what I originally had in mind—tools that would help more people create new SNES games, especially those who aren’t hardcore assembly programmers and would prefer something more like modern, accessible game-development environments, while still allowing the finished games to run as efficiently as possible on the original hardware?

I would love to get into that but not as a solo dev. I am remaking my personal assembler to be made public soon™. I post updates in the discord's tool-development channel. QoL as priority.

[Oziphantom]

so you can have SNES version of games like these https://www.youtube.com/watch?v=FczCmT1xos8 which give higher framerates, better support for machines, easier to mod and hack and almost anybody with basic programming knowledge can change and improve.

I.e get your fave snes game and add widescreen support, hires assets, more save slots, fix bugs in them etc

OK, so it’s basically a similar idea, but only for existing SNES games? Do those games actually end up running on the SNES again after conversion, or is the goal just to extract, modify, and then play them on other hardware?

Do we know if anyone in the SNES scene is working on something closer to what I originally had in mind—tools that would help more people create new SNES games, especially those who aren’t hardcore assembly programmers and would prefer something more like modern, accessible game-development environments, while still allowing the finished games to run as efficiently as possible on the original hardware?

I’m just curious about that, and even more so after this thread.

C dev for SNES has been arround for ages, https://github.com/alekmaul/pvsneslib most of the released games have been made with it. You won't hit the machine limits with it though and it has some issues. But people are using VBCC and MOS-6502 as they find it faster in just 6502 mode than the TCC compiler in 65816 or WDC compiler.

[SNES AYE]

so you can have SNES version of games like these https://www.youtube.com/watch?v=FczCmT1xos8 which give higher framerates, better support for machines, easier to mod and hack and almost anybody with basic programming knowledge can change and improve.

I.e get your fave snes game and add widescreen support, hires assets, more save slots, fix bugs in them etc

OK, so it’s basically a similar idea, but only for existing SNES games? Do those games actually end up running on the SNES again after conversion, or is the goal just to extract, modify, and then play them on other hardware?

Do we know if anyone in the SNES scene is working on something closer to what I originally had in mind—tools that would help more people create new SNES games, especially those who aren’t hardcore assembly programmers and would prefer something more like modern, accessible game-development environments, while still allowing the finished games to run as efficiently as possible on the original hardware?

I’m just curious about that, and even more so after this thread.

C dev for SNES has been arround for ages, https://github.com/alekmaul/pvsneslib most of the released games have been made with it. You won't hit the machine limits with it though and it has some issues. But people are using VBCC and MOS-6502 as they find it faster in just 6502 mode than the TCC compiler in 65816 or WDC compiler.

I’m familiar with PVSnesLib, and it’s a great option for those who are able to fully grasp it and make effective use of it. However, I was referring to something significantly more accessible and user-friendly—something suited for people who can’t easily wrap their heads around PVSnesLib or don’t find it practical to use.

It may not be obvious to those who live and breathe this kind of development, but PVSnesLib isn’t really anywhere near the level of “casual-friendly” I had in mind. Still, I’m genuinely grateful that it exists at all, because as far as I know, it remains one of the very few legitimate options available for creating new SNES games and demos in 2025—which is kind of astonishing when you think about it.

And who knows, if it continues to be improved and refined, maybe one day PVSnesLib will reach a level of accessibility and ease of use where even someone like me could make genuine use of it.

[Oziphantom]

the problem is the SNES, the lib can hide the 65816 and the how and whats of setting up VRAM word address vs byte address and handle the DMA options, but you can't really hide the SNES, the modes, the VRAM layout, the VBlank limits.

I might make a port of CBM BASIC 7.0 to the SNES though for the new first steps on a SNES tutorial, which is to be simpler than my simple tutorial.

[SNES AYE]

the problem is the SNES, the lib can hide the 65816 and the how and whats of setting up VRAM word address vs byte address and handle the DMA options, but you can't really hide the SNES, the modes, the VRAM layout, the VBlank limits.

I might make a port of CBM BASIC 7.0 to the SNES though for the new first steps on a SNES tutorial, which is to be simpler than my simple tutorial.

A SNES development tool with truly accessible, intuitive ease of use may not exist yet, and the obstacles might be significant, but I still find it hard to believe the challenge is genuinely impossible or tied to insurmountable limitations of the hardware itself. I think such a tool is ultimately achievable, even if it would require substantial effort on multiple fronts.

It reminds me of a discussion I had years ago, when I was convinced it had to be possible to create modern hardware capable of running real SNES games just like the original system—without donor chips, emulators, or any other clearly compromised workaround. Before FPGA solutions existed, many people insisted it simply couldn’t be done: that the SNES was too complex, that no one produced hardware like that anymore, and that no one would invest the time or resources to make it happen. And yet FPGA technology eventually arrived and delivered basically exactly what I had hoped for.

I hold the same hope for a truly “casual” SNES development environment one day—not something compromised or low-quality, but something genuinely capable and still approachable for someone like me. And who knows—maybe even you’ll be part of making that happen. I’m living the dream!

Edit: Anyway, I’m going off on a bit of a tangent, so I’ll leave it there. I don’t want to derail the discussion.

[SNES AYE]

Do we know if anyone in the SNES scene is working on something closer to what I originally had in mind—tools that would help more people create new SNES games, especially those who aren’t hardcore assembly programmers and would prefer something more like modern, accessible game-development environments, while still allowing the finished games to run as efficiently as possible on the original hardware?

I would love to get into that but not as a solo dev. I am remaking my personal assembler to be made public soon™. I post updates in the discord's tool-development channel. QoL as priority.

I take it there aren’t many people in the SNES development community interested in working on something like that as a collaborative project? It always boggles my mind, but I can’t even code in assembly, so I can’t have too strong an opinion on that.

Best wishes with your personal assembler project. I hope it turns out great and adds some nice QoL features.

[Memblers]

mkwong98 on the forum here has done a similar thing for NES, it might be useful to see how that works.
viewtopic.php?t=26098

I also imagined you could go back and forth during development to create a more efficient and practical modern workflow.

I didn't try it, but I thought it would be funny to try taking something like one of mkwong's ports, then port it back to NES with llvm-mos. It would do a call graph on the full game, and would be interesting to see how RAM is used afterwards, but there's no practical reason to this.

[Biff Burgertime]

Do we know if anyone in the SNES scene is working on something closer to what I originally had in mind—tools that would help more people create new SNES games, especially those who aren’t hardcore assembly programmers and would prefer something more like modern, accessible game-development environments, while still allowing the finished games to run as efficiently as possible on the original hardware?

That's the thing, though... If you want to make games that run fast, efficient code, then your game needs to speak the native language of its target hardware. In the SNES' case, that's assembly.

When it comes to things like NESMaker, you're trading ease-of-use for efficiency. If a "SNESMaker" was created, you wouldn't be able to make anything too technically-impressive with it.

These things are all about trade-offs & compromises.

[Nikku4211]

I.e get your fave snes game and add widescreen support, hires assets, more save slots, fix bugs in them etc

Hi-res pixel art? Oooookay...

A SNES development tool with truly accessible, intuitive ease of use may not exist yet, and the obstacles might be significant, but I still find it hard to believe the challenge is genuinely impossible or tied to insurmountable limitations of the hardware itself. I think such a tool is ultimately achievable, even if it would require substantial effort on multiple fronts.

I think his point is that the very SNES hardware itself is complicated in a way completely foreign to modern hardware. You can abstract as many of it away as you want, but if you want to take off the training wheels and truly utilise the system (at least in a relatively unique way like I want to), you'll really need to learn the in-depth details of how this early 1990s hardware works.

And that alone is enough to scare away people who don't already know 65c816 assembly code, especially those that think they need to start small on a completely different system rather than trying to start small on the very same system they've already been interested in putting a game on.

Though that can be split into its own separate thread about many creative people obsessing over trying to make a magnum opus right away.

I take it there aren’t many people in the SNES development community interested in working on something like that as a collaborative project? It always boggles my mind, but I can’t even code in assembly, so I can’t have too strong an opinion on that.

Even when coding for the same system in the same 65c816 assembly, everybody has vastly different workflows, with different assemblers and different tools they're used to. It would be hard to get them to all work together with how many are only used to doing what they do completely on their own.

I've certainly learned that lesson the hard way during the 2025 SNES game jam, which is why I've never came close to finishing a SNES game even just for that. You can make a split thread out of this.

When it comes to things like NESMaker, you're trading ease-of-use for efficiency. If a "SNESMaker" was created, you wouldn't be able to make anything too technically-impressive with it.

I don't even know what you'd be able to make with it. It'd have to be very limited just to be a simple no-code solution that still needs to run well on early 1990s hardware. You can make a spli-- no, don't.

[SNES AYE]

Thanks for the interesting replies.

I just want to make sure I’m understanding the core point correctly. Are some people saying that there is literally no way, now or in the future, to create a tool that would let someone work at a higher level—something like C, possibly even with some drag-and-drop elements—and then convert that into highly optimized, near-perfect SNES assembly, as if it had been written that way from the start?

I don’t mean “it would be extremely hard and require a huge amount of work to design and implement,” but that such a tool is considered fundamentally impossible to create. Not “the methods for doing this are not currently known in any remotely practical or efficient form, and there isn’t enough incentive to pursue something that difficult right now,” but “it simply could never be done.” And because of this inherent limitation, any SNES development tool built above pure assembly would always end up fundamentally limited.

In other words, is the tenet that higher-level code like C simply cannot be translated into fully optimal SNES assembly—or, for all practical purposes, as close to that as humanly possible—even by a highly advanced, well-designed, user‑friendly tool? Because unless I’m misunderstanding something, that seems to be the takeaway from the discussion.

Does that make sense as a question?

[Fiskbit]

We've had tools that do exactly this since the 1950's. They're called compilers. The vast majority of code in existence is compiled (in some way) from a high level language to assembly; this is the norm. Compiler-generated assembly code is not the same as human-generated assembly code. It will likely be more efficient at some things and less efficient at others, but on the 65816 (for which we have the cc65 compiler for C), I would guess that you can expect a significant performance penalty. That could be improved with a better compiler, but writing good assembly code is probably always going to be faster.

[Pokun]

If it's not clear yet, C does not work well with 65816. WDC has an official C compiler for it but I don't know if it's any better than cc65, it won't output highly optimized assembly anyway.

I guess it's technically fully possible to invent a new high-level language that is designed to work well with 65816, but it's unlikely to happen anytime soon.

I don't see why a drag-and-drop DE that spits out highly optimized 65816 assembly should be impossible either, but it's definitely in the territory of "require a huge amount of work". It's more likely that something like NES Maker for SNES will happen.