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.
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?
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.
The created ROM is likely too big for the default mupen64plus core (since an entire macro is injected directly into the ROM), and so I've included a .dll that adds extra RAM to m64p in the submission (should be placed in /path/to/BizHawk/dll/).
Can we see the patch? Also the documentation on the .gzm format.
extra ram: https://github.com/TASEmulators/BizHawk/compare/master...glankk:BizHawk:16mb
official documentation on macro (.gzm): https://www.practicerom.com/manual/menus/macro/index.html
The .gzm file itself is just a binary file, where:
First 4 bytes is number of inputs (or frames)
Next 4 bytes is number of RNG seeds (scene transitions)
The next 4*[number of frames] bytes are input data
The next 12*[number of rng seed] bytes are RNG seeds
The next 4 bytes is n_oca_input (usally zeroed out)
The next 4 bytes is n_oca_sync (usally zeroed out)
The next 4 bytes is n_room_load (usally zeroed out)
The next 4 bytes is number of rerecords
And the last 4 bytes is the last recorded frame
I have to say I do not understand your steps to run this on emulator especially with that github project or the instructions to open a menu in game to then run what you are calling a macro. Could you make a short video on how to make this file then run it in BizHawk?
Sorry, I thought it might not be clear as it is a little complicated. Here is a video that shows how to build gz and inject a macro.
https://www.youtube.com/watch?v=-sh3kQ3Cnqw
I will agree with other commentors that yes, this is not a vanilla OoT ROM. The gameplay is however functionally the same. The Submission notes have my view on it.