Spectrum Computing

Just gonna add a vote for Auf Monty...

I wonder how far it can be pushed.
How about:
Nonterraqueous
Tantalus
Explorer

Quite an intriguing idea. Nice for those of us who struggle to get off the first screen in Technician Ted..

Pobulous wrote: ↑Tue Oct 30, 2018 12:21 pm Explorer

Auf Wiedersehen Monty does seem well suited. Though I don't have an AY emulation at the moment, so no music

Tantalus shouldn't be a problem size-wise, though I'm not familiar with the gameplay, which useful to know it's working properly. I remember Nonterraqueous 1 from back in the day, which was big but pretty sparse.

I'm hoping tempt someone else to have a go at porting, once I've got a description of how to do it. Soon...

Something interesting might be Robin of the Wood, since it is a game based almost purely on random positions on the map.
I'm not sure if the positions are resolved before the player enters a room, but if that is the case, could be interesting to watch realtime

All cases I've seen so far generate the item locations when the game starts, and that seems the best place to do when there are limits to the number of certain items types that can appear. That's certainly true for Dynamite Dan, Dynamite Dan II, Starquake, and Sabre Wulf. Dynamite Dan II does that for objects on all 8 islands at the start of the game, so you can look ahead to see where the record will be!

TileMap waits until the game state has initialised before cloning across all rooms, so they're given the same starting state. That ensures the same items are in each room when the player finally enters them.

Can this work for games where enemies and objects move between the rooms? I've got a game in mind that I'd be interested in porting with this if it's possible.

djnzx48 wrote: ↑Fri Nov 02, 2018 4:20 am Can this work for games where enemies and objects move between the rooms? I've got a game in mind that I'd be interested in porting with this if it's possible.

Yes, though it will require some knowledge of the data involved in the object's state, and maybe the code that manages it.

In Sabre Wulf the Wulf is effectively a global object that moves between rooms, as it runs back and forth at the bottom of the map. In TileMap the active room containing Sabreman owns the Wulf state data, and takes snapshots after it is updated. That data snapshot is global to the game, and before each room runs the Wulf code it takes a fresh copy to synchronise it. It gives the overall effect that there is only one and it's moving between rooms.

It might still depend on the game you have in mind, but I believe it should be possible. There's some flexibility to change the approach if that doesn't quite fit.

Thanks, I've got a build working now and found the room address, so I'll see if I can make any progress on this.

If you're at the stage of building TileMap itself, make sure you've pulled the latest code. I simplified the code hooking yesterday, so existing hook handlers will need adjusting. There are still some build issues with the Z library it uses as a sub-module, which doesn't yet play nice with recent Visual Studio versions. It just means ignoring some link warnings until it gets fixed.

Shout if you need any more details.

In case it's useful, I've written up some details on how TileMap works: https://simonowen.com/articles/tilemap/

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.



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

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.

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.

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.

[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.