This topic is for the purpose of discussing #5492: Mukki & ruadath's GBA Sonic Advance in 10:49.73

Although the total time of this movie is 3 seconds longer, this is mostly due to the increased framerate of VBA. If we discount the opening portions of both movies (which gets rid of the GBA BIOS animation on mGBA, and the lack of reset on VBA), it should be fairly straightforward to see that this is the shorter movie (despite the 3-4 frames of additional lag picked up on each level due to more accurate emulation).

For convenience, can you please make a table of sorts of the improvements?

Sorry, I've been a little bit busy with some things so I apologize for the delay in getting the table up. I also might replace the movie with a version that achieves the same real time value but reduces in-game time by performing RNG manipulations before the level timer begins rather than in the middle of the level.

Previously mentioned improvement is here Same real time, but minor improvement to IGT. It should be noted that unlike previous Sonic runs, this movie prioritizes real time over IGT; it would not be very difficult to reduce the IGT further by waiting at the start of each of the RNG levels for some long amount of time to get perfect RNG, but I don't think that would prove very interesting. Hence the time loss on certain stages. In any case, it shouldn't matter, since this movie beats the previous one in terms of IGT as well (even if you do count the clock desync in the final stage against this run).

Just an enquiry, not trying to flame, but:

but this is actually copied identically from the previous TAS and appears to be due to clock desync between the emulators

If the bulk of this TAS is copied directly from Mukki's input, wouldn't it basically make him the main author of this run? If so, I think he deserves to be at least co-authored in the title. The low rerecord count also seems to suggest that minimal work was done to optimise every level. Sorry, I'm just genuinely curious as a similar issue was raised by a few staff members in the Sonic Advance 2 chaos emeralds submission.

Sure, I don't mind (just changed the submission). TASvideos seems to be pretty wildly inconsistent about how authorship works for these kinds of movies; I've seen runs that are just a few frame improvements be credited entirely to the new author, so wasn't sure what to do. It doesn't really bother me either way. The main point of the submission was to get the run ported to mGBA since the original one doesn't run on console (at least not without waiting for 15 seconds on the main menu). This submission fixes that, and also makes minor improvements.

Fog, not sure if you did this, but since I didn't see it mentioned in the submission notes, could/did you replace the file with the IGT improvement listed a few posts earlier? Thanks.

This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [3414] GBA Sonic Advance by Mukki & ruadath in 10:49.73

Link to video Console-verified using Game Boy Interface. A lag frame was inserted at frame 24890.

Thanks for posting :)

I tried applying Bisqwit's camhack to this game, but this movie desyncs. Download test.lua

Language: lua
while true do
    offX = mainmemory.read_s16_le(0x5B96)
    offY = mainmemory.read_s16_le(0x5B98)    
    camX = mainmemory.read_s16_le(0x59D0)
    camY = mainmemory.read_s16_le(0x59D2)    
    mainmemory.write_s16_le(0x59D0, camX+offX-128)
    mainmemory.write_s16_le(0x59D2, camY+offY-80)    
    emu.frameadvance()
end

With VBA-Nest it's possible to hook lua functions to memory writes and executes, but I couldn't figure what registers hold what, and what the PC is when camera values are being written. Otherwise you can do things like this:

Language: lua
event.onmemorywrite(function()
	offY = mainmemory.read_s16_le(0x5B98)
	camY = mainmemory.read_s16_le(0x59D2)
	emu.setregister("R7", camY+offY-80)
end, 0x030059D0)

It just kinda doesn't work...

Does it still desync if you make a savestate, run the camhack code, render, and then load the savestate without updating the display?

I tried implementing this and even if I force frameskips in hawk's code for those "invisible" frames, I couldn't make it usable. Based on this draft by Dacicus and Masterjun, you have to advance 2 frames in order to see your hacked camera, then load a state and call emu.frameadvance() again to let the emu continue. And even after hacking hawk a bit, it's really not ready for this setup yet. For posterity: https://pastebin.com/79pVQzAq https://pastebin.com/fUVspZyc Nevermind, it mostly works. Just slowly. https://github.com/TASVideos/BizHawk/pull/1725 And with the updated script I made it blazing fast! Download sonicadvance_camhack_bizhawk.lua

Language: lua
local offX, offY, camX, camY
local addr_offX = 0x5B96
local addr_offY = 0x5B98
local addr_camX = 0x59D0
local addr_camY = 0x59D2

while true do
	client.invisibleemulation(true)
	local memorystate = memorysavestate.savecorestate()
	
	offX = mainmemory.read_u16_le(addr_offX)
	offY = mainmemory.read_u16_le(addr_offY)
	camX = mainmemory.read_u16_le(addr_camX)
	camY = mainmemory.read_u16_le(addr_camY)
	
	Xval = camX + offX - 128
	Yval = camY + offY - 80
	
	mainmemory.write_u16_le(addr_camX, Xval)
	mainmemory.write_u16_le(addr_camY, Yval)
	
	client.seekframe(emu.framecount()+1)
	client.invisibleemulation(false)
	client.seekframe(emu.framecount()+1)
	client.invisibleemulation(true)
	memorysavestate.loadcorestate(memorystate)
	memorysavestate.removestate(memorystate)
--	client.invisibleemulation(false)
	emu.frameadvance()
end

Link to video