nesdev.org

If you add IPS support, consider providing an option to let the user mark an IPS as using a header or not by renaming it to end in ".sfc.ips" or ".smc.ips".

Why no PNG screenshots? Qt can encode a QPixmap to PNG, if this answer by Kaleb Pederson is to be believed.

It can, but higan/bsnes hasn't had Qt as a direct dependency in years and I don't think this new official incarnation of it is supposed to either.

bsnes will use hiro as its GUI toolkit, just like higan. hiro does not offer any features not explicitly meant for GUI design, so even though it has a Qt compilation target, it cannot be used to save PNG images. The most complicated part of PNG is Deflate, and while nall (general-purpose header library) has a Deflate decoder, it does not have a Deflate encoder. In fact, nall can create Zip archives, but it uses the Store method exclusively when it does so.

bsnes v073 previously supported UPS as its only patching format, and it applied UPS patches before trimming headers. For bsnes-classic, I'm planning on doing the same thing with IPS patches but waiting until after trimming headers before applying BPS patches.

In case anyone wanted to know what bsnes/higan versions supported which GUI toolkits, here's a chart:

hiro (old):
bsnes v028-v041

Qt:
bsnes v040-v073

phoenix:
bsnes v069-v091
higan v092-v094

hiro (new):
higan v095 and up
bsnes v107 and up

hex_usr wrote:Well, I sent a PM to AWJ this morning (shortly before 09:00 PDT). As of 17:00 PDT today, he hasn't responded.

Individual is alive and well. Patience is a virtue.

Yep, I just got his private message, too.

AWJ has spoken: his project is still alive, and he wants me to rename my project.

I replied to him that it would be really nice if he could either update bsnes-classic's manifest format to BML, or retire manifests and exclusively use heuristics. I'll still rename my project either way, but I'll be much happier about it if AWJ does either of these things.

Because it was always about the XML manifests; I wouldn't have ever bothered if bsnes v073 had no manifest support whatsoever.

hex_usr wrote:Yep, I just got his private message, too.

AWJ has spoken: his project is still alive, and he wants me to rename my project.

I replied to him that it would be really nice if he could either update bsnes-classic's manifest format to BML, or retire manifests and exclusively use heuristics. I'll still rename my project either way, but I'll be much happier about it if AWJ does either of these things.

Because it was always about the XML manifests; I wouldn't have ever bothered if bsnes v073 had no manifest support whatsoever.

I don't understand what you intend to gain by attempting to browbeat me into removing functionality from my software.

hex_usr wrote:Because it was always about the XML manifests; I wouldn't have ever bothered if bsnes v073 had no manifest support whatsoever.

In what way is "no manifest support" supposed to be an improvement over "older manifest support"? It wouldn't improve the situation with, for example, the FEoEZ translation. Likewise, retroactively removing manifest support entirely would just inconvenience actual users by breaking support for numerous existing projects for no particularly great reason.

If "BML instead of XML" were just about language/syntax then I would have done it in bsnes-plus a long time ago, but the part that's not immediately implied is the additional reliance on outright gamepak/cartridge folders, a board database, etc. which are all rather conceptually major changes that I simply don't have the time or desire to prioritize at this point (and I have a feeling AWJ doesn't either).

(I absolutely don't intend to start any kind of additional discourse/debate about this, but on the off chance that byuu ever decides to support some sort of BML-based manifests for the standalone ROM support in "new bsnes", I'd happily add support for that as soon as possible.)

It really doesn't accomplish anything for AWJ to update from one deprecated format to another deprecated format.

My end goal is for users to not have/need/want actual manifest disk files to exist at all. It's just not possible to express every variation on SNES PCBs (down to literal bodge wiring on production games) with 100% perfection without it being hopelessly emulator-specific.

Manifests are, at best, a way for users to get games working that don't work in higan out of the box. Anything worthwhile will get supported in icarus directly, including Tengai Makyou Zero's fan translation in v107.

We don't even have userbase numbers for mainline higan, let alone any forks, so who knows if it's even worth pursuing. Open source lets people do whatever they want. Some people sell my work and don't share money with me, some people complain about my code yet fork it instead of writing their own, some people go against my wishes and do things I'm opposed to, and some, I assume, are good forks (but seriously, some forks are pretty great!) It is what it is, and I knowingly agreed to that when I chose my license. I'm trying not to complain so much about forks I don't like anymore, but I've always acknowledged they have every right to do what they want.

If I want people to use my work, I'll just have to give it my all to put out the better release.

on the off chance that byuu ever decides to support some sort of BML-based manifests for the standalone ROM support in "new bsnes", I'd happily add support for that as soon as possible.

As of v107, I've removed the board mapping rules from the manifests, and I'm making a promise not to break the format of manifest.bml again. Yes, seriously. I promised to not change BPS, and I haven't. And I promised not to change bass syntax anymore with v15, and I haven't. I promised MSU1 would remain backward compatible to v1.0, and it has.

I'd love it if other projects could utilize my SNES preservation database, because holy god damn I put a lot of time, money and effort into that, and I'm not even halfway finished yet. You don't need manifest files next to ROMs for that, though. You don't need game folders for it either, as I'm demonstrating with bsnes v107.

But right now, the only thing I'm literally on my hands and knees begging for, is set maintainers to distribute coprocessor firmware with games. I don't care how they end up doing it, I'll support it. You've got your copier headers, your SMC file extensions, your compressed archives, just please ... I need the firmware! It's part of the goddamned game, and it's copyrighted -- I can't ship it!! This is leaving me at a permanent disadvantage to HLE-based emulators, where games just "work" out of the box.

byuu wrote:As of v107, I've removed the board mapping rules from the manifests, and I'm making a promise not to break the format of manifest.bml again. Yes, seriously. I promised to not change BPS, and I haven't. And I promised not to change bass syntax anymore with v15, and I haven't. I promised MSU1 would remain backward compatible to v1.0, and it has.

Totally understandable, hence "on the off chance" - I was pretty much assuming it wasn't actually going to happen, and I respect your decision about that.

(I was also assuming that the v107-and-on format was what hex_usr was referring to in the first place, but I've already forgotten too much about the other previous formats to know if there might have been a more fitting alternative that anyone still uses...)

I'd love it if other projects could utilize my SNES preservation database, because holy god damn I put a lot of time, money and effort into that, and I'm not even halfway finished yet. You don't need manifest files next to ROMs for that, though. You don't need game folders for it either, as I'm demonstrating with bsnes v107.

Believe me, I greatly appreciate the work that's been put into this, even though my own fork doesn't directly benefit from it nearly as much as it could/should. And it has never really been my intent for bsnes-plus to somehow undermine or compete with mainline higan either, especially now that it's becoming (in my eyes) more and more attractive to the average user with every new release, not to mention the fact that it's much more actively maintained.

The fact is that I just decided one day to start on a little hobby project based on something I was personally familiar with, for better and/or worse. (Really, the only actual goal was for me to not have to use Geiger's debugger anymore, and I guess mission accomplished?)

Wait, do I read it right that bsnes-plus does not require the annoying cartridge folder?

The fact is that I just decided one day to start on a little hobby project based on something I was personally familiar with, for better and/or worse. (Really, the only actual goal was for me to not have to use Geiger's debugger anymore, and I guess mission accomplished?)

You have the one project where I completely understand why you're stuck on the version number you are. It needs such a massive amount of hooks into the core, and the core is constantly changed and cleaned up by myself. Bizhawk comes in second place, but I don't think a once-a-year core update there is asking too much.

Beyond that, it saddens me that we're all duplicating effort here. I know a lot is my fault, I don't work well with others and merge their changes, as I'm picky about my codebase.

But like I said, it is what it is. I'm thankful we're at least sharing changes. I'd much rather have bsnes-classic and the occasional hires math fix or SuperFX timing improvement that we both have to commit, than not have any of it.

byuu wrote:You have the one project where I completely understand why you're stuck on the version number you are. It needs such a massive amount of hooks into the core, and the core is constantly changed and cleaned up by myself. Bizhawk comes in second place, but I don't think a once-a-year core update there is asking too much.

Even so, didn't the later "laevateinn" debugger provide basically the same interface with a less outdated version of the actual emulator? It was probably just a bit of nearsightedness on my part, honestly.

byuu wrote:Beyond that, it saddens me that we're all duplicating effort here. I know a lot is my fault, I don't work well with others and merge their changes, as I'm picky about my codebase.

Duplication of effort notwithstanding, I think the fact that all these forks still have quite a lot of your work in common is a pretty serious net positive (could you imagine a world with twenty more closed-source snes9x forks instead? )

Either way, I'm glad to be able to involve myself in working on something that a handful of people find useful. I hope I'm not somehow considered to be doing harm to the scene because of that, even if some things about my project aren't as close to the state of the art as they ought to be...

calima wrote:Wait, do I read it right that bsnes-plus does not require the annoying cartridge folder?

I'd call it less a matter of "doesn't require"; higan doesn't necessarily "require" them either since you can just import regular ROMs most of the time and let the rest be handled behind the scenes. The real problem (which I absolutely agree is a problem) is that bsnes-classic/plus don't even support cartridge folders.

Revenant wrote:

calima wrote:Wait, do I read it right that bsnes-plus does not require the annoying cartridge folder?

I'd call it less a matter of "doesn't require"; higan doesn't necessarily "require" them either since you can just import regular ROMs most of the time and let the rest be handled behind the scenes. The real problem (which I absolutely agree is a problem) is that bsnes-classic/plus don't even support cartridge folders.

Handling it behind the scenes still copies the ROMs there. Which I don't like, both because it's ugly and because it puts the cart folders in my home dir, which is on a different disk to where I keep ROMs, and has much less space free.

calima wrote:

Revenant wrote:

calima wrote:Wait, do I read it right that bsnes-plus does not require the annoying cartridge folder?

I'd call it less a matter of "doesn't require"; higan doesn't necessarily "require" them either since you can just import regular ROMs most of the time and let the rest be handled behind the scenes. The real problem (which I absolutely agree is a problem) is that bsnes-classic/plus don't even support cartridge folders.

Handling it behind the scenes still copies the ROMs there. Which I don't like, both because it's ugly and because it puts the cart folders in my home dir, which is on a different disk to where I keep ROMs, and has much less space free.

Just create a symlink if it's really that much.

Or change the library path. You aren't required to have the library inside your home directory. In my case, I have an entire hard drive partition set aside just for higan's library, because I also put games for other systems such as the GameCube and PlayStation 2 in there.

Of course, this doesn't help if you store your ROMs on read-only media such as CD-R disks. In that case, you should just use byuu's upcoming bsnes revival or my Qt-based fork.

=========================================

AWJ, I'm sorry if you think I'm “browbeating” you; you're obviously free to do whatever you want. Just as I'm free to write a replacement emulator and do everything in my power to make sure ROM hackers never feel obligated to write hacked-up manifests for the severely outdated XML-based standard ever again.

I also want to focus on replicating bsnes-plus's debugging features, eventually. Just like bsnes-classic, bsnes-plus also uses XML manifests, so it too is on my radar.

For now, I'm using the tentative name “bsnes-mcfly”, a name that represents traveling into the future. This name won't become final until higan and bsnes v107 are released.