Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
Sure, I guess this is all theoretically true. But I find that unlikely if the same input has the same effect, and the ram values are the same, and the physics, and I encountered no differences. Possible, but unlikely.
Also, from a practical standpoint, all I can say is..This is Donkey Kong, man. What is there to fix up? Why would they bother? What "unknown differences" could possibly happen that would affect gameplay on a short simple game? Seems like you are arguing the concept, not the actual situation.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
I personally have not made this assumption. I did my homework, and drew this conclusion.
Here are a few details:
1) This is a valid NES rom, in every way, there's nothing "Wii" about it, it is a NES game, that plays in a NES emulator
2) The Ram Addresses are identical to its counter part (very handy for making a TAS)
3) Take a look at the two games in the PPU Viewer or Nametable viewer, same stuff in the same addresses.
4) The physics are the same, as is the frame timing. As you said it is "just copied inputs", implying that the same input has the same effect.
Are there differences between this version and the one released for the NES? Yes.
In addition to a new level, the cart itself changed. The original was released on a NROM board. This is the cheapest board to make since to make since it does not contain on board chips to extend the limited NES capabilities. It uses the 32kb of PRG and 8kb of CHR rom.
The new rom uses MMC1 which at the time of the NES release would have been more expensive, since it has extra chips to store more PRG and/or CHR data. 3 levels fit nicely on NROM, but you can't cram in a 4th. It is logical to think that this was a business decision to gut a level to fit on a cheaper board. When releasing this NES game as a VC Wii game, these types of considerations aren't an issue. It isn't more expensive to use a different board when the board itself is emulated. So it is only logical to release the NES game as it was originally intended before it was gutted.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
1) I dont' believe this ROM to be a "Wii Remake". I believe it to be a real NES rom, and most likely pre-dated the "official" version
2) I didn't just "copy inputs", this is my own work.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
We don't modify published movie files.
In theory we can add an additional movie file (the .bk2) but there's no official way to do this. Doing so involves tinkering with the database.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
When the Vault was implemented, we went back and unrejected a lot of movies. However, we decided not to touch cancelled runs. Those were the author's wishes, and I would prefer to honor that. If they want to uncancel, that's fine, but it will be their choice.
Grassini is trying to encourage authors to uncancel their movies and see them judged under the new rules. I see nothing wrong with that.
For what it is worth, I'd prefer to see runs uncancelled and then rejected if need be, a verdict helps the community (setting precedents and refining rules). Plus, should rules change there's the option of unrejecting (we don't uncancel).
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
IF you exploit Nintendo's VC bugs (which btw are not relevant here, this is an easy to emulate NES game that both emulators emulate flawlessly), then I see that as exploiting an emulator bug. Just because it is an official emulator doesn't mean it isn't an emulator bug. And those aren't (and shouldn't) be allowed here.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
How is wrapping the game in Nintendo's virtual console and artificially forcing the game to run at 50hz more "official"?
Everything I can tell about this rom is that this IS the official version, and is a real nes game in every way. And likely what they would have released originally for NES, if it weren't cost considerations.
Am I in the minority here that VC submissions are bad? You have a double layer of emulation there. Just because it is Nintendo's emulator doesn't mean you aren't emulating an emulator.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
I'd like to hear about any vba version that emulates these games correctly.
And also any feedback about mGBA, as that is an emulator I'm hopeful about adding to BizHawk
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
Note exactly, but close. It was to avoid triviality. And to make sure the vault movies have meaningful technical achievement as you mentioned. In most cases the triviality is indeed due to some uncontrollable timer or some such.
And to specifically mention a genre was to avoid as much subjectivity as possible. A rule like "must not be trivial" creates a subjective situation that will be as hotly debated and argued, similarly to entertainment value with moons.
If this is a non-trivial technical achievement with no entertainment value, maybe the rules can be adjusted. Then again, if it is so non-trivial, does it not have entertainment value?
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
I can say with confidence our rerecord count isn't accurate and is lower than what it really was. We made many iterations as part of our process, probably starting from a fresh movie. And not all our effort was counted (just depended on who checked in what). And since we don't really care about the rerecord count, no effort was made to keep an accurate log
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
Well that is bsnes (which lsnes and bizhawk both use). It is slow, but it is insanely accurate to the real SNES. And snes9x is very much not accurate to the real SNES.
bsnes is greatly preferred, if you can suffer through low FPS, or get better hardware.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
1) He said 25fps BEFORE recording a movie, movie recording (with the bsnes core) has even more overhead to ensure sync stability. I don't think sub-25fps is a reasonable TASing experience.
2) That's a suspiciously low fps even for your computer specs (which are bad). What kind of fps do you get with for example, NES Super Mario Bros?
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
This was resolved in another thread, but I thought I'd re-post here for anyone who reads this.
The bus is specifically with the bsnes performance core and rewind. By default, the performance core is used when you are casually playing and will switch to compatibility for movie recording. You can force it to compatibility in snes -> options.
This is isn't a priority to fix either, the performance core is only in there because of how painfully slow the compatibility core is, better is to finish porting snes9x as our speedy core option.
This is the only known combination where rewind is crashy. Of course things like N64 with very large savestates will be laggy and problematic, and you can crash your emulator by using the in memory rewind option and too large a buffer.