 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
1 user currently in Rom Hacking:  hukka |
| Acmlm's Board - I2 Archive - Rom Hacking - Mario 64 - Amazing Stuff |
 |  |  |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| User | Post | ||
Cellar Dweller Flurry !!! Level: 27  Posts: 258/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| The N64 CPU is based on the CPUs SGI created for their workstations and has the same instruction set. The devkit that SGI created for Nintendo probably used the same compiler that SGI provided with their IRIX operating system. What I think is more likely is that Nintendo turned off optimizations while developing SM64 because the optimizations created N64 specific bugs. Another possibility is that the compiler lacked optimization capabilities. Creating a good compiler is hard work, and even good compilers have weaknesses. |
|||
VL-Tone Red Cheep-cheep Level: 23  Posts: 173/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by HyperHacker Yes it's the level selector, that thing:  About the limitations imposed by the scripting aspect, a Mario 64 level editor may end up looking like my StarFox level editor  (which is currently offline) Nahhh, SM64 is different. While SF also uses the same kind of commands, they are used as the level is played, and branching can occur in the middle of a level depending on interactions, it makes it harder to represent the levels as they are and edit them. SM64 loads levels at once, even though some jumping may occur, it's a linear process overall. An editor can simply track down object locations as they are decoded, then the editor writes to those location when an object is modified. But it all depends on how deep we want to edit the game. Ideally, we could create a whole new game using an editor, but yeah getting to that would be hard. But minimally, one could build an editor that can edit the position, rotation, type and other properties of all objects found in a level. One could also build an polygon object editor, where you can move vertices and change textures. So levels would be editable, but like in many level editors, you wouldn't be able to add or delete objects, you wouldn't be able to start from scratch. Same for the polygon editor, you wouldn't be able to add or delete a vertex, or import new models. Removing any of these limitation on the editor could require a lot more work, and could impair on the ease of use of the editor. Also there is still the issue of MIO0 files. Changing a 0x18 command into a 0x17 command to load uncompressed data from the ROM is doable, but can be a little complicated to do. With this method, I was able to achieve this:   Note that it's candy for your eyes only, because there is no IPS patch for it. Anyway it's really too hard to play with the 3d controls and shifting camera and it has some other limitations (no pipes) so I don't intend to spend much more time on this hack. Maybe I'll make a movie if some ask for it, and I can also explain how it was done. Originally posted by Cellar Dweller I was not referring to the way individual functions are compiled, but rather the structure of the level format, and the way it's stored, loaded and rendered. My point was that SM64 DS probably has a more "bloated" structure than the original. They probably made the game much more modular and portable, so they could add new features and retool levels. I remember reading at the time (in 1996) that Mario 64 was running at 50% the speed on their "emulated" n64 running inside the SGI workstations. For some reason, I always felt that this early Mario 64 beta screenshot was probably taken directly out of the SGI "emulator" (I'm putting this inside quotes because it's not exactly an emu)  Anyway, Cellar Dweller, back to more serious things  Do you know how this 0x18 number connects to the routine? Did you find a table where all those command's "opcodes" are stored?Also, when you refer to "segments", is it the same thing as what I'm mistakenly call "banks". If so, it means that the segment table is where segment number's memory offsets are stored, to be used when command 0x17 and 0x18 are called? I guess I'll call them segments from now on So did you find a list of the RAM offsets assigned to each segment? And is it dynamic? |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 260/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| I figured out that it was a function that processed 0x18 commands by decompiling it and by looking at what it did. It calls another function that I had previously decompiled and found out that it loads data from the ROM into RAM and decompresses it. I have not found the main level loading function, but I will be looking for it. I suggest calling them "segments" because that is what SGI and Nintendo call them. The table of segment base pointers is in a fixed place, but the memory for the decompressed MIO0 files is dynamic. I found the table by searching a savestate for a copy of a decompressed MIO0 file, translating the savestate offset into a RAM address(that was the hard part), and scanning for a copy the pointer. The RSP has its own segment table, and the base pointers must be loaded into it using the graphics command I posted the format of in a previous post(we don't need to to this to edit the level; the game code does it using this table). One thing that I should point out is that the game code works with virtual address and the hardware and RSP microcode use physical addresses. The N64 CPU and Ultralib support complex virtual memory layouts. SM64 does not use the complex memory management features available, but instead has a simple relationship between physical and virtual addresses. The virtual addresses have the high bit set and the physical addresses have the high bit clear. Virtual and physical addresses are otherwise identical. EDIT: $%^&$#&^ !!!!  I just found out that not all of the game code is loaded into RAM using the same difference between RAM and ROM addresses. So far, to find the address in RAM of a function found in the ROM I added 0x80245000 to the ROM offset, but this will not work for all code. The loading functions and the table with their addresses has a RAM-ROM difference of 0x80283280. The jump table is at 0x8038b8b8 in RAM and 0x108638 in ROM. The last function I posted has the wrong RAM address. (edited by Cellar Dweller on 09-27-05 06:17 AM) |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7297/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| I don't see why an editor couldn't keep a copy of the script in memory, and just add or remove object commands, then find space to insert it. It'd be difficult, but I bet it could be done. Oh yeah, and  . How did you get the ? blocks, just a texture hack? (Oh, and there are pipes, as seen in the Bowser courses.  )(edited by HyperHacker on 09-27-05 08:57 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 174/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by Cellar Dweller No probalo, I will call them segments from now on. What is the use of the jump table again? When you say that the memory for the decompressed MIO0 files is dynamic, do you mean that when a level is loaded, they are stored one after the other without any empty spaces in between? I guess we could run into problems if we start extending the content of MIO0 files. I'm sure that changing the size wouldn't be a problem in itself, but the game could run out of space to store all the MIO0 and data segments. It will be very useful to know how much total RAM is available for segment data. So continue hacking in that direction, it will sure be useful  Originally posted by HyperHacker I didn't say it was impossible, I just said it would be difficult. When you start managing space and delete things around, especially with variable size objects and with a lot of jumping around in the data, you add much more chance of ROM corruption or other problems. Take a look at level 1, as decoded with my "updated" knowledge. At 2ABF58, 0C 0C 02 00 00 00 00 09 15 00 04 58 command 0x0C assigns number 09 to level 1. When level 1 is called using number 09, the game jumps to offset 0x458 in segment 0x15 where you can find this: 00 10 00 0E 00 40 5A 60 00 40 5F B0 0E 00 02 64 This command 0x00, like the 17 command, copies decompressed data from the ROM into a RAM segment, but it also makes the script jump to an offset inside that segment. In this case it loads data from 405A60, and jumps to offset 405A60+0x0264. Here is the rest of the process, with some objects clipped for space considerations. The first number is the segment number, the seconth is the base offset in ROM of this data, and the third is the offset relative to the base offset. Just add this number to the base offset to find this data in the ROM. In brackets [] is the data found there, and a short description of commands I know about.
The game seems to jump back and forth to segment 0x15 to load and assign enemies to numbers. But there is also a lot of jumping around from and to segment 0x0E to place objects using command 0x24. Maybe there is a reason why there seems to be groups of objects that are accessed like sub-routines, and that messing around with this grouping could lead to problems. I sound a little negative on this, but your original question was "I wonder how hard it'll be to make an editor for a game that uses scripts to store its level data. :-/". So I gave you a taste of how hard it could be to make an editor Now about the SMB in SM64 hack. The '?' block and the brick are texture hacks on '!' blocks. The coin '?' blocks contain coins, and the Power '?' blocks contains a red cap. Bricks contains the metal cap, and another type of block, used for the end of level staircase contains the vanishing cap (not seen in my screenshots). I hacked the decompressed MIO0 data for the '!' textures, then pasted the -uncompressed- data at the end of the 8 megs ROM, with padding to make it a 16 megs ROM. I then went to find the 0x18 command that loaded this MIO0 data, change it to a 0x17 command so it would copy uncompressed data instead, and repointed the offset to where the data was, at 0x800000. I did pretty much the same for the level layout, copying the uncompressed level 1 MIO0 file after the other uncompressed file at the end of the ROM, since I modified objects found inside the MIO0 file, the ones that are documented in a list somewhere in the thread. One of the problem is that the cubes are too big for Mario, but I didn't find available objects that where the right size. Anyway it's already too hard to walk straight on platforms even at this size. The size makes the platforms too high for Mario to reach without a double-jump. Also the block are very sensible to trigger, and will explode even with side collision. Blocks with coins disappear and don't come back like others. Sure I know that there are pipes in SM64 Remember the opening when you first start a new game? The problem is that the MIO0 file that contains the pipe object is not loaded with level 1. Also, pipes in SM64 cannot have a variable height, as is. And lastly, it's hard to stand on those pipes without falling into them as Mario magically avoided to in SMB. My plan was to use logs objects, that I would distort to make them larger, and then hacked the texture so the sides would be green, and the top as a green ring with a black circle. To make higher pipes, I would have stacked them on top of one another. There is also not enough objects space for all blocks in level 1-1.(Edit: I just found out that command 0x36 loads music for the level! Command 36 for level 1 starts at 0x405E60 in ROM, just change the 03 to something else and have fun!) (edited by VL-Tone on 09-28-05 03:55 AM) (edited by VL-Tone on 10-03-05 07:05 PM) (edited by VL-Tone on 10-03-05 07:08 PM) |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 261/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| The jump table I mentioned points to the functions that process the level commands. For example, the 0x18th entry points to the function that processes the command to load a compressed file. I don't think that expanding MIO0 files will be a problem unless they get so big that all of the MIO0 files required by a level will fail to fit into memory. Dynamic memory means that the game code will allocate memory on an as needeed basis, and level data may be placed in different places each time a level is loaded. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 175/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by Cellar Dweller So you mean that these jump points are in order, command 0x00 being the first? This is a great discovery then! About the MIO0 file size, that's what I was saying, changes in individual MIO0 files would not be a problem, but the total size of all segments could be too high. Do you have any idea how much total RAM is available for segment data? As for the segment table, is it reseted each time a level is loaded? Yesterday I found the command to load music for a level (0x36), the byte defining music for level 1 is at 405E66 in ROM, and normally contains 03. Here is the list of possible values (There may be some little mistakes in it, as I was tired when I made this list)
Values higher than 22 seem to be silence, but I didn't check higher than 30 so there may be some other tunes (but I doubt it since the other values seem to cover any known songs in the game) (edited by VL-Tone on 09-28-05 11:55 PM) |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7331/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
Originally posted by VL-Tone Docks, not Rocks. Don't suppose you managed to find the RAM address that selects which music to play? I always wanted that, but couldn't find it... (though I suppose I can look again now that I have this list.) |
|||
stag019 Snifit Level: 23 Posts: 290/299 EXP: 62259 For next: 5464 Since: 06-10-05 From: C:\Documents and Settings\stag019\Desktop Since last post: 9 days Last activity: 7 hours |
| ||
00-nothing Does that look right? |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7338/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| Nothing stands out... Though I did notice something. You say everything after 22 is silent, but some in the middle of the list crash the game. This makes me wonder if some of those could be leftover entries where beta music might have been at one point. | |||
Peardian Lava Lotus The Uncanny Mario Art Master KvSG #87 is up! No Trouter yet... Halloween's over... Turkey time! Level: 58  Posts: 1436/1696 EXP: 1545376 For next: 32170 Since: 07-01-04 From: before 3:00 - school, after 3:00 - Pearl Island Since last post: 7 hours Last activity: 6 hours |
| ||
Originally posted by VL-Tone That could be what's used for the Castle outside. Sorry if I'm bothering you...  |
|||
|
stag019 Snifit Level: 23 Posts: 291/299 EXP: 62259 For next: 5464 Since: 06-10-05 From: C:\Documents and Settings\stag019\Desktop Since last post: 9 days Last activity: 7 hours |
| ||
| No, because there would be bird chirping. | |||
|
Peardian Lava Lotus The Uncanny Mario Art Master KvSG #87 is up! No Trouter yet... Halloween's over... Turkey time! Level: 58 Posts: 1438/1696 EXP: 1545376 For next: 32170 Since: 07-01-04 From: before 3:00 - school, after 3:00 - Pearl Island Since last post: 7 hours Last activity: 6 hours |
| ||
| The birds are part of the music? | |||
TapTap Nipper Plant Level: 24  Posts: 103/405 EXP: 68995 For next: 9130 Since: 08-22-05 From: Yoshi's Island Current Posting Mode: Spree Since last post: 7 hours Last activity: 6 hours |
| ||
| I just really want to say that you guys are doing an awesome job, and I hope in the next few months, you can have a full editor done. You're doing a great job, keep up the good work. VL-Tone, those screenshots ae amazing. | |||
tachyon Octorok Level: 7 Posts: 11/23 EXP: 1089 For next: 359 Since: 07-28-05 Since last post: 5 days Last activity: 10 hours |
| ||
| arrgh! you exeded your bandwidth for the beta shots, which is really frustrating to me because I'm really into beta stuff. no offense, of course, but you should try to get it up. |
|||
|
stag019 Snifit Level: 23 Posts: 292/299 EXP: 62259 For next: 5464 Since: 06-10-05 From: C:\Documents and Settings\stag019\Desktop Since last post: 9 days Last activity: 7 hours |
| ||
Originally posted by tachyonI really don't think that's on his site… Here's the picture from a different site. It's not hard to find...  |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7344/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| Yes, I'm pretty sure the bird sounds are an actual music track. It makes sense, seeing how they didn't put any actual music there; easier to just record bird sounds for the music than to code a random bird sound generator and not use the music track at all. And I was just thinking, in that pic where you remade part of an SMB level, you could play with the 'behind Mario' camera mode. Speaking of which, one of those commands must set the default camera mode. Notice in levels like Snowman's Land and the first Bowser course, it starts zoomed out. (edited by HyperHacker on 09-29-05 11:23 PM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 176/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by HyperHackerOriginally posted by VL-Tone Well I think that the Dire Dire Docks tune Rocks! About the crashing music values, I thought the same, maybe they were used for music that was removed from the beta version. As for the RAM portion that select which music is played, I didn't look for it. I found the 36 command use just by comparing the difference between values in different levels. When I saw that bowser courses had the same values, it became evident to me that it was the music command. You might check for the 0x36th entry in the jump table and try to disassemble the 0x36 command to see what it changes in RAM.Using the behind Mario cam could be useful to run in straight lines, but it's very hard to see where you are going when playing a SMB level with the equivalent of a first-person-view, the best would be to have the camera sideways. I guess that we'll eventually learn more about how the Lakitu cam works, so that maybe we could avoid unwanted shifts in the view angle. Thanks stag019 for fixing my list As for value 0x00, it seems that Peardian is right, by looking at the castle ground level script I saw that it uses value 0x00 for the 0x36 command. I don't know why the birds are not chirping in level 1... Maybe the bird samples are not loaded in level 1? By the way Peardian, you don't bother us at all, don't hesitate to post again in this thread tachyon: no the beta shot was not on my site, I hope I didn't make the guy bust his bandwidth by linking the screenshot directly... Zachio: Thank you for the kind comments,there are much more screenshots that are offline for now, I'm working on fixing that. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 262/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| I have already disassembled the the function that handles the 0x36 command, and have started trying to figure out how it works. You can see what I have so far at http://s91407720.onlinehome.us/acmlmboard_files/romhacking/sm64/proc80380300_set_music_prelim.txt. The top half is the disassembly with decompilation notes on the right side. The bottom half is where I am trying to get an accurate decompilition. Here are a few links that may help with understanding how the music system may work: http://www.halleyscometsoftware.com/mboard/forum.php?showthread=881 http://www.halleyscometsoftware.com/mboard/forum.php?showthread=776 If anyone wants a copy of the disassembler I'm using, I can post a current copy in the commons. I have already posted an older version there, but I have fixed some bugs and added features in my current version. It is a simple command line tool. |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7353/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| Well I could be wrong about the bird sounds. What I wrote may make more sense, but this is Mario 64 we're talking about. And yes, that song does rock. |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| Acmlm's Board - I2 Archive - Rom Hacking - Mario 64 - Amazing Stuff |
| | |
