Unlimited room header! And the RT (Room Transfer) program

Page 3 of 6 Previous  1, 2, 3, 4, 5, 6  Next

View previous topic View next topic Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Sun 11 Aug 2013 - 5:00

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

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by Puzzledude on Sun 11 Aug 2013 - 14:31

This is beautiful. Very well made Very Happy. 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.
avatar
Puzzledude



Since : 2012-06-20

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Sun 11 Aug 2013 - 18:02

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.

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by Puzzledude on Sun 11 Aug 2013 - 18:27

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. Smile
avatar
Puzzledude



Since : 2012-06-20

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Sun 11 Aug 2013 - 18:45

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

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Tue 13 Aug 2013 - 6:46

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

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by Puzzledude on Tue 13 Aug 2013 - 8:09

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.
avatar
Puzzledude



Since : 2012-06-20

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Tue 13 Aug 2013 - 8:15

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.

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by Puzzledude on Tue 13 Aug 2013 - 8:27

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.
avatar
Puzzledude



Since : 2012-06-20

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Tue 13 Aug 2013 - 8:37

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.

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Tue 13 Aug 2013 - 8:51

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 :-)

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Sun 18 Aug 2013 - 9:46

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?

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by Puzzledude on Sun 18 Aug 2013 - 10:31

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.
avatar
Puzzledude



Since : 2012-06-20

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Sun 18 Aug 2013 - 10:45

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.

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by Puzzledude on Sun 18 Aug 2013 - 11:17

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.
avatar
Puzzledude



Since : 2012-06-20

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Sun 18 Aug 2013 - 11:23

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.

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Mon 19 Aug 2013 - 9:01

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

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by Puzzledude on Mon 19 Aug 2013 - 9:25

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.
avatar
Puzzledude



Since : 2012-06-20

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Mon 19 Aug 2013 - 9:34

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.

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by Puzzledude on Mon 19 Aug 2013 - 9:41

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.
avatar
Puzzledude



Since : 2012-06-20

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by Puzzledude on Mon 19 Aug 2013 - 11:48

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.
 
avatar
Puzzledude



Since : 2012-06-20

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Mon 19 Aug 2013 - 13:20

Damn.....thank you for your efforts.
At the moment i figured out that there is a significant problem reading the room layers. To certainly identify all 0xFFFF's is not that easy it sounds like. I will try another (the 6th?) idea now and hope this will work. After that i come back to the sprites. It's no problem to write the sprites to bank 0x3F (the last bank in the 2nd MB), so i will try this.

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Mon 19 Aug 2013 - 17:59

Ok, got it now. The last few hours i had trouble with a strange memory leak, but not in the code that handles the room transfer. The problem occures when creating the new rom name. No idea whats happen here, the debugger can't help me. For the moment i need to use a hardcoded name "_Zelda3(U).smc" for the output rom. I will fix this.

But good news: Thanks to your hint with the jsl, the sprites work now. I write them in the last bank before the 2nd MB starts, this is bank 0x3F. The layer code also works properly. And against all odds, the PW rom works too :-)

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

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by Puzzledude on Mon 19 Aug 2013 - 18:50

This is great news. I will test and analyze the code in hex tomorrow.
 
Meanwhile I've tested the header some more. If hole/warp, staircase1 or 2 are not in the room, their value is irrelevant. But with staircase3 and 4, which are also Door1 and 2; this special transit will not work in bg1. In fact it need a special door to make the transit, namely type 35 (which is displayed normally only on bg2).
 
This is good news, since we know, that if there's max space for the header, all values must be filled (with room 0 by default). If on bg1, it is impossible to use type 35 (door is not displaied, will not go through), but if type 0 or all other, it will transit normally (it will not go into room 0). If on bg2, if will never go to room 0, if the door goes up or down. So the effect door1 is room 0 will only work on door which leads left or right and only if type 35. If type 32, the transit is normal.
 
So if don't use doors type 35, the additional expanded header will never bug the rom.
avatar
Puzzledude



Since : 2012-06-20

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by XaserLE on Tue 20 Aug 2013 - 4:27

This is perfect, so we don't need to care about the additional bytes, awesome!

XaserLE



Since : 2013-01-22

Back to top Go down

Re: Unlimited room header! And the RT (Room Transfer) program

Post by Sponsored content


Sponsored content


Back to top Go down

Page 3 of 6 Previous  1, 2, 3, 4, 5, 6  Next

View previous topic View next topic Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum