QuoteIn regards to headers in my own editor, I plan to half support them in initial releases by removing them and letting them manually add them on save if desired. This is a transitional phase so that other tools can be reworked for headerless support, in phase two it will only remove them. I think this approach should a bit less dramatic, and help ease the change in.
Yeah, it was only because I snapped that it was so dramatic.
If I ruled the world, yeah, this would be my approach via emulation:
Step 1: start with a popup warning, "Copier header detected. Support for these are deprecated. Would you like me to remove them? Yes / No / Always / Never"
It's important that IPS patches are transformed along with the change. A very easy thing to do.
Wait a few months.
Step 2: remove the "Never" option. It is critical that this build add other desirable features and major improvements, like a new sound engine to fix SMW fireballs, for example.
Wait a few months. Tools will likely update at this point, as will some ROM piracy sites.
Step 3: "Copier headers are no longer supported. To play this game, it must be removed. Shall I remove the header? Yes / No / Always"
A no option now will result in game loading being canceled. Again, there has to be a major reason to upgrade. Support some new special chips and re-add netplay support here. Add some TAS and debugging features for good measure.
Wait a few months. The rest of the piracy sites will update as they'll be inundated with requests to.
Step 4 (optional): remove the message, and remove the detection. This last step isn't pragmatic, but it does fulfill the goal of no longer having to detect such things.
-----
Of course, with no real market share, I'd only be asking the people who already have clean ROMs. And as soon as I moved on to even step 2, everyone would switch back to another emulator.
QuoteErrr, I think you misunderstood. By "affording others the same respect", I was referring to respecting other authors developing their own software (not Bsnes) as they wish.
To be more specific I'm talking about situations like here where you advised Imamelia to direct his disdain at myself regarding copier headers. Admittedly pretty minor, but it doesn't set a respectful tone for later.
You're right, I'm not very respectful of different positions as I used to be. It's definitely not a positive attribute of myself.
I wasn't meaning in that post for imamelia to go and complain to you. I was more meaning that Geiger had the right idea in removing them. What was irritating was tools that would intentionally keep adding them back. Of course, idealism aside, both will irritate a user. They want their preferences respected, and neither of us do that right now.
QuoteFor the headers, I'd merely call it being pragmatic. Copier headers are hardly evil after all... I consider it a technical issue myself, not a moral one.
To lend background, I've been releasing translation patches since 1998. I have had to deal with people's IPS patches failing due to headers vs no-headers since then. And pro-tip: once you have an emulator, you not only get questions about your patches, but about everyone's patches ever made.
I tried a two-pronged approach and made an IPS alternative with Nach as well. It failed to gain any traction, less popular than PPF and Xdelta.
I've had to support headers in my emulator, in my assembler, and in my earlier translation patches. I've had to perform ROM/LoROM conversions with $200 offset calculations in my head far too many times (LunarAddress is very nice, by the way.)
If you ever want to experience pain, try detecting where the internal game headers (with vector addresses) are at in a ROM. Now try doing it with a header involved. And now try doing it with the first three years of copier-PD software that do not pad their ROMs to an even multiple of 32KB.
It may not be the biggest issue in the world, but headers do absolutely nothing, nothing at all, useful.
QuoteI'd just agree to disagree and leave it at that. It's only a file extension... not worth letting it affect your attitude or relationships.
Oh, it was many things. He wanted me to support JMA, which I did. I had to work with others to patch it for 64-bit support he never added. Then he would only allow the change under GPLv2 (my emulator had a no-fork clause back then), and wouldn't fix upstream after a couple years. Never did get support for non-ANSI filenames.
He had the NPS patch format, so I helped revise, advertised the spec for two years on RHDN, released all the tools, added the emulator support to bsnes and Snes9X, and ... nothing. He never released any tools, never supported it with ZSNES, etc.
Then it came to memory maps. HiROM and LoROM are made-up terms, real memory maps are more complex and have 40+ configurations. We need the PCB IDs to know exact mirroring. He had access to log this info via NSRT but would not do so because, surprise, games don't often read from the mirrored areas. Eventually resulted in me buying the entire USA set and recording them myself. JPN set may never happen :/
Then the file extensions issue. Then supporting arcane interleave formats. Then about applying my VRAM-write-block patch. On and on.
It's not like we got in a big fight or anything. He just stopped talking to me. I don't really blame him, I've always been vocal about my critiques with their emulation. Most specifically their inaction toward fixing them, even when I'd provide patches. For instance, they want to keep allowing those illegal VRAM writes solely because old ROM hacks/translations depend upon them.
QuoteActually no, LM really does write each change to the ROM file individually. It's useful being able to modify the ROM in an external hex editor then saving something in LM without it losing the hex editor changes.
Drat. So then the only truly transparent option will be to hijack your file write commands via DLL API hooks to manually adjust the offsets :/
Would it offend you if I or someone else were to take a shot at that? It'd be in the form of a launcher that loads in your unmodified program as a debuggee process.
No sense even trying if you would be upset by it, or worse, try and block such actions in future releases.
QuoteAnd I'd rather you not, if you don't mind. If for some unforseen reason I did chose to release the source in the future, it would be in spite of such behavior, not because of it.
For what it's worth, please disregard my comments. Especially about the SFX tracer. I'm sure everyone knows I am intolerable, but I'd hate for my actions to cause detriment to others.
I'm absolutely huge on this open source thing and all. But I do know where you are coming from. For the first five years I had a no-derivatives license because I feared people would hack bsnes to run broken software like the VRAM write and Addmusic/echo buffer stuff. Speaking only for myself, I eventually came to realize that just because some people will do bad things doesn't mean that others who would do good should suffer for it.