I've been tweaking with the room loading routine and added a few things to it to allow me to reuse roomdata. There's no need to explicitedly set byte-for-byte all the playfield data for all the zones of a room in all rooms of all regions. Especially when you consider how many 3-byte strings will be identical.

Now in the room data I just specify the starting offset (low-address) for where a 3-byte string will be taken from. The highbyte/page has been pushed into the high nybble of the Zone-Counter byte. There will never be 15+ zones of data in a room simply because I'm not reserving ram for that many zones. In fact I have the room loader designed to limit the zone counter if it tries to tell it there's more zones for the room than the program allows. Since the high-byte for the graphics page will always have the form of $FX, I only need to store the X portion and add the F in afterwards via an ORA.

For the relative exit format (2 bytes are used instead of 4 to specify the 4 room exits) each nybble holds an offset value from the CurrentRoom variable. What I do is load CurrentRoom, subtract 8 from it. Then add the nybble back into it. IF the nybble is 0 however, I don't bother with that and just assign 0 to the room exit. Room 0 in the code indicates a dead exit so this way I can always kill an exit even when using relative exits.

Due to the subtracting of 8 from current room, when we add the nybble back in we get the offset as follows:

	  0 |  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  <-- nybble value.
	  X | -7 -6 -5 -4 -3 -2 -1  0  1  2  3  4  5  6  7  <-- offset from CurrentRoom

With careful planning this could save a lot of space without hurting the world layout. If relative exits were the ONLY way to specify exits then you'd have trouble with the world layout. ("What do you mean I've already used all rooms that are within range!") But I can explicitedly set exit values as well if necessary. The only catch is that a room has to be entirely relative-set or entirely explicit-set. I could probably change this later since I have two more bits in the RoomStatus nybble. (Which occupies the top nybble of the RoomStatus/RoomType byte.)

The addition I'm making right now is the ability to either load the playfield data for a room as I mention above - or give the room/region pointer for a different room. In effect it would jump to the new room, totally ignore the color/ctrlpf/exit information for that room, and just load it's playfield data. Between use of the ball positioning and playfield-mirroring that can be different, the exact same playfield data could look quite different despite being the exact same data. Additionally I'm thinking about allowing specific zones to be loaded/overwritten after I load a different room's data.

I suppose I could look at the playfield loading as direct and indirect playfield loading.

At any rate I plan on spending today and tomorrow rewriting the room loader then I'm going to change the Test Region layout. The new layout will make use of all the different aspects of exits and room loading. (Dead exits, tying exits so they lead back into the same room, direct/indirect room loading, relative/explicit exits, etc.)

After that I'll upload a new rom of the new Test Region.