Was not sure, so I've gone through and checked. I've tried clearing the save ram on both, copying the cart save to GBAHawk, copying the GBAHawk save to the cart, and 0xFF the whole save on both, neither seem to change the seed I reach the minigame at.
Thanks for the quick response and suggestion. I've so far tried setting it to 10000, 20000, and 32000, none of which seem to change the frame it arrives at as the RNG is the same across all three. It's just the option titled "EEPROM Offset"? (I've been changing it manually in the SyncSettings.json to get to the point where I can test it.)
Hi, was recommended coming along here from Discord. I'm trying to start on a little project to do some learning. A big goal for me was being able to run the TAS on console, since I had all the hardware I would need to run through GBI. The game is Spyro Fusion, saves with EEPROM. I've been using GBAHawk 2.2.0, and have verified that my dumps match what they should be in terms of the bios and game. The game rarely advances RNG, which makes manipulation trivial in most instances, except for a singular minigame that appears approx. 3 mins into gameplay. The RNG function uses the current frame count to seed it when starting the minigame, so I need to know what frame I've entered the minigame. On GBAHawk, I've seen the value I get, and the starting position of the enemy (which gives me an idea of where I am). On console, the same inputs give me a different starting position. After playing around on GBAHawk, it appears like the console is entering 4 frames later than emulator. My suspicion at the moment is due to the game doing occasional auto-saves with EEPROM. I understand that there is a sync option for tuning, which might solve my problem. But I'm unsure where to start with it (as the range is ~64k possible options). Does anyone have any suggestions based on the situation? Thanks in advance.
It may be possible to significantly improve the run in the future when subframe resets become possible.
Do you need an authentic Emerald or LeafGreen cart to do testing?
Makes more sense. Starting at 225 means it takes 163 scanlines to get to the second frame, 65 scanlines less than the typical 228 total scanlines. I would assume me offsetting by an entire frame more just worked due to how Pokemon polls inputs (once at the start of the main loop, which normally at the beginning of vblank).
That still doesn't make much sense? Startup timing tests indicate that input would be polled sooner on console than emulator? Is it GBI somehow being late with its internal timestamp tracking? (by ~20 PWM frames???) Keep in mind by "1 frame back" I meant I just set the starting cycle from 0 to -CYCLES_PER_FRAME.
I already had the cycles per frame add set to the end of the movie. The subtraction of the frame is after that change. (in fact, you have some weird -1232 * 65 offset already? Which doesn't make much sense)
cycle = -1232 * 65
#cycle = 0
with open("GBItimestamps.txt", "w") as f:
for line in inputs:
sline = line.decode().rstrip()
if sline[0] == "|":
data = sline[:-1]
data = data[1:]
#data = data[25:]
if data != lastInput:
if cycle < 0:
f.write(f"{0:08X} {convert_frame(data):04X}\n")
else:
#sometimes need a -1 here, depends on timing of inputs per game
f.write(f"{cycle//4096:08X} {convert_frame(data):04X}\n")
lastInput = data
cycle += CYCLES_PER_FRAMEThank you Alyosha, that's great! What did you have to do to resync the video for console verification?
Flash ID checking would end up taking differing amounts of time depending on flash ID returned, so that could be useful for letting the user select it regardless.
By "same chip as in Pokemon" do you mean you checked by unscrewing your own cartridge? Flash 1MB chips come from potentially 2 different manufacturers, Sanyo and Macronix (the latter being more common iirc?). The Pokemon RTA community has noted Sanyo chips apparently are much faster than Macronix chips.