But you could get releases down to 50MiB or so. You'd have to run the tool before playing on either hardware or emulator. What I want to do is build a tool that'll decode a set of MP3s into PCMs (WAVs without headers), and *possibly* AVIs into tiledata blocks (the latter is *way* harder.) > If that is done, and the filesize issues are resolved somehow, I expect MSU will be accepted. Renaming / moving a game is a total PITA with your method. > My favourite would be making the ROM importer pick up romname.msu/romname-1686.pcm/etc in the same folder. I'd suggest MSU1 patch authors ignore these holdouts. I can't do anything about people insisting on using v073, which is 22 major releases old. Ikari seems receptive to supporting the file naming convention I use (but not right away), which would make a universal, emulator-agnostic format. sd2snes has similarly never required one. As such, with v095+, I no longer require manifests. There's no getting around the format changing as emulation is improved. The manifest turns out to be a very emulator-dependent, low-level detail. > Volatile format - you need a BML file to enable MSU-1, and byuu has changed how those look many times (sd2snes is using an old version), making MSU not only bsnes-only, but bsnes094-only. Last updates in January 2007 and April 2011. But both emulators are as good as dead anyway. If they wanted to support it, they could. MSU1 is 4KiB, or 200 lines of code, to emulate. > They really got screwed two-fold on this one, huh? Poor little guys. And possibly hypocritical in light of the Addmusic fight you guys had. I agree it's inconsistent with a goal to only have stuff that runs on real hardware. MSU1 can trivially be made backward-compatible, so long as you also have SPC music to use. > With the modern rules about preserving compatibility across all major emulators and the real SNES, I can see why this would create controversy The rest of us have only done 1-2 games each. It's almost exclusively Conn and DarkShock putting out all the MSU1 hacks for various games. > I would've thought that at least one or two others would have tried it by now, considering MSU-1's been around for a while zsnes users are the flatearthers of emulation amhunter If that is done, and the filesize issues are resolved somehow, I expect MSU will be accepted. My favourite would be making the ROM importer pick up romname.msu/romname-1686.pcm/etc in the same folder. The snes9x offer still stands talk to byuu if you want to take advantage of it, I'm too lazy myself. We tried poking around a bit with workarounds for these problems, but all workarounds we could find had at least as bad drawbacks as the original problem. Before that (if it ever happens), I vote unconditionally reject. If byuu creates a format he promises will work in every future bsnes, I'll implement that in snes9x. Volatile format - you need a BML file to enable MSU-1, and byuu has changed how those look many times (sd2snes is using an old version), making MSU not only bsnes-only, but bsnes094-only. bsnes only - even if you can make it fall back to SPC, that's not how the author intended it, and it gives worse results than bsnes. You can do things to shrink it more (the extreme case being distributing it as MP3s and providing a converter), but that makes it harder to unpack, especially on non-Windows. It also tends to not compress quite badly putting it in a ZIP file usually only shrinks it by ~15-20%. Filesize - MSU-1 music is huge, 10 megabytes per minute. It also brings a fair amount of problems: While it does bring some advantages, I don't see it as very useful for SMW. MSU-1 turns the tables: ZMZ and BSNES/Higan, those very same emulators that were and are still incapable of playing Apocalypse-era hacks, are now the only ones that can play this new breed of MSU-1 hack, and Mr. The horrible aftershock of this realization is still felt today, as hack mods bravely trudge through the thousands of broken hacks attempting to right this wrong. Snes9x 1.52+, BSNES (now known as Higan) and ZMZ (although it didn't exist back then) would crash, as would a real SNES. During The Great Addmusic Apocalypse, only older, less accurate emulators like ZSNES 1.51 and Snes9x 1.51 could play hacks that had been used with older Addmusic versions. Ironic, isn't it? It's the polar opposite of The Great Addmusic Apocalypse. With the modern rules about preserving compatibility across all major emulators and the real SNES, I can see why this would create controversy. Both of which are resource hogs and lag like hell on sh*tty less powerful computers. *Higan, and ZMZ with the BSNES Balanced core. I personally believe this is the next big thing in SMW hacking. The possibilities of CD quality music in hack is far reaching. I have always been in full support of the MSU1 for SMW.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |