It starts with \x03 to indicate there's three strings: then it describes the city three times. at runtime it uses select_string function with a random input to select one of the three strings

okay now that I can decode the chunks (well, most of them) I can identify a lot more of them:

00 Name and (some other info)
01 ???
02 Image
03 City descriptions
04 Items to steal
10 ???
11&up: Hints leading here

So like, the 12 chunk for Tokyo says:

b'\x05asked about the exchange rate for yen\x00was practicing Japanese characters\x00said\x81planned to take photographs of Mount Fuji\x00asked about tours of the Imperial Palace\x00was interested in visiting Shinto shrines\x00'

So it picks from one of those 5 options

and then 13 will be:
b'\x02asked questions about Shinto rituals\x00said\x81was researching an archipelago\x00'

so when it sets up a city that has hints to lead to Tokyo, it picks 3 of these sets of questions, then picks a question in each set.

tool that'd really be handy right now:
a "live" version of binxelview, so I can step through the DOSBox-x debugger and see how memory is changing in real time, as an image.

that might not be TOO hard to hack in, hmm.

I'm stepping through a high-level loading routine I don't understand yet, trying to figure out when it decompresses an image by watching the RAM it uses for file loading and decompression and spotting when the image appears

sadly DOSBox-X's memory breakpoints don't let you set up a breakpoint that covers a whole 64k. you only get one byte. A shame.

ooh, I'd also need to be able to watch multiple address ranges at once. that'd be sweet, multiple windows of visibility into RAM

I'm in Paris, I look at work ram, I see the image of the Eiffel. I head to Rome, and before I load the next image, I can see that the Eiffle tower in workram now has the wrong stride.
That's odd, because it means it had to rewrite the image in memory, the image it's about to unload.

I think this might be the GUI system doing a screenshot of the image under a window, so it can restore it at the end. And it still does that here, even though we'll never need to restore that image: we're about to overwrite it

Here's what I want a tool to do:
I hit a breakpoint in the debugger, I turn it on, set another breakpoint, and hit go.
between those two breakpoints, every time a CALL instruction is hit, it dumps my selected memory region. If it's identical to the last dump, it's ignored.
At the end, each dump is rendered as an image, and the combined set are an animation I can scroll through.

I need a higher order debugger. I'm doing too much shit manually

GOT YOU, YOU SON OF A BITCH! I FOUND YOU.

it's in a function I already found, temporarily named "blit_related".

I guess they don't decode the image until RIGHT before it needs to go up on the screen!

if definitely decompresses and then blits the image as two parts, which aren't evenly sized, and it starts from the bottom

I think they're just trying to keep their RAM usage down by not having both halves in memory at once

wait is this image format vertically interlaced!?

It loads the half-width version, then a few functions later, it's been replaced with a full-width version.
Strange!