Casual SNES development

[Nikku4211]

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.

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.

I wasn't saying SNESDev becoming full of shovelware is something that's already happening. I was just building on Pokun's idea about the potential for that to happen.

It is true that I already don't feel as connected to the SNESDev scene/community as I did back in 2021, but I wouldn't currently go that far to say that the homebrew scene is already full of shovelware right now.

Though there is the occasional homebrew release with plagiarised graphics here and there, but the SNESDev scene is small enough that usually other homebrew scenes are targeted with plagiaristic projects first.

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.

If this was 2021, I probably would have been more desperate to have the SNESDev scene boom. I would have taken anything at that point over the dead silence most people have around that system as a development platform.

But I have changed. With all the drama I've seen in other homebrew development communities I frequent, I kind of have grown comfortable with SNESDev staying on the low. I know it's going to be tough to deal with a sudden boom in SNESDev activity no matter what causes it. I'd have to get used to having more eyes on me by then, which is not something I would have anticipated when I wrote my first SNES homebrew LibSFX demos (that just show a random art piece I drew) in 2019.

I'm not going to fight tooth and nail against any boom, because I don't know everything so I can't be already sure what's best for SNESDev as a whole. I can't even be sure what would be best for myself as a person right now.

Maybe this reply is splitbait, or maybe that belongs in a whole different forum now. I don't know.

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?

Which one?

Chances are, I know just as much about what's coming along with some of my own projects as you do.

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.

[...]

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.

This is expected. I expect most homebrew for any system to be small-scope arcade-type games like Pong, Snake games, and whatever other 70s-80s arcade games can easily be cloned without leaning too much into high-skill level design.
That's not an issue. Developers need to start somewhere, and if they decide that making higher-scoped games just isn't for them, that's fine too. It's good when people realise they are not going to make miracles happen, and aren't concerned about making one magnum opus.

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).

This did seem like a good idea for professional game studios, with how much there seemed to be a gradual shift in how game designers were marketed from the 1970s to the 1980s.

I have no idea how to attract less-technical-minded artists to a system as limited as the SNES, though. It's not an NES, but that simply means the limitations aren't unique enough to attract people specifically to its challenges, yet also are still likely too limited for modern pixel artists to be satisfied learning any of the limitations the hard way when they inevitably overestimate (yes this is not a typo, I don't mean underestimate) the system's capabilities.

Back in the 1990s, it would have just been rationalised as the "H-est D" of the era - as pixel artist Blake Reynolds puts it - but in 2025, it's very clearly not even HD, and not even the "best" way to utilise standard definition or below (even for 2D) either. I wonder how many pixel artists who got their start way more recently would struggle following the less obvious (for 2D anyway, to non-technical people) limitations of the SNES' graphics hardware with its many background modes and sprite limitations while drawing for that system, even without actually handling coding themselves.

[SNES AYE]

Which one?

I can’t remember the name of the game, and I’m starting to think I might be mixing it up with another SNES title. It was a platformer, and I recall something about it having a fishing-pole mechanic. The creator had either increased or decreased the size of the line’s segments to make it look better. Also—possibly the same game, or maybe a different one—I remember some cool Mode 7 sections where the character was jumping. Sorry this isn’t more helpful; I wish I remembered it better. Oh, and it was a sequel, I think.

I wonder how many pixel artists who got their start way more recently would struggle following the less obvious (for 2D anyway, to non-technical people) limitations of the SNES' graphics hardware with its many background modes and sprite limitations while drawing for that system, even without actually handling coding themselves.

As a trained artist experienced across traditional 2D, multiple digital mediums, 3D software, and both unrestricted and highly constrained formats—including SNES—I don’t think creating artwork to SNES specs is inherently harder than doing so for other retro systems once you understand the key limitations: palette availability, colors per tile, sprite size limits, tile counts, and similar constraints. Most technical considerations beyond that—sprite limits, tilemap layout, background modes—should typically be the programmer’s or the tool’s responsibility, not the artist’s, aside from basic awareness. Working within limitations is never trivial, of course, but any artist with an interest in the SNES can learn and adapt; skilled artists routinely create strong work across mediums and restrictions.

The real problem isn’t making SNES-spec art—it’s testing it. While plenty of tools help create graphics that meet SNES requirements, converting them into proper system-ready data and viewing them on real hardware or an accurate emulator is an entirely different challenge. Simply getting to the point of displaying an image in a SNES emulator is, frankly, nightmarishly convoluted: an obstacle course of obscure steps, fragmented instructions, and niche toolchains that demand far more technical expertise than any artist should need just to see their work on screen. As far as I can tell, there is still no straightforward tool that takes SNES-spec art and outputs a .sfc/.smc file—or injects it into a blank ROM—that runs cleanly on actual hardware or an emulator without jumping through near-impossible hoops. It shouldn’t require being a computer wizard to do something as basic as previewing your art. Ideally, you’d drop your assets into a tool and instantly get a functioning SNES ROM that lets you view them in an emulator to make sure everything is looking correct.

Until such transparent, intuitive testing exists—even purely in emulators—artists remain stuck in an absurd situation, and that’s before considering all the other non-art parts of SNES development. If tools like this already exist, I would genuinely love to know; years of searching and asking around have turned up either nothing or a few potential methods so inaccessible that they stop me in my tracks, which I honestly think shows how badly the situation needs fixing. If this is that difficult for someone with experience, it’s practically impenetrable for newcomers who simply want to create SNES-style art and see it running.

I have a full set of SNES-spec-ready sprites and backgrounds, yet even today there still isn’t a simple upload or drag-and-drop solution that lets me take one or two steps and view them properly in a SNES emulator. I’m convinced this lack of accessible tooling is a major reason we don’t see far more artists producing high-quality SNES-style work, and I’d love for anyone with even a passing interest to have a way to test their art effortlessly. Ultimately, it all comes down to tools, accessibility, and ease of use.

[Nikku4211]

I can’t remember the name of the game, and I’m starting to think I might be mixing it up with another SNES title. It was a platformer, and I recall something about it having a fishing-pole mechanic. The creator had either increased or decreased the size of the line’s segments to make it look better. Also—possibly the same game, or maybe a different one—I remember some cool Mode 7 sections where the character was jumping. Sorry this isn’t more helpful; I wish I remembered it better. Oh, and it was a sequel, I think.

You're talking to somebody who has never finished a single SNES game.

Assuming that the 'cool mode 7' sections actually were a different game, that still doesn't sound like anything I've made. That sounds more like Nova the Squirrel 2, an upcoming SNES game that is being developed by the eponymous NovaSquirrel.

I... am not NovaSquirrel.

As a trained artist experienced across traditional 2D, multiple digital mediums, 3D software, and both unrestricted and highly constrained formats—including SNES—I don’t think creating artwork to SNES specs is inherently harder than doing so for other retro systems once you understand the key limitations: palette availability, colors per tile, sprite size limits, tile counts, and similar constraints. Most technical considerations beyond that—sprite limits, tilemap layout, background modes—should typically be the programmer’s or the tool’s responsibility, not the artist’s, aside from basic awareness. Working within limitations is never trivial, of course, but any artist with an interest in the SNES can learn and adapt; skilled artists routinely create strong work across mediums and restrictions.

It's not simply about whether it is harder than other retro systems from before it.
My point is that I feel people who usually already work with system limitations don't find the SNES' limitations interesting enough, which can be for a reason less related to how difficult it'd actually be for them to work with it. And it's going to be hard in general for any artist not already experienced with any actual retro console at any capacity.
Most pixel artists today don't make pixel art for actual retro consoles or actual retro handhelds. If they make pixel art for any game, it's usually going to be a game on modern systems where the game only vaguely imitates a lower resolution.

I guess most games would only need basic awareness from artists if you're going after looking like most other games on the SNES that already exist. Not like most of the people who want to make a SNES game would be interested in making use of rarely-used hardware features or rarely-used video modes like I would, or would really want to push the sprite pixel limit.

The real problem isn’t making SNES-spec art—it’s testing it. While plenty of tools help create graphics that meet SNES requirements, converting them into proper system-ready data and viewing them on real hardware or an accurate emulator is an entirely different challenge. Simply getting to the point of displaying an image in a SNES emulator is, frankly, nightmarishly convoluted: an obstacle course of obscure steps, fragmented instructions, and niche toolchains that demand far more technical expertise than any artist should need just to see their work on screen. As far as I can tell, there is still no straightforward tool that takes SNES-spec art and outputs a .sfc/.smc file—or injects it into a blank ROM—that runs cleanly on actual hardware or an emulator without jumping through near-impossible hoops. It shouldn’t require being a computer wizard to do something as basic as previewing your art. Ideally, you’d drop your assets into a tool and instantly get a functioning SNES ROM that lets you view them in an emulator to make sure everything is looking correct.

Until such transparent, intuitive testing exists—even purely in emulators—artists remain stuck in an absurd situation, and that’s before considering all the other non-art parts of SNES development. If tools like this already exist, I would genuinely love to know; years of searching and asking around have turned up either nothing or a few potential methods so inaccessible that they stop me in my tracks, which I honestly think shows how badly the situation needs fixing. If this is that difficult for someone with experience, it’s practically impenetrable for newcomers who simply want to create SNES-style art and see it running.

I have a full set of SNES-spec-ready sprites and backgrounds, yet even today there still isn’t a simple drag-and-drop solution that lets me take one or two steps and view them properly in a SNES emulator. I’m convinced this lack of accessible tooling is a major reason we don’t see far more artists producing high-quality SNES-style work, and I’d love for anyone with even a passing interest to have a way to test their art effortlessly. Ultimately, it all comes down to tools, accessibility, and ease of use.

As an artist and musician myself who is also a jack of other trades including SNES programming, it's tough for people who are more experienced to even be able to think from the lens of someone who has none of that knowledge they have.

There's always different levels of inexperienced. From people who don't even know what a tilemap is, to people who know a bit about the hardware but have never directly ran a command-line tool before, to people who do know how to code but simply struggle to make their tool very convenient to use for other people with completely different workflows.
Making a tool accessible is not an easy problem to solve. In such a niche tech community, it's hard to find inexperienced people willing to try it out, and even harder to find ones that trust you as a person enough to even bother testing it. Testing an unfinished program over and over again can be very draining, too, in a world where all time comes at a premium.

[SNES AYE]

Assuming that the 'cool mode 7' sections actually were a different game, that still doesn't sound like anything I've made. That sounds more like Nova the Squirrel 2, an upcoming SNES game that is being developed by the eponymous NovaSquirrel.

I... am not NovaSquirrel.

Ah, yes, I was confusing you with NovaSquirrel. Apologies for the mix-up.

I understand what you’re saying about the challenges around art, tools, and accessibility. I do think there are plenty of people specifically interested in working on the SNES who are just waiting for the right tools to appear, so there is an audience, but I get that it’s difficult to design tools that truly meet their needs. Personally, I think the ideal approach is to make the surface-level experience as simple and accessible as possible while letting the heavy lifting happen under the hood, with more advanced features available when people are ready for them. That seems like an ideal approach to me, especially in a scene where newcomers can vary widely in experience and confidence.

I'm happy to test these kinds of tools since I would directly benefit from them. In fact, if there’s a tool that allows genuinely simple uploading and outputs SNES art assets in a format that can be directly viewed in an emulator—even something as simple as a single background viewer where you can switch between images—I’d be very interested.

[tepples]

I can’t remember the name of the game, and I’m starting to think I might be mixing it up with another SNES title. It was a platformer, and I recall something about it having a fishing-pole mechanic.

Fishing pole platformer may have been Umihara Kawase. If the protagonist looked a bit like Dora "The Explorer" Marquez, and the enemies were fish, and the HUD was positioned really far from the top and bottom of the screen, then it was definitely Umihara Kawase.

I don’t think creating artwork to SNES specs is inherently harder than doing so for other retro systems once you understand the key limitations: palette availability, colors per tile, sprite size limits, tile counts, and similar constraints. Most technical considerations beyond that—sprite limits, tilemap layout, background modes—should typically be the programmer’s or the tool’s responsibility, not the artist’s, aside from basic awareness.

You'd probably still need to choose a background mode up front in order to set the colors per tile for each background.

As far as I can tell, there is still no straightforward tool that takes SNES-spec art and outputs a .sfc/.smc file—or injects it into a blank ROM—that runs cleanly on actual hardware or an emulator without jumping through near-impossible hoops. It shouldn’t require being a computer wizard to do something as basic as previewing your art. Ideally, you’d drop your assets into a tool and instantly get a functioning SNES ROM that lets you view them in an emulator to make sure everything is looking correct.

Say someone were to create such a point-and-click tool, yet that someone's computer runs a different operating system from yours. For example, say I built a preview tool for Linux, and you want to use it but you use Windows. (Now that public security updates for Windows 10 have ended, I don't even own a computer capable of running the supported version of Windows.) Would you find it worth installing another operating system in a virtual machine if it meant you could point-and-click your way to an SFC file to preview your art on hardware or in an emulator?

[SNES AYE]

Say someone were to create such a point-and-click tool, yet that someone's computer runs a different operating system from yours. For example, say I built a preview tool for Linux, and you want to use it but you use Windows. (Now that public security updates for Windows 10 have ended, I don't even own a computer capable of running the supported version of Windows.) Would you find it worth installing another operating system in a virtual machine if it meant you could point-and-click your way to an SFC file to preview your art on hardware or in an emulator?

That’s a genuinely tough question. Speaking only for myself, a part of me would want to try running another operating system just to use a helpful tool like that—but realistically, I probably wouldn’t. I’m neurodivergent, and big changes or learning entirely new systems can feel overwhelming and stressful for me. Honestly, I don’t even really know what a virtual machine is beyond the basic idea of running one operating system inside another, and I wouldn’t have the slightest clue where to start.

Because of that, I personally feel it makes the most sense to create tools that are as accessible as possible for the widest audience—ideally across the most common and familiar operating systems. When a tool only runs on a platform most people don’t use, it can unintentionally recreate the same kinds of barriers that already exist with some current Windows-based SNES development setups, like PVSnesLib. Even just finding, downloading, installing, configuring, and getting things to run can already be a huge challenge. That's before you do a single thing that would be part of actually starting to make a game or demo.

I may not express this perfectly, but I genuinely believe the key is reducing every obvious barrier to entry and making it as easy and welcoming as possible to get started. Even seemingly small hurdles add up and can make SNES development feel overwhelming or out of reach for newcomers—especially for people who are simply curious and want to dip a toe in without immediately running into technical hoops. And again, that's before they discover just how difficult it is grasping all the options and quirks of the SNES hardware itself, the various capabilities and features, and the limitations they have to work around. Every single possible step to reduce friction is a godsend.

That said, creating such a tool for Linux could absolutely help build its own meaningful community of SNES developers. I certainly wouldn’t discourage that, even if it maybe wouldn't benefit me personally in the end. Any step forward in accessibility or community growth is a good thing. I just tend to speak from my own experience and what I think might help the largest number of people who are interested in SNES development but haven’t taken the leap yet.

[Nikku4211]

I'm happy to test these kinds of tools since I would directly benefit from them. In fact, if there’s a tool that allows genuinely simple uploading and outputs SNES art assets in a format that can be directly viewed in an emulator—even something as simple as a single background viewer where you can switch between images—I’d be very interested.

Okay, if you say so.

But really, a bigger sample size is needed to ensure any tool is actually agnostic across varied-enough workflows instead of being extremely optimised for one or two specific workflows. Different people have different needs. If you can't get enough people to test a tool, it's hard to agree on what is most important to its accessibility, which is paramount to ensuring a tool isn't too complicated for absolute newcomers.

I’m neurodivergent, and big changes or learning entirely new systems can feel overwhelming and stressful for me.

Even in this subforum, trust me, you are not alone here.

If you are stepping into a literal new hobby for yourself, you should probably expect to need to learn quite a bit. The only question is how much you expect to learn vs. how much you actually need to learn in order to make what you want to make.

Even for people way more well-versed in these skills than I, this applies to them too just as much as it applies to newcomers. That's why so many dev tools are seemingly made specifically for one kind of workflow each. You can realistically only speak for yourself, whether as an interested newcomer or as a well-known tool dev.

Because of that, I personally feel it makes the most sense to create tools that are as accessible as possible for the widest audience—ideally across the most common and familiar operating systems. When a tool only runs on a platform most people don’t use, it can unintentionally recreate the same kinds of barriers that already exist with some current Windows-based SNES development setups, like PVSnesLib. Even just finding, downloading, installing, configuring, and getting things to run can already be a huge challenge. That's before you do a single thing that would be part of actually starting to make a game or demo.

I may not express this perfectly, but I genuinely believe the key is reducing every obvious barrier to entry and making it as easy and welcoming as possible to get started. Even seemingly small hurdles add up and can make SNES development feel overwhelming or out of reach for newcomers—especially for people who are simply curious and want to dip a toe in without immediately running into technical hoops. And again, that's before they discover just how difficult it is grasping all the options and quirks of the SNES hardware itself, the various capabilities and features, and the limitations they have to work around. Every single possible step to reduce friction is a godsend.

That said, creating such a tool for Linux could absolutely help build its own meaningful community of SNES developers. I certainly wouldn’t discourage that, even if it maybe wouldn't benefit me personally in the end. Any step forward in accessibility or community growth is a good thing. I just tend to speak from my own experience and what I think might help the largest number of people who are interested in SNES development but haven’t taken the leap yet.

A lot of what you're saying is easier said than done. I keep emphasising this because I'm legitimately not sure what you expect from the other people here.

You have said you understand the difficulties behind all of what you are saying, but it sounded like you were just brushing them off.
It's not like we simply don't know that barriers to entry need to be reduced to get more people into the dev scene. It's just about how you expect people to do exactly that. How do you expect them to identify and actively reduce hurdles when developing a newbie-friendly tool for SNES game dev?

Any step towards accessibility or community growth only means something when it actually verifiably works. That's why taking initiative even in a situation like this ideally needs a well-calculated first move, rather than just a long and tiring game of trial-and-error.

[SNES AYE]

I'm happy to test these kinds of tools since I would directly benefit from them. In fact, if there’s a tool that allows genuinely simple uploading and outputs SNES art assets in a format that can be directly viewed in an emulator—even something as simple as a single background viewer where you can switch between images—I’d be very interested.

Okay, if you say so.

But really, a bigger sample size is needed to ensure any tool is actually agnostic across varied-enough workflows instead of being extremely optimised for one or two specific workflows. Different people have different needs. If you can't get enough people to test a tool, it's hard to agree on what is most important to its accessibility, which is paramount to ensuring a tool isn't too complicated for absolute newcomers.

I’m neurodivergent, and big changes or learning entirely new systems can feel overwhelming and stressful for me.

Even in this subforum, trust me, you are not alone here.

If you are stepping into a literal new hobby for yourself, you should probably expect to need to learn quite a bit. The only question is how much you expect to learn vs. how much you actually need to learn in order to make what you want to make.

Even for people way more well-versed in these skills than I, this applies to them too just as much as it applies to newcomers. That's why so many dev tools are seemingly made specifically for one kind of workflow each. You can realistically only speak for yourself, whether as an interested newcomer or as a well-known tool dev.

Because of that, I personally feel it makes the most sense to create tools that are as accessible as possible for the widest audience—ideally across the most common and familiar operating systems. When a tool only runs on a platform most people don’t use, it can unintentionally recreate the same kinds of barriers that already exist with some current Windows-based SNES development setups, like PVSnesLib. Even just finding, downloading, installing, configuring, and getting things to run can already be a huge challenge. That's before you do a single thing that would be part of actually starting to make a game or demo.

I may not express this perfectly, but I genuinely believe the key is reducing every obvious barrier to entry and making it as easy and welcoming as possible to get started. Even seemingly small hurdles add up and can make SNES development feel overwhelming or out of reach for newcomers—especially for people who are simply curious and want to dip a toe in without immediately running into technical hoops. And again, that's before they discover just how difficult it is grasping all the options and quirks of the SNES hardware itself, the various capabilities and features, and the limitations they have to work around. Every single possible step to reduce friction is a godsend.

That said, creating such a tool for Linux could absolutely help build its own meaningful community of SNES developers. I certainly wouldn’t discourage that, even if it maybe wouldn't benefit me personally in the end. Any step forward in accessibility or community growth is a good thing. I just tend to speak from my own experience and what I think might help the largest number of people who are interested in SNES development but haven’t taken the leap yet.

A lot of what you're saying is easier said than done. I keep emphasising this because I'm legitimately not sure what you expect from the other people here.

You have said you understand the difficulties behind all of what you are saying, but it sounded like you were just brushing them off.
It's not like we simply don't know that barriers to entry need to be reduced to get more people into the dev scene. It's just about how you expect people to do exactly that. How do you expect them to identify and actively reduce hurdles when developing a newbie-friendly tool for SNES game dev?

Any step towards accessibility or community growth only means something when it actually verifiably works. That's why taking initiative even in a situation like this ideally needs a well-calculated first move, rather than just a long and tiring game of trial-and-error.

After drafting countless versions of a response, having realized I may have already caused even a small amount of upset or sparked the slightest tension despite my best intentions, I’ll just say this: I honestly don’t know how to answer some of your questions in a helpful or productive way right now.

That said, I still believe that a genuinely accessible and user-friendly SNES development tool—one that even people like me could use—would be a game-changer for the broader SNES development scene, and a largely positive one at that. I clearly have no idea how to get there, even just in discussion, at least not within my capacity in here.

With that in mind, I apologize if I’ve upset, triggered, or offended anyone in this thread.

[creaothceann]

Say someone were to create such a point-and-click tool, yet that someone's computer runs a different operating system from yours. For example, say I built a preview tool for Linux, and you want to use it but you use Windows. [...]

That’s a genuinely tough question. Speaking only for myself, a part of me would want to try running another operating system just to use a helpful tool like that—but realistically, I probably wouldn’t.

Best solution would be a JS program in a *.html file that runs in the browser. Problem is that not everyone is a web developer. (And it makes piping data a la <input_file tool1 | tool2 | tool3 >output_file impossible.)
Second-best solution would be Windows programs that run via Wine on Linux and natively on Windows. Problem is that Linux users would probably hate to install "M$" tools on their system.
So a cross-platform language/compiler would be needed that can be easily installed and used to compile programs. (My preferred choice would be Lazarus / Free Pascal. Problem is that the programming community seems to have decided that Pascal is now a 'toy' language.)

I don’t even really know what a virtual machine is beyond the basic idea of running one operating system inside another

A VM is basically an emulator, like ZSNES or Mesen, but for an entire PC. If you have used DOSBox you have used a VM.

and I wouldn’t have the slightest clue where to start

It's as easy as typing how to use virtualbox.

[NovaSquirrel]

I think making a tool that's flexible enough and friendly enough (and then being support after it comes out - that's something that's easy to forget) is going to be such a substantial amount of work that people are going to need to fund it if it's going to exist. And I did see a Kickstarter for this be attempted and then get canceled because it wasn't doing well. Maybe someone else would have more success with different timing or with different marketing?

I attempted making a friendly tool at one point as a hobby thing (thread) and then realized that no one was going to collaborate on it with me (so it wasn't a matter of someone just needing to kick it into motion, and I was going to have to do the entire thing myself, which I didn't want to do), that I would rather work on games instead of tools, and that if I did make it then I would be stuck having people bug me to do unpaid tech support and feature requests forever, so I canceled it after I got it to a spot that satisfied my curiosity. Someone else could pick up where I left off, though. Or maybe someone could try a GB Studio fork? I've seen people go that route for NES and Genesis.

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?

Nova the Squirrel 2 has been on hold as I've taken care of other projects. I have learned that trying to have like 7 ongoing projects means none of them are going to get done in a reasonable amount of time, so the past while I've been prioritizing the smaller or more urgent projects as I work towards focusing on just this and one side project. Maybe sometime next year?

[tepples]

Best solution would be a JS program in a *.html file that runs in the browser. Problem is that not everyone is a web developer.

That, and:
2. To prevent a script in one HTML document saved in the ~/Downloads folder from exfiltrating the contents of other files in the ~/Downloads folder, web browsers treat each file served with the file: scheme as a separate origin and deny cross-origin resource sharing (CORS) on all URLs in the file: scheme. This means a lot of JavaScript APIs based on the same-origin policy won't work. This in turn means everyone who downloads and runs an HTML tool will also have to download and run Python or some other program that can act as a web server on localhost, unless there's some good way to include binary files in the HTML.
3. Web browsers offer cookies, localStorage, and IndexedDB APIs to save a project under editing to the user's profile. However, unless the user has added a web application to the device's home screen, some web browsers' tracking protection policies automatically delete the user's data associated with an origin once the user has started the browser on more than seven separate calendar days without visiting that origin. Safari does this since 2020, for example.
4. Exporting data is a lot more painful than importing it. A web-based editor can open files and folders that the user drags in. However, it cannot save a folder's worth of files, nor can it overwrite the file that the user dragged in. It can save only individual files with an unpredictable name. They all go to the ~/Downloads folder, with an unpredictable number inserted before the filename's last dot (such as output (17).sfc) to distinguish otherwise identically named files in the folder.
5. An anti-fingerprinting mechanism in web browsers randomizes the least significant bits in PNG files saved from <canvas> elements. This added noise breaks the expectation that PNG is a lossless format. Users of Rilden's tiledpalettequant tool have run into this problem. Safari does this.
6. Some of the more vocal people I follow on Mastodon are hardcore traditionalists who believe that web pages ought to be static and applications ought to be native.

It's as easy as typing how to use virtualbox.

The last time I searched for something like that, the results implied that a lot of useful VirtualBox features required the Extension Pack. Oracle strictly forbids use of the Extension Pack for a purpose that's remotely commercial. If you're using VirtualBox to run a tool to develop a game that you plan to distribute on Itch.io under "Name your own price" terms, that's commercial. Oracle sells commercial licenses for VirtualBox Extension Pack, but unlike the analogous situation with vbcc, there's no way to buy just one license. You have to buy at least 50 seats at a time. This appears to be scaled for a large enterprise rather than a small or medium business or a hobbyist seeking to recover some of their expenses.

[NovaSquirrel]

The last time I searched for something like that, the results implied that a lot of useful VirtualBox features required the Extension Pack.

What specific features did you see that looked like they would be helpful for homebrew development? I tried looking into it and saw stuff like "host webcam passthrough" which is irrelevant, and features that looked more relevant to a context where you're deploying Virtualbox in a headless server setup, or deploying it to employees and you've got an IT department. The only thing that looked helpful to me was USB 3 passthrough, but I just stuck to using the virtual storage I had attached to the VM. I used VirtualBox without the Extension Pack to compile and test Petal Crash Online builds and didn't have any issues with missing features.

[tepples]

USB passthrough was the big one, particularly if I decide to upgrade to an EverDrive N8 Pro, FXPak Pro, or some Game Boy Advance multiboot solution. I forget off the top of my head what the others were. I admit that last time I checked, I was looking from the point of view of running Windows as the guest so that (among other things) iTunes could still sync to an iPhone's Music app through its Apple Mobile Device Service driver. It wouldn't apply quite so strongly to SNES AYE's situation of wanting to run Linux as the guest.

Or maybe I had concluded that Guest Additions were part of the Extension Pack. How well does drag and drop work between Windows File Explorer on the host and applications on a Linux guest?

[lidnariq]

USB passthrough was the big one

It's only higher speeds. USB1.1 passthrough does not need the Extension Pack.

Or maybe I had concluded that Guest Additions were part of the Extension Pack. How well does drag and drop work between Windows File Explorer on the host and applications on a Linux guest?

Now that Win10 is not supported, you can require people use X11 on WSL instead.

[creaothceann]

USB3 is apparently part of the main program now.