For the case of Blades of Steel, a super determined human who wanted the best possible real time world record would reset until uninitialized RAM gave him the perfect RNG for his route.
By the way, Blades of Steel is a sports game. The point still stands though.
Emulator Coder, Site Developer, Site Owner, Expert player
(3598)
Joined: 11/3/2004
Posts: 4738
Location: Tennessee
creaothceann wrote:
[*]It makes the TAS itself look weaker: it can only complete one specific version of the game, not all of them.
A great many of our current TASes fail this criteria. One I can confirm is NES Friday the 13th (because I'm currently experimenting with it with the idea of exploiting unitialized ram). If you set the initial WRAM state in the emulator with random values, the currently published TAS usually desyncs (suggesting it is assuming a particular value from an unitialized address).
And as for this:
creaothceann wrote:
An emulator should always emulate as accurately as possible. That means observing and emulating real-life RAM cell values.
Faithfully emulating real hardware would involve some form of random initialization which would make these TASes impossible to TAS! In this case either the TAS "gets a say", or we don't get the luxury of making the TAS in the first place
How about we do something like this, and do it many times and create a heat map?
we could take a hex grid of data and represent it by a pixel per value and create an image. The color of that pixel will be hotter based on the number of times it was "on"
If the heat map was essentially evenly colored, we could conclude that essentially any ram combination is theoretically possible. However if the image was "clumpy" then we know we need to be more skeptical of what's possible.
Yes please. Not only is this a great idea, I suspect that the resulting images will be very pretty ^_^
A warb degombs the brangy. Your gitch zanks and leils the warb.
It makes the TAS itself look weaker: it can only complete one specific version of the game, not all of them.
A great many of our current TASes fail this criteria.
Then they should be easily replaceable when more accurate emulation is available.
adelikat wrote:
One I can confirm is NES Friday the 13th (because I'm currently experimenting with it with the idea of exploiting unitialized ram). If you set the initial WRAM state in the emulator with random values, the currently published TAS usually desyncs (suggesting it is assuming a particular value from an unitialized address).
IIRC, tests by byuu have shown that SNES WRAM shows specific patterns upon power-on (and repeated power-cycling shows specific value degradation patterns over time). These patterns are semi-deterministic: they may differ for different hardware versions, RAM chip versions, etc. but are deterministic enough to be (most likely unknowingly) relied upon by game programmers. NES (and others) are most likely the same.
So I'm not for filling the RAM with rand() values, but for a specific, most-likely pattern that has been agreed upon to be used for all TASes. (There may be game-specific patterns required for cartridge SRAM.)
EDIT:
http://board.byuu.org/viewtopic.php?f=5&t=2554http://board.byuu.org/viewtopic.php?f=8&t=4050
The way I see it, TASing occurs within a closed "universe". The universe consists of the console and its input devices, the game, and presumably a display and speakers. The TASer enters into this closed universe after it has been created, and, with perfect knowledge of the state of the universe and perfect timing, manipulates the input devices (possibly including reset, power off, eject, etc.) to achieve their desired goals. Those are "the rules" from my perspective, and I grant that others may feel differently.
It seems to me that you are suggesting the power button is not a valid input. Surely, after creating this universe, the console isn't just already turned on. The taser needs to start it. And the timing with which they start it will affect the starting ram state. Why is that not a valid input?
Emulator Coder, Site Developer, Site Owner, Expert player
(3598)
Joined: 11/3/2004
Posts: 4738
Location: Tennessee
creaothceann wrote:
adelikat wrote:
creaothceann wrote:
It makes the TAS itself look weaker: it can only complete one specific version of the game, not all of them.
A great many of our current TASes fail this criteria.
Then they should be easily replaceable when more accurate emulation is available.
In the case of Friday the 13th that IS accurate emulation! The reason I picked it was because NESbots have the same behavior of randomly syncing and randomly not, because NES RAM is random. What should we replace the published TAS with, in this case?
In the case of Friday the 13th that IS accurate emulation! The reason I picked it was because NESbots have the same behavior of randomly syncing and randomly not, because NES RAM is random. What should we replace the published TAS with, in this case?
Not completely random though, see the links I added above.
We don't have to replace the published TAS if we really absolutely 100% can't emulate that aspect of the NES. If that's the case we have to admit that our emulators will be always different from real hardware, but we can still use them for creating and rating TASes. They'll just not be 100% syncable.
While I'm generally in favor of allowing this stuff, because insisting on a single arbitrarily-chosen-by-emulator-developers state is really dumb, there is another possibility (though maybe not a very realistic one):
We could demand that every movie sync against *every* possible initial state.
This is obviously impractical to test exhaustively, but the rule could just be that movies obsolete other movies that can be shown to sync for fewer initial states.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Clearly TASes of the future will be fully fledged scripts that vary from the input file whenever uninitialized RAM has an effect on the game's behaviour.
I don't get what you are implying though. Even with semi-random behavior, you can't get 100% reliable sync...
I'm saying that a RAM map should be created, using values that were observed on hardware, by a function like this. This RAM map will then be "frozen" and used for all emulator versions and all emulator runs, with no additional randomness involved.
This would be the closest we can get to hardware without sacrificing replayability on emulators. Syncing TASes will still be somewhat difficult on hardware, but that's going to be unavoidable.
I don't get what you are implying though. Even with semi-random behavior, you can't get 100% reliable sync...
I'm saying that a RAM map should be created, using values that were observed on hardware, by a function like this. This RAM map will then be "frozen" and used for all emulator versions and all emulator runs, with no additional randomness involved.
All right. Now suppose the following:
The US electric network runs on 110 volts, and a SNES plugged into the US network gives a RAM map that looks <so>. However, the European electric network runs on 220 volts, and a SNES plugged in there gives a RAM map that looks substantially different, even though the console is otherwise identical.
Then it would make perfect sense to me that a TAS'er could choose which of the two maps to use for any particular run, in the (admittedly rare) case where this affects gameplay. The key here is that (1) this act is possible in real life, and (2) the burden is on the TAS'er to explain how it is possible. Note that "possible" does not mean "likely". If it's something as simple as "this bit is usually 1 but if you boot up, 10% of the time it's going to be 0" then that's fine; if a TASer wants to start play with some complicated program preloaded in RAM, well then he's going to have a lot of explaining to do.
We have at least one run on the site that requires you to set your Wii Username to <something> or it won't sync, and we have at least one DOS run under construction that requires you to set your system date to <something> or it won't sync either. That's the same principle as here.
The US electric network runs on 110 volts, and a SNES plugged into the US network gives a RAM map that looks <so>. However, the European electric network runs on 220 volts, and a SNES plugged in there gives a RAM map that looks substantially different, even though the console is otherwise identical.
Then it would make perfect sense to me that a TAS'er could choose which of the two maps to use for any particular run, in the (admittedly rare) case where this affects gameplay. The key here is that (1) this act is possible in real life, and (2) the burden is on the TAS'er to explain how it is possible.
He could choose between using the (E) or the (U) versions of the game. If the emulator is emulating the (U) system, it should preload the RAM with a built-in (U) RAM map. If it detects a (E) game and switches to emulating the (E) system, it should load the (E) RAM map.
Radiant wrote:
We have at least one run on the site that requires you to set your Wii Username to <something> or it won't sync, and we have at least one DOS run under construction that requires you to set your system date to <something> or it won't sync either. That's the same principle as here.
Even in a TAS you can set the name/date and reboot the system, right? The SNES for example can be power-cycled via TAS.
He could choose between using the (E) or the (U) versions of the game.
That's not what I mean. The map is not dependent on the version of the game cartridge, but on the voltage of the wall socket that you plug your console into.
Even in a TAS you can set the name/date and reboot the system, right?
He could choose between using the (E) or the (U) versions of the game.
That's not what I mean. The map is not dependent on the version of the game cartridge, but on the voltage of the wall socket that you plug your console into.
Yes, that's why I said the emulator chooses the RAM map. So for the TAS creator, the only remaining way to influence the RAM map would be by choosing what region the TAS is for.
Radiant wrote:
Even in a TAS you can set the name/date and reboot the system, right?
That is not always the case, no.
For what systems?
When you can't change that data as a player then it becomes an inherent property of the hardware itself. The community would have to decide if it uses a fixed name and date on startup, or allows the TASer to provide that data. I'm for the former option.
This would be the closest we can get to hardware without sacrificing replayability on emulators. Syncing TASes will still be somewhat difficult on hardware, but that's going to be unavoidable.
No it's not. You could use a random ram state, and then save it to the movie file.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
I think this is a perfectly acceptable thing to do, AS LONG AS the chosen state can be attained by a console power on, and as long as the console does not have a bootstrap / BIOS that pre-set some (or all) of the memory to certain values, for which case having the movie pre-set these values to something else after the bootstrap / BIOS execution should not be considered valid.
I honestly cannot see the point in all this.
If you want to run your own code in the console, then make your own ROM. If you want to modify the game's own code, then make a modified version. If you want to modify how the console works, then take the source code of the emulator and change it.
You are free to do so, but none of this has anything at all to do with speedrunning. Speedrunning is playing the game.
Joined: 5/2/2006
Posts: 1020
Location: Boulder, CO
Warp wrote:
I honestly cannot see the point in all this.
If you want to run your own code in the console, then make your own ROM. If you want to modify the game's own code, then make a modified version. If you want to modify how the console works, then take the source code of the emulator and change it.
Let me break it down then: What we want to emulate an unmodified ROM, and we want the emulator to work like a console does in real life.
The problem is, in real life, the initial state of some memory is not predictable, so the question becomes "what should its initial state be?"
"Just showing the end credits" is not in question, as there is no initial memory state that will cause that to happen.
Anyway, my vote is to just allow whatever. It would be too hard to prove that any initial state in particular is possible, so go nuts.
If you want to run your own code in the console, then make your own ROM. If you want to modify the game's own code, then make a modified version. If you want to modify how the console works, then take the source code of the emulator and change it.
And none of the three has anything to do with what is being asked here.
And none of the three has anything to do with what is being asked here.
That's not what this sounds like: "We could have an entire program sitting in unitialized memory, and through memory corruption techniques maybe we could get the game to start executing at this point and completely take over the game"
I repeat: If you want to run your own code in the console, just make your own ROM. It has absolutely nothing to do with speedrunning.
Voting yes since this can improve tasing as a whole, improve current movies ect...
Now my question is, does this mean we get a virtual extra category for every game on the site (provided it actually change something to the run...) ? or does this mean saving 15 frames on super metroid trought this technique is ok for obsoletion?
Im voting yes for this thing, but little clarification on what the changes would imply if it was adopted would be nice :p
