Casual SNES development

[vbc]

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.

vbcc also has a 65816 version (viewtopic.php?t=25773).

[creaothceann]

create a tool that would let someone work at a higher level - something like C

There have been higher-level script interpreters, for example for the SCUMM language, for Another World, and other games. The game developers can then be categorized into "game script writers" and "engine developers". One advantage is that the "game script writers" can work in the high-level language much more suitable for that specific game (among other advantages like easy portability). The disadvantage is that this game code needs to be read, decoded and executed by a virtual machine, just like a GameCube emulator has to create a virtual GameCube, with a certain performance loss.

possibly even with some drag-and-drop elements

A level editor?
Programming languages that work via drag-and-drop are either GUI development tools like Visual Studio, Delphi or Lazarus, or they are very primitive languages for kids. You'll always be faster via the keyboard, which is good because writing a game usually involves a lot of code.

and then convert that into highly optimized, near-perfect SNES assembly, as if it had been written that way from the start?

"highly optimized, near-perfect [...] assembly" can be a very dirty thing. It may contain jumps into the middle of an opcode, it may use undocumented opcodes (well, not in the case of the 65c816), it may use self-modifying code. They may temporarily disable hardware interrupts and use the stack pointer register for other purposes.

There are various well-known things that a human can use to optimize code. These may even be incorporated into code generators.
But a human can have a very different view of the program than a compiler. They may for example realize that for a specific game, certain variables will always contain values of a certain range or pattern, and use that info to reduce pre-calculated look-up tables.

[Nikku4211]

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.

CC65 doesn't support 65c816 compiling, only assembly to 65c816 through CA65, so technically WDC can generate better code for the 65816, because CC65 can't compile C code for the 65816 at all to my knowledge.

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.

Wiz and Higueul don't count?

I've never used either (since I'm used to hand-typing 65816 ASM by now) and Higueul is officially described as a low-level language, but both look about as high-level as C would be compared to 65816 assembly.

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.

A drag-and-drop game maker for SNES that has highly optimised hand-written engine code would either be very limited to stay doing what it's specifically optimised for, or become very unoptimised very fast if it ends up supporting custom code that isn't supposed to be as complex as direct hand-typed assembly.

[tepples]

Even unoptimized code that runs at 30 fps can prove useful. Once you have the game design blocked out in a high-level language, that gives you enough context to hire a programmer to reimplement the inner loops in assembly.

[Nikku4211]

"highly optimized, near-perfect [...] assembly" can be a very dirty thing. It may contain jumps into the middle of an opcode, it may use undocumented opcodes (well, not in the case of the 65c816), it may use self-modifying code. They may temporarily disable hardware interrupts and use the stack pointer register for other purposes.

There are various well-known things that a human can use to optimize code. These may even be incorporated into code generators.
But a human can have a very different view of the program than a compiler. They may for example realize that for a specific game, certain variables will always contain values of a certain range or pattern, and use that info to reduce pre-calculated look-up tables.

I wonder if there's a page on the SNES.NESDev Wiki for 65c816 assembly optimisations, both to show which 6502 optimisations aren't as useful on 65816 and to show 65c816-specific optimisations either not practical on vanilla 6502 or just has no advantage on vanilla 6502.

Yeah, a human would need to be in so much more control than a C compiler just to get the right optimisations for the specific game/demo they would want to make. That's the nature of optimisations on systems this old, they're often nowhere near general-purpose.

Even unoptimized code that runs at 30 fps can prove useful. Once you have the game design blocked out in a high-level language, that gives you enough context to hire a programmer to reimplement the inner loops in assembly.

Assuming you are an entrepreneur and somehow have enough income to hire a programmer (under a fair wage) in the first place.
Otherwise, you'll just have to deal with the difficulty of needing to get yourself inside the lemon of people interested in your project that also have the skills to make it possible as well as the time (and money).

Also even if you're some idea guy with a spare thousands of dollars to put into your project for whatever reason, I feel like there's going to be a point where you'll run into diminishing returns where it'd actually be faster to just have the game coded directly in assembly to begin with. Rather than bother to make an entire prototype on the SNES in C just to desperately try to pitch to assembly programmers.

Or make the prototype run on a different system that might not be accurate enough if you want to demonstrate how exactly you want your game to use the SNES hardware.

[Pokun]

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.

Wiz and Higueul don't count?

I've never used either (since I'm used to hand-typing 65816 ASM by now) and Higueul is officially described as a low-level language, but both look about as high-level as C would be compared to 65816 assembly.

I don't know either, SNES AYE would have to be the judge if any of those matches what he seeks.

[SNES AYE]

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.

Wiz and Higueul don't count?

I've never used either (since I'm used to hand-typing 65816 ASM by now) and Higueul is officially described as a low-level language, but both look about as high-level as C would be compared to 65816 assembly.

I don't know either, SNES AYE would have to be the judge if any of those matches what he seeks.

My focus and interest is on a SNES game creation tool designed from the user experience down, rather than from the code up—regardless of how it’s actually built. The main priority should be simplicity and ease of use at every level: installation (perhaps not even requiring one, just running from a self-contained exe), setup, and the interface people interact with moment to moment for creating, building, and testing games—before they ever touch low-level code.

The underlying language matters only insofar as it isn’t so obscure that almost no one can use it when they inevitably have to. What matters most is that the tool is accessible, allowing designers, artists, and musicians to work naturally at a high level—including right from the very first installation and setup. The specific coding language and syntax only become truly relevant at the limits of what the tool can do automatically, or when users want to extend things manually beyond the built-in options. That’s exactly the kind of tool I’m looking for as a creator who wants to work directly on new SNES games and demos.

I was primarily asking about the method of translating between Assembly and a higher-level language, and then ultimately the tool, and vice versa, because I thought the other thread was describing a possible way of achieving this bridge—from being stuck with obscure Assembly to having something far more accessible on the coding side. I feel that solving this could be key to making the whole approach work in a meaningful way, once combined with the end tool and user interface, for a much broader user base of creators.

Does that make sense? Are you following what I mean here?

[Fiskbit]

When people who can't do art want art, they work with an artist. When people who can't do music want music, they work with a musician. If you can't program, why not just work with a programmer?

I'm not arguing that accessible tools are a bad thing. Greater accessibility is generally a good thing, and letting people achieve more themselves and have some independence is good. But making games is frequently a collaborative endeavor, and if you collaborate with a programmer, odds are very good you'll make something much more worthwhile than if you use some limited tool that lets you avoid this discipline of skilled work. If you yourself can bring something meaningful to a collaboration, then I don't think finding a programmer to work with should be prohibitively difficult.

[Pokun]

...
Does that make sense? Are you following what I mean here?

Yes, I know what you mean and I know your pain. I'm more of an artist myself and just a slowly self-taught hobby programmer, I am always struggling with the coding side of my projects.

You are looking for something with high accessibility, which is sort of rare especially for open-source stuff. Making things accessible takes much more work, and that is time and energy programmers rather spend on making it more powerful and feature-complete. It requires making it usable on multiple platforms without the user having to build it from source and it requires well written documentation readable by people without a background in engineering.
The more powerful the tool becomes the more technical it becomes which means it becomes harder to maintain a high accessibility.

But while waiting for such a wonder program to appear, which I'm sure it will at some point, I personally choose to spend my free time at learning more programming so that I can cover my weakness.
Learning programming requires a lot of reading old technical manuals, but what I think is more important is to practice it. Like with everything, knowing it at a conscious level is not enough, you will get stuck again and again, you need to do exercises to learn it on a subconscious level.

Unfortunately for 65816 I'm not sure where to find such exercises (though I haven't been looking very hard as I've focused on other CPUs). Since it was used in Apple II, I think it might be best to look for Apple II programming books and exercises.

[SNES AYE]

When people who can't do art want art, they work with an artist. When people who can't do music want music, they work with a musician. If you can't program, why not just work with a programmer?

I'm not arguing that accessible tools are a bad thing. Greater accessibility is generally a good thing, and letting people achieve more themselves and have some independence is good. But making games is frequently a collaborative endeavor, and if you collaborate with a programmer, odds are very good you'll make something much more worthwhile than if you use some limited tool that lets you avoid this discipline of skilled work. If you yourself can bring something meaningful to a collaboration, then I don't think finding a programmer to work with should be prohibitively difficult.

This follows on from my previous comment. I’m not talking about just working with a programmer on one-off personal projects, though that can be a great option for collaboration. Solving the project-specific programming aspect first isn’t the key to opening up SNES game creation to a much wider base of creators. What I’m really interested in is a tool that lets people design and build games at a high level before needing to dig into low-level details or optimize every cycle of performance. Ideally, anyone should be able to get up and running and create basic games without facing major barriers from the start, which would be helpful for me as well.

I want to emphasize that I’m thinking about a tool that’s not just for me, but something that opens up SNES game development to many more people. That’s my focus in this conversation: exploring ways to reduce current barriers and create a tool that is genuinely usable without limiting creators to only very simple projects. The underlying code is important, of course, and this conversation began in another thread about converting SNES Assembly to C, as I understood it, because there seems to be a key challenge in moving from SNES Assembly to a higher-level language (and back again). I imagine that would be an important piece of making a truly accessible, user-friendly, and highly optimized SNES development tool. At the same time, I think the code itself is secondary to having a tool that sits on top and makes game creation approachable for a wider audience.

I also want to clarify that I never said I can’t program. Although, I can’t program in Assembly, which is a very specific skill. I’m not trying to solve my own Assembly limitations here, but rather exploring ways to address what I see as the broader issue for the SNES creator community. I’m not the focus, and don’t wish to be. The ultimate goal isn’t just supporting one project, but creating an ideal tool that enables the broader SNES creator community in the long term. That’s a far more meaningful endeavour in my opinion.

Again, does that make sense? Do you see what I’m getting at here?

[Pokun]

Yes it makes sense and I think it's the natural way for the industry to evolve. But it has an ugly side to it too, it will cause more shovelware homebrew for SNES. It's much of the same type of problems the art, comic, music and film industries are facing. It's just so much easier to create multimedia work than ever before with more accessible technology, and this favors quantity over quality.

And now we have powerful AI which is starting to make crafting even easier, changing the industry even quicker, even the literary industry is affected.
I checked up on a film at IMDb the other day, the summary that showed was AI-generated and pretty much useless, just one of many bad examples how to use AI nowadays (shame on you IMDb).

But I still think it's a natural and pretty much unavoidable evolution for increasing efficiency, the industry just haven't learned how to handle it yet.

[SNES AYE]

Yes it makes sense and I think it's the natural way for the industry to evolve. But it has an ugly side to it too, it will cause more shovelware homebrew for SNES. It's much of the same type of problems the art, comic, music and film industries are facing. It's just so much easier to create multimedia work than ever before with more accessible technology, and this favors quantity over quality.

And now we have powerful AI which is starting to make crafting even easier, changing the industry even quicker, even the literary industry is affected.
I checked up on a film at IMDb the other day, the summary that showed was AI-generated and pretty much useless, just one of many bad examples how to use AI nowadays (shame on you IMDb).

But I still think it's a natural and pretty much unavoidable evolution for increasing efficiency, the industry just haven't learned how to handle it yet.

I actually agree with you about the potential for shovelware, which is unfortunately hard to avoid when opening things up to a much larger audience. That said, I genuinely think the overall impact could be a net positive. While we might see some filler or lower-quality releases, I also expect to see a few real gems, a fair number of solid games and demos, and generally a healthier scene with more development activity for the SNES overall. And I’m all for that.

If we end up with even one or two genuinely cool new games each year—especially legitimate physical boxed releases—that would be a win in my book. I also think that bringing in more skilled game designers, top artists, and talented musicians, alongside the typically hardcore programmers who currently make up most of the scene, is key to making that happen—something much harder under the current highly restrictive conditions.

So yes, I’m an advocate for potentially opening things up, giving more people the tools to start creating new SNES games and demos, and I’m genuinely interested in seeing what would emerge from that.

[Nikku4211]

But it has an ugly side to it too, it will cause more shovelware homebrew for SNES. It's much of the same type of problems the art, comic, music and film industries are facing. It's just so much easier to create multimedia work than ever before with more accessible technology, and this favors quantity over quality.

And now we have powerful AI which is starting to make crafting even easier, changing the industry even quicker, even the literary industry is affected.
I checked up on a film at IMDb the other day, the summary that showed was AI-generated and pretty much useless, just one of many bad examples how to use AI nowadays (shame on you IMDb).

Without going into too much detail, as I know from personal experience that this specific aspect of the topic is probably best kept off of anything owned by NESDev.org, I am indeed very much worried about this too.
I don't want to lose that spark I used to have whenever a new SNES homebrew releases. I used to feel a bigger connection to SNESDev homebrew community output back in 2021 or so, back when there weren't anywhere near as many SNES games coming out. It was smaller, but that's exactly why it felt personal.

If anyone wants to make SNESDev easier for non-coders, go ahead. I won't stop you. Maybe we need more people who primarily lean into the more creative fields involved, as video games are not just computer programs, they are also art.

I have no idea how many people in homebrew communities think of video games as art in a similar way I do. With how much coding is often about problem-solving, I wouldn't be surprised if other people have that same 'problem-solving' view when it comes to the non-coding parts of a game's design and aesthetic.
I personally think that kind of view would miss the forest for the trees, but who cares when I'm just some random bumbling idiot that just happens to have a drawing tablet, the Windows 7 version of MS Paint, a Steam-gifted copy of Aseprite, Notepad++, MSYS2, and OpenMPT?

[SNES AYE]

I don't want to lose that spark I used to have whenever a new SNES homebrew releases. I used to feel a bigger connection to SNESDev homebrew community output back in 2021 or so, back when there weren't anywhere near as many SNES games coming out. It was smaller, but that's exactly why it felt personal.

I must be totally out of the loop here, because what I’m seeing in my feeds is mostly just a small handful of new SNES games in development—literally a number you could count on two hands, if you're lucky—with only occasional updates from their developers. Beyond that, it’s mainly the regular stream of ROM hacks (mostly SMW) and those now fairly common direct NES-to-SNES ports, which I think are all very cool but still feel different from original projects. It’s that first category—the truly new SNES games—where I feel the scene could really use a lot more activity and ideally attract more highly skilled designers and artists.

I don’t follow any hardcore development forums outside of this place; I’m mostly going off what I see on standard social media, YouTube, and a few retro-centric gaming sites that regularly post about new homebrew projects. From that perspective, I’m not seeing much happening on the SNES—certainly not compared to the likes of the Game Boy, NES, Genesis, Amiga, Neo Geo, or even the Master System, where the rise in development seems to be producing a steady stream of genuinely cool new games, along with the expected flood of shovelware, of course.

I guess it ultimately comes down to personal perspective—whether someone sees the scene as bustling, ticking along, stagnating, or pretty much dead. I see it somewhere between ticking along and stagnating, talking about specifically in relation to new games, especially given how much development I would have expected on the SNES relative to its popularity. I’d love to see it bustling, though.

On that note, I think you were working on a game for the SNES, but I haven't seen anything about it in quite some time. I haven’t been looking specifically, but nothing has popped up wherever I normally browse. How’s that coming along?

[Pokun]

Well yeah, I guess the SNES homebrew scene isn't exactly risking to drown in shovelware, so more accessible tools probably would only do it good. If anything it could help increasing the interest in the system.
Homebrew for any system has a lot of very simple games varying greatly in quality, which isn't strange since there is no quality control (and it shouldn't be). And SNES, being one of the least targeted systems relative to its overall popularity, has very little variation in its homebrew compared to more popular homebrew platforms, simply because it has less homebrew releases.

And yeah that about attracting more artists is a very good point. Nintendo realized this early on, and other companies soon followed, that the video game industry should use similar strategies as the film and animation industries where artists are designing the games and engineers handles the technical side (although the staff members can have multiple roles that overlaps and many companies allows anyone to pitch game ideas). This was made obvious with the smash hit Donkey Kong designed by an artist (Miyamoto) after having failed as Radar Scope designed by an engineer (Uemura).

That's another reason homebrew tend to be a bit bland. It's mostly made by anyone that have the skill to code and the interest to make a game strong enough to finish something, but they may or may not also have skill in drawing, design and music which may be necessary for creating a good game.