Page 1 of 2

Re: TileMap v1.0

Posted: Sun Nov 04, 2018 1:45 am
by obo
In case it's useful, I've written up some details on how TileMap works: https://simonowen.com/articles/tilemap/

Re: TileMap v1.0

Posted: Tue Nov 06, 2018 8:12 am
by djnzx48
Here's what I've managed so far. Still need to get the rooms to remain synchronised and prevent the enemies attacking the player in inactive rooms.

Image

I noticed that BRIGHT colours don't work for some reason, is that just something on my end?

Re: TileMap v1.0

Posted: Tue Nov 06, 2018 8:21 pm
by obo
It wasn't just you, non-bright colours were broken. It's been like that since the start and I'd never noticed. I've just pushed a fix for it -- thanks!

It's great to see your progress so far! I've generally found most games have a single call to the routine that adds and manages the enemies, which could be returned from in the inactive case. If you're lucky the main loop is a big list of calls, and you can try them off one by one -- that was certainly the case for the Dynamite Dans, and I think Starquake too.

If the synchronisation remains a problem it might need some special handling in the underlying engine. I have wondered whether games that run frame synced could stay frame synced across all instances. If that needs enhancing I'll take a look. I'll see if I can commit a partial progress update for Sabre Wulf, since that has some locking and shared data use, which may work for you too.

Re: TileMap v1.0

Posted: Tue Nov 06, 2018 9:03 pm
by djnzx48
Thanks, the Sabre Wulf code would be useful to look at. I've located the main loop which does happen to be a series of CALLs, and I've found some addresses for the enemy structures. This game has some quite odd code in places, such as using a loop of LDI: DJNZ to draw the sprite rows even though they're only three columns wide.

I don't think it uses any HALTs so it might be a problem that some rooms run faster than others. If the enemies are being synced every frame then maybe it doesn't matter that the collion code is still running?

I'm not sure how to go about finding the RNG seed, since I couldn't find any references to FRAMES. There's a single LD A, R instruction operating on something that looks like it might be an RNG, but I haven't checked it yet.

Re: TileMap v1.0

Posted: Tue Nov 06, 2018 10:15 pm
by obo
I'll look at getting some SW code up after work tomorrow, as it's getting a bit late here now. It's also not frame synced, and even worse it runs the player at intervals that depend on when the ROM frame counter advances. For that reason I used a single hook to either store the data (active room) or fetch a copy to use (other rooms). It's using a std::shared_lock so multiple threads can read, the single writing thread can have exclusive access to update it.

For the RNG, I'd probably start by randomising the Z80_R(tile) value after loading the snapshot to see if it helps. I've been tracking down the use of R in SpecEmu using Debug -> Run Until -> Opcode -> LD A,R. If they don't trigger it might require a bit of extra detective work. A typical RNG will usually read a few values, have some shifts and maybe XORs, and store back in the same location it read from. They tend to look fairly distinctive.

Re: TileMap v1.0

Posted: Fri Nov 09, 2018 7:07 pm
by obo
[mention]djnzx48[/mention]: I've pushed a code update to GitHub that includes a partial Sabre Wulf implementation.

That game has all the state data in a single block, which is broken into 12-byte units for different entity types. It's stored in the game object, and updated when the active room reaches certain points in the code. The inactive rooms take a copy of the data when the reach the same points, to synchronise entities between rooms. Currently only the wulf, rhinos, and fire are supported. The game doesn't support drawing partial sprites at the room edges so they do jump a bit as they cross the boundary, but you'll only ever see them in one room.

The natives and hippo/warthog are more complicated as they res-pawn near Sabreman if they stray too far away. I'll get round to finishing that off at some point.

The data and locking may give you what you need, if you know where the state is stored and a good place to synchronise it. If not, let me know and I'll take a closer look.