Posts for comex

Experienced Forum User
Joined: 12/4/2013
Posts: 8
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.)
Experienced Forum User
Joined: 12/4/2013
Posts: 8
I'm only a TAS fan, not a creator thus far, so don't mind me too much, but here are some broad suggestions for the next or any future GDQ: - I don't remember seeing any GDQ TASes that focused on showing off luck manipulation. To me this has a big "neat" factor whenever it's done either live or in TAS. While luck manipulation isn't TAS-only, TAS can make it work in far more games and with much more sophistication than a human, making it a good example of why TAS is inherently interesting rather than just a "cheat". An ideal showcase would be a game that is highly luck-based and can be completely broken with just luck manipulation, no other major glitches. CCGs sound like they could fit the bill well; in the "Heavy luck manipulation" category I see Gostop DS and Pokemon TCG, both around 20 minutes, though I haven't watched them (yet). (There is also Yu-Gi-Oh! Forbidden Memories, but it's longer and its description says "[t]he chances for manipulation are limited". Of course, there are dozens of other, unTASed Yu-Gi-Oh and Magic games...) Turn-based tactics games like Fire Emblem might work too, or even RPGs, though you probably couldn't get through the whole game. One big caveat: many/most submitted TASes of turn-based games go through the menus too fast for a viewer to have any real idea what's going on (without constantly pausing, at any rate). The result may be fast, but at least to me it’s not very entertaining at all. Especially for an exhibition, I think it would make more sense to optimize for some sort of turn count, then rate limit menuing so the viewer can follow along (and the couch can at least make an attempt to explain interesting mechanics). Of course, doing that would blow up the aforementioned 20 minutes considerably, but it may not be necessary to complete the whole game, or there may be other games/modes that can be completed faster. - Arbitrary code execution is now old hat both here and at GDQ - but only on 8- and 16-bit consoles. ACE in a 3D game would both be a novel feat and present the opportunity for a very different post-control playaround. Including just basic visual corruption effects - we've seen what sprite corruption on old systems look like too many times to count, but the silly effects you can get in 3D by messing with vertices and such are much less well known. More structured effects like cel shading, outlining, night vision, etc., usually associated with shader overrides on emulators, should also be possible to replicate on console in at least some cases. Probably lots of more elaborate things I haven't thought of. Not sure how much time people on this site have spent looking for suitable bugs in 3D games. Certainly likely to be much rarer due to higher level code, higher likelihood that invalid states crash rather than doing anything interesting, etc., but far from nonexistent. Super Mario 64 in particular has so much known about it and so many glitches... (This is something I actually know a little about; I once wrote an exploit for Brawl people still use for homebrew, albeit based on save data rather than controller input. Maybe someday I'll spend time on my dream of finding an ACE bug in Melee. But I'm lazy.) Of course this also runs into the issue that most modern consoles have never had attempts at TAS verification, and may require fundamentally different techniques to verifiably TAS due to timing variation. But the N64 at least has been shown to not require this. - Oh, and yes please on Hyper Princess Pitch! That run was amazing.
Experienced Forum User
Joined: 12/4/2013
Posts: 8
Hmm, I didn't see RachelB's reply. I will have to look into this, I guess, if someone else doesn't.
Experienced Forum User
Joined: 12/4/2013
Posts: 8
Actually... 4.0.2 was released well before that bug was fixed. However, it was also released before the revision claimed in that link to have caused it in the first place, so it might work for you.
Experienced Forum User
Joined: 12/4/2013
Posts: 8
Experienced Forum User
Joined: 12/4/2013
Posts: 8
Can you confirm whether or not, as I said on the bug tracker, you can get multiple outcomes with the same dtm (doesn't matter whether it completes the level or not, just whether the outcome is different) without changing any settings at all in between, and with all of the dangerous options set correctly in both the general and game-specific settings dialogs? Your post seems to imply that you can, but it's unclear to me why you're fiddling with settings so I must ask. I tried playing back the dtm myself; the result depended on the settings (MMU), but it was completely consistent between the two copies of Dolphin I was running, even though there was heavy load, conditions likely to induce indeterminism. (And yes, Dolphin should be more user friendly; it should warn you if there is a possibility of desync, and all relevant settings should be synced with the movie file. But that's lower priority.)
Experienced Forum User
Joined: 12/4/2013
Posts: 8
If you can reproduce this on the latest build of Dolphin, please file an issue: https://code.google.com/p/dolphin-emu/issues/list
Experienced Forum User
Joined: 12/4/2013
Posts: 8
Just popping in to ask if there are still any particular improvements to Dolphin that you think would help out with this.