[flamewing]

Oh, I got it -- it is an engine issue, coupled with the definition of a "frame" for emulators. A frame in Gens and BizHawk last, in general, from V-Int to V-Int (or when V-Int would have happened, in the cases where it is disabled).

Here is what I think is (at least part of) the problem: most of a frame happens during active display; the game updates its logic, decides where sprites are, where the camera is, and calls BuildSprites (or equivalent). Frame finishes rendering for display*, V-Int happens, a frame ends. During V-Int, the data buffered by BuildSprites is transferred to the VDP, as is horizontal scroll based on camera position. This stuff will be rendered during active display, while the game logic will update positions and so forth; at the end of this frame, the image generated the first frame I talked about will be shown. Reading data at this point will give the "wrong" values for sprite positions and camera location relative to the graphics because the graphics are from 2 frames ago -- you are using the new positions and camera location to render overlays on graphics two frames old. Sometimes, they will line up -- but that is by chance, or when you are moving at constant speed.

Now, the S3&K engine is a lot more optimized than S1 and S2, particularly when it comes to level drawing -- S3&K renders the level during active display to a RAM buffer and transfers the whole thing during vblank. S1 and S2 set flags during active display that say what needs to render, and it renders it all during vblank. And what is more, S1's 68k sound driver also probably gets in the way of it all, making it even worse.

I have no theory at the moment about the differences between Gens and BizHawk; could be due to accuracy differences or due to how they render the overlays.

[sonicblur]

If it helps at all, BizHawk has OnMemoryRead(), OnMemoryWrite() and OnMemoryExecute() Lua callbacks, if you'd rather not be restricted to frame boundaries. You could always hook either the addresses themselves, or the execute on the code that changes them.

Not sure if Gens has something like that. Here is the documentation for them:

		[LuaMethodAttributes(
			"onmemoryexecute",
			"Fires after the given address is executed by the core"
		)]
		[LuaMethodAttributes(
			"onmemoryread",
			"Fires after the given address is read by the core. If no address is given, it will attach to every memory read"
		)]
		[LuaMethodAttributes(
			"onmemorywrite",
			"Fires after the given address is written by the core. If no address is given, it will attach to every memory write"
		)]

They all take in an address as argument.

[ZanaGB]

Mercury, on 05 September 2014 - 04:58 PM, said:

sonicblur, on 04 September 2014 - 07:23 PM, said:

If Gens continues to frustrate you, why don't you try writing the same script for BizHawk instead?

ZanaGB, on 05 September 2014 - 04:34 PM, said:

Well. I am not the most knowledgeable person regarding how this goes. but I definetly know that BizHawk offers support for LUA scripting and a far more accurate emulation core.

Thanks for recommending BizHawk, I'd never heard of it and it's great to have more options. Unfortunately, though, when I rewrote the script for BizHawk and tried it out, the exact same thing happened - only worse, as it now happens even when the screen is not scrolling.

I am glad to know that my small suggestion has helped some ( at least to further proof that the S2 engine is weird, and to show there are some other capable emulators for recording and scripting over ). Hopefully this can help for the future

I should probably not waste my trial posts like this but it's always good to know when your information can be useful

[Mercury]

sonicblur, on 05 September 2014 - 07:45 PM, said:

I think this is just a case of the game not working the way you think it should. If you can provide any evidence to the contrary, I'm still willing to try and get you help with this.

It totally is the game, not the emulator. I just tried onmemoryexecute on the V_Int routine, and it now works exactly as I expect.

Spoiler

timer = 0;
timer_prev = 0;

problem_count = 0;
write_count = 0;

memory.registerexec(0x000408, function()
	write_count = write_count + 1;
	
	cam_x = memory.readword(0xffee00);
	cam_y = memory.readword(0xffee04);
	
	sonic_x = memory.readword(0xffb008);
	sonic_y = memory.readword(0xffb00c);
	
	sonic_radius_x = memory.readbytesigned(0xffb017);
	sonic_radius_y = memory.readbytesigned(0xffb016);
	
	sonic_screen_x = sonic_x - cam_x;
	sonic_screen_y = sonic_y - cam_y;
	
	timer_prev = timer;
	timer = memory.readword(0xFFFE04);
	
	if (timer == timer_prev) then
		gui.drawbox(0, 0, 320, 224, 0x00000080, 0x00000080);
		problem_count = problem_count + 1;
	end;
	
	gui.drawbox(sonic_screen_x - sonic_radius_x,
		sonic_screen_y - sonic_radius_y,
		sonic_screen_x + sonic_radius_x,
		sonic_screen_y + sonic_radius_y,
		0xFFFFFF3F, 0xFFFFFFFF);
	
	gui.drawbox(sonic_screen_x - 10,
		sonic_screen_y,
		sonic_screen_x + 10,
		sonic_screen_y,
		0xFFFFFFFF);
	
	message = string.format("Timer: $%X\nWrites: %d\nProblems: %d", timer, write_count, problem_count);
	gui.text(16, 64, message, 0xFFFF00FF, 0x000000FF);
end);

Thanks for all the help, everybody! This was really confusing the heck out of me.

[flamewing]

sonicblur, on 05 September 2014 - 08:32 PM, said:

Not sure if Gens has something like that. Here is the documentation for them:

It has them, yes:

sonicblur, on 05 September 2014 - 08:32 PM, said:

"onmemoryexecute"

memory.registerexec

sonicblur, on 05 September 2014 - 08:32 PM, said:

"onmemoryread"

memory.registerread

sonicblur, on 05 September 2014 - 08:32 PM, said:

"onmemorywrite"

memory.registerwrite

They all take address, size (number of bytes to watch) and callback as parameters.

[flamewing]

Double-post, but an important one: there is a built-in work-around in Gens rerecording for this issue, as well as a lua-based workaround. The built-in work-around is in the graphics under the "latency compensation" submenu. Selecting option 1 will make the hitboxes more accurately positioned.

The way this works is at the core of the lua workaround: you make a savestate, emulate two (non-lag) frames, then invisibly load state again. After this, you draw anything you need based on what is in RAM and everything will be correctly positioned relative to the GUI.