I'm a novice programmer currently but my programming knowledge due to being a retro game enthusiast involves quite a lot of low level and assembly related stuff that in more practical coding and programming tutorials would sound just plain bizarre. So when I discovered VGM files, I was INSANELY fascinated by the tiny memory space they consume. One day I then thought... What if I dont have to constantly use sound samples and stuff? Like y'know how for the jump sound for the Genesis Sonic games is using the sn76489 and a square channel (although not every sound effect would use a PSG chip but like how it reduces repitition). I asked this question on the Sonic Retro discord but I was wondering if I could get some more info on this idea since one guy said that having emulators of sound chips in a fan game could put heavy strain on your device while another guy said that it would be effective (albeit possibly tedious to get done but I'm still curious regarldess) thus I've got a bit of confused and thought that unlike Discord, the forums here won't be fast moving as much. SUPER curious on anyone's thoughts! :D
It depends on what "engine" you are looking to use, in my experience. For instance, Mega Man Maker is a great fan game made in Game Maker, which uses soundchip emulation extensively by necessity. (They have tile sets and BGs from 7+ Mega Man NES games to choose from, so OGGs for all their related songs would sincerely bloat the package.) But, in Game Maker's case, that comes with two caveats: All of the good NSF extensions are still GML scripts, not a natively compiled library/delphi file, which comes with a performance tax. (This is in addition to the performance tax of emulation itself.) It's a fair trade for a game with Mega Man's mechanical simplicity, but I would be wary of doing that for a Sonic fan game built in Game Maker. (Your games only get access to one CPU core, so you really have to make it count!) The GML interpreter has never been faster, but emulating anything with a trig and calculus-heavy collision system on top of it sounds too risky to me. And I have seen more than a few GM:S Sonic frameworks that put collision robustness and "pretty code" over performance, which is dire for achieving 60 FPS on most computers. Meanwhile, with Unity and Godot, you can have the performance boost that comes with C#. Your performance overhead looks a lot more roomy. It simply becomes a matter of retro enthusiasm to choose soundchip emulation over pre-rendered MP3/OGG files. (And, of course, if you're coding in C or C++ with SDL attached, all of this is irrelevant! You can run five SNES emulators at once on a modern potato PC. Emulating two soundchips from the Genesis is nothing for today's processors, with optimal emulation.)
Sonic Robo Blast 2's sound engine supports sequenced music in the form of VGM and tracker modules, and various mods have used this functionality. It's certainly feasible to add a emulator sound engine to your game; designing how it'll be intergrated in the code is the real puzzle.
Like I said on the Discord, this is feasible, yes. It'll shrink the amount of storage your game uses for audio too, that is true. But you're talking about putting an emulator inside your game. This isn't something that's going to have a ready-made solution; and far from tedious, for someone that describes themselves as a novice programmer and is asking this question at all, it's more laborious and time-consumingly difficult.
I turned ValleyBell's SMPSPlay tool into a DLL and have used it in various mods for games and a screensaver. It only does music at the moment, but what you're talking about is certainly possible.
I think that was the concern of their original question. Not so much the implementation, (Something they want to figure out!) but how chip emulation fairs once it's working. And for the most part, it's not really a performance issue. It's more what you said: Quite a task if you're hoping to start from scratch As someone who owns *two* Super Famicoms, 15+ cartridges, and multiple SNES controller adapters for Wii/PC: I don't use BSNES or Higan. VSYNC never wanted to play nice for me with for each upgrade in computing power I got over the years, across both AMD and Intel-based processors. No amount of fiddling with settings or Googling gave me useful solutions. I can admire the idealistic principles behind cycle-accurate emulation, but the end result is a self-defeating argument for preservation if it can't do something as basic as vertical blanking correctly. (Even with hardware that exceeds the higher requirements.) Snes9x is above-and-beyond a very capable emulator these days. That's what I recommend to people. No one is asking for cycle-accurate soundchip emulation here, either. Not if you want a game that runs reliably on the low to mid-range PCs of the enthusiasts who would want to play your indie/fan game in the first place.
Just to add my 2 cents: I too have used emulation for sound before in the form of ProSonic. It used the standard Starscream emulation used in Gens as its base to handle VGM and GYM playback, and did so quite effectively with no noticeable performance hits. To tell you the truth, the solutions before me are probably better. But if you're curious about how I went about implementing such a thing, look at the ProSonic source code. As I was writing that paragraph just now, I remembered I also did this in my SonicAmp sound driver which I think I partially based on the work I did in ProSonic. It's in C++ and is a whole lot less messy, though I don't think I ever made that source code public. Maybe I should one day. But in the meantime, if you want to see it, I can retrieve it for you.
Yeah, they're using game-music-emu. Sound chip emulation for BGM is easy, what I really want to see is a full integration where you can trigger synth patches as sound effects. Would be extremely practical for web games where binary size is the main constraint. Web Synth achieves this with generic FM synthesis, would be cool if you could just pipe it .vgz files and DefleMask patches.
