(08:25) - FatRatKnight_ joined
(08:25) <FatRatKnight_>Which surface is drawn on seems to be dependent on the function. And I am annoyed at the disconnection.
(08:26) <TASVideoAgent>New reply by Evil_3D (Sega: Sonic 3 & Knuckles): http://tasvideos.org/forum/p/452636#452636 [a:1] (Sonic+Tails max rings HCZ2)
(08:27) <FatRatKnight_>Since there are two drawing surfaces, it really feels like the gui family needs to be split.
(08:28) <FatRatKnight_>And actually, with the possibility of the canvas as well, might just be best to have a single set of functions, and spin off a set tied to whichever drawing surface whenever one is created.
(08:28) <ThunderAxe31>makes sense
(08:28) - FatRatKnight quit (Ping timeout: 255 seconds)
(08:29) - FatRatKnight_ is now known as FatRatKnight
(08:29) <ThunderAxe31>I don't see why there have to be multiple ways to basically do the same thing
(08:29) <FatRatKnight>There's also two functions for expanding the main drawing surfaces.
(08:30) <FatRatKnight>The 'emu' and 'native' surfaces.
(08:30) <ThunderAxe31>I know that, Warepire told me
(08:30) <ThunderAxe31>iirc.
(08:31) <FatRatKnight>From what I can tell, 0,0 is constant relative to the top-left corner of what can be drawn on, not necessarily the top-left corner of the game viewing area.
(08:31) <FatRatKnight>With the way LuaHawk is set up, there appears to be a set-up for multiple different scripts, that theoretically can all work nice and independent.
(08:32) <ThunderAxe31>yes. by the way, I think the emulator should get back to the original resultion after ending the lua execution.
(08:32) <FatRatKnight>Except that by redefining 0,0 away from the game's corner whenever the left and top borders are affected, this also messes up any scripts that don't try to access this information.
(08:32) <ThunderAxe31>it currently doesn't, and it's kind of unpractical
(08:34) <FatRatKnight>I also have a problem with a specific memory familiy function, where it sets a default memory region to read from. If the script assumes it's the only one setting a default, and sets it only once, it screws up when another script decides on a different default later.
(08:36) <FatRatKnight>So, with potential 'global' changes from different scripts, defensive coding like memory.read_u8(addr,"IWRAM") will ensure the script consistently reads from the right spot, which is a bit more burden on the script maker.
(08:38) <ThunderAxe31>yes I know
(08:38) <FatRatKnight>I also recall that, in some eariler versions of BizHawk, I had access to "BUS" or "System Bus" region for a memory read. Don't know if my memory is faulty here, but I really like not having to trim off the leading bits of any pointers I extract from the game.
(08:38) - Evil_3D quit (Ping timeout: 260 seconds)
(08:38) <ThunderAxe31>fun fact: you can still do that on GB/C.
(08:38) - Shinryuu joined
(08:39) <FatRatKnight>Or worse, read the pointer that can pick from different regions, determine which region it fits in, then tell BizHawk both the trimmed pointer and the region to read from.
(08:39) <ThunderAxe31>yes, I've noticed your function in Zook script
(08:40) <FatRatKnight>If the bus was a valid region to read from, I won't have to maintain that function.
(08:40) <ThunderAxe31>I know
(08:41) <ThunderAxe31>you should note all this facts to adelikat if you already didn't
(08:42) <FatRatKnight>Well, I have a topic where I talk about the 0,0 and borders things.
(08:43) <ThunderAxe31>good
(08:43) <ThunderAxe31>and what about the system bus region?
(08:43) <FatRatKnight>Packed away in a footnote in my scripts, apparently.
(08:44) <ThunderAxe31>then I'll tell him myself. I had some discomfort myself as well because of it
(08:44) <FatRatKnight>A copy of our IRC conversation wouldn't hurt.