Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
fsvgm777 wrote:
Yeah, we always go with what's given on the site, and the total run time used on the site is the one if run on BizHawk. I can add a note in the description that the TAS timing on console is 3:10:06.195. The RTA timing on console seems to be 3:03:54.857, per SRC timing (gaining movement of Link -> first frame of final blow cutscene)
Oh sorry, I just straight up thought the 3:07:26 was the timing for the encode with final slash, cause i looked at it briefly and saw ganon/zelda shenanigans when hovering over 3:07:00 on the video. Tricked myself.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
I want to extend a great thank you to everyone at TASVideos that worked on having this movie be officially published. It's been underway a long time and I did not have much hope originally, but this makes me excited to submit other/future TASes. It was great working with you.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
I'd like to add a little note on timing:
The current timing in the encode is ending on last slash, this is not actually where the macro ends as some of the credits need to be "mashed" through. The last input falls on the last textbox of Zelda in the Sky before she starts playing the Ocarina (at approximately 3:10:08 in the encode), and the textbox lingers for 2 frames (at 60fps) after the input is given.
This would give a time approximately 2:40 slower than the current published time. On emulator (BizHawk) the end would actually be at around 3:07:2x (the submitted encode was recorded on BizHawk, but the published encode is recorded on a real N64, leading to the disconnect), as there seems to be some disconnect between how a real console lags/loads and how BizHawk does so (leading to BizHawk having less lag overall)
For what it is worth RTA now times from gaining movement of Link until last slash, which would make this encode approximately 3:04:xx with RTA timing.
I'll leave it up to TASVideos to decide what timing is the most accurate to use for this.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
fsvgm777 wrote:
PancakeTurtle wrote:
feos wrote:
SO, FINALLY, I captured video is this run was replaying in ares, and since the frame of reset when starting the macro, to the last emulated frame of it (thankfully it was also the last frame of input, no blank frames at the end), I'm getting the overall duration of 3:07:26.833 in ares frames. 3:07:26.317 if I count from the first non-lag frame which is when the macro counts its first frame.
Very close to the timing for the original recording I did. On a real N64 with TAS timing the timing seems to be 3h10m07s, so still significantly more laggy than ares.
That's...interesting. Using the practice timer present in GZ, I get a total time of 3:14:29.0 on TAS timing on my NTSC-J N64. Although I'm not sure how reliable it is in the first place.
Although I had to "manually" time it, since it only starts when pressing an input combo (I set it to C-Down for convenience).
EDIT: For the record by the way, I am using a Summercart64.
I can't speak for the practice timer in GZ since I don't use it, but it seems like it's an approximation and not necessarily accurate, since the hardware variance should not be 4 minutes. Timing it again using real time (with livesplit or something) should hopefully give something very close to 3h10m07s, otherwise we will have to investigate zfg1 for having overclocked his n64 :p
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
feos wrote:
SO, FINALLY, I captured video is this run was replaying in ares, and since the frame of reset when starting the macro, to the last emulated frame of it (thankfully it was also the last frame of input, no blank frames at the end), I'm getting the overall duration of 3:07:26.833 in ares frames. 3:07:26.317 if I count from the first non-lag frame which is when the macro counts its first frame.
Very close to the timing for the original recording I did. On a real N64 with TAS timing the timing seems to be 3h10m07s, so still significantly more laggy than ares.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
feos wrote:
PancakeTurtle wrote:
EDIT: Nevermind, the desync is most definitely because File 1 already exists, please delete it before playing the macro.
How? I've never played this game, I don't know Japanese, and when I press things randomly different GZ operations happen. Removing the saveram file from host didn't help.
EDIT:
The thing that made it work past that desync point was starting the macro replay while at the title screen or at save file selection.
I don't know how the file was there already, maybe you played it back for a bit once by accident and wanted to retry without clearing saveram? In the video you posted you're already desynced after file select, before the first textbox even comes on screen, since the inputs to make the filename are used for loading the file instead. It was lucky (or unlucky) it managed to sync back up due to the timing of textboxes being delayed and allowing Link to move seemingly normal for a while.
Made a fixed version of that PR https://github.com/TASEmulators/BizHawk/pull/4506 and I'm getting consistent deyncs:
Link to video
For the ROM, I used upstream GZ GUI patcher and applied it to the ROM used in this submission. Loaded that rom along with the SD card image created by Dolphin with just the macro present, and ran the macro by importing it from GZ menu.
Please check this for me: under the "macro" menu there is a "settings" submenu, please check that "wii vc camera" is unchecked. Also make sure that "ignore state's rng" setting is unchecked if you are using the upstream, it might have an influence?
If both of the above is unchecked and the macro still desyncs please go to the "watches" menu, and add the watch 80105440 of type x32, you can click the anchor to have it always display, as I'd like to see when the desync is happening then.
EDIT: Nevermind, the desync is most definitely because File 1 already exists, please delete it before playing the macro.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
feos wrote:
Is there no way to replay this tas on emulator using upstream GZ?
Not unless the emulator supports SD cards (for example via SummerCart64 interface, like Parallel Launcher). The upstream GZ does not have the functions needed for injection of the macro directly to the rom.
feos wrote:
I built the patched ROM exactly like you did in the video, but it gives black screen in any version of bizhawk, with both ares and with your patched m64p. Its size is different from what it has in your video:
Sorry about that it seems that recent additions to GZ has caused the file to not open on BizHawk, usually this is memory related but I have not tested. I have created a branch that should be a preservation of the version I used for getting the 100% TAS running on BizHawk: https://github.com/MrPancakeTurtle/gz/tree/100%25tas
When using this branch I can run it on BizHawk and I am getting:
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
Alyosha wrote:
Two clock sources could potentially be fixed with a hardware mod
How many parts of a Nintendo 64 can you replace while still saying it is in fact an original official Nintendo 64. Where is that line drawn? Can you replace all the parts?
Alyosha wrote:
Can you go into some more details of non-determinism?
More seriously, I am unfortunately not the correct person for this. You'd need some real N64 hardware nerds for that (I learned about the oscillators from thar0 originally).
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
Bigbass wrote:
PancakeTurtle wrote:
Bigbass wrote:
AFAIK, the original OoT could be TASed if someone chose to do so. (...) (Of course, as you noted, sometimes games cannot operate in the original environment, especially in a TASing context. However I don't believe that's the case here.)
This is absolutely the case here: N64 Zeldas cannot ever hope to play back inputs on real hardware, even if you had an emulator that met "perfect" accuracy standards.
I wasn't referring to replaying TASes on hardware. I was talking about whether the game actually worked or not. As in, there are many SM64 rom hacks for example that do not function at all on original hardware.
Sure, but Ocarina of Time cannot operate in the original environment (N64) in a TASing context.
sometimes games cannot operate in the original environment, especially in a TASing context
By extension a TASing environment on emulator is therefore not representative of the original console, which means that none of the current movies posted under this game are any more accurate than a GZ macro.
There is no "purity" or "perfection" in the TASes for this game, they are inherently flawed, as both emulators and GZ "hack" fixes to make the game deterministic.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
Bigbass wrote:
AFAIK, the original OoT could be TASed if someone chose to do so. (...) (Of course, as you noted, sometimes games cannot operate in the original environment, especially in a TASing context. However I don't believe that's the case here.)
This is absolutely the case here: N64 Zeldas cannot ever hope to play back inputs on real hardware, even if you had an emulator that met "perfect" accuracy standards. There's fundamentally non-deterministic elements* involved that make no two playbacks the same even on real hardware. SM64 only gets away with it due to the game's logic not being sensitive to any hardware counters or the presence of lag. Almost all N64 games are in the other category, they are sensitive to these things and this excludes them from ever playing back on an unmodified cartridge or console, irrespective of how they were recorded.
*For example lag on Nintendo 64 is strongly non-deterministic, we know of at least one reason why this is: The N64 has a shared memory architecture and two crystal oscillators, one for the system clock and one for the video clock. The video clock drives RAM refreshes on HSYNC, rendering the entire system sensitive to the relative phase of the two oscillators.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
InputEvelution wrote:
Inaccurate emulation that is designed to be deterministic isn't necessarily an obvious choice over real hardware that is forced to be deterministic.
FWIW the prevailing opinion within the OoT speedrunning community is real hardware being the better option, as emulators are known to be wildly inaccurate for OoT specifically. In fact emulator is banned for all times faster than 110% of the current world record for speedruns (i.e. if record is 1h then runs on emulator faster than 1h06m are banned).
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
feos wrote:
If I were to run this movie on console, how exactly do I know which frame is the last frame of inputs?
Leaving on the setting "Settings->Pause Display" in GZ displays the GZ framecounter in top left when a macro is loaded (0/220626 at the beginning 220626/220626 at the end, when 220626/220626 is displayed the run is over, the macro has no further inputs).
Leaving on the setting "Settings->Input Display" in GZ displays the inputs GZ are playing back, or the inputs you are inputting yourself if not playing a macro.
Neither option adds any additional lag frames over the entire run, if that is a concern.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
feos wrote:
Current frame number and inputs.
I still don't understand what you are asking?
BizHawk and GZ can both count frames (but GZ frame count isn't satisfactory for you) and view inputs. It is fairly trivial to see when the last input is and then see how many frames that is in on BizHawk or see when that is in real time on GZ?
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
feos wrote:
How do you detect that frame of the last input? Also I'm noticing in the code there's a way to run a timer, is it used to measure movie duration by the community?
By looking at what frame has the last input? I am not sure what you are trying to fish for?
Timing for GZ movies is simply the real time it takes from the start to the end of the movie. I cannot speak for the accuracy of the GZ timer.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
feos wrote:
PancakeTurtle wrote:
feos wrote:
At which point exactly? Is Bizhawk used every time by your community for this?
Realistically BizHawk is not used for GZ. Recording on real hardware is preferred as this gives a far more accurate time than any emulator, in fact this run is about 2.5 minutes slower on real hardware (3h10m07s). This means 1.0 and 1.1 version will be recorded on a real N64 usually and 1.2 will be recorded on Wii VC. The encode of this run was recorded on BizHawk, but the actual commentated version published on ZFGs channel is recorded on a real N64 and would be the run the community would refer to for timing. For the timing for TASvideos I used the "approved emulators" BizHawk and the framecount from first reset to last input.
For reference I recently completed 2 All Dungeons TASes, for two different versions of the game ( https://youtu.be/FAnn-S8Cq8I ). They are both recorded on original hardware. If I were to record the N64 version on BizHawk it would give a timesave of around 35 seconds, seemingly due to BizHawk not accurately emulating all the lag, which would have given the N64 an unfair advantage it does not have on real console.
Have you tried the ares core in 2.10? Mupen64plus is indeed very inaccurate.
"real hardware is preferred as this gives a far more accurate time than any emulator" still applies. There is no 100% accurate N64 emulator currently. The All Dungeons timing I was referring to was recorded on 2.9.1 ares core.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
feos wrote:
At which point exactly? Is Bizhawk used every time by your community for this?
Realistically BizHawk is not used for GZ. Recording on real hardware is preferred as this gives a far more accurate time than any emulator, in fact this run is about 2.5 minutes slower on real hardware (3h10m07s). This means 1.0 and 1.1 version will be recorded on a real N64 usually and 1.2 will be recorded on Wii VC. The encode of this run was recorded on BizHawk, but the actual commentated version published on ZFGs channel is recorded on a real N64 and would be the run the community would refer to for timing. For the timing for TASvideos I used the "approved emulators" BizHawk and the framecount from first reset to last input.
For reference I recently completed 2 All Dungeons TASes, for two different versions of the game ( https://youtu.be/FAnn-S8Cq8I ). They are both recorded on original hardware. If I were to record the N64 version on BizHawk it would give a timesave of around 35 seconds, seemingly due to BizHawk not accurately emulating all the lag, which would have given the N64 an unfair advantage it does not have on real console.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
CasualPokePlayer wrote:
As the format has a variable input rate, and seemingly no way to know when the rate switches statically, inputs cannot be used to derive the movie time. Therefore, GZ cannot become an "accepted emulator" like Doom replays. The format would need to be changed to add in movie time (directly or indirectly) in order to have GZ to become an "accepted emulator"
Makes sense. A format change is probably not out of the question, but that's not up to me.
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
CasualPokePlayer wrote:
then it needs to fall under normal publication rules in order to be published. As far as the goal goes, it seems perfectly fine within Standard or Alt (unsure exactly which this fits in, possibly Alt if there are major skip glitches within the TAS yet SRM is avoided; if SRM is the only possible major skip glitch then the goal could be accepted into Standard). For technical requirements, this means being able to replay the TAS, on an official release of an approved emulator (although console-only playback being accepted could come under a rules change; in that case the .gzm here should be the one parsed, not a bk2).
It (understandably) wont fall under normal publication rules for emulator. If .gzm (and console only) becomes an accepted format it could fall under Standard as the only useful glitch not used (at the time of creation) is SRM.
CasualPokePlayer wrote:
I'm also skeptical of this kind of change; how does doubling the RAM work, if the problem was the ROM was too large for the emulator?
However, mupen is not the only N64 core on BizHawk, another option is the Ares64 core. Could you try playing back the "large" ROM on that core in 2.10 rc2?
The Macro is stored in RAM, so it is not the ROM that is too big, but that when it loads it puts the macro into RAM. I was unclear in my explanation. In fact macro injection is memory inefficent, so this is not an issue on a real N64, but this macro is close to the limit the N64 can play without running out of memory too.
feos wrote:
Is there a way to calculate accurate duration of the entire movie in seconds, from just the gzm file itself?
I do not actually know, I've asked the main developer of GZ, so I'll return with an answer when I have it :)
feos wrote:
If we treat this as a per-game TAS environment and parse the actual input file, it may not have to work on approved TAS emulators, because it's not a movie made on/for them. But figuring out the tech aspect is part of how we want to support it properly, instead of it being a bunch of black box files that we can't even host currently.
Basically having GZ as an "Approved Emulator" for Ocarina of Time?
Experienced Forum User, Published Author, Player
(39)
Joined: 9/26/2023
Posts: 27
PancakeTurtle wrote:
First 4 bytes is number of inputs (or frames)
I should specify, this is the number of actual visual frames, and not input frames. This means instead of constant 60 FPS it is measuring 20 FPS at normal gameplay, 30 FPS at pausing, and 60 FPS at the title screen (given the n64 actually lags so much it's more like 30 frames per second on title screen).
Example: The 100% TAS .gzm has 220626 inputs (or frames), but if it was the input frames it would instead be 674650. It is evident that 220626*3 is a little less than 674650, because some of the frames in the 220626 count is recorded at 30FPS or 60FPS.
