It will support nonexistent boards by defining them in a structured way. This one probably through a newly defined CNROM-HOMEBREW board type which I will define and bind to iNES headers specifying mapper 3 which don't bind to anything else first.
You can't expect a new emulator to support every hacked up bogus 'mapper' ever conceived, unless it does so by having virtually no validation on anything, which guarantees bugs later.
Yes, you can. All you have to do is to put up a message saying that the mapper cannot be validated, and ask the user if they want to go ahead anyway. If they do, you temporarily pretend it's been validated (for the rest of the session). If bugs pop up after the user has chosen to skip validation, that's not your problem.
Changed my mind. But I am still disappointed that this run made it. I remember watching it here recently and wondering why I couldn't figure out what was going on, when the one I'd watched previously made perfect sense. I can't tell what they did at all. And isn't that the point of a TAS--to show off all the neat things you are doing, showing HOW the game can be beaten by a super human?
I hope no one will mind me talking about this. It's a bit tangential, but I think it illustrated how lsnes should be run.
creaothceann wrote:
It's just that byuu has a certain stance on the issue (ROM headers are worse than useless (patching problems), archives don't have enough benefits today and needlessly complicate the code) and I agree with him. You can even include a build of snespurify, in addition to the source.
The thing is, his arguments are all based on his idea for revolutionizing how people think about emulation, and not based on any real practical concerns. It's based on his idea of what people should want, and not on what people actually do want. These are the same things that people hate closed source programs for doing.
His devotion to accuracy is commendable. His idea that there's one right way to handle emulation, including even how we have to arrange our files, is not. If you don't want to use a certain part of the code, don't lobby for it being removed, just don't use it.
lsnes definitely should not remove things just because some people don't want them. Remove them because people aren't using them.
I'm surprised they're swooning over the animated GIF which demonstrate how to do the tricks instead of the actual TAS'es that show the glitches in real-time. Eh, I'll give 'em a few days.
Wonder if they've seen the Megaman ones yet.
Pretty sure that's because they are interested in seeing how it's done, and not watching it happen itself. The GIFs make the text explaining what's going on clear.
I know that, unless I know the game well, I generally do not bother to watch videos unless they are either subtitled or there's a lot of information about what's happening in the submission. Unless I can work it out myself, it's just not fun.
Because the glitched run uses the pipe glitch just like the previous fullgame run (by andymac), just to a greater extent. Therefore it makes no sense to have seperate categories. At first I complained about this reason for obsoletion, but later accepted it. All that's left is either a "glitchless fullgame/all levels run" or a "no-pipe glitch fullgame/all levels run", the former makes more sense since the pipe glitch is actually a "touch an object, quit out of the level at the same time" glitch which there are several varations of, for example touching the bubble item or the bell (to skip half of Moon Zone 2). But I think both categories would be fine.
Also, I just noticed I messed up while editing the VBMs, so the submitted VBM lists andymac as the author, yet the rerecord count is correct. I think this can be ignored.
No, it doesn't make sense because it DOESN'T USE THE SAME GLITCH. The pipe glitch is not the glitch. The glitch is the fact that you are able go outside the map area of memory to locations in memory that are not intended, allowing you to edit the game's RAM from within the game. You shouldn't be able to do that. The game should restart the level when it detects that you are far enough outside the intended game area. (Like, say, what Mario 64 does if you go too far.)
And, yes, I know that's a tradeoff they made to get the system to work on the console. So is every other glitch.
You all even admitted in the previous publication that this was what was interesting about the run. If it weren't for those glitched screens, would you have even accepted this? No, because it wouldn't have completed the game.
And I just went back and looked at the first submission in this branch--it flat out says it doesn't use the pipe glitch. So what happened here is that one run that didn't use a glitch got superseded by one that does got superseded by one that uses another glitch.
I am appealing that this submission be re-examined. I have seen much more "boring" submissions be accepted. And to fans of SCII this TAS is fantastic.
Unfortunately, this runs into trouble with site rules.
Basically, some judge would have to get the run to sync (and the emulator isn't very sync-stable between computers).
Then there is getting publishable encode (I think converting from existing one might be possiblity).
Or someone could work on a version with an official DOS emulator.
BizHawk supports 7z, and 7z still do rar, zip, gzip, etc
Cool. I'm still waiting on .NET Framework 4 to install, so I didn't know. I've got everything downloaded, but the installation is going rather slow.
EDIT: Finally got it working. My review: it needs more display filters, particularly the ones that don't blur the screen. The more basic advinterp and advmame (EPX) are needed, as are the hqx family.
And, as expected, the bsnes core on my single core netbook is too slow, even with as much frameskip as possible. I don't know if you'll be able to speed hack it, as the designer is so dead set against speed hacks that he may have made that difficult. I sincerely doubt any speedhacks will make it run on my netbook (which is enough to run snes9x at triple speed.)
There are only two Snes ROMs that are 48Mbit or 6MB in size, the rest typically range from 2Mbit to 32Mbit. Not being able to compress them should not be an issue.
Especially because you can compress them (at least on NTFS file systems). Just use the built-in Compression option in Windows on the properties tab. Yeah it's not the tightest compression, but it does get close to ZIP level.
That's assuming BizHawk doesn't have other archive support. If it does, use that. RAR is so far the best I've seen for SNES games.
I know you're pretty busy, but it really would be nice if you could at least finish the boss guide for this. I at least would like descriptions of your strat for the last two, which have nothing but a video.
It's fun to watch, but I like to know a little about what's going on.
My experience with YouTube is that they will only enforce policies if enough people complain. I think they wait until there's some minimum number of complaints before they even bother to check the video.
I really like this run, and the best part about it being it's hardly a spoiler, except maybe for the end of the game credits..
What you see at the ending of the game credits is the best ending. It only occurs if you beat the game without ever dying. Which most players end up never seeing.
I know this is over two years old, but I have to comment: It's not as hard as you think. You see, there's a glitch I've known about since before TASVideos existed, a glitch that works on the original GB version that still works on the GBC/DX version.
If you Save & Quit (See first post for how) while the dying animation plays, the death counter won't trip. As long as you do that, you'll still get the good ending no matter how many times you die.
Even though this will never be used in a TAS due to time restraints, I thought you might find it interesting. The site is about knowing games in and out, after all.
EDIT: And, yes, this run was incredibly fun to watch! I particularly loved the detailed notes. But how do you get use a dungeon key from the wrong side? I didn't see that mentioned.
