I really hated the experience of playing on any smartphone. Something about the "controls" if you can call them that, annoys me deeply.
Games designed for it are alright, but I can't stand trying to use an emulator with only a touch screen and tiny keyboard. :| Makes me want one of those PSP phones, but I don't buy Sony products...
I'll repeat what I said elsewhere: Subcategories and goals. Instead of just categorizing runs as "100%", "Any%", etc, you categorize them first by goal (complete everything, beat the last boss, just get to the end screen by any possible means, etc) and then by method/route (normal-but-superhuman play, using glitches X and Y, using glitch Z, etc).
To me, "play the game faster and better than humanly possible" is a very different beast from "use frame-precise input to manipulate a memory corruption glitch to trick the game into jumping to the end scene". The latter is more like hacking the game than playing it, really.
A communal Youtube channel is also a great idea.
Isn't everyone using Mupen64Plus (or some variation of it)? It's still in development. It's true though that all N64 emulators (including Nintendo's) are terrible and inaccurate, and I doubt any existing N64 TAS would actually play back on real hardware.
Slowking wrote:
Derakon wrote:
Sounds to me like the GC/Wii version uses an inaccurate imitation of the real behavior.
Or they deliberatly fixed a bug the N64 has with OoT, where the game sometimes reads memory that is out of the N64s range.
That's kinda like blaming a person for getting in the way of a bullet. The N64 didn't have a bug. OoT did, and the N64 reacted as it was designed (throwing an exception on out-of-bounds access). The emulator is in the wrong, ignoring that and allowing it to keep running.
After all, why give the emulator more range than the N64 had, unless you want to prevent these kinds of crashes? Who knows what Nintendo was thinking. ;)
Because it takes extra CPU time to check for invalid memory accesses, and they decided not to bother doing so, since the game shouldn't be doing it anyway. Emulators often sacrifice accuracy for speed.
I should note though, IIRC the game only crashes if you attempt to use the Deku Stick as an adult. I had the stick on B many times on the N64, and it worked fine as long as I didn't press B. From what I've seen none of the routes require actually using the stick, so the game wouldn't crash anyway.
It'd also be worth investigating to see if the crash can be prevented, by using a different version or figuring out what causes it.
Sounds like the best solution is for bSNES to store, in a known location within the save state files, the offsets at which RAM, VRAM, etc are stored in the file. Then tools like vSNES or a dedicated sprite ripping program would be easily able to look up the graphic data in memory.
Or, does bSNES support Lua scripting? A script could trivially dump any region of memory to a file, producing a raw VRAM dump or such. (Or if not, why does it have to be bSNES?)
Should you? Of course. Do any games actually do anything different, aside from cosmetic things like palette adjustment to make up for the GBA's shitty screen? AFAIK, only Zelda.
A lot of games use a simple checksum to detect any save corruption. It kind of amazes me that Pokémon games didn't for so long...
I don't know of any emulators that emulate a nonexistent "reset" button on handhelds, either. They just emulate a power cycle. (Most don't emulate the GB boot ROMs with the Nintendo logo, so it's effectively the same as a reset anyway.)
I always felt like there should be categories on a per-goal basis (100% vs any%), and within those, subcategories based on how the goal is achieved (few/no glitches, BA/RBA, this warp-straight-to-the-credits glitch, etc).
CosmoZSR wrote:
that screenshot was mine, done on console.
Can we really call VC "done on console"? It's still an emulator, not really any different than those on PC. A little more accurate, but even then, not very. (It doesn't even emulate the RSP, for instance; it uses HLE just like PC emulators do.)
Hmm, but then, do the reset buttons suffer from contact bounce? ;)
It's true though, switching the power off is about analogous to taking a hammer to the CPU, as far as program state is concerned. The only difference being it doesn't physically destroy anything... You can't expect to emulate that accurately, unless you're emulating down to the subatomic level.
Why would load times be an issue for N64 emulation, though? It's loading from cartridges, and other cartridge-based systems don't have such problems. I think the main problem is just that N64 emulators are inaccurate and hacky, adding lag here and skipping it there to try to make the game work mostly well. (Still most choke on e.g. Zelda's pause screen, Mario Kart's jumbotron...)
With disc-based systems load time becomes an issue since it's not really possible to accurately emulate the disc drive's physical motions, but load time from cartridges should only be limited by how fast the CPU can read them?
I found it pretty interesting. That opcode matrix, that's basically just a big array of flags telling whether to perform step X for opcode Y? Quite interesting approach.
Well I find it entertaining to watch such perfect driving. A glitched all-track run would be neat too, but glitched runs of games like this tend to get pretty repetitive. Turn left, jump off cliff, get put back on track, repeat twice. It's technically impressive but not a ton of fun to watch.
Resetting while saving always seemed cheap to me. There's got to be a way to break this game without that... that coin case bug might lead somewhere, at least.
I'd love to see a run of this that plays all tracks with no huge shortcuts. Of course, how to define "huge shortcuts"... I'd go with "the camera should show a route around the entire track each lap". i.e. cutting a corner here and there is fine, as long as the road you skipped past is still on the screen. (There's potential for abuse "well it's there... waaaaay over there..." but this game has a pretty low draw distance, so maybe not.) Taking a shortcut put there deliberately (e.g. the sandbar or tunnel in Koopa Beach) would be fine too.
You might debate whether a shortcut exists deliberately, e.g. jumping the wall at the beginning of Wario Stadium. Fortunately this game's coding helps with that a bit: when you jump over the wall, you can't see the track beyond until you land on it, because it doesn't switch which segment it's rendering until you land. So probably that route wasn't intended, or else they'd have set that up to avoid the graphical glitch.
In this case though we have a more interesting possibility: I've been able to decode and render the levels from the game, including the paths defining the routes that the AI, camera, etc will follow and that players must roughly adhere to. I've also managed to hack Lua scripting into Mupen64Plus, although it hasn't made it into the official branch yet due to laziness. So we could define allowed routes in terms of the path data defined in the game, and if we wanted to be really strict, even write a script that checks if the player is straying too far from the path.
This isn't a perfect solution though, since e.g. there's no path leading through the tunnel in Koopa Beach (no need, since the game allows players to skip portions of the path), yet it's hard to say that route shouldn't be allowed or wasn't intended.
Perhaps we could make a rule like "no skipping more than 10% of the track in total"? You could measure the length of the track by playing one lap without cutting any corners (but taking the shortest possible routes, sticking to the insides, etc) with an odometer script (which I've already written), or the length of the aforementioned paths, and then require the player's route to be at least 90% of that length (or whatever other number is appropriate for any given track). Then the trick becomes getting the distance covered as close to that limit as possible and keeping speed as high as possible.
Or the player could just plan their routes for each track and post them to see if everyone agrees on them, but I imagine that'd get even more nitpicky than this idea is already... :P
There are a few games, such as the PS2 .hack series, where you can actually load a previous game's save file and use the same characters/stats/etc in the new game. In that way part 2 becomes like a "second quest" of part 1, except that you can play it without actually finishing (or even starting) part 1.
Well such an exploit is what I meant. If a glitch causes the game to use uninitialized memory, and the emulator doesn't random-fill it at startup/power cycle, the behaviour could be completely different. e.g. if RAM is initialized to all zeros, a glitch that cause the game to jump to some random place in memory might just lead it to execute a bunch of NOPs before finding its way to something executable, while on a real console the behaviour would be unpredictable.
As I see it the reset button is an input just like the controllers, the SRAM, the real-time-clock, etc. On most systems it just signals an interrupt and the game is free to respond however it wants. Exploiting the fact that the programmers didn't consider resetting mid-save and employ a checksum is not really any different than exploiting the fact that they didn't consider pressing left+right simultaneously and employ a speed limit.
Powering off is a trickier issue because, as Xkeeper mentioned earlier, you can't be sure what the result will be - as the chips power down they start behaving non-deterministically. NES games would tell you to hold reset, because that would stop the CPU - otherwise it would spaz out as its power supply slowly drains away and might chuck some garbage into your save file. Game Boy games use write-protected save RAM for the same reason. So you can't be certain that a hard power-off/on on a particular frame, or even a particular CPU cycle, will always do what you wanted.
That said, of course, if we assume the save RAM isn't damaged by this non-deterministic behaviour, and produce entertaining videos based on this assumption, I see no reason not to accept them. The power button is still an input to the CPU just like all the others, and developers should indeed be assuming the system will be shut down at any arbitrary time - how many people have had an electrical failure during a game?
Similarly, I see no reason to reject a run that uses a Game Genie code if the result is entertaining - no different than a ROM hack. Using a code to skip right to the end or remove all monsters isn't really entertaining, but maybe a code that makes your character run faster and jump higher might be amusing to watch. Of course you couldn't compare it to a run done without the code, but it might still make a fun video.
What bugs me about (S)RAM corruption videos is that a lot of emulators zero-fill memory at startup/reset, whereas on a real machine, the contents of memory on power-on or reset are going to be either be random, whatever was there before (possibly deteriorated), or for fresh SRAM potentially some data left there during manufacturing.
I'd be satisfied to know that emulators used in TAS videos initialize all memory to random noise on any power cycle, but if you want to really nitpick, I could stick Mario Kart in my N64, then quickly switch it off, replace it with another game, and switch it on again... the data takes more than a few seconds to deteriorate, so I could essentially control the initial contents of RAM that way... and of course uninitialized SRAM probably contains pieces of older save files... then I could make a run which "beats" a game by just tricking it to jump into some uninitialized memory where the previous game left a subroutine, which survived power cycle and conveniently jumps to this game's end sequence... or by hitting new game, saving, and quickly resetting after the game has written just enough data to mark the save file as valid, then loading a previously erased save in which the game is beaten...
but just how far down the rabbit hole do you want to go? ;)
[edit] formatting derp
The only feasibility I can see here is if you have multiple cores and your bot needs to do a lot of number crunching on several different inputs to compute the best possible action - in this case you could spawn several threads to do the math using all available cores. Trying to get multiple threads to interface directly with the emulator - let alone while it's running - would just be hell.
That one's a bit different though in that AFAIK it doesn't exploit any glitches - the game is just so ridiculous that you can win by random chance the first time you search. (Plus, it's just so damn entertaining to see the game beaten faster than it starts! :p)
Unfortunately modern N64 emulators don't enforce the limitations of the console, so games load and run faster than they should. That does mean a lot of the runs aren't technically valid...
It's a problem with hacks too, since you get hacks that won't work on a real console because the GPU isn't fast enough or they aren't sending it some instructions that it needs but that emulators just ignore...
Anyway this is a really cool project. All you do is send back the next frame every time you're asked for it? I would have expected syncing to be a nightmare...
Give it a few years/decades and maybe we'll have computers powerful enough to genetically evolve an input sequence that beats Mario. :p
I think the King's Bounty run involved some brute-forcing? But that was for only 0.3 seconds of input...
If you want to get an idea how infeasible brute-forcing is, do the math (again!): for 8 buttons, you have 8 bits of input per frame. You want to compute the shortest input sequence that wins the game.
One frame = 8 bits = 2^8 = 256 possible input combinations to test. Did you win? No..
Two frames = 16 bits = 2^16 = 65,536 possible input combinations.
Four frames = 2^32 = 4,294,967,295.
8 frames = 2^64 = 18,446,744,073,709,551,616.
For just eight frames you already have 18 quintillion possible input sequences. Every additional frame multiplies the number of possible sequences by 256.
Keep in mind that the only way to tell if a given sequence wins the game is to play it in the emulator from start to finish, and if you want to create the best sequence, you have to be able to backtrack - it's not enough to say that by frame 10,000, Mario's made pretty good progress, so those first 10K frames don't need any more adjustment, because maybe he headed into a dead end at frame 8000. (FYI, 2^10000 has 3011 decimal digits.)
Also mind that you don't know how long the winning sequence will be. So, assuming the winning sequence is only 8 frames long, that doesn't mean you only have 2^64 possible sequences to try - you first have to determine that you can't win in 7 frames, or 6, or 5... that means you have 2^64 + 2^56 + 2^48 ... + 2^8 sequences.
For n frames, the total number of possible input sequences is 2^(n*8) + 2^((n-1)*8) + 2^((n-2)*8) ... + 2^(2*8) + 2^(1*8).
By the time you get to frame 60 - that's one second of input - you already have 2^(60*8) possible sequences to try - that's
312,174,855,031,599,223,138,159,722,979,316,
630,574,859,814,266,497,115,085,91,569,596,
253,717,388,197,656,201,203,061,030,634,919,
711,598,269,311,214,066,22,895,447,975,679,
288,285,306,290,176 possible 60-frame movies. And that's only after you've tried every possible movie of 59 frames, 58 frames, 57 frames...
Let me know when your computer can generate the works of Shakespeare by brute-forcing strings one character at a time and then checking the entire result (no partial matches allowed!). Once you can do that... brute-forcing a TAS still won't be feasible, because now instead of a simple strcmp() to check if your input is correct, you have to feed it into a considerably more complex function, e.g. Super Mario Bros.
Noob Irdoh wrote:
Or, did you download the emulator source code, checked it all to see if it's malicious, and compiled it by your own? Very well, ask the TAS@home to be open source (and multi-platform too while that we're at it) and compile it too by your own.
And then you have to trust that your compiler isn't bugged... wrote your own in machine code? Hope you trust your CPU... ;)
[edit for less page stretchage]
