 |
|
 |
|
| Posts by byuu |
|
|
|
|
|
|
|
|
> We discussed this to great lengths, and the best solution we came up with was a patcher that could apply both bps as well as ips patches, which would make things even more complicated for a newcomer...
I suppose I can make my tool apply IPS+UPS+BPS; but I don't intend to allow it to create anything but BPS.
> Space is not a problem at SMWC at the moment
So why do I have that huge banner at the top, with all the fancy URL generating tricks? :/
Space=Bandwidth=Money.
> I discussed this in #serioushax a few days ago. I can't see why we shouldn't stick to IPS.
I agree, and I have three more reasons to stick with IPS:
1. patches must be created against headerless ROMs. bsnes and Snes9X will strip headers first, which will allow the BPS patch to work on both headered* and headerless ROMs at the same time (*9x only.) We'd need a separate bps-snes to do this transparently.
2. the default mode validates checksums, which prevents stacking patches. Checksums can be ignored, but that will be a separate option.
3. UPS failed, so how can you trust me now on BPS?
Can I please ask that there not be any discussion about adopting any of my stuff here officially, ever? My stuff always offers tons of new benefits, then we have a feigned discussion about trade-offs, and it always comes down to "change is bad." I'm okay with that!, it's your site, your rules ... I just don't like wasting my time when the outcome is always a foregone conclusion.
That said, I'd love to hear what you guys think about my stuff, including BPS. The more feedback I get, the more I can improve! Let's just not approach it like we have to convert the world, or change any rules here. That's really not necessary.
> Pretty sure new people won't be able to figure out how to create a patch.
What's more likely? A casual gamer not knowing whether to click "apply" or "create" in Lunar IPS; or a ROM hacker not knowing how to specify a program argument or create a text file?
I can post a bps-create.exe that defaults to creation mode when given no arguments. I could also include bps-create.bat with the program. But do you think new people would be able to figure out how to unzip a file?
> Nobody uses that big ROMs around here
Nobody's made use of the ExHiROM/ExLoROM option from Lunar Magic for a 5-6MB ROM? That's a shame.
> ...anyone dumb enough to use wrong ROM doesn't deserve being here?
Interesting. You don't want to cater to casual gamers that can't add or delete binary headers from their ROMs; and Ersanio is worried about hackers who can't use a command-prompt. Quite the difference in perspective between you two.
> Nobody ever adds data at the beginning of the ROMs around here
Delta makes smaller patches, even on linear ROMs. Mystic Ark goes from 365KB to 253KB. Bandwidth bill goes from $365/yr to $253/yr.
> I can't think of any reason why this can't be in a readme or something
It's nice to only have to distribute one file, and not have to compress it first. One less step to play the game. Harder for casual users to remove the readme when redistributing.
Anyway, I planned for BPS to not catch on. SMWC doesn't like change, RHDN doesn't like change and hates my guts, and ZSNES still lacks 2007-era UPS support. Ergo ...
The metadata is going to be accessible from within the emulator (think Help->Patch Instructions.) The metadata is also going to be tied into an online database, similar to my built-in cheat code database.
This database makes cooperation or adoption completely unnecessary. We can convert IPS->BPS for any meaningful patch ourselves. Gamers can load SMW, choose "Find Patches", and get a nice popup list. Select, hit okay, play.
Browsing SMW Central for patches will be as antiquated as browsing adware sites for Game Genie codes when all is ready. And for those that won't use my emu or database, well, their loss I suppose =)
|
|
|
|
> we have changed a darn lot regarding accuracy standards. I'd merely have to name the music section as example
I was not aware that was completed. You are right then, I was wrong to say SMWC never changes. Sorry about that.
> I don't really get what you're referring to here, but I don't think I should care.
You say space(bandwidth) is not an issue, yet there is a banner saying that ads are needed for the site to survive, which suggest money problems. If this helps reduce bandwidth totals, you would be saving money.
> There are ~400 patches, ~400 blocks, and a fair amount of sprites designed for use with xkas on this site, none of which can be assembled with bass
I get that! It takes work to convert. IPS->BPS is actually pretty easy in comparison, but it's still a change. And we still have to deal with ZSNES' lack of support for BPS.
But that's what I mean. There are not technical weaknesses in my specs: bass does literally everything xkas does, and a whole lot more cool stuff (conditional assembly, operator precedence in math, SPC700 assembly, bugfixes, cleaner codebase to hack on, custom mapping for eg ExHi/LoROM, unified define/macros with proper closures, LL(1) grammar, offset save/restore, etc.)
But it requires work. This is what I mean, it's our fundamental difference in philosophies. I enjoy the idea of improving things, so this is no problem to me. It took me myself time to clean up all my ROMs for my own emulator. They were all ZIP+SMC+header, too.
Yes, someone may beat the pants off BPS with a spec that's still easy to understand and implement. If so, I will endorse that spec over mine, and want to change again.
That's progress! Imagine if everyone stuck with Win 3.1 because they were used to it. "Pre-emptive multitasking is nice, but we really don't need it for what we use our computers for now. People would have to install a new operating system."
> I am sorry, but you are not in the league to hinder us from talking about your stuff. =/
Correct, I was asking. I really don't mean to be rude. In fact, my goal is to prevent drama. Half the people want to use it, half the people say we shouldn't, and in the end nobody can.
Why take sides? If there is a true, serious chance of changing a spec here, I'll be happy to weigh in on why you should. But if not, well, why would I want to keep fighting for it?
> Also, no one is forcing you to waste your time on us. Feel free to leave the discussion at any time if you wish ^-^
As stated, I enjoy the non-SMWC adoption discussion.
It's pretty obvious and well-deserved why people end up disliking me over time, but you guys so far are willing to tolerate me, unlike some other communities. I do value feedback, especially from people who would actually use the tools.
> Can you spot the flaw in the current system?
> Just let SMWC accept either IPS or BPS patches for hacks. Let the hack author decide which to use.
> I think it should at least be available for those who want to use it
> I have a question: Why nessesarily we have to switch all the hacks to BPS format when we can simply allow both files?
This is what I was trying to say before. Let people do whatever they want. Yes, consistency is nice. But hell, offer patches in IPS+BPS if space really isn't an issue.
> They do? Why is that? I thought that BPS could be used for any data
BPS as a raw spec doesn't know about SNES games. So a raw BPS patcher will let you make a patch against a headered ROM. But as we all know, the header data is useless, and may vary between ROMs, making CRC checks impossible.
So, BPS on SNES patches should be made against ROMs with no header. Ideally, we want a "Lunar BPS"-style app. In this way, you can use headered ROMs to make your patches. Your emulators always remove the header internally, every time, no matter what. Apply the patch after that. Your ROM can have a header the whole time on disk, but the result is your patch works regardless of whether your ROM has a header.
> All right. Just plain discussion about the stuff itself, then, rather than whether we should or should not use it?
Yes =)
I can improve my tools to honest technical discussion, but I'd rather not be the guy trying to force unwanted change.
I can't do anything about "this isn't backward-compatible", because I can't modify/improve IPS at all without breaking that. Sure, I could come up with file spec tricks to do more (offset=0,length=0,RLElength=0,metadataLength,<metadata+checksums>), but that's really no different than a new file format. It just keeps all the weaknesses of the old ones, and breaks old patchers. Just like the IPS cut command did.
> It just slightly annoys me that you seem completely unable to see any other reason besides "change is bad" that any one wouldn't use your software.
That's not true! I want legitimate technical flaws. I hear a lot of varied arguments, but they all mean the same thing.
"We have too many patches in IPS already"
"IPS' flaws aren't that bad for us"
"The improvements aren't important to us now" (of course, you haven't used them yet)
Let's take IPS->BPS:
* can support >16MB ROMs; which bsnes supports (1)
* bypasses header v no-header patching problem
* validates patch was applied okay
* smaller patches
* patches can shuffle data; delta-mode (2)
* stores metadata (3)
* no 'EOF' bug for >4MB games
* no unsupported 'cut' command for older patchers
* multi-byte RLE and LZ matching
(1) what if SMWC branches out to NSMB hacking?
(2) what if ExLoROM catches on, and we want to move what data appears in HiROM sections? Or what if NDS hacking is more like a file system?
(3) patch-usage instructions in emulators, inclusion in online databases, custom mapping code for MSU1 and the like, any number of additional possibilities yet to be explored (XML is extensible.)
As far as technical weaknesses, there are none. BPS does everything IPS does, and then it does more, and it does it better. If there's a flaw in the format, I haven't heard it.
Same goes for xkas->bass. Arguments against it were:
* comments are // instead of ;
* we have old patches in xkas format
* old bugs not that big of a deal
There was no, "bass cannot do xyz that xkas can", it was all, "we would have to redo things to work in bass."
Yes, that's progress!
> I think the real reason mostly is that you refuse to make concessions for anybody.
I offered to make a bps-create.exe, or include a batch, or clone LIPS. I added macros inside of macros for bass. The only concession I won't make is backwards-compatibility, because there's no point in improving if we don't make use of the improvements.
> While that argument would make sense for these (which aren't IPS), we're not talking about that.
That was a sticking point for RHDN on UPS. Of course, both UPS and BPS can be stacked. You just have to ignore the checksum, which is ... exactly what IPS always does. So, it was considered inferior because it allowed you to optionally verify patching ...
> Do like this tool and allow both.
If you want a clone of LIPS, I can certainly do that.
> Some of us, for example me, prefer hard-patching our ROMs, but that's why hack descriptions exist.
Yes, applying the patch should ideally write the information out to a file.
> What if the next one that comes out is light years better for some other reason?
Then we switch to it. It's not like a new patching format comes out every day. And if there are improvements to BPS that keep the spec as simple, I'd be pretty surprised.
> Evolution in favor of long-term improvements is great, but there is something to be said about stability, too -- there's no reason to change everything on the site each time something new comes out
I agree! Overnight changes are not the best. Just allow people to submit BPS for now if they so desire, and host the tools to use it. Allow the format to grow.
> Maybe simply have a "magic checksum" of 0000 0000 for both the target and output files signifying "don't bother"?
Ignoring checksums are fine. If they are ignored, storing as 0000 wouldn't hurt anything. A patcher is free to detect this to automatically toggle the "ignore checksum" checkbox.
> The interface could use some slight work, such as a LIPS-like way to choose between creating/applying patches while inside the program.
Okay, that's you and Ersanio now. So if it's a big deal, I will put the toggle button inside the GUI.
> The point I'm trying to get across is that if you want to compete with LIPS, you shouldn't just compete in terms of the file format (which everyday people don't give a damn about), but also in terms of functionality and ease-of-use.
Right, this is my online database approach. I am going to offer users exciting new ways of using patches with emulators.
I want to support allowing patch selection at load time, I want each patch to have information about the games, I want patches to have documentation inside the emulator, and I want them to be downloadable right from the emulator itself.
> ...I just realized that the specification actually has a gigantic hole for third party extensions: Tags in the metadata.
That is totally fine. Metadata allows us to customize BPS for any domain-specific purpose. You could make an <smwcentral> tag if you like.
> Creating a new format is a bit of a catch-22. Nobody changes because nobody else changes and it's too much effort to do it anyway.
Correct! This is reason we still have IPS. Its faults are dismissed, replacement strengths are dismissed. No tools will support it because no hacks use it, and no hacks use it because no tools support it.
Same reason we have copier headers. Just imagine, if one person back in the '90s did what I was doing today, nobody here would know what copier headers were. All the pain it causes now is due to procrastination in the past. The longer we wait, the harder it is to ever change.
> ...the interface could still use some work, though. ;)
That's why I am here =)
I said there were no technical flaws with the spec, which I still stand by. But you guys have pointed out usability concerns, so let's eliminate those as well! At the very least, let's make sure it really is only "change" that is a problem.
> ...doesn't that violate the definition of "metadata"?
Yes. In our case, it's XML, so it is designed to be extensible.
Using it to store patching instructions is a severe violation of the specification, and won't be endorsed by me.
You see, IPS had no spec author (at least, we don't know who it was.) Someone added RLE later, and most everything supported it. I *believe* FuSoYa added the cut command, which few tools support.
Nobody can stop others from extending specifications, which is why we just have to solidify all the edge cases. There are no undefined fields. If you parse BPS as I said you should, you can't trojan the spec with new features. But anyone can hack the version marker, prepend or append data, store stuff in metadata, etc, and I can't stop them. So yes, it's important that people not accept non-canonical patch extensions. Otherwise BPS' value will be diluted.
|
|
|
|
Better?
Size comparison in handy table form here:
http://byuu.org/programming/bps/
I will also make a LIPS-clone with the exact layout and functionality, that auto-strips headers for patch creation. Give me some time on that one.
> For one, there's no reason to get rid of IPS patches rather than just phase them out
Copier headers are becoming less common. No-Intro does not include them at all, and many GoodSNES mirrors strip them all, as do NSRT users. Getting rid of IPS eliminates the problem of whether to apply to a headered or unheadered ROM.
People also might mix up regions or revisions of SMW, or apply to pre-patched images, and IPS won't let them know that.
The other stuff are benefits you aren't currently using, but may find helpful if you give them a try.
> Being a pain in the ass to update is a legitimate reason to not want to adopt something new, in my opinion.
We can batch convert all IPS patches in one minute. We can replace the LIPS tool with an IPS+UPS+BPS tool. bsnes+Snes9X can support soft-patching.
The only hurdle is ZSNES soft-patching. I've been thinking about taking a header-magic style approach, to add BPS support to it, if I can. Of course, it's open source, so there's that approach too, but that's less fun =)
|
| Last edited on 2011-08-22 11:51:08 PM by byuu. |
|
|
|
> they should be an ASM format instead, and bps isn't designed to compete with that
Thank you. That is what I've been trying to say all along. Use the right tool for the job. ASM patches allow more flexibility to prevent two patches overwriting the same spot for their inserted data.
> I still disagree with the ability to ignore checksums at all
Me too, I hate making compromises like that. I add an extra "your ROM is probably corrupt" if you apply and the checksum fails, at least.
> ...I haven't seen you do anything worth disliking? There's nothing wrong with some constructive discussions, and that's all I've seen you do.
I am quite opinionated, and present my positions very harshly. Not a fan of subtleties and, "my idea is nice, but then so is yours so let's all be friends." As such, people tend to take me too seriously.
I keep the personal ad hominems and personal biases out, but I tend to call things as I see them, even those I can't be 100% sure about.
> I could ask for a little more verbosity on what "source", "target" and "delta mode" is
I can do original file+modified file for source+target, but that eats up a lot of room for showing the (albeit not critical) file path.
Delta mode is too tough to explain without a huge paragraph there. It's like the audio input frequency setting from bsnes. At some point, you have to expect people to do a bit of research.
> However, with all this metadata around, a LIPS interface seems inappropriate somehow.
My thought was to separate metadata and patch creation to different programs. If I try and integrate, people will get all upset at how complicated the GUI looks. The metadata format is also domain specific: it can be anything, even a ZIP file. Of course, we must endorse a standard for SNES hacks for it to be usable by other tools.
I'd say maybe ...
<Apply BPS Patch> <Create BPS Patch>
<Options> <Edit BPS Metadata>
> screenshots (a bunch of base64-encoded PNGs or something)
That is certainly doable, but is quite overkill. Still, if that's what you want ... =)
> Yeah, we've got plenty of programmers here. It won't take long to make a converter if we want that.
I'd certainly love to have some coding help, if anyone wants to make some cool tools. Not too in to cloning LIPS myself, given I've already made a patcher of my own.
> Are you going to patch up Lunar Magic too? As long as it can create IPS pathes but not BPS, I belive it will be a bigger hurdle than zsnes.
I didn't realize it could do that o.O
It's possible, but header-magic was just a toy idea. I don't really want to keep adding crazy stuff to it. Great project for another coder here. Detect the CloseHandle() when the filename ends in .ips, then convert to BPS.
> ...or maybe we could ask FuSoYa about it. It sounds more respectful than messing up his tools.
Worth a shot. But he strikes me as the pragmatic type. Like no header support, he probably wouldn't be interested until SMWC switched to the format. Which is that whole chicken and egg thing again.
Yeah, that's the thing people don't like. I'm speculating on what FuSoYa would do/think, based on the limited amount I've spoken to him. But for all I know, maybe he's tired of IPS too. You never know.
|
|
|
|
Only performance core allows invalid writes to go into CGRAM+OAM.
The only difference between compat and acc are that the latter initializes PPU registers to random values and renders a pixel at a time instead of a scanline at a time.
Same CPU+SMP+DSP cores in both.
I don't debug ROM hacks for people (due to time constraints), but if someone can narrow it to a bug on my end, I'll fix it.
|
|
|
|
> I can't find anything that blocks bad CGRAM access in the compatibility PPU in 080, everything I can find says that everything will go to where it should. Did it change in 082 or something?
Nope, been blocked for years now.
snes/alt/ppu-compatibility/memory/memory.cpp
Eg oam_write:
Code if(regs.display_disabled == true) {
oam[addr] = data;
update_sprite_list(addr, data);
} else {
if(cpu.vcounter() < (!overscan() ? 225 : 240)) {
oam[regs.ioamaddr] = data;
update_sprite_list(regs.ioamaddr, data);
} else {
oam[addr] = data;
update_sprite_list(addr, data);
}
}
ioamaddr is where the PPU is fetching from. Accurate during Hblank, but obviously can't be during rendering using a scanline-based core, but also won't go where "expected", either.
CGRAM has similar blocking.
> the latest comsumbes even more CPU power
bsnes: the curiously preposterous, 1 1/2 calorie unbelievable emulator. What it says on the tin.
|
|
|
|
Oh, yeah. There are a couple of titles that'll write to the first palette entry (backdrop color) right in the middle of a frame, so you pretty much have to do it cycle-based to get the proper icgramaddr.
The &0x7f is because I was forcing icgramaddr to 0x1ff, which is a high byte. Palette entries are only 15-bits, so if I let d7 get set on a high-byte write, the INIDISP brightness adjust table would be indexed out of bounds. I should have made the code check &1 anyway just so it was more clear. But whatever, it's the speed-hack, disabled-anyway code.
|
|
|
|
> I'd prefer that the folder in which bps starts browsing for the target file be the same in which I opened the patch
I can do that for anything but Windows Vista+. Vista and 7 force the common file dialog to the past folder it was in when said application was opened, and there's no way to override it.
> Additionally, an icon of some sort, the default Windows no-icon icon is atrocious to look at, especially with a full folder.
Don't have one.
> Demo World would still need to be applied to an edited ROM when converted to BPS
What's wrong with making the patch transform original SMW into SDW? May be a bit bigger, but probably not by too much.
> and Zsnes, the people who don't give a damn about accuracy and just want to make an awesome hack and have some fun with it
Yeah, just call me Ebenezer Scrooge. Our group demands all work and no play!
> It's still recommended though, and honestly, if you got to choose between ips and bps, I'd even state that it would be stupid to patch ips.
With an IPS+BPS patcher for download here, it seems fine to allow either. There's your backwards-compatibility. And it gives BPS a chance to actually catch on. Because of course nobody will implement it if there are no patches for it.
|
|
|
|
|
ZSNES all the way. bsnes is too slow and unfriendly.
|
|
|
|
Hmm ...
Unique features, pros:
* control of GUI with a gamepad (does not require Joy2Key)
* macros (unless your keyboard/gamepad does it for you)
* snow effect in the GUI background
* customize the color of the menubar and background
* use your own custom 5x5 font
* Toaster + April Fool's easter eggs
* no window border mode
* custom mouse cursor + capture
* advance one frame at a time for screenshots without the debugger
# fast as all hell (great for laptop battery life, older PCs)
# raw speed makes fast forward key badass
Sparse features:
* netplay (v1.42 and below only; also in older Snes9X, SSNES and Mednafen)
* rewind (also in bsnes v070-, and SSNES has much better Braid-rewind)
* movie recording/playback (also in SSNES)
* multiple mice (also in bsnes)
Missing features, cons:
* it's most likely dead
* 7-zip, RAR, GZ support
* multi-archive support (GoodMerge set)
* Super Game Boy emulation
* working SA-1 emulation (broken in v1.51, requires v1.42)
* BS-X emulation
* ST-0011 emulation
* S-RTC emulation (returns system clock instead, cannot override)
* SPC7110 decompression emulation (requires GFX packs)
* DSP-1, DSP-1B, DSP-2, DSP-3, DSP-4, ST-0010, Cx4 low-level emulation
* dual multitap support (N-warp Daisakusen)
* UPS/BPS patching support
* multi-part cheat codes (two GG codes bound to the same item)
* persistent cheat codes (it overwrites values once per frame; games can modify the value again mid-frame.)
* built-in cheat code database for the 1000+ most popular games
* lowercase letters
* ability to display filenames longer than 24 characters
* internationalization (no non-English text or filenames)
* OS integration (native widgets)
* pixel shaders for video
* flexible XML memory mapping
* MSU1 support
* save state manager that supports descriptions for each slot
* no support for Direct3D, OpenGL (and thus no point-scaling on XP-, and no linear-scaling on Vista+), XAudio2, XInput (Xbox 360 controller analog triggers)
* no externally loadable video filters
* only runs on OSes with 32-bit x86 libraries installed (no consoles, cell phones, tablets, handhelds, ARM nettops)
* no functional debugger (DOS-only version made useless in v1.42+)
# bad timing (FastROM is faked, CPU runs 40% too fast)
# bad video emulation (mid-frame VRAM blocking, Mode7 EXTBG, Mode6, pseudo-hires)
# bad sound emulation (distorted SFX, no APURAM echo writes)
# dozens of game-specific hacks
# hundreds of bugs (https://zsnes.bountysource.com/development/bug_report)
Debatable points:
? doesn't enforce SNES limitations
? you only have to upgrade it every five or so years
? custom GUI mentioned both in pros and cons; some like it, some don't
? familiarity (humans naturally hate change)
? desync audio emulation to prevent audio stutters*
(* which is why the SMW sound effects sound so bad, but also why there is no audio input frequency setting like Snes9X v1.52 + bsnes. This is better for novices, worse for tweakers.)
The bsnes cons list is similarly longer than its pros list, same for Snes9X. What's clear is that no emulator is the best of every world.
That it has even one unique feature or benefit means that it's the right choice for people who value that above all else. Telling someone their desired features are less important than yours is self-aggrandizing and will only be met with resistance. Speed and the custom GUI are what people most typically like best about it.
The original poster is very clearly trying to troll. Who cares? Use whatever you want. Just have the hack approvers test on real hardware and reject whatever doesn't work (including MSU1 if so desired.) It's their site, they set the rules.
|
| Last edited on 2011-08-27 05:00:06 AM by byuu. |
|
|
|
> However my point still stands on the whole compatibility thing. Who gives a crap as long as the hack is fun, creative, and entertaining. I also have a feeling Byuu hates me. A lot.
Nah, no ill feelings. Let's analogize this bitch!
Subject: "Pepsi vs Coke"
Body: "I drink Pepsi because I enjoy flavor, why don't Coke drinkers get that?"
(I prefer Jones Cola, FWIW.)
> and I'm still mad about BZSNES
Oh come on, that was totally awesome.
|
|
|
|
I am sorry if you were offended by that, but it was meant as a joke; to point out that if we kept on our current path, we would have to emulate emulators, rather than the SNES itself. It did of course do what it said it did, as well.
The GUI was just having fun with Qt stylesheets. I wrote that theme initially for the official ZSNES/Qt port (which never went anywhere), so I had it lying around already.
Regardless, I still donate all of my knowledge and code to the ZSNES devs, and assist where I can there as well. You'll find me credited in multiple changelogs for the project as proof of that claim.
You are of course welcome to take offense on their behalf, but it is unnecessary. The only hostility with me and ZSNES is with two of the GUI designers, which is a personal matter that I've addressed elsewhere and has existed long before the April Fools joke.
As disrespectful as I can be, my honest to god true intentions are to try and motivate them to take pride in their work and improve their emulation as well. You're free to disagree with the importance of accuracy until the end of time, of course. And as such I too will continue to promote my beliefs.
If I really didn't care, I would not have released my emulator source code, spoken with their devs at length about various hardware behaviors, contributed source code improvements, etc. I wouldn't help out my enemy, in other words.
|
|
|
|
> It looks like your tool wins byuu.
To be fair, Xdelta3 -9 inside a 7-zip max compressed archive will still beat BPS by a small amount. But Xdelta's a really complex spec, lacks easy to use tools, and only has one C++ implementation that is GPL only (so no closed source tool authors could use it). BPS will almost universally crush IPS uncompressed, and should always at least tie when compressed. It crushes UPS either way.
The advantages I am pushing are: almost as easy as IPS to implement, supports delta patching (SMW->SDW, FEoEZ example, works great on non-ROM platforms) (also makes ROM patches smaller), has checksum verifications, eliminates copier header patching issues, and stores metadata.
> All of those arguments have been said before, and we have responded to all of them.
Ah, the bane of my existence. Repeating yourself over and over and over (and over) because people won't read what's already been said, often times a single post above them.
And then finally, after the twentieth time you've had a ten-post or more discussion with people about the same thing, being as polite as possible, you snap and use a profanity. Instantly, everyone assumes you are an unreasonable asshole about it.
> Not to nitpick by I don't think anyone seriously responded to my argument that although IPS is an inferior format, it still has a lot of tools, and most romhackers already have at least one. I am honestly not sure if this is a big deal or not though.
Nothing really to be said about it, your point is correct. It's the change thing again. People like me will upgrade on technical merits alone. Most people won't upgrade unless the benefits are extremely substantial to them personally. And a few people just simply will never upgrade, period.
But again, we're stuck with a chicken-and-egg problem: if nobody will adapt the format until it's popular, then it'll never get popular, will it?
I agree that forcing everyone to switch instantly isn't the answer. There's so many ways to do things gradually.
Step 1. offer all patches in IPS or BPS, post BPS patching tools.
Step 2. let patch makers see the the benefits and reduced support issues first-hand.
Step 3. allow future patches to be BPS only, if the author wants.
Step 4. more tools support BPS, wrap the rest with DLL injection magic ala header-magic.
Step 5. announce a date for transition, six months out.
Step 6. accept that no matter what you do, there will be people unhappy about it.
|
|
|
|
> Also, I've noticed that the "technical people" (coders, porters) are less resistant to change than the general public. Maybe it's just easier for them.
Seriously?? I've found it the exact opposite. I have a whole lot of casual users who are totally cool with all of the changes I propose.
It's usually the big-name ROM hackers that throw the biggest fits about change, in my experience. (There are, of course, exceptions to every rule.)
Like when we tried to replace IPS back in '08, RHDN hackers would have nothing of it, despite them being the ones to have to deal with the dozens of patching failure threads. General users don't care. They need a patcher either way, it's a 20KB download and can come with the patch.
So many of them still use xkas v06, ZSNES/DOS debugger, etc.
It seems to me that they have more invested into things, because they are using the stuff so much more than anyone else. And this can hold true for casual users, too. You'll find the ZSNES since '97 people are the least likely to consider even Snes9X, for instance. The longer you use something, the more set in your ways you become. Hell, I still use Photoshop 7 
|
| Last edited on 2011-08-31 05:29:51 PM by byuu. |
|
|
|
> Nearly all SMW hacks have headers, which the original patches required, so you'd have to go through and somehow automate a fix or do it manually.
snespurify is supposed to apply the IPS patch with the copier header intact, and then create the BPS patch without it, and then remove the ROM header. But there's apparently a bug in v11 where the BPS patch keeps the header that will be fixed.
> Second, you'd be using (an actual SNES emulator), which is already incompatible with the vast majority of SMW hacks, because of Addmusic problems.
Which also won't work on a new Snes9X with BPS support, nor on a new ZSNES (hahah) with BPS support (hahahahahah.)
You're going to have to keep requiring outdated emulators here anyway.
> is there anything necessarily wrong with using a header on your ROM to maintain compatibility with tools that assume a header
It props up a file format that makes zero technical sense. The tools need to be fixed, because they are broken, period. I'm not ever going to support headers again, and I won't compromise my ideals to prop up a patching format.
Regardless: BPS patchers should make only headerless BPS patches, even when used with a headered ROM. When applied in an emulator that does allow copier headers, the patching should happen after header removal inside the emulator. On such an emulator, BPS patching works with or without a header. I've covered that already.
|
|
|
|
The 9X header removal was an idea, unlikely to occur. BPS support is in, though, thanks to OV2.
It only works on BPS patches made against unheadered ROMs. Your ROM itself can have a header or not, it doesn't matter, it'll still work.
There is no reason to include the copier header in patch application. It can be any of 30 different formats, making it far less likely that your user will have the right ROM. And nothing you write there in your patch output will have any effect on the emulation anyway.
So no, I wouldn't like that idea. Nor would any emulator developer who is tired of the copier header patching problem.
A patch applier designed for the SNES could both create and patch a game and leave your copier header intact, and that would be just fine.
|
|
|
|
QuoteOf course if the patch creation program covered roms to headerless internally before creating the patch this wouldn't be a problem, but that doesn't seem to be the case from what I heard.
That's the plan. Any patcher that is designed to work with SNES files should remove the headers from the ROMs *internally*, and create the patch. The files on disk will retain their headers if they were there before.
My reference patcher does not, because, as you say, it's a generic patcher that is agnostic to all formats. I have been too busy to make a "LunarBPS"-style tool specifically for SNES patches.
|
|
|
|
QuoteTurns out he had inserted then forgotten about an ASM hack in a bank past 40, and the ASM was reading not from RAM as intended but from an area of the map that normally isn't used in a LoROM game. The value read may vary depending on how your emulator/flash cart/copier wants to map it.
Yep, another problem with the SNES scene.
There's really no such thing as HiROM and LoROM. There are varous 74LS and MAD-1 mapper configurations that mirror different games in different ways. Probably 80+ variations.
The ROMs lack PCB layout information, so emulators basically go for compatibility, and mirror ROM data everywhere possible. This ends up differing between emulators and you have problems like that.
If anyone has seen the XML maps required by MSU1, that's basically why they are there: to describe the exact board layouts without relying on useless, inexact internal header info.
For official games, I have cataloged over 700 PCB IDs to get exact mappings, others have done hundreds more. But ROM hacks are just going to have to: a) not access non-standard regions of memory (best idea); b) use an XML memory map to describe their layout (won't work anywhere else); or c) cross their fingers.
|
|
|
|
QuoteThough, no idea exactly how one can make a hack compatible with the SNES and not bsnes, and how the hack moderators would deal with that.
You should absolutely accept such a hack.
QuoteThe whole accurate emulation debate's been going on since emulation started. Sure it'd be nice to have had all emulators be accurate from the very beginning, but there would've been opposition just like there's opposition today.
Exactly. They all anticipated the backlash. I didn't, and reacted poorly. We have speed-only, and accuracy-only+code clarity. No middle ground. All I've done was polarize people to one side or the other, most to the former.
Snes9X is starting to inch toward that middle ground. With the new APU, I think v1.54 will finally make it there.
Most regrettably is how the trend persists here of "it has to be *bsnes* compatible?", which is nonsense. Only ZSNES will run these hacks, and only on x86 systems. No consoles, no handhelds, no cell phones, no tablets, etc. At least say Snes9X v1.52-compatible.
ZSNES2 will be out eventually, and Windows will remove 32-bit runtimes in a few years (they double the Windows install size, and 32-bit apps run 20% slower.) People will start caring when *nobody* can run their hacks.
|
|
|
|
QuoteOr simply because Lunar Magic probably has a lot shallower learning curve than something like Game Maker
The funny thing is that FuSoYa has put so much work into LM, that I'm certain one could have made a full-fledged SMW clone on the PC with far less effort. Reverse engineering is a lot harder than creating.
Of course, it makes perfect sense to me: the idea of making SNES games is cool. They run anywhere thanks to emulation, and the limitations are part of the charm. This is of course lost on some people here, where LM is used as a glorified Game Maker ...
QuoteAnd then explain exactly why it doesn't work on bsnes (presumably even in accuracy mode) in the hope of uncovering something that could be fixed.
Yes, as long as it's not an obfuscated emulator detection, like Alcaro's LFSR PRNG check, I'll happily fix any legitimate and proven problems. I won't go hunting to do your bug research for you, though, as I'm not as familiar with what you've done as you should be.
QuoteI suppose the main reason SNES9X rarely gets brought up in such arguments is exactly that: the polarization. It's not noted for being fast (and inaccurate) like ZSNES, and it's not noted for being accurate (and laggy) like bsnes. It's somewhat of a jack of all trades but a master of none.
Right, it's an easy tool for exaggeration. Hence you always see 3-4GHz for bsnes requirements, when in reality they're about 1.6GHz on a PC that is properly maintained. And claims of catering to a tiny minority. Snes9X needs half the system resources, and has the same issues with broken hacks as bsnes does, along with ten times the userbase size.
QuoteI swear that not only have we had this discussion several times already, any thread that compares and contrasts emulators or asks why we should or should not support accuracy always ends up like this.
Yep, the topic has been done to death a dozen times. But what can you do? If people are going to keep bringing up the red herring of "bsnes compatibility", we'll have to keep responding :/
Quotehaving an emulator that can do both accuracy as well a different one "go outside the lines" of the limitations from SNES (filters, savestates, rewinds, etc.)
All SNES emulators do those things. But yeah, another emulator to bypass hardware limitations is fine: no sprite limits, hires-Mode7, fancier audio interpolation than gaussian, overclocked processors, HLE coprocessors, etc. I couldn't use a truly accurate N64 emulator, as that would force 320x240 rendering, which looks disgusting.
|
|
|
|
|
|
|
|
|
|
 |
|
 |
The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.
Copyright © 2005 - 2013 - SMW Central
Legal Information - Link To UsTotal queries: 27
|
|
|
|
