Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
I would still prefer if one of the authors themselves submitted the movie (as BK2), but other than that I'm not asking for anything special. No writing is needed, the submission text can be all filler for all I care.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
This is silly.
First of all, BizHawk's N64 backend is Mupen - the latest version of libmupen64plus. Apparently mupen64-rr is over a decade old, so it would make sense for there to be divergences, but a lot should be directly comparable.
Also - if the run syncs but ends up with a different time, I'm guessing (could be wrong) that the divergence is primarily caused by video lag - that is, on some frames, the RSP/RDP is taking more than the allotted time to render the scene, and the specific amount of time differs between tests on Mupen, BizHawk, and real N64 (because neither version of mupen properly emulates the RSP/RDP's cycle timing). This raises two questions:
1. Mupen, both the old and new version, supports multiple video and RSP plugins. Was this comparison by sonicpacker:
- Final Mupen time (4'21"67) is closer to the final console time (4'22"6x) than BizHawk (4'24"28)
performed with the same plugins and plugin settings on both emulators? Has anyone compared the results with different settings on the same emulator?
2. Can the run be improved to avoid lag in the first place, e.g. by using fixed camera mode? This might make it less entertaining, but should save time, including on console - as well as reduce divergence between emulators.
Alternately, if the lag is caused by something other than video, it would be best to figure out what. ROM timing? CPU emulation? (There are also multiple CPU backend settings.)
Here, this could be the submission text. /s
It's a drawing of Mario overflow jumping into a PU below him!
DeRockProject: the Life-changing Project
(TAS is perfection in this imperfect world. TAS is the answer to the longest math problems we have, called video games. TAS perfects worlds. TAS is god. TAS is the future. TAS needs us. Let it govern us. All hail TAS.)
Sorry if it sounds very naive, since I don't know about Mupen coding, but how difficult/tricky/idk would it be to rewrite/fix the AVI writer in it? I know it doesn't fix the desync issues in certain games apparently, but (maybe) encoding runs would be less annoying?
2. Can the run be improved to avoid lag in the first place, e.g. by using fixed camera mode? This might make it less entertaining, but should save time, including on console - as well as reduce divergence between emulators.
Run was already prepared to avoid as much lag as possible, including on lag that would just affect on console and not on emulator (both mupen and bizhawk).
comex wrote:
First of all, BizHawk's N64 backend is Mupen - the latest version of libmupen64plus. Apparently mupen64-rr is over a decade old, so it would make sense for there to be divergences, but a lot should be directly comparable.
Also - if the run syncs but ends up with a different time, I'm guessing (could be wrong) that the divergence is primarily caused by video lag - that is, on some frames, the RSP/RDP is taking more than the allotted time to render the scene, and the specific amount of time differs between tests on Mupen, BizHawk, and real N64 (because neither version of mupen properly emulates the RSP/RDP's cycle timing).
I honestly never checked why Bizhawk is slower, but it seems to be mostly at the intro (power up). Then they seem to run at the same speed (Bizhawk's core is Mupen after all, as you said).
Mothrayas wrote:
adelikat proposed an alternative compromise: the movie is still submitted as a BK2 file, but the displayed time will be changed to reflect that of the equivalent M64 file.
Would this work for you? This would solve the SM64 community's gripe with the BK2 reporting an off time, while publishers can still encode and publish in BizHawk.
I'll agree with whatever Plush says, since he's the one who worked on the improvement.
As for my personal opinion, I agree with what adelikat said time ago, both emulators are currently inaccurate. Just because Mupen gets closer to console's time doesn't mean it's more accurate. However I can understand the SM64 TAS community concern here (including me), which is having an improvement of 2 frames that'd lead into a final time that is 2 seconds slower, and even slower than console just doesn't look nice. So in my opinion submitting as BK2 and keeping M64 timing would be a fair solution I guess.
Finally, from what I've checked so far, console runs games a bit slower (59.8xFPS vs 60FPS), but loading times are faster (This applies to both Mupen and Bizhawk). This makes console almost as fast as Mupen on this category, but much slower (~1 min) on 120 star, since there aren't that many loading times there.
Joined: 6/23/2015
Posts: 22
Location: United States
I think it's kind of weird that console timing isn't in the conversation for being the standard. Like, it doesn't get any more accurate than that. I understand there are issues with determining the start point, but that seems minor compared to the inaccuracies of RDP emulation.
Like mkdasher said, the 1 Key TAS was optimized for console, not any particular emulator. A notable example was BitFS, which didn't lag at all (IIRC) on Mupen but had a lot of lag on console, particularly when Mario was around the elevator. We had to scrap a really cool POV where we got the camera stuck in the elevator so you could see Mario's entire BLJ, because it introduced additional lag. The movement was redone several times, and the movement + camera you see in the run yielded the least lag on console. I think DDD fixed cam also reduced lag.
Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
Tyler Kehne wrote:
I think it's kind of weird that console timing isn't in the conversation for being the standard. Like, it doesn't get any more accurate than that. I understand there are issues with determining the start point, but that seems minor compared to the inaccuracies of RDP emulation.
I would be fine with this, but this would still have the problem that the time would appear slower than the previous publication, which some may still find to be a problem. M64 timing wouldn't be controversial in this aspect.
By the way, since you and mkdasher have involved yourself into the discussion now, do you guys (being coauthors of the new run) have any interest in converting and submitting the new run?
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
I think it's kind of weird that console timing isn't in the conversation for being the standard. Like, it doesn't get any more accurate than that. I understand there are issues with determining the start point, but that seems minor compared to the inaccuracies of RDP emulation.
Like mkdasher said, the 1 Key TAS was optimized for console, not any particular emulator. A notable example was BitFS, which didn't lag at all (IIRC) on Mupen but had a lot of lag on console, particularly when Mario was around the elevator. We had to scrap a really cool POV where we got the camera stuck in the elevator so you could see Mario's entire BLJ, because it introduced additional lag. The movement was redone several times, and the movement + camera you see in the run yielded the least lag on console. I think DDD fixed cam also reduced lag.
Console timing would be what I'd go for but I already assumed TASVideos Staff wouldn't accept it LOL
Console timing sounds like the best way to go. We shouldn't care about having a slower time than the previous publication, that happens all the time on this site.
Current project: Gex 3 any%
Paused: Gex 64 any%
There are no N64 emulators. Just SM64 emulators with hacky support for all the other games.
On the other hand, Mupen has plenty of encodingissues which makes them a very large pain to publish.
I looked at some of those encoding issues:
"Consistency is optional: Playbacks fail to sync or sync differently on different playthroughs for no apparent reason." Mupen basically never desyncs like that. It only desyncs if you load state or save state or something stupid on the first frame of the TAS.
"fails if monitor goes into powersaving mode" this only happens if aero is turned on. Just turn it off.
"captures parts of windows and menus in front of the capture window" that's annoying but can be avoided by not putting anything in front of the Mupen window.
"no 2GB split" There is an AVI-splitting version of Mupen. It Only splits 26 times (which is annoying), but it works.
You forgot other problems, like audio dropouts on longer captures, crashes with capture with 2GB split version, audio channels swapped, limited files outputed by 2 GB split before Mupen crashes due to running out of letters (it splits by adding a letter to the end of the filename, guess what happens when all 26 letters are used... yes, the capture is THAT bad) .
jlun2's suggestion of rewriting the capture part of Mupen is a sound idea, but of course, we need someone to actually do that. It is less likely for someone to work on code that will be obsoleted soon anyway...
Mupen basically never desyncs like that. It only desyncs if you load state or save state or something stupid on the first frame of the TAS.
Bullshit. I've had multiple "who knows what happened" desyncs encoding Mupen.
Ethan White wrote:
this only happens if aero is turned on. Just turn it off.
Bullshit. I've had it happen on Windows 7 with no aero. (This may be GPU plugin specific).
Ethan White wrote:
that's annoying but can be avoided by not putting anything in front of the Mupen window.
So my computer is entirely unusable for the length of the capture job, cool.
Ethan White wrote:
There is an AVI-splitting version of Mupen. It Only splits 26 times (which is annoying), but it works.
Let me guess, it's available as binary only on some dude's geocities website? I like that though, it shows the utter incompetence of people who decided to modify Mupen; you know you have a splitting problem, so you make a splitter... and you give it a limit of 26 splits. Heh.
I'd argue that because Super Mario 64 runs can be synched between emulators, and between emulator and console, via automatic lag compensation on polling, that it really doesn't matter what emulator is used; after all, all you're submitting is the input file. Come up with an emulator-agnostic format for it if you need to, to make it really clear that the run isn't attached to any given emulator. There are games where the emulators act differently from each other in terms of sync-stability, and therefore someone has to make a decision about which emulator each run is on, but IIRC that isn't the case here.
The actual time should be determined via the most accurate available method of replaying the run (which in the case of Super Mario 64 is TASbot, because none of the existing emulators handle lag correctly); this goes for both the displayed time, and for determining whether a change is actually an improvement. Producing the encode is up to the encoders. (For what it's worth, I would not object at all to a rule that states that runs submitted on Mupen can be encoded on Bizhawk.)
I'd argue that because Super Mario 64 runs can be synched between emulators, and between emulator and console, via automatic lag compensation on polling, that it really doesn't matter what emulator is used; after all, all you're submitting is the input file. Come up with an emulator-agnostic format for it if you need to, to make it really clear that the run isn't attached to any given emulator. There are games where the emulators act differently from each other in terms of sync-stability, and therefore someone has to make a decision about which emulator each run is on, but IIRC that isn't the case here.
The actual time should be determined via the most accurate available method of replaying the run (which in the case of Super Mario 64 is TASbot, because none of the existing emulators handle lag correctly); this goes for both the displayed time, and for determining whether a change is actually an improvement. Producing the encode is up to the encoders. (For what it's worth, I would not object at all to a rule that states that runs submitted on Mupen can be encoded on Bizhawk.)
This is my view too. Everyone gets what they want - encoders can use Bizhawk, TASers can use Mupen, record keepers can use console timing.
The actual time should be determined via the most accurate available method of replaying the run
I've been considering this one for a while for other non-N64 consoles. The official timing should be, at a minimum, an output from the emulator that's read after the run is emulated. This handles VFR consoles well, like the NES; since turning rendering off and on can change the skipped dot pattern, you don't know exactly how many cycles a run took until the emulator has played it back.
Another example is the GameBoy, where we regrettably use a method of input timing that makes it much more difficult for TASers, in order to get more accurate timing -- but that's simply because the timing that TASVideos uses is coming from the wrong place altogether.
I'd argue that because Super Mario 64 runs can be synched between emulators, and between emulator and console, via automatic lag compensation on polling, that it really doesn't matter what emulator is used; after all, all you're submitting is the input file. Come up with an emulator-agnostic format for it if you need to, to make it really clear that the run isn't attached to any given emulator. There are games where the emulators act differently from each other in terms of sync-stability, and therefore someone has to make a decision about which emulator each run is on, but IIRC that isn't the case here.
The actual time should be determined via the most accurate available method of replaying the run (which in the case of Super Mario 64 is TASbot, because none of the existing emulators handle lag correctly); this goes for both the displayed time, and for determining whether a change is actually an improvement. Producing the encode is up to the encoders. (For what it's worth, I would not object at all to a rule that states that runs submitted on Mupen can be encoded on Bizhawk.)
This is my view too. Everyone gets what they want - encoders can use Bizhawk, TASers can use Mupen, record keepers can use console timing.
This is the solution. Publish the improved run. Lets all move on.
http://tasvideos.org/userfiles/info/40608078650579692
Here is a converson from Mupen to BizHawk for this run. I didn't see that exact plug in settings to convert with so I just used the defaults.
(I'll even submit it if you want, since it's been like a week already might as well wrap this up)
Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
Spikestuff told me that mkdasher was going to convert/submit it, although it's been a week since then.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Can someone provide me memory addresses of the player and camera struct (positions, speed, acceleration, etc.)?
The ones I found have only basic stuff.
I tested my input script and the angles seem very unprecise. In the script are many more things wrong, don't use it.
See here: https://youtu.be/mMqwVekr0Ak The lines are twitching to much and I don't know if there're special conditions for the control stick for this game that would make an optimal solution of my script unoptimal.
Can someone provide me memory addresses of the player and camera struct (positions, speed, acceleration, etc.)?
The ones I found have only basic stuff.
I tested my input script and the angles seem very unprecise. In the script are many more things wrong, don't use it.
See here: https://youtu.be/mMqwVekr0Ak The lines are twitching to much and I don't know if there're special conditions for the control stick for this game that would make an optimal solution of my script unoptimal.
It's a drawing of Mario overflow jumping into a PU below him!
