Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha wrote:
CasualPokePlayer wrote:
Alyosha wrote:
What is the status with console verifying this?
Currently not possible it appears. The TAS desyncs right at the title screen, console taking less time with the picture spam compared to Gambatte for some reason. We don't know why it does, after extensive testing of the camera (using a GBC + flashcart + GB Camera cartswap setup) we couldn't find any major timing inaccuracies. Currently our best bet is just the GBA behaves differently with timing for some reason (although that doesn't make sense, that would mean that the PHI, a direct representation of the GB's clock, is faster on the GBA).
So GBC also takes less time then Gambatte, or just GBA?
Is the amount of time enough that the reset you mentioned would be faster on console?
I mean the testing was done on a GBC, which Gambatte matches. GBA is potentially different, although untestable due to the inability to cartswap.
Also no, not at all. The reset was barely faster in GBHawk; console would be slower by several seconds.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
For anyone using DS firmware, I advise to avoid firmware which matches the hash in the firmware db. That hash matches a hacked firmware, and should not be used.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha wrote:
What is the status with console verifying this?
Currently not possible it appears. The TAS desyncs right at the title screen, console taking less time with the picture spam compared to Gambatte for some reason. We don't know why it does, after extensive testing of the camera (using a GBC + flashcart + GB Camera cartswap setup) we couldn't find any major timing inaccuracies. Currently our best bet is just the GBA behaves differently with timing for some reason (although that doesn't make sense, that would mean that the PHI, a direct representation of the GB's clock, is faster on the GBA).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Well, I looked a bit into this, and seems I made some wrong assumptions.
The character does move to the end of the screen faster in this submission, but this doesn't actually speed up getting to the fadeout. The fadeout (from what I can find) relies on 2 things. 1. Fanfare played out (starts playing once player crosses finish line). 2. The mole reaching the finish line. That second one being relevant here, as this submission has that mole getting to the finish line 1 frame sooner. For whatever reason, the mole drops to 0 speed for a frame in the old movie. Jumping at the end avoided that drop in speed, and thus this submission ends up faster.
EDIT: Looking into it, it seems like if the player is on the ground at the finish line, the mole will drop to 0 speed for a frame. If the player is in the air, this doesn't happen. So that would directly make jumping the improvement, as that shortens waiting for the NPC.
EDIT2: On a slightly unrelated note, the several second wait at the beginning actually does affect a potential strategy. You could soft reset once you hit the finish line and the game would let you go to the actual credits. This is actually a faster strat within GBHawk, but in Gambatte it's much slower due to the wait on bootup.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
feos wrote:
Since this is after controllable gameplay has ended, it feels uneasy to accept an improvement to loading times when otherwise loading times have become longer
TASVideoAgent wrote:
This happens with both GBHawk and Gambatte, so this improvement is legit.
Also, the loading times becoming longer is only at the very beginning on game boot, due to the game spamming take picture commands for some reason. GBHawk didn't bother to emulate the timing of these commands, while Gambatte does as accurately as known with current research.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
feos wrote:
TASVideoAgent wrote:
Messing around, I found out that I could jump right before the goal, and that seemed to be slightly faster.
What is faster exactly? The timer is ticking for 855 frames in both movies, which is an indication to me that controllable gameplay is of the same length.
The character exiting to the left and the screen fading out happens sooner with this jump.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
feos wrote:
Jigwally wrote:
2) I know since I submitted this that at least a couple of improved solutions were discovered to some of the levels, if you get in touch with Archanfel he probably knows which ones they are
Is there any info about this?
Archanfel hasn't been on the forums for nearly a year, and I can't find any other social contact info on him. RTA runs were not any help (all either the same or slower solution), and as I established earlier the linked JPN TAS on nico used the exact same solutions.
feos wrote:
Regarding "questional" improvement, I think the whole question about it will become moot if the movie simply uses an older version of the core to make the comparison clear and the improvement obvious. If the improvement reduces lag in the same places accuracy increases it in, it's really hard to compare and prove which kind of lag is prevailing, especially when there's overall more of this lag, and no improvements in routing.
I mainly didn't actually do it entirely due to issues I had with my lua script, although granted, that was with an older version of the lua script which also had issues with the JPN version, which I was able to resolve for that version, so perhaps it might work fine? I'll look into it when I can.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Fortranm wrote:
SGB and SGB2 firmwares are listed under both SNES and Gameboy on the Firmwares setting, and each entry looks for different files.
That's intentional, the ones in SNES cover the SNES side of firmware and the ones in Game Boy cover the Game Boy side of firmware (the latter is usable in HLE cores unlike the former).
Does Open ROM go to the SNES folder for all SGB cores, or just BSNES cores?
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
PPLToast wrote:
no BIOS accuracy improvements and HLE of CGB-DMG colors (restoring to original Gambatte behavior of hacking in the post BIOS state)
What does this mean exactly? The improvements got reverted for sync or something?
The meaning is more the approach was changed for no BIOS. Originally Gambatte had no bios option, which simply set the state to (about) the post BIOS state.
When BIOS support got properly added, no BIOS support got removed. Eventually no BIOS support was put back in, but instead of doing the original hack in post BIOS state, instead BizHawk was simply providing a homebrew BIOS. This is problematic due to Gambatte's testsuite, which will fail many of its tests if it does not get the exact same post BIOS state as a real GB/C.
In 2.6.3, the original approach was put back in, along with being closer to the post bios state than original Gambatte behavior. In GB mode, the exact same state is put in, which also makes it so movies made without a BIOS can always be resynced to having BIOS (assuming ELF isn't being used). GBC mode ends up having hundreds of possible post BIOS states just from the header, so the state is taken off the header data in Gambatte's testroms, and will not be right for many games. GBC-GBA mode is the same deal as GBC mode.
Confusing mostly since this was just taking off a commit message/pr iirc, hope this clears this up.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ThunderAxe31 wrote:
CasualPokePlayer wrote:
I've redone the TAS on the JPN version: http://tasvideos.org/userfiles/info/73397997229424541
I'm not yet entirely convinced this should be the preferred version for this submission, so this shouldn't replace the movie file, at least yet.
Is there any demerit in using the JPN version?
More being demerit in using the JPN or 1.0 version of the game, which feature various graphical glitches. 1.1 seems to have been slowed down to avoid these graphical glitches.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha wrote:
re there any (not input related) timing inaccuracies that come up from not having the SNES there?
I'm not sure what you mean. There aren't really any actual timing issues which are reliant on the SNES, at least as far as movie syncing goes. The only SGB specific thing that can cause a desync is multiplayer emulation (for slightly duh reasons, and since the GB can read out which player is active). Everything else is invisible to the GB.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ThunderAxe31 wrote:
Some people don't like SGB because it plays at a slightly faster framerate than actual GB/C, leading to misleading record comparisons. However, that would not be the case for SGB2, as it uses an internal clock faithful to actual GB/C speed. Why not implementing SGB2 emulation?
My implementation in Gambatte is currently SGB2 only (being it literally requests the SGB2 bootrom). Which happens to be good here too as the movie parser wouldn't parse the cycle count correctly for SGB1.
Alyosha wrote:
I'm not really familiar with the technical aspects of SGB (besides the clock issue between SGB 1 and 2), would TASes generally sync between Gambatte and BSNES? If there is some technical reason they wouldn't, what would it be?
The non-v115 BSNES core has horrible GB emulation, around VBA levels of accuracy.
Even then, inputs wouldn't quite sync, since inputs on a normal SGB would be locked to the SNES's framerate, while Gambette just has the whole sync frames to GB's VBlank thing (nor could it know what time is SNES's VBlank really since there isn't an SNES in there).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Right, should of mentioned I was using latest dev on my SGB meme thing. That branch is being put into bizhawk for ??? reasons, don't know why it isn't using the correct version.
0 length is silently turned into 35112 length (full frame), so somewhat invalid I guess.
Of course, be wary of timing from frames, frame length is just a suggestion towards Gambatte, it will sometimes overrun the requested length due to the event scheduling that takes place and such. Using the cycle counter (i.e. lua's emu.totalexecutedcycles()) would be the true time so to say.
The spreadsheet is asking for access.
Also, GB subframe stuff is possible to verify to an extent. At least, GBI's resolution for inputs is 256 1MiHz cycles. If it's within that range, it could be verified. Being smaller would end up being tricky and possibly not verifiable.
EDIT: Got a userfile of what I believe you saw: http://tasvideos.org/userfiles/info/74082050596796939
Seems to just be a dumb game that does a stupid amount of polling. Nothing fancy really. It's probably not impossible to verify if GBI timings play nice (i.e. luck) but it's ultimately nothing too amazing.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ThunderAxe31 wrote:
Did you try improving the Space Faver II play?
I did not for this movie. Later on, I did look into that part of the movie (mostly checking how well it synced if title screen was delayed, fun fact rng is different so it desynced), and did note that there was maybe some possible improvement in terms of defeating each giant head, but I could get anything better.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Noxxa wrote:
Prototypes would need to meaningfully distinguish themselves from their released version (if there is one) and qualify for Moons.
This seems to be more restrictive than the current ruling in for prototypes, which allows them for Standard. I don't think putting more game choices under Moons is a good idea here.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Fortranm wrote:
Would it have been faster to get Bike Voucher before teaching Cut so that Instant Text is effective during that dialog until the Yes/No option?
You can't Escape Rope out of Surge's gym, you still have to go to the nearest place which can Escape Rope, which ends up being the Fan Club you get the Voucher from. You end up going a lot of extra movement for just a tiny amount of extra IT use.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
I did some digging into this, and ended finding out the "glitch" used is not so much a save glitch (nor really a glitch at all).
The first thing to know is this game does NOT attempt to read out SRAM at all. So this itself shows this is not a "save glitch" as the publication has it, nor is "bugged SRAM" the cause of this "glitch". The game also does not ever read out uninitialized RAM, so that possible cause is out of the picture.
Some further reverse engineering can also clearly show that the all items being unlocked is the game explicitly setting all the flags on start up (in fact, the versions that don't do this have nearly the same code, except it 0s out all the flags instead of setting all of them, a simple 1 byte difference in that function). I couldn't figure out how all the stages were unlocked, although I presume it's in a similar fashion to items, given there aren't exactly that many other possible causes (besides maybe some weird mapper issue, but this is very unlikely considering the above). The stages being unlocked are indeed just similar code intentionally setting all the flags for them.
Considering the above, I don't believe this is even a "glitch," as it purely seems like a version difference in how the game sets the "no save data" state. It could even be perhaps argued this was some debug build released, which would be disallowed by the rules.
To note, the "does not attempt to read out a save file" is not only present in this version, but it's also present in the version used by the other published movie, and in the original Zook Hero 2 (which fun fact was dumped a few years after this submission). Presumably this saving mechanism only ever worked on the final undumped "Rockman DX3", although I would have no idea if this is really the case.
In any case, the "save glitch" label is inappropriate, and should be cleared out. This movie should also probably be obsoleted by the other movie, given its content overlaps and this movie doesn't even abuse any sort of "bug" but just abusing a version of the game having intentional code which sets all the flags.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
monji wrote:
I wondering if it can be done without holding the F key all the time.
Running the emulator normally without holding the frame advance key is identical to holding down the frame advance key, save for the lack of audio for the latter.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Wobmiar wrote:
Out of curiosity, do someone know if Dolphin devs intend to make GBA encoding a thing?
That is something that is intended to be added. It's really just whenever someone has the time to go hook everything up. mGBA has worked fine before with encoding (see upstream and BizHawk) so it's just a matter of time before someone does the thing.
