Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
MAME-rr is a standalone fork of an ancient MAME version that adds barebones TASing support. It does not refer to the MAME core in BizHawk (which is a fork of a recent MAME version). As stated in the OP, the final TAS has to sync on the MAME core in BizHawk 2.9.1, so we can assume it does in fact work on MAME in BizHawk (if it doesn't, that'd be hilarious and embarrassing)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
SmashManiac wrote:
Out of curiosity, what happens when loading a glitched checkpoint?
It depends on the exact glitched checkpoint used. Most just end up going inside a glitched 8-4 (which completing or exiting just results in progress as normal for 8-4) or just slap you on the map at 8-4 for whatever reason. Some decide to go in 0-1 (i.e. effectively start a new game). Some just crash the game.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
DrD2k9 wrote:
Heads up to any potential teammates: My time is limited, but I’ve typically enjoyed working on these.
I’m in.
Edit: CasualPokePlayer and I are teaming up.
Confirming this (don't know why I didn't confirm earlier lmao)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
My comments on a theoretical ACE payload which launched directly into the credits was mostly just for an argument for considering the ending sequence before the credits as gameplay (which in turn was a secondary argument for including the input to the credits in the final movie). Whether or not such an ACE payload is and if it's even possible is for someone else to figure out, and at most leaves it to a theoretical possible improvement. This doesn't mean anything for if this movie is accepted or not; it only leaves in a path for it to be potentially obsoleted in the future.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
It would still mean there is a GreenZone file in the tasproj. Try removing the file manually (the tasproj can just be opened up with 7zip as it is just a zip file in reality). Alternatively, upload a bk2 (File -> Export to bk2 in TAStudio menu)
The precedent in that run and the run mentioned in that run is predicated on a very important thing you've overlooked: there are no credits after the ending sequences of those games. Therefore, the ending sequences are the definitive ending point themselves, as the lack of credits after the ending sequence means that title no longer goes to the credits.
Link's Awakening does have credits after its ending sequence of dialog, therefore the precedent you linked simply does not apply. Also therefore, the definitive ending point in Link's Awakening is the credits, and the inputs for getting to the credits should be included in the actual movie.
OtakuTAS wrote:
CasualPokePlayer wrote:
Bobmario511 wrote:
but uses a glitchy warp to mid credits instead of the cleaner warp that your run does.
A warp mid-credits would probably be more optimal under a TAS setting, due to us ending on the last input, and the TAS would need to reach a definitive end point (i.e. credits) rather than the end point decided by RTA. The fact these inputs can be optimized away with a slightly different glitch I'd argue clearly brings them into the category of gameplay and thus timesave here counts.
The method used is known as "old ACE", is an emulator glitch, and is caused by old Gambatte overlooking opcodes that would crash console. It crashes on emulator too now (I believe, but I digress).
While that is unfortunate, that misses the point I was making. If you were to figure out a way to do a mid-credits warp like "old ACE" while still working on the newest emulators, while it wouldn't save any time under RTA standards, it would save time under TAS standards. As above, the inputs for getting to the credits should be in the movie, and since that theoretically can be optimized away, that is a very good argument to consider it optimizable gameplay, ergo a good argument to consider it gameplay that should be in the actual movie.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Windows 8 (not 8.1) doesn't have the required .NET Framework version for the latest versions of BizHawk.
Even then you probably should just update it to at least Windows 10 here if not just for security.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Bobmario511 wrote:
but uses a glitchy warp to mid credits instead of the cleaner warp that your run does.
A warp mid-credits would probably be more optimal under a TAS setting, due to us ending on the last input, and the TAS would need to reach a definitive end point (i.e. credits) rather than the end point decided by RTA. The fact these inputs can be optimized away with a slightly different glitch I'd argue clearly brings them into the category of gameplay and thus timesave here counts.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
You missed the detail on when the player moves down. The newer run does it immediately then save+quits, while the previous run did save+quit then moves down. Doing it immediately turned out to be faster than delaying it for reasons I can't recall.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ISOs are often junk for PSX, as more often than not they are multi-track and thus require a more complex format (e.g. cue/bin). What game exactly are you trying to run here?
Also, are you using BizHawk under Linux with WINE/Proton by any chance? It could false positive the Administrator check.
YoshiRulz wrote:
kevindadmun100 wrote:
[[...]] I definitely not running it as administrator [[...]]
That will not trigger the Administrator account check (I have my only account set as Administrator and it doesn't trigger the warning). You'd have to explicitly run the .exe with Administrator permissions.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Converting AR codes to something BizHawk understands would require looking into the AR code format and seeing what the code exactly does. If it's just freezing some memory address unconditionally, it's relatively trivial to do the same in BizHawk with its own cheat interface. If it's doing something more complex, it may require some lua scripting in order to implement it.
.SaveRAM files are .sav files with a different extension. Importing .sav files is nothing more than renaming them and placing them in the correct folder (NDS/SaveRAM folder)
I assume you just want a place to save whatever TASes, whether complete or not, onto the site, and not what we typically refer to as publications (a completely separate ballgame). You probably want to just look at the userfiles here.
For adding resources to a game, look at the game's own game resource page. You may need to ask a staff member for editing permission on game resources here however, as you lack the Published Author role which normally is what gives permission to edit game resource pages.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
A separate "glitchless" category for 100% in general isn't yet in Standard from what I can tell (still under consideration). Regardless of that, the multi-game setup here would itself disqualify the run from Standard.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Keep in mind the gray palette is not at all a measure of accuracy, rather they are chosen as they are the easiest to look at and have perfect contrast. As far as the Game Boy was concerned there were no "colors" other than "0, 1, 2, 3", going from light to darker, and not necessarily linear in that path. The original Game Boy had some shades of green, and the Game Boy Pocket had some shades of gray, but they were not the perfect contrasting grays given by default in Gambatte. If you want "accuracy" you could want to switch to the SameBoy core, where you can select between the colors of various models (i.e. original Game Boy, Game Boy Pocket, Game Boy Light) along or the "perfect" shades of gray.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
The second image in https://tasvideos.org/Forum/Topics/24580?CurrentPage=1&Highlight=523813#523813
The light gray has 0xBDBDBD and 0xBEBEBE, the dark gray has 0x686868 and 0x696969, which are quite off.
Having some differences is actually normal, it's due to the fact that internally the core only stores custom palettes as RGB555 (while the user selects colors in RGB888, so it converts them downwards), when it gets put on the screen it has to be converted to RGB888, that process is a bit lossy but it doesn't really matter much as you couldn't tell without getting some tool to check the exact colors. Even then the differences should be minor, not major like the above example I brought.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
I use Windows 10 myself. I assume it'd be due to some configuration or whatever on your end. Something is definitely going completely wrong here, as the colors are just wrong in the first place.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Trying this myself (using the default gray palette, which has all 3 palettes use the same gray palette) and I can't replicate. Furthermore, your screenshots suggest you're using a custom palette anyways, as the grays do not match the default gray palette in Gambatte. I could guess your custom palette actually has different grays between the 3 sets of palettes in it resulting in more colors. That or something else is going wrong anyways (maybe Windows code for sending it to the clipboard is going wrong? which case there is not BizHawk bug, perhaps it's some setting you enabled or whatever, or maybe it's actually the fault of the program you're pasting it into)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Ctrl + C messes things up? Are you sure you don't mean Ctrl + Shift + C? Ctrl + C is a raw copy of the emulator's frame buffer, so it should have no issues at all (Ctrl + Shift + C goes through a GPU render pass which could screw things up maybe depending on however you configured the display and driver quality and such)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
The thing we want above all else is sync stability. Accuracy and speed are seconded and overall independent compared to sync stability, as sync stability is largely a question of having proper savestates.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
EZGames69 wrote:
I believe there’s some settings in dolphin that lets you set the internal AR to 4:3 under the Wii Configuration menu. Although I’m not entirely sure how much it affects sync, but I wouldn’t be surprised if something like this isn’t supported by something as old as 5.0 dolphin.
This would be supported in Dolphin 5.0 (Config -> Wii -> Aspect Ratio). This maps directly to the aspect ratio setting you would be able to see in the Wii Menu settings (which the game would proceed to read and change how it renders internally). The aspect ratio in in the Graphics config wouldn't map to that, it'd be more akin an aspect ratio setting on a TV if anything (and would not affect sync, unlike the Wii config variant).
