Movies are no longer directly comparable because the base system has been changed.
Ideally, the chain of emulation goes from real hardware → emulators → TAS. A TAS changing the emulated hardware goes the other way around (and those who want to verify those TASes must find ways to change real hardware before they can run them).
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.
And then taking that state and writing it to the console RAM? That might work.
RachelB wrote:
Warp wrote:
Speedrunning is playing the game.
Usually the point of speedrunning is to avoid playing as much as possible.
Finishing in the fastest way is just to rate movies against each other. They would be pretty boring without entertainment.
arukAdo wrote:
Voting yes since this can improve tasing as a whole, improve current movies etc...
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.
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.
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.
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.
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
An emulator should always emulate as accurately as possible. That means observing and emulating real-life RAM cell values. I don't think a TAS should have a say in that, especially since it's supposed to be just a list of external input states.
TASes are supposed to use the highest difficulty level. They aren't supposed to bypass that with a technicality.
In real life, achieving that particular state of RAM requires the environment (temperature, radiation, ...). A TAS is supposed to demonstrate the superior skills of an imagined "god player". If almost all that supposed god player does is waiting 100000 years for the right circumstances, it doesn't feel impressive at all.
It makes the TAS itself look weaker: it can only complete one specific version of the game, not all of them.
slamo:
If you still have the dump file, could you extract the audio to .wav or .mp3 and upload it to MediaFire/Mega/etc.? I'll try to dump it myself but it looks very complicated.
No vote. I just wasn't entertained by the fact I had to watch it slowed down just see what's going on, and for the actual video, I never played this game before, and had no clue what I was watching. Sorry about that.
There should be a rule that you can only vote if you've played the game before...
Prince of Persia:
- part 1 00:05 to 00:10
- part 1 03:05 to 03:13
- part 2 04:36 to end of level
- part 2 07:50
I don't think this is a TAS... Correct me if I'm wrong. I decided I'll use Jazz and the SkyRoads TAS because that game is famously really difficult.
Well, I'm pretty sure it's tool-assisted (savestates, probably with slowdown, but not frame-by-frame).
I just found it funny; no problem with me if it won't be used.
Happenst thou have time to find something for me? I'll look at it but much later unless I get what I requested, an actual link to a specific passage (or a couple in this case) in the run. Much appreciated in any case!
Jazz Jackrabbit (has downloadable video):
- 00:58 (faster movement)
- 04:12 up to end of level
Prince of Persia:
- part 1 00:05 to 00:10
- part 1 03:05 to 03:13
- part 2 04:36 to end of level
- part 2 07:50
