ROM (not copier) Header Hacks

[Richard C.]

If they are turned OFF by default, something like a message telling you to turn them on if you experience problems could appear each time you load a rom, that way, people who actually read and know something about what they are doing would be more likely to report decent and new bug reports on the emulation core.

If they are turned ON by default, there would be less annoying bug reports from idiots than if they were turned OFF, however, many people would not be aware of the new option, and less valuable bug reports would be posted.

Vote!

[pagefault]

I vote for ON since people expect games to 'just work'.

[grinvader]

I'd say flame the bad bug-reporters into oblivion and beyond. RTFM, the usual drill.

[ipher]

ON. People won't know to turn them on no matter how many warnings we put.

[Nach]

I say we look at each game we have a hack for, track down what it's hacking, and fix the problem, thus bypassing the whole issue.

[blackmyst]

I'm not sure. I suppose it's a bit of a quality vs. quantity issue as far as bug reports are concerned. I guess I'll vote for "off." But Nach's option sounds good too. :p

[Deathlike2]

Why does it exactly matter?

I think header hacks are the least of most people's probs...

If you factor in IPS patches, most of the time, the patches do something with the header data.. When I remover header data from those games that I have an IPS patch for.. it doesn't work (I can't play the game)... period.

Most people worry about adding/removing a header when something doesn't work... so let the user worry about it and document why this is the case. I understand there are bad headers.. so you can always mention in the documentation what the normal procedure for them are for (like use NSRT to remove them and perhaps add a valid header).

I guess by default, it should just be ON.. for IPS patches.

[grinvader]

Deathlike2: this is not about COPIER headers. This is about ROM header hacks.

This means:
ZSNES loads a game, and looks at its name, then updates several emulation-related critical variables (such as special memmappings, or different timings) accordingly.
Hacks.

[Agozer]

I say ON. At least it gives the people the ability to choose.

[AspiringSquire]

Since ZSNES has always had them in use anyway, I think the default should be ON. I agree with ipher and pagefault: there are too many people—who don't know or care if hacks are used—to have the toggle OFF by default; they just want to play the games.

Off-topic:
It would be these same people who would rather not have the data output at the bottom of the screen when a ROM is loaded. I would actually appreciate a toggle to turn that off, too. The default would be on, of course, but when you already know your ROMs are fit for use with ZSNES, you don't need to see the message every time.
I'm just offering an idea.

[grinvader]

Off-topic:
It would be these same people who would rather not have the data output at the bottom of the screen when a ROM is loaded. I would actually appreciate a toggle to turn that off, too. The default would be on, of course, but when you already know your ROMs are fit for use with ZSNES, you don't need to see the message every time.
I'm just offering an idea.

No sweat, easily done... once another checkbox is added to the GUI.

[pagefault]

This thread is kinda stupid. I think it should be an internal vote anyway.

[DEFIANT]

I say we look at each game we have a hack for, track down what it's hacking, and fix the problem, thus bypassing the whole issue.

[xamenus]

ON, though fixing the hacks should be top-priority IMO.

[Noxious Ninja]

Turn it off. Tell people that recently, ZSNES has had some things changed in order to improve compatibility. Unfortunately, these fixes have uncovered some old bugs which also need to be fixed. While many games work better with the new ZSNES, some games will be worse until these bugs are fixed.

Then do what Nach said.

[Clements]

It ought to be on by default, and then change the bug reporting guidelines to include a line saying something like "Did you try unchecking the enable header hacks option to see if the bug is still present" in a similar way to the new/old graphics engine, so that if ZSNES is improved and one of the hacks becomes unneeded but breaks the game if enabled, then you could check if the bug is still there by disabling the header hacks option.

[Nightcrawler]

I say we look at each game we have a hack for, track down what it's hacking, and fix the problem, thus bypassing the whole issue.

It's quite obvious that THIS is the correct solution. Everybody wins here. This is where my vote goes.

I hate polls that have no good choices.

[Clements]

I say we look at each game we have a hack for, track down what it's hacking, and fix the problem, thus bypassing the whole issue.

It's quite obvious that THIS is the correct solution. Everybody wins here. This is where my vote goes.

I hate polls that have no good choices.

But all the games with hacks cannot be fixed overnight unless some miracle happens, so in the meantime a choice for default has to be made if such a feature of choosing hack or hackless is implemented.

I guess another option would be not to implement hackless at all, but that is a bit stupid since it would save ipher compiling two builds everytime. Same for vice-versa.

[Nightcrawler]

Ok.. I suppose that makes sense.

Then the only real obvious choice is to default to ON because quite frankly, a large majority of people who use ZSNES would not be smart enough to know about this option and it will help prevent complaints of why does game xxx not work.

Pagefault hit the nail on the head when he said:

I vote for ON since people expect games to 'just work'.

It's true.. It's damn true.
Sad.. but still true..

[Richard C.]

I say we look at each game we have a hack for, track down what it's hacking, and fix the problem, thus bypassing the whole issue.

It's quite obvious that THIS is the correct solution. Everybody wins here. This is where my vote goes.

I hate polls that have no good choices.

But all the games with hacks cannot be fixed overnight unless some miracle happens, so in the meantime a choice for default has to be made if such a feature of choosing hack or hackless is implemented.

I guess another option would be not to implement hackless at all, but that is a bit stupid since it would save ipher compiling two builds everytime. Same for vice-versa.

Thank you, Clements

[Nightcrawler]

BUT.... leaving header hacks in there encourages these problems not to get fixed. Some hacks lasted for many many years. The game worked.. so no one bothered to fix the problem. As long as things like that don't happen, it should be fine.

[Kagerato]

Some hacks lasted for many many years. The game worked.. so no one bothered to fix the problem.

That's why people like you and I need to get our ass in gear and start working on zsnes :p

I'm actually somewhat serious. The more people working on the code, the more obvious its problems become and the more manpower available to fix them.

[Nightcrawler]

Some hacks lasted for many many years. The game worked.. so no one bothered to fix the problem.

That's why people like you and I need to get our ass in gear and start working on zsnes :p

I'm actually somewhat serious. The more people working on the code, the more obvious its problems become and the more manpower available to fix them.

Yeah... we should. But me personally, I really don't like the ZSNES source. Everytime I sit down to start changing something, I get dissapointed with the severe lack of comments and general disorganization and quit. It doesn't lend itself well to true open source in my opinion. I'm just not willing to spend the time to familiarize myself enough to start modifying the core. It's just not friendly to new developers.

[grinvader]

But me personally, I really don't like the ZSNES source. Everytime I sit down to start changing something, I get dissapointed with the severe lack of comments and general disorganization and quit. It doesn't lend itself well to true open source in my opinion. I'm just not willing to spend the time to familiarize myself enough to start modifying the core. It's just not friendly to new developers.

You tell me.

[Kagerato]

Everytime I sit down to start changing something, I get dissapointed with the severe lack of comments and general disorganization and quit.

This is what you call a self-perpetuating system.

I admit, the utter enormity of the whole project is rather daunting. If the source code were printed at a reasonable font size, it would take up a sizeable floor space

It'll only be cleaned and organized as fast as there are developers to do it, though. I'm optimistic that the source will be relatively readable to newcomers in the not-so-distant future.

I'm just not willing to spend the time to familiarize myself enough to start modifying the core.

For me, it hasn't been a lack of interest or desire to learn the structures and intricacies of the code. It is to a great extent my lack of time that prevents me from doing something significant. In the coming months, I'll have more of that precious commodity available, and we'll see what comes of it.