Advertisement
Guest User

Untitled

a guest
Oct 31st, 2012
231
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 12.39 KB | None | 0 0
  1. [quote]I've been asked by 4 of my peers to continue responding in this thread ... I've also received a PM from a forum member[/quote]
  2.  
  3. One, if I'm upsetting you, I don't want to keep doing so. Don't feel obligated to respond if you don't want to.
  4.  
  5. Two, may I ask who your five peers are? Generally curious, and it's kind of strange to say something like that without names. Eg "I have 374 people who agree with me; asking me to respond to you."
  6.  
  7. It seems a bit suspicious that besides you, everyone responding to this thread who voiced an opinion was in agreeance with me. I'd like to speak with these people directly.
  8.  
  9. I am not dead-set in my ways. Present compelling arguments and I will change my position. All I ask is that you potentially do the same.
  10.  
  11. [quote]who agrees with me that this is purely a "personal crusade" of some sort[/quote]
  12.  
  13. The 374 people I talked about this (who will remain anonymous) agreed that you were making up these five people.
  14.  
  15. [quote]- Removing the header from the file does not solve the problem -- IPS patch is still likely to fail to "do the right (desired) thing" 50% of the time[/quote]
  16.  
  17. For existing patches, you are correct. Any patch already made with a copier header will now fail 100% of the time.
  18.  
  19. Once copier headers were removed from eg Snes9X, RHDN could easily bulk update their entire archives. Emulators and tools could easily offer a "Patch not working" option to recode the patch with -512 on every offset for legacy works.
  20.  
  21. Yes, removing headers will cause a bit of pain now. But leaving them around forever will cause more pain in the long run.
  22.  
  23. [quote]People using IPS patches need to provide the filename of the ROM and a MD5/SHA1 of the ROM the patch is intended to be used against[/quote]
  24.  
  25. Yes they do, and they usually don't. And their users don't know how to get the SHA1 of a file.
  26.  
  27. [quote]Issue is not the responsibility of the emulator/library or front-end author -- cannot reliably (100% of the time) be solved with software[/quote]
  28.  
  29. Maybe not to you, but as both a ROM hacker/translator and emulator author, it's of particular importance to me.
  30.  
  31. [quote]Conclusion: not valid justification for modifying ROM / removing header from file[/quote]
  32.  
  33. We will agree to disagree.
  34.  
  35. [quote]Removal of header from file would cause some existing tools not to work.[/quote]
  36.  
  37. Yes it would. Which is why I made Header Magic. It hooks Windows APIs to ensure these older tools work. And once headers are gone, the tools will have no choice but to update.
  38.  
  39. And now everyone gets the benefit of tools that just work. They no longer have to fight with one tool that needs a header, and another tool that needs it gone.
  40.  
  41. [quote]Cannot reliably be solved (i.e. some tools are not going to work no matter if header removal is done or not)[/quote]
  42.  
  43. And yet I solved it anyway.
  44.  
  45. [quote]Conclusion: not valid justification for modifying ROM / removing header from file -- issue is irrelevant to topic[/quote]
  46.  
  47. You're coming into this discussion with the intention of being right, not in having a technical discussion.
  48.  
  49. Dismissing everything I say does not a discussion make.
  50.  
  51. [quote]Issue is not the responsibility of the emulator/library or front-end author[/quote]
  52.  
  53. So what? I'm only allowed to address things that are strictly related to emulators? I own my emulator, I wrote it, it belongs to me. I can do whatever I want with it. I can require my users to upload photos to the Infinite Cat Project to use it if I feel like it.
  54.  
  55. [quote]quote seems to imply that if there was only one "type" of ROM (i.e. headerless), this would somehow make ROM verifiers better or decent or good in some way[/quote]
  56.  
  57. It would simplify them by virtue of one ROM type being less than two.
  58.  
  59. A direct hash of a file would be all that was needed. One could even use the file checksum stored in a ZIP archive to authenticate the file without having to decompress it first (if they so chose. Obviously a corrupt ZIP header is possible, but unlikely.)
  60.  
  61. So yes, it would be easier.
  62.  
  63. [quote]Not enough precise detail to reach conclusion -- have not seen this myself -- need more technical specifics please[/quote]
  64.  
  65. NSRT produces its own header that ZSNES uses for things like determining which controllers to connect when you load the game.
  66.  
  67. [quote]If the ROM distribution group didn't exist, the same problem would already be happening, re: FIG vs. SMC vs. SWC vs. GD3 vs. GD7 vs. UFO vs. [0-9][0-9][0-9] (split-image SMC) vs. lots of other formats[/quote]
  68.  
  69. And I'm addressing that issue as well by only looking for SFC extensions.
  70.  
  71. And I'm also taking flak about that. Apparently people also have a god-given right to use SMC/SWC/FIG/MGH/MDH/GD3/GD7/SF2/BIN/etc as well.
  72.  
  73. [quote]if anything this argument supports not modifying the ROMs (i.e. end-users will mess this process up and make things worse[/quote]
  74.  
  75. I've yet to find anyone who messed up their ROMs when they used purify.
  76.  
  77. It's a two-click tool that pulls off all copier headers in 10 seconds.
  78.  
  79. [quote]need more technical specifics on this please; as such I am assuming this means "split image SMC"[/quote]
  80.  
  81. No. My Super UFO 8.3j copier needs to interlave HiROM images to work. I don't fully understand why, but that's how it works. I don't recall the exact orientation, but I believe it was something like swapping every 32KB of the file around.
  82.  
  83. Me sticking a vanilla HiROM image on my UFO, even with a UFO header, would fail to work.
  84.  
  85. Splitting to 1MB files is another problem. I think ZSNES *might* load split ROM files, but that would be it. And that emulator was discontinued nearly six years ago.
  86.  
  87. [quote]This issue would exist whether copier headers existed in the ROM or not[/quote]
  88.  
  89. No it would not. Games would only have one hash if there were no header. Games can have any possible hash value since the 512-byte header can contain any data at all.
  90.  
  91. [quote]coder/programmer "does not like doing odd math" effectively[/quote]
  92.  
  93. I've never found an emulator that could reliably detect copier headers with 100% accuracy. In fact, I challenge you to try. I guarantee I can make a ROM that fails your test.
  94.  
  95. Perhaps you feel that's missing the point, and we just have to support the arbitrary known list of files that aren't padded. Personally, I don't think we should load unpadded ROMs at all, but that's just me.
  96.  
  97. [quote]I also offered proper workarounds for this (focus on emulation and stop focusing on the front-end / file parsing bits)[/quote]
  98.  
  99. That's not a solution until someone takes over the front-end.
  100.  
  101. [quote]there are ways to solve this problem other than using said formula[/quote]
  102.  
  103. There are not.
  104.  
  105. [quote]However, give us some credit -- those of us who wrote demos on the console did so back in 1991-1996, where copiers were the only thing we had and disk space mattered more. I ask kindly that folks retain context (time period, etc.) when bitching![/quote]
  106.  
  107. Absolutely. I'm not really concerned at all. The goal was to list all negatives.
  108.  
  109. Unfortunately you're just dismissing them all as "irrelevant" and "not valid justification", so we aren't really having a debate here, but yeah.
  110.  
  111. [quote]Social problem; i.e. "this hurts me to have to do"[/quote]
  112.  
  113. The arrogance is astounding.
  114.  
  115. There is NO REASON any should have to do this just to appease the 30 people using copier headers. Get over yourself.
  116.  
  117. I don't care how doable it is. That isn't the point. The point is that it's completely and utterly pointless.
  118.  
  119. [quote]Workaround: romhackers can remove the header from their images before working on them, to ease their pain, then re-apply header before creating + releasing IPS patch[/quote]
  120.  
  121. Oh good, so the 500+ ROM hackers out there can add and remove copier headers after every modification.
  122.  
  123. But you can't add a header when playing games on your SWC.
  124.  
  125. I see how this works. It's about making you happy, at the expense of everyone else.
  126.  
  127. [quote]But as you can see, some of the points above are refuted[/quote]
  128.  
  129. And I've refuted the theory of relativity by saying it was irrelevant and not justifiable.
  130.  
  131. Coming in, finding any POSSIBLE excuse to back up your justification, and then claiming you've "won" on that point is a joke.
  132.  
  133. If this is how you debate, we're wasting our time. You've already made up your mind here.
  134.  
  135. [quote]As such, I still have yet to see justification for requiring everyone to modify their ROMs (copier header removal) rather than just ignoring them in software (emulator/library or front-end)[/quote]
  136.  
  137. Do you want me to keep pasting my list of reasons?
  138.  
  139. Copier headers are useless, they make patching more difficult, they complicate the loading and hashing and verification of files, they make life more difficult for ROM hackers due to tool authors fighting over whether to support or enforce them being there or absent, on and on.
  140.  
  141. [quote]I still see this as byuu's personal crusade[/quote]
  142.  
  143. Really? Because you've only said the word "crusade" seventy six times so far. You should try repeating yourself a bit more to make your points.
  144.  
  145. [quote]It is not a matter of the complexity involved in supporting these old formats[/quote]
  146.  
  147. Correct! With the exception of the unpadded ROMs, I can support detecting headers and removing them. And then all of the problems I've mentioned with them remain indefinitely. I become part of the problem, and not part of the solution.
  148.  
  149. [quote]So it's not about the technical benefits at all[/quote]
  150.  
  151. I don't know why it's so hard to explain to you.
  152.  
  153. ONE format is a technical benefit over TWO formats. It's simpler. 2 < 1.
  154.  
  155. And the only cost is a -very- temporary inconvenience, and then it's done. Once and for all.
  156.  
  157. [quote]How can a person say it's not a crusade given the above?![/quote]
  158.  
  159. How can one person use the same word seventy si.... seven times in one thread?
  160.  
  161. [quote]I'm not the one proposing everyone who has a SNES ROM modify it for philosophical reasons.[/quote]
  162.  
  163. The horror you speak of requires two clicks from the user.
  164.  
  165. I have had 40,000 downloads where this has been required, and of that maybe five people had any trouble at all.
  166.  
  167. The only people concerned about it are ROM hackers (who have tools that force people to use copier headers) and copier owners (all thirty of them.)
  168.  
  169. [quote]I'm stating there's no reason to demand the world modify a billion files (filecount*person) when it doesn't have to be that way.[/quote]
  170.  
  171. You're ignoring all the benefits to doing so, therefore of course there's no benefit in doing it to you.
  172.  
  173. [quote]Just from this, I'm just saying this argument has no end because of personal stuff.[/quote]
  174.  
  175. Yeah, there really is no point in continuing the conversation.
  176.  
  177. Especially when we're not having a real debate.
  178.  
  179. "This is a problem."
  180. "No it's not because there's a workaround."
  181. "... that we need a workaround IS a problem."
  182. "No it's not, you're on a crusade."
  183. ...
  184.  
  185. [quote] The point is these headers can be safely ignored by software (emulators, etc.)[/quote]
  186.  
  187. No they can't. Some patches depend on them, some do not. ROM hackers throw a shit-fit if you distribute a pre-patched image.
  188.  
  189. [quote]Regarding "a standard ROM format" -- xkcd covers this quite well.[/quote]
  190.  
  191. That would be relevant if I were proposing a third format. These two formats already have and continue to exist.
  192.  
  193. I'm saying we should pick one and be done with it all.
  194.  
  195. [quote]However so far that doesn't appear to be the case. (again, nothing presented so far indicates it's technical)[/quote]
  196.  
  197. Just because you say so doesn't make it true.
  198.  
  199. [quote]You're right they don't -- and do you know how that information is provided to Nintendo? I do: on paper. Do you want proof of my statement? I'm happy to show you the pages of the official SNES developers manual ("SNES Software Submission Requirements") which contain 2 pages of fields/data one has to fill out when submitting a ROM to Nintendo for review. Would you like to see it or will you just trust me?[/quote]
  200.  
  201. What does that have to do with anything?
  202.  
  203. He said there were no headers on the original images submitted to Nintendo. That was correct. Paper forms are not copier headers.
  204.  
  205. [quote]Good fucking lord people! The topic at hand is whether or not ***REMOVING THE HEADERS FROM THE ROM ITSELF (MODIFYING THE FILE)*** is justified, or if they can just be ignored by software.[/quote]
  206.  
  207. This is why we can't have a rational debate.
  208.  
  209. You are, for whatever reason, grossly invested in this emotionally.
  210.  
  211. [quote]Only a US American can say such a foolish comment and actually mean it.[/quote]
  212.  
  213. Pretty much. Our gluttony is shameful.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement