RT (Room Transfer) program

I thought so. No matter which value is there, the game ignores it. But there is one case that could be a problem. The doors normally lead to the room above, left, right or bottom if there is no header data for it. But when extending the data, the header data is there and so the door leads to the specific room given. But since this extending is done by using MathOnNapkins HM version, one need to correct these rooms anyway, so we shouldn't care about this.

This tool modifies the rom this way, that it will be unusual with HM, so it is there to merge roms together after editing. But i think this will be the most important tool alongside HM, cause when HM lacks of room space, you can simply use another rom and edit new rooms there with lots of chests, objects and sprites and finally merge it to one rom. Of course, only if it works as i excpect.

Do you have an idea about this 4 pointers for the object data of rooms?

*Primary pointers at:
1. 8746, 01 80 1F --> F8001
2. 874C, 00 80 1F --> F8000
3. 883F, 01 80 1F --> F8001
4. 8845, 00 80 1F --> F8000 (all corespond to F8000)

Why are there 4 pointers?

No matter which value is there, the game ignores it. But there is one case that could be a problem. The doors normally lead to the room above, left, right or bottom if there is no header data for it. But when extending the data, the header data is there and so the door leads to the specific room given.

In this case the specific room given should match the natural door transit. I guess the manual edit would do.
 

Do you have an idea about this 4 pointers for the object data of rooms?

*Primary pointers at:
1. 8746, 01 80 1F --> F8001
2. 874C, 00 80 1F --> F8000
3. 883F, 01 80 1F --> F8001
4. 8845, 00 80 1F --> F8000 (all corespond to F8000)

Why are there 4 pointers?

You need to change all 4 pointers (the 1F only) to move the data. I guess looking at the actual code could tell us why. I guess 4 diffrent routines are being loaded. But that really doesn't matter, since this is a primary pointer(s). The secondary at F8000 are the importaint ones, and all have 3 bytes and can point anywhere.

Ok. This is the next thing i'll do.
By the way, you're right, this pointers don't matter. I forgot there is no need to move the pointer table since there is space for all 320 :-D

Ok, updated this one. It does the same, i only optimized the code and added in interesting feature it thought you could like, makes hex-editing very easy :-), try it and look at the new headers.

https://www.dropbox.com/s/gn68y40ndk26hif/RT.zip

This is beautiful. Very well made . Like you would be reading my mind. I always wanted to have it so, since one header fits into one line. And the message above which room it is. The pointers are round and precalculated. We don't have to calculate no pointers anymore, only search for room header+ number as txt! With this, we can edit headers in hex, no editor needed.
 
If you could keep this strategy with other future implementations, it would be great. For instance for items or sprites an entire 8000 bank is used (can not be more because of the 2 byte addressing), and then divided by 320 (number of rooms)+ one line for room message.

It is however a question how to make precalculated pointers for objects (probably not doable, since we can not know, how much space is neccessary for one room --> this is not space friendly if the room hasn't got much data, but a lot of space is pre-reserved for it).
 
 
EDIT
I've just did some more precalculating for 2 byte pointers, for items and sprites. 8000 in hex (one bank is maximum), divided by 320 rooms in dec is 66 in hex. Which is 60 rounded in hex, one line for room number info. So 50 in hex or 80 bytes in dec for the actual code.
 
This is very fortunate. With items FF FF is ending for one room, while with sprites we have 00 at the beginning for sort sprites info and FF to end the string. So 2 additional bytes.
 
80-2 is 78 bytes remaining, which can be divided by 3, since 3 bytes are neccessary to define one item or one sprite. 78/3 is 26. So 26 sprites and items per one room possible, for 320 rooms (this is more than enough, to much for the emulator actually). Emus can handle around 10-14 sprites in one room, or maybe 18 on fast rom, and around 20 items per room.
 
 
You can even use the very same pointers here. Since the first one would be pointed at the beginning of the bank, others would follow with the +60 in hex appart.

Glad to see that you like it :-)
Yes, i will keep this strategy. There is a functions to prevent bank breaks and step to a new line. All is calculated in-place. The next i wanna do is to write the object data (layers). My plan is to write the layer data of a room completely and than calculate the pointer for the next room, so the distance between this pointers depends on length of the layer data. But the every room will always start on a new line in the hexeditor and with the info text above.

My plan is to write the layer data of a room completely and than calculate the pointer for the next room, so the distance between this pointers depends on length of the layer data. But the every room will always start on a new line in the hexeditor and with the info text above.

I didn't know this could be done. This is a smart move, since then precalculated (rounded up) pointers are not necessary. But you can still find the data (despite the fact it is changing), with the search of the text above the start.
 
PS
I was testing some headers, and I could find the start of header for room 260 (start room) and room 97 very fast and with no address or pointer calculation.

Yeah :-D this makes it really easy to find necessary data.
About the pointers: This is not that hard it sounds like. I only go to the beginning of an hex line and convert this adress in the file to a snes adress and this is the needed pointer. And i always take care of a bank breach, thats all. These pointers are a really good thing if one can control them :-D

Ok, Objects done (i call this "Layers" in the code).
Now for the first time ever :-D it's possible to copy one of the rooms 0-295 to one of the rooms 296-319. Tested it and works.
Search string for hex editor: "Layer Room xxx"

https://www.dropbox.com/s/gn68y40ndk26hif/RT.zip

This is very well made. It is optimal for data extracting and locating. Regarding the actual transfer. Let's say we want to transfer room1 of 1.smc into room310 of 2.smc. I've typed this:
RT.exe 1.smc 2.smc SrcRoom1-DestRoom310, but I coudn't find data of room1 on room310 of the second rom. Or maybe I've typed it wrong.

You need to write it this way:

RT.exe 1.smc 2.smc 1-310

And if you want more rooms to be copied, type:

RT.exe 1.smc 2.smc 1-310-2-311
(this copies room 1 to 310 and room 2 to 311)

And notice that the new rom is named as "_2.smc" to not overwrite the original rom.

Ah, I works now. The data is copied correctly for all rooms.

I did some more testing of the pointers and the pointer for room 260 didn't actually point to the data specified. Room 260 is at 20F020, snes is 41F020, so the pointer is 20 F0 41, current pointer is 20 70 42. I found this by accident, since you always start the game in room 260.

Did you try copy another room into 260 or did you let this room untouched? Did you try to walk in 260? In my test this room appeared without problems.
You can send me your rom if you want, so i could better understand what the problem is.

Ah ok. But in theory, when using identical roms the tool should make a complete copy but with moved data sections (headers and layers). Should work normally, but never tested this.

Next is sprite section :-)

Moving sprites is nearly done, i think it will be finished today. Puzz, in your dungeon data document you speak about the 768 bytes long pointer table for sprites. 768/2 = 384 --> 320 rooms "some additional data". I am pretty sure there is no additional data, it's simply space for 384 pointers for room sprites, cause the last 88 rooms (decimal) have the 0xEC9D pointer and 384-88 = 296 --> number of rooms available.
I thought about moving all pointer tables to the end to extend them. In theory the engine should work with more than 320 rooms. But the question is, how necessary is this?

This is true, but I could bring sprites into room 296, using the pointers which go beyond the limit, you talked about. Yes all the pointers are the same, but they should work for rooms up to 319 (however there's enough space for 384 rooms). It is a question what's beyond 319th room in the pointer area.
 
Of course pointers beyond 295 are only necessary if you have the wish to fill 319 rooms (which I think is your goal). But it is not necessary to go beyond that, since the pointers for rooms (for instance) don't go beyond 319.

Really strange.

By moving all pointer tables it shouldn't be a problem to use more than 320 rooms but i think this is more than enough, so not really necessary.

Yes, you could move the pointer table, but unfortunatelly the block (area in hex) is hardcoded to not-read it further. For instance for rooms, the program reads 320x3 bytes (from room 0 to room 319) for pointers. This is 960 bytes (hardcoded data block) in dec. It will not read bytes 961-963 for the 321st room. So I don't know why sprites use this extra space, since it is impossible to make the 321st room.
 
But Math on Napkins was actually talking about "infinite" rooms for his Black Magic, as well as infinite chest etc. So obviously he found a way to expand the reading block for pointers. But he was also talking about the "custom written code", which is obviously defferent from what Alttp is using.

Oh i've never heard this before, sounds logical, shame on me that i didn't thought about that :-D.

Yeh, a while ago when i coded the RHE i talked to Math and he said the same to me. He's recoding some parts of the engine so nearly everything is possible.

Updated.

-Fixed a small mistake when reading room layers, should now work 100% correct.

-Moving sprites: Here is a problem. The JSL is correct, the new loader code is correct and all adresses seems to be correct. Rom runs, but no sprites there. No idea whats going wrong here. Puzz, could take a look at that? I move the sprite pointer table without the pointers above 320 and thought, this were the problem. But adding them doesn't solved the problem and setting them to zero in the original rom doesn't effect other sprites so i guess this isn't the problem. The new loader code is at the and of the sprites.

-Usage improvements: using the program without a room list copies ALL rooms from source to destination rom. Using the program without destination rom and without room list makes a copy of the given rom with moved room data.

-Parallel Worlds rom: Doesn't work properly but will be hopefully fixed in the future.


https://www.dropbox.com/s/gn68y40ndk26hif/RT.zip

All variants (first rom only, both roms, both roms with source and dest rooms), gave me a message: The data to be written would cause a bank breach, can not proceed. Headers are written normally, the layers are written to room 165. So I couldn't see the sprites' code.

Regarding PW. I don't think it will ever work with that rom, since PW has virtually all data relocated.

Damn. Can you send me the rom(s) you tested with? I only have this problems with PW, but with my other roms (original and gates of darkness) it works properly.

Standard US Alttp rom, no header(original) is the rom I used
 
 
Standard US Alttp rom, no header (this version is saved once with Hyrule Magic, while no changes have been made. Hyrule Magic makes his first adopt of the rom)
since the upper one didn't work, I used this one also, same result
 
 
It seems like there's a problem in reading layer for room 166 (until this room, all is fine). This was similar with the previous version. Rooms from 166 on were not working, but from 0 to 165 they were ok.
 
If you could publish the original rom, that you are using (since it works with that one), I could hex analyze it and see which version it is (there's also the EU version). Will try it on Gates of Darkness.

EDIT
Works with Gates of Darkness. Will analyze the sprites, since like you said, no sprites are in the game when loaded in the emu.

I've tested this out. The jsl command will Not allow you to jump past 2MB. So the transfer only works between 0 and 1FFFFF in hex. All the calculations are correct.
----------------------
 
 
reading the code
 
4C296, = pointer 22 D0 D2 43, 43 D2 D0 = 21D2D0, ok, primary jsl jump (but can not jump past 2MB).
 
at 21D2D0
E2 30 A9 43 48 AB C2 30 AD 8E 04 0A A8 B9 30 9C 6B, ok
 
 
30 9C 43 = 439C30 = 219C30, ok, pointer table
 
room 260 = 261x2 = 522 in dec
pointer is B0 CA, B0 CA 43, 43 CA B0, =21CAB0,ok, start of room 260
 
code
00 97 1A 73 FF code for uncle for Gates of Darkness, ok.