I think it uses the PAL version because the author seems to be from a German-speaking country (at least based on the comments). I looked up the SDA record for a frigate escape on the PAL version (0:04:25.40 remaining); that TAS is 4.1 seconds faster over that section, at 0:04:29.50 remaining. So at least it isn't unoptimized enough to lose out to a realtime runner, although I'm not sure how optimised the PAL frigate escape is on SDA (the author seemed to think 0:04:26 remaining was possible but not more, so unless a new realtime trick is found and someone uses it, I guess times like that are definitely in the TAS-only range).
Still, the TAS didn't look too visually impressive, especially the movements of the Morph Ball near the start (which didn't seem to be using the shortest line). Morph Balling everywhere is the standard non-TAS route, but TASing can often make other routes possible...
I'm a friend of this MrSpEeDrUn, he used PAL because he thought somebody will do better than him with NTSC, so he has still the PAL record =)
I could convince him to use NTSC, he wants to be at the Parasite Queen until Friday =)
I assume he's talking about the loading that occurs while you're waiting for a door to open, which certainly would include the timer. If normally you spend 7-8 seconds waiting for doors, but Dolphin loads instantly, then that's 7-8 seconds saved.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I noticed this also. Resident Evil 4 cuts off at least 1 second per load screen, and 1/2 a second every pause screen, and load times are included in the game timer. This should be obvious in Frigate since we can see the timer at the bottom of the screen. With the number of required doors for a TAS of Metroid Prime, I bet we can save at least 2 minutes just because of "better hardware." If the TASer is saving 7-8 seconds alone in the Frigate due to load times, imagine how much the rest of the run would benefit.
But this is interesting, and potentially scary.
Does the reduced loading times just means that the emulator has better hardware / is bettering upon the original hardware, or is it simply because there is a load of stuff that it doesn't emulate properly?
The game generally counts loading of a room as play time. In the Metroid Prime 3 speedrun in SDA, the runner regularly went into Hypermode during loading times in order to survive being shot at while waiting for a room to load.
There is a major problem when trying to TAS Metroid Prime though.
When you load a state, the is a bug, something, that deletes all the input of the frame before the load state.
Because of that bug, I can't really appreciate TASing the game. But if it ever gets corrected, I will sure TAS the game.
With the number of required doors for a TAS of Metroid Prime, I bet we can save at least 2 minutes just because of "better hardware." If the TASer is saving 7-8 seconds alone in the Frigate due to load times, imagine how much the rest of the run would benefit.
Let's call things by their names here. The emulator doesn't take into account data loading rate when it should, demonstrating a drastic difference. It should emulate the original hardware, not better hardware.
This is improper emulation, nothing else, and all improvements achieved through it are thus irrelevant and in fact counterproductive. We don't, and we shouldn't use emulation inaccuracies to our advantage because that just defeats the purpose.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
This is improper emulation, nothing else, and all improvements achieved through it are thus irrelevant and in fact counterproductive. We don't, and we shouldn't use emulation inaccuracies to our advantage because that just defeats the purpose.
I wouldn't say it is inaccurate emulation. We are loading from harddrive space instead of a disk. On the XBOX360 you can install games to your harddrive so you don't have to tolerate as long of load times. But I do agree that this gives TAS an unfair advantage.
I would imagine emulating load times would be very difficult. However, if we were to use a disc instead of the ISO, then load times may be more accurate, since your computer would have to read the disc, but still this would be improved over the console if your disk drive was faster than the gamecube drive. TASvideos probably wouldn't accept from disk TASes anyway.[/quote]
I wouldn't say it is inaccurate emulation. We are loading from harddrive space instead of a disk.
You're contradicting yourself here. :) Yes, we're loading games from a harddrive, a device the Gamecube doesn't have and can't have by design. Hence, improper emulation.
SoulCal wrote:
I would imagine emulating load times would be very difficult.
Well, not that difficult. Gamecube's discs' capacity (1.4 GB), spinning mode (constant angular velocity), and hence transfer rate (2 to 3.1 MB/s), are known. The exact transfer rate for a given chunk of data can be represented by an approximated function, and hence emulated in software, although I admit not everybody will bother when you can just use average/maximum transfer rate as the base. Another number that will have to be added to every instance of loading is access time, which is 128 ms on average in this case, and is the only thing that isn't worth realistically emulating, since the precise value is as good as random within certain bounds.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 4/21/2004
Posts: 3517
Location: Stockholm, Sweden
I spoke briefly with a developer from team dolphin and this is what he had to say about the matter:
<AngerFist> random question to anyone who knows: it appears that dolphin doesn't emulate "loading" time. this is apparent in games like metroid prime and resident evil 4. can someone confirm this?
<no_cluez> AngerFist: yeah.
<no_cluez> AngerFist: there's that "speedup disc transfer " setting in the iso properties, it kinda emulates it... but not accurately
<AngerFist> okay
<AngerFist> do you reckon it's an easy fix to emulate the load times?
<no_cluez> no
Edit: More info below
<no_cluez> sure we know the ideal transfer rate... but that doesnt equal the actual read data
<shuffle2> the problem is that audio transfers compete with data transfers
<AngerFist> what do you mean by compete
<shuffle2> the drive buffers audio and other data seperately, and gives preference to audio data
<shuffle2> so if you have a game streaming a lot of audio
<shuffle2> other data rate will go down
Edit 2:
<AngerFist> hmm ok
<AngerFist> now i can begin to understand why no_cluez said it would not be easy fixing this.
<no_cluez> ;)
<SS> There is a game with a loading bar which normally loads slowly, when I enable speed up disc transfer, the bar is done in less than a second.
<SS> Makes sense.
<shuffle2> it's not impossible, just requires someone to cook up a test for real hw :p
<AngerFist> i *might* find someone to do that.
<AngerFist> if i could find someone, would you be willing to investigate shuffle&no_cluez?
<shuffle2> sure, no promises since i am teh busy recently
<shuffle2> i hear no_cluez has tons of free time and doesn't know what to do with it
<no_cluez> AngerFist: sure, if I actually had a clue.. :P
<no_cluez> shuffle2: actually I only have 3 weeks of free time left :/
<shuffle2> well that is better than 0!
So if anyone could help them with what shuffle2 asked for, we could hopefully a.s.a.p. put an end to the no loading time error.
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
<mugg> is it dolphin not emulating the load times or the avi only having 1~10 frames (when it should have 400 frames)?
<mugg> dolphin emulates ssbm's and tony hawk ug's load times, but only records 1 frame for it in avi
Naw, this is different. What they're talking about happens when the game dynamically loads the next room while you're messing around in the current, that is, without interrupting the gameplay. But it does show a difference in time Samus would wait for a door to open.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
But the MAIN problem toward TASing the game is not about the loading time =(. I could TAS the game without this problem solved, and I would rather TAS it with seconds cut off, since there is no read-only mode for dolphin yet v_v.
The main problem is when loading a state, the frame right before it has no recorded input, thus making a good TAS impossible.
And another thing to consider about the TASers of Dolphin, is that we don't have read-only mode. If we want to see if a part of a TAS synched, we need to start the TAS all over EVERYTIME.
I know you guys want to see an accurate TAS of the game, but if you really want to make the game longer for me as a first fix, you're doing it wrong =(.
And another thing to consider about the TASer of Dolphin, is that we don't have read-only mode. If we want to see if a part of a TAS synched, we need to start the TAS all over EVERYTIME.
The read-only mode does work...partially. Every loadstate has an associated dtm file with it, and only that state can continue playing the dtm from that loadstate location. Let's say I created a dtm and I play it back to check for desyncs. If I savestate1 during playback, read only mode will work when you shut down Dolphin, but only if you DON'T save the dtm. Once you save the dtm file (either by renaming or overwriting it), that specific savestate1 you created will not allow for read-only mode to work with the new dtm. However, this still requires that you watch an entire dtm file anyway, so this isn't too beneficial to TASers except for things like recording the avi or for things that don't require ridiculous amounts of luck manipulation.
My guess is that the programmers made it so a dtm file has specific savestates associated with it. Although you may have two savestates that are identical (such as taken on the same frame number, but created in different ways) only one will allow for read-only mode. They probably did this to PREVENT desyncs, so you don't load a state that isn't even part of the TAS you are creating. If they could remove this link between dtms and savestates then it may work.
So, apparently Dolphin *does* have RAM watch, but it's only accessible in debug mode. Anyways, through some effort combining cheat search with RAM watch, I can now bring you the following.
8046B9BC - X position
8046B9CC - Y position
8046B9DC - Z position
8046BAB4 - X velocity
8046BAB8 - Y velocity
8046BABC - Z velocity
The X and Y position addresses may not be the true addresses, as they don't seem to respond to changing their values like the others do. However, they should still be usable.
Some other things
--Samus is about 2 units tall
--Speeds are measured in units/second
--The acceleration due to gravity is -35 units/second^2
--There is no terminal velocity
--When falling, the Morph Ball bounces off the ground with 1/5 of its impace velocity.
looks like a good start. do you think you could find the in-game timer? that would help a lot, considering there are a lot of things that need to be tested.