Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
Potato Stomper wrote:
So are we going to say that a nuclear bomb detonated near the NES console and by chance the radiation made all the bits change to the proper value for the credits to run?
Or that the electrons in the NES all randomly quantum tunneled so that they form a desired state?
A TAS should abuse the software, but not the hardware in my opinion.
That IS abusing the software. The software is what is reading uninitialized ram.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
creaothceann wrote:
Real time runners can't change the state of RAM at power-on to anything they like. At best they could reset the console (when they see through the game's actions that a RAM cell didn't have the desired value at power-on) until they get the values they want. Also, this only works for certain patterns; you can't get all values for all RAM cells.
Exactly. They can try again until they get the desired values. Why can't we do the same thing, just using tas tools?
*There's the idea that you could take a TAS of one of the launch titles of a system (e.g. SMW or SM64), give it Data, who goes back in time to the launch event and completes the game in front of the audience. That wouldn't be possible with a TAS that requires specific RAM state.
That doesn't make the tas unauthentic. Every single game that reads uninitialized ram and does something that could affect sync with it will desync when played back on console. There's nothing you can do about that. The game will run different every single time you start it.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
Okay, I'm curious, are there any games that would be faster to run in real time, than to tas using warp's rules (no initial ram state manipulation, and no resetting, are two he's said in this thread)?
I don't understand the desire to limit tases from doing things that could just as well be done by real time runners. I feel like that defeats the entire purpose of a tas.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
For what it's worth, i also thought Bisqwit's post was a bit inappropriate for this topic. The links should not have been included imo, and it may have been wise to not go into so much detail about who they are.
But then, i also think there was no need to call him out for it the way you did, warp. It seems to me that it would have made more sense to send a pm saying you didn't think it belonged, and asked him to edit it.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
creaothceann wrote:
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.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
And we have some precedence for this. DS movies specify RTC. In real world terms, that means that a DS must be powered up at EXACT a particular point in time for the TAS to sync. To DSbot my NSMB tas for example, you would also need a time machine (or set your internal clock to the correct time, but that's a less fun example). These TASes are considered valid, because this is a valid state for a DS to be in on power-on. Yet, this is information that could also be attained at a point in the timeline beyond 0, therefore a movie could start from a savestate and achieve the same results.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
Derakon wrote:
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?
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
This game has a lot of text too, and it would be a lot harder for most of our viewers to follow along if they don't understand Japanese.
I've always found this argument really dubious after noticing the huge disparity in view counts of tases on youtube vs nico. It seems to me that the Japanese are the biggest audience. So if that is your concern, the Japanese version should be preferred.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
- Do I still need the two DSP files?
For tasing, yes. There are open source replacement files that can be used, but the timing is not the same as of the official dsp roms, so don't use those.
You may be able to use HLE in new revisions (anything after 3.5-80 or something like that, but only with games that use the AX ucode (that would be roughly 99.9% of them. Some of the first party nintendo games, particular zeldas other than SS, luigi's mansion, and others do not), which should be perfect/nearly perfect. I know the netplayers have been using HLE for a while now without deysncs, but i don't think anyone has really tested it with tasing, so i can't promise anything, but i would expect it to work okay.
- When I stop emulation, it would ask me if I really want to. Can that popup be turned off?
Yes, in interface settings.
- In contrast to the previous Dolphin versions, savestates, savegames, dumped videos and audio, etc. don't get saved in a subdirectory of the Dolphin folder anymore, but they get saved under
user/documents/Dolphin Emulator/...
Is there a way to determine what directory it uses because this creates some chaos for me. I want the 4.0 related files to be in the 4.0 folder and not somewhere completely different...
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
Something along the lines of hourglass might be possible.
It'd probably be easier, and run faster to just write a ps3 emulator than trying to get ps3 games running in linux on a ps3, honestly.
Experienced Forum User, Published Author, Player
(127)
Joined: 12/3/2011
Posts: 1579
Nercroposting can create a lot of confusion when people see old threads, not realizing they're old, and start responding to things that are no longer relevant.
