 |
| 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 |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by VL-Tone |
| Pages: 1 2 3 4 5 6 7 8 9 10 |
| User | Post | ||
VL-Tone Red Cheep-cheep Level: 23  Posts: 161/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 Bio My site was down for a day, the link(s) should work now. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 162/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| The format is pretty complicated, having complete freedom on individual item placement, would generate item data of a different size (this is not unlike compression) and SnowBro put limitations in what you can do when moving items in MetEdit to avoid changing the size of the data. My own Metroid level editor, which is almost finished since about two years, is actually only missing an item editor, and I had plans to implement it in a less limited way, where you could move individual items anywhere, and remove items if the new data size became too big. You can try my (old) Metroid level editor online at http://www.angelfire.com/electronic/dokidoki/zebes.html (edited by VL-Tone on 08-23-05 08:04 PM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 163/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Hi there, gotta keep this thread alive... The image format in Mario 64 and in many other n64 games, is 16-bits per pixel, 5 bits per color channel and 1 bit for alpha, RGBA 5551. To produce my images I used my own program that converts a MIO0 file into an RGBA 8888 (8 bits per channels) RAW file that I open in Photoshop. For some reason, Photoshop defaults to CMYK color when opening a 4 channel file. I converted the images straight to RGBA color. Unfortunately I recently found out that I it still resulted in colors that are off. So it means that all the images I posted until now have wrong colors  Maybe I'm daltonian and I don't know, but I didn't notice it before I'll try to make a batch script to fix them all. As for my level editor, the version online is not really useful now as the included combos mostly work in other levels. You can move and rotate objects though... But my own development version did improve. I recently discovered some key commands used in the object layout data. Take Level 1: You can find this line in a list in my hacking doc http://pages.infinit.net/voxel/Mario64HackingDoc.txt
It comes from this command at 2AC10C in ROM:
The "00" command that is 0x10 bytes long loads and warps to a level. The level layout data is loaded in "bank" 0E in RAM. So 405A60 is the address (in ROM) of where the object layout data starts, 405FB0 is the end, usually where a MIO0 file is (and that file is not necessarily used by this level). Now 0000264 is the entry point inside the level layout data. This is where the game starts to read data inside bank 0E in RAM. (these are symbolic RAM banks, not hard-wired). So 405A60+ 0x264= 405CC4 At this address you get:
Now about the geometry layout data, I wont deconstruct the whole data since I don't know much about it. The data happens to start at offset 0x0440 in bank 0E. As you can see in the command up-there: "22 08 00 36 0E 00 04 40", it's the data to load the grill geometry and associate it with 36.
Ok that's about it as for describing data. (Dang this post is long!) My development program can now show just about every level including most of it's "24" objects. My programs now look into a folder containing all decompressed MIO0 files from the game. So it can now decode just about everything on the fly. This means an eventual editor could feature the actual objects instead of boxes It also decodes the textures directly from the MIO0 files now so the colors are fixed. For now though, it's very slow to load a whole level and I'm still experimenting. One thing that I have to find is how the different body parts of Mario and other enemies are connected, and it's probably in the geometry layout data. Another important thing missing is the connection between commands 22 and level layout found inside compressed data. Those for which there is a description list.One last thing, I put all the pictures I posted here in an album that you can see there: http://pages.infinit.net/voxel/m64index.html Note, the colors are off  (edited by VL-Tone on 09-06-05 03:05 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 164/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 Yeah these are called ASM macro-commands, StarFox uses that too. I don't know exactly how banks are mapped into memory, but from I've looked inside a savestate, banks don't all have the same size. I would guess that their location is always the same though. I'm not sure what you mean by byte-swapping things though everything I posted is in normal byte order. I cannot find your example "01 00 23 45" in my post, what kind of offset were you talking about? Edit: I think I know what you mean HyperHacker... This is from the command that loads geometry layout data for object type 36. 22 08 00 36 0E 00 04 40 0E is the bank number and 000440 is the offset inside this bank. And I'm %100 sure about it since I use it to decode levels. 000440 is meaningful, it's the offset of the first command of the geometry layout data in bank 0E, and it happens to be the grill that appear when using object type 36. Other offsets precisely match. I did not find the use of this command by messing with it and loading the emulator, I found it by figuring out that those were offsets to geometry layout data inside a specific part of RAM, just by looking at the data. Then I did some experimentation that proved it to me. Most everything described in my last post is tried and tested, except things with question marks (edited by VL-Tone on 09-06-05 02:57 AM) (edited by VL-Tone on 09-06-05 03:06 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 165/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| HyperHacker, I guess I over-reacted, but I felt a little insulted you thought I have done a byte order mistake, when I fully knew it was impossible, since all offsets matches and are used in my current decoder version... Anyway I don't do byte ordering mistakes anymore! So like I said, in my example, it's really 0E for the "bank" and 0440 for the offset inside that bank. Here is something very very interesting that I found... Take this command: 18 0C 00 07 00 3F C2 B0 00 40 5A 60 It decompresses the main MIO0 file for level 1 (3FC2B0 in ROM) in RAM bank 07, which is always used to store the main geometry data for a particular level. 405A60 is the end of this MIO0 file in ROM. You can re-point the pointer to the end of the ROM at 800000 for example (don't forget to set the end pointer too), and append a MIO0 file at the end of the ROM. Some emulators may want a ROM with a standard size so you may want to "pad" the rest with "00" or "FF" to get a 12 or 16 megs ROM. It works, I tried it, but you still have to decompress, recompress every-time you make a change... But here is the very very interesting part: command 17 is just like command 18, except that it copies uncompressed data in RAM... So try this: At 405CC8 in ROM, change "18 0C 00 07 00 3F C2 B0 00 40 5A 60" to "17 0C 00 07 00 80 00 00 00 81 17 C2". Then append the decompressed version of MIO0 file 3FC2B0 at the end of the ROM (at 800000), pad the rest to get a 12 or 16 megs ROM. You can then edit the uncompressed version of the MIO0 data right in the ROM!!! As a quick example, you can change the sign object byte (34) that is found near the starting point. Byte 34 for this sign can be found at 1129B in the MIO0 file (81129B in ROM) . You can change it to something else, like 64 for a breakable box. The same could be done for almost all other MIO0 files. The only problem with this would be making patches for hack distribution, but still, for now it can be very useful to experiment without having to decompress and recompress data all the time! (Edit: added an example hack of level 1's MIO0 file) (edited by VL-Tone on 09-06-05 11:04 PM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 166/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 All the MIO0 files decompressed amount to a little less than 8MB so doing this for all files would get us a 16MB ROM, though you could use the compressed MIO0 file space in the first 8MB for other things. What is the biggest possible size for a n64 ROM? In any case, compressing the resulting ROM or patch using ZIP would probably save us as much space as using MIO0 compression. Yeah I'm pretty sure there is a table for the "banks" locations, I didn't look for it yet though, one way to find it would be to find where bank 07 is in RAM, then looking for this offset inside the ROM. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 167/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 Nebetsu lol, I'm a man, and hetero at that (oh well do I really have to specify that in a ROM hacking forum?) So you just read all pages of this topic in one stretch? How much time did it take? I wish I had more time to spend on this, fortunately I will be able to post more often in September. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 168/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 I knew that it's September , so what I mean is that I have more time, starting this month, I guess I should have just said that As for a dump of bank 7, if you are in Level 1, it should contain in RAM the decompressed data found in the MIO0 file found at 3FC2B0 in the ROM. It starts with:
|
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 169/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 You mean that this 32-bit word points to a location in RAM that contains the level data? Or does it contains the address of the compress data in ROM which would be 3FC2B0 for level 1? Also, could you post some of the data found at address 0x33bb60 in a PJ64 savestate so I can find it in my own savestates? Don't ask why, but I don't have access to PJ64... HyperHacker, look at this picture: http://membres.lycos.fr/nes3d/Mario64InsideCastleRooms2.jpg You'll see where this cloud textured plane comes from. I guess most people don't know this, but if you switch to the head/camera mode and you look inside the entry holes for Rainbow Ride and the Secret star in the sky which is in the opposite wall, you'll see clouds at the bottom. I removed the level editor link from my sig, because it's far from being up to date, and actually the "combo list" is almost useless since it contains objects from all levels, combined in numeric order. I now know that, for example, object type 36 means something different and needs a different behavior depending on which level you are in. (Command 22 in the object layout data decides what is associated with number 36) My own internal "evolved" version that can open almost all levels and display objects as they are is really not ready to be published. For one thing it needs a folder containing all decompressed MIO0 files to work. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 170/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 It was the most recent public release on my download page (dating from july). Unless you want a very buggy update, you'll have to wait until I release a useable version. With all my recent discoveries, I have many things to add and test. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 171/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Well all my pics are gone for now, so I guess there wont be much useless eye-candy left in this thread  I will have to build myself a script to change all the images urls in my posts. I hope to fix that in the next week.Until then, there is still enough textual info for someone to build a usable Super Mario 64 Level editor that can edit shapes and level layouts. You can look inside http://pages.infinit.net/voxel/Mario64HackingDoc.txt for a few of the basic offsets and format description, but this doc would need to be updated with other info found in this thread. And there may be a couple of things I forgot to post about. Anyway...BGNG, you are doing great things with both F-Zero and now SM64 DS I wish the n64 version was as neatly organized as the DS version.I will venture to ask the un-ask-able, why dont you build a SM64 editor? You would obviously do a better job than me. Anyway these days I\\\'m busy and need to take some time off the internet. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 172/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Cellar Dweller: Wow that's looks neat, continue your great work But ehm...could you put it in context? I don't know how to connect this to what I know about Mario 64. What is the mystery struct? BGNG : About that BASIC compiler, this is really neat, I assume it will be able to use the touch-screen? You know what would make an ideal DS development tool in my mind? That it include a graphic and sound library manager. A window would contain a list of thumbnails of graphics and sound in your game, and you would be able to import more, copy and paste, and do some basic editing and conversions between native DS graphic and sound formats. You could give them names and refer to them in BASIC code by name or ID number. Anyway it's just an idea, even without that, a BASIC compiler for the DS is just too cool Super Mario 64 really seems to be optimized for speed and space, it uses what some call "Macro ASM commands". One byte is the opcode and the following bytes are parameters for this particular command. These commands can load things into memory, draw levels and objects, and do just about anything needed in the game logic. Some command jump to other addresses in the ROM, some commands to jump back. Sometimes there is a lot of jumping around, and it really has the overall structure of an ASM program, though it's probably automatically compiled from some higher level language and/or a custom level design tool. Overall it really is close to the way the SNES StarFox works. I read that SM64 originates from late experiments with the FX chip. I traced back (manually) the main command that loads Level 1 in ROM: 2ABF58: 0C 0C 02 00 00 00 00 09 15 00 04 58 Bank 15 contains data starting at 2ABCA0. So this 0C command makes the program jumps to 0x458 + 2ABCA0. From there it makes another jump using 00 10 00 0E 00 40 5A 60 00 40 5F B0 0E 00 02 64. (it loads data from 405A60 into bank 0E and jumps to offset 0x264 there) Following the program from there loads the whole level. If you look around 2ABF58, you'll see other 0C 0C commands. Each level seems to be assigned an ID number, for level 1 the number is 9. Others have negative values, like the different modules of the opening and game over sequence. For example FFFFFFF7 (-8 in decimal) is the id for the debug menu. It jumps to offset 0x0268 in bank 15. So if you change 15000458 to 15000268 in the ROM you'll get the debug menu when you enter level 1... It doesn't really work like it should, you can still try it because it gives weird results Macro ASM commands found at 2ABCA0, 2A6120 and 269EA0 seem to be the heart of the game level loading logic. The first address gets loaded in bank 15 while the two others get alternatively loaded in bank 14. There is a lot of jumping around between those banks and it's hard to track down where the main entry point is. I suspect it's at offset 0 in bank 15 (2ABCA0). In this area I also found a lot of text: 265980: a lot of text there, seems like classes and routine names (C++?) Just before that there are some uncompressed textures used in the Mario rubber face demo. There is one routine named "yoshi_scene"... Text at F2E20 seems related to the game engine. DPRINT OVER mapinfoarea xwx dwy dwz dbgY dangY dbgcode dbgstatus dbgarea dwater At F44F0 there is text about more low level stuff like AUTOSEQ AUTOBNK FIXHEAP DMACACHE at F4DAB you can find this:
Kawa-oneechan I never give you the finger, I expressed my opinion about this, I personally don't like to hack a recently published game. Then other people added their opinions about it, and it caused some backlash reaction to your mention of SM64 DS. So since then I felt bad about it, and it was obvious that you stopped posting in this thread because of this incident. I expressed that while Nintendo tolerates hacking older games, this is pushing the envelope a little. But, at the same time, I think Nintendo likes that more people learn to program the DS. They've dubbed it the "Developer System" after all. I'm thinking more and more about trying to develop a game for the DS. In any case, I don't want people to stop posting about the DS just because I said that I didn't want to hack SM64 DS. If you continued to post about SM64 DS I wouldn't have said a word about it, I would simply continued to focus on the n64 version. I suspect that the formats are different. From what I know about it, they probably did a complete remake of the game using data and documentation from the original, unlike the All-Stars and Mario Advance series, which are more or less "ports" of the original code. I think that they wanted to have much more freedom to redo and expand the game by doing that, and they probably designed an improved level editor for it. I suspect that they planned ahead and made it possible to port it for the Revolution. Why would they do that? How about an online multi-player version of Super Mario 64 with up to 64 players? That would be fun! |
|||
|
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? |
|||
|
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) |
|||
|
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) |
|||
|
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. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 177/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 stag019 I'm not sure what is your question, maybe I didn't explain it well. I simply used my level decoder to output the level layout as formated hex. Then I looked for the 0x36 command inside a few levels. I knew that Level 1 had value 0x03 and then found that Bowser's courses all had 0x11 as a parameter. I could have been wrong, but it turns out to be the music command as I thought. Part of my SM 64 hacking has been like that, figuring out commands by looking at them and their context, and trying to guess what they were used for, and I was usually right, since I already did the same for a similar script format and commands in StarFox. Many of these commands crash when you change a parameter to a value that is not valid, so I couldn't just "corrupt" each of them and deal with repeated emu crashes and weirdiness until I found a correct value that could show the function of each commands. Anyway, the jump table Cellar Dweller found, will be very useful, but my "intuition" can also have it's purpose, as it's not always obvious to find the purpose of a command by looking at the ASM that powers it. Cellar Dweller: I don't know much yet about USF music ripping (yet), do these people have to figure out the actual format of the tunes? Or do they rip out the music playing code and the data without knowing the details of the format? I always suspected that in SM64, music was in MIDI format, or a variation on it. Obviously, the songs were played on a MIDI keyboard and recorded in MIDI format. Part of the Dire Dire Docks song (which rocks ), seem like it was played "live" by Koji Kondo on a pressure sensitive keyboard, as there is a human feel to variations in the intensity of the notes.Also, I looked at the disassembled code, I noticed the off0x36 and off0x38 at the end, does it mean that command 0x38 also loads music? |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 178/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 stag019Originally posted by VL-Tone oh you mean something like that? Haunted House It seems that more than one 0x36 command can be found in one level. Often, it's used for the hidden slides music. Also while the 6th byte is the song number I identified, the 4th byte is unknown to me, so I'll let you the pleasure of finding it yourself I'm still working on the editor, but maybe it would me more fair to say "I didn't abandon working on it" since I didn't work much on it lately. The main problem is that the newer decoder is incompatible with the editor part, so I would have to make some major changes. Also my new decoder gives me errors while loading some levels, and I didn't feel like debugging it... Anyway until I move to a new host I won't release an update.Cellar Dweller , that 4th byte must be the one you were talking about. As for MIDI, with what you've said, I'm now pretty sure we'll find MIDI files somewhere inside Mario 64, they may not have the standard MIDI header, since I didn't find any instance of it (it starts with "MThd"). (Edit: forgot to address the part about my editor) Edit: Forgot to tell you about some finding I made yesterday. I confirmed that Zelda: Ocarina Of Time, does indeed uses the same polygon object format (with a few new commands). I thought it was a given, but it's nice to see it confirmed (looks like I'm replying to myself). There are a whopping 1400+ Yaz0 files inside OOT (is my decoder buggy or there are some big empty spaces found in some of those?). Anyway Mario 64 fans, don't worry, I won't spend more time on Zelda OOT anytime soon. And to Zelda fans... sorry (edited by VL-Tone on 10-03-05 03:45 AM) (edited by VL-Tone on 10-03-05 03:46 AM) (edited by VL-Tone on 10-03-05 04:02 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 179/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 but not as much as you may think. Along the way, Nintendo switched tools, and most third parties used their own format. As for why there are four 0x36 commands in Tall Tall Mountain? This is a very interesting question The first command triggers song 0x03 which is Level 1's song also used in TTM. The three others trigger the slide music... I'm not sure why there are 3 of them. It seems that the level layout data is grouped in 4 main groups. They end or start with 0x31 and 0x20 commands. Are there 3 way to enter the TTM slide? I don't know yet what enable switching between those groups. Actually I found something not so far from that, but it's not directly connected to the groups, I cannot find any offsets referring to them. So what I found is the main use of the 0x26 command. It's used to connect warps, doors and slides! Let's take a look at part of Cool Cool Mountain (which is easier to understand than TTM) 395F04 [24, 18, 1F, 00, FA, 18, 0D, E8, F6, FF, 00, 00, 00, 8C, 00, 00, 00, 0A, 00, 00, 13, 00, 2F, 74] I included the 0x24 commands that are before the 0x26 series because they are connected to the 0x26 command. These objects have a type byte of 00 so they are invisible, depending on the behavior associated with them, they can be an entry or exit point, a warp, a room transition. The 18th byte of these particular commands identify them, and these id numbers are referred by the 0x26 command. The first one has id 0x0A and behavior 13002F74 which is the behavior for Mario's start position in the level. Id 0x1E is for the chimney entry, id 0x1F and 0x20 are warps on the broken bridge on top and bottom of the mountain. The first 0x26 command puts Mario at the starting point of the main level, pointing at the 0x0A position. For some reason, changing the values for this particular command have no effect. I'm not sure if the second command is even used. It warps to the wooden house at the bottom of the slide, like you entered it by the door (which is impossible normally since the door knob disappear when you exit the slide bottom house). The third command is more interesting , it's the warp to the Penguin Slide. 395F74 [26, 08, 1E, 05, 02, 0A, 00, 00] 1E is the entry point, in the chimney. I don't know the use of the 0x05, it's value can vary in other levels, commonly used values include 0x05, 0x06 and 0x24. The 0x02 (fifth byte) selects the slide level, and 0x0A is the id of the position inside the slide area (which is not the same as the 0x0A position in the main level). The fourth and fifth commands warp between the two bridges, from position id 0x1F to 0x20 and back. This happens inside the main level as specified by the 0x01 value. 395F7C [26, 08, 1F, 05, 01, 20, 00, 00] 395F84 [26, 08, 20, 05, 01, 1F, 00, 00] The two last commands are for the level exits,either by dying or taking a star. 395F8C [26, 08, F0, 06, 01, 33, 00, 00] 395F94 [26, 08, F1, 06, 01, 65, 00, 00] F0 is for successful exits and F1 is for a failed attempt. The 33 and 65 values point to the Cool Cool mountain paintings inside the castle. If you change the 0x01 value to 0x02 you can access paintings found higher in the castle. So have fun experimenting with changing those values (edited by VL-Tone on 10-04-05 04:27 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 180/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Dang my Cable Modem ISP (videotron) has been down all day yesterday... Anyway the good news is since I didn't have the net to waste my time reading digg.com I did spend some more time on hacking Mario 64... The result? I found that the 0x26 command can be used to warp at any entry/exit point in the game instantly! From CCM: 395F84 [26, 08, 20, 05, 01, 1F, 00, 00] This command will warp from warp 0x20 in the current level area to Course 0x05 (CCM) --> area 0x01 --> entry point 0x1F. Using the good old SMB level number syntax, it could be written as 5-1-1F. At 2ABE8C in the ROM you can see a bunch of 0x0C commands. As I explained somewhere in the thread the 0x0C command assigns id numbers to levels, storing the related pointers. The 0x0C command at 2ABE8C as an id number of FFFFFFFF and this means -1, the negative values are assigned to title screens and menus. Somewhere after that you'll find 0x0C commands with positive id numbers that refers to levels, and the one with id 00000005 is incidentally Cool Cool Mountain. Also from CCM, the death exit warp is 395F94 [26, 08, F1, 06, 01, 65, 00, 00] 0x06 is the inside of the castle, 0x01 is the first floor area and 0x65 is one of the two exit point from the CCM painting (could we call it Level 6-1-65?). The successful exit point for CCM is 0x33, as defined by a 0x24 command and associated behavior. This means a level could exit to two different locations in the same room as the painting. But like I said, the game can warp to any other exit/entry point in any level. The only problem I found is when you assign an exit with a success painting exit behavior to a non F0 or F1 0x26 command, it will freeze after playing the animation (just like the Castle courtyard I experimented when swapping painting entry points). Note that the painting entry points doesn't use the 0x26 command. If you jump from something that is not a real "warp" to a real warp exit point, you may not have time to regain control of Mario before he gets warped by the warp point he's standing on. (by real warps I mean place you stand and fade away) Other than that, you can warp to anywhere in the game. There are 177 0x26 commands found in the level data. Some may have duplicate "warp to" values, but from a rough estimate there are at least 100-150 different places Mario can warp to. I made a cool little program that I will probably publish, called "Super Mario 64 Shuffle". It randomize entry and exit points in the game. This can lead to a very fun game (or one that is pretty limited depending on how you are lucky). Every-time you enter a double door or jump into a hole, use a warp or enter a mini game inside you will have a surprise. I didn't randomize the death/completed exits values, but that could be an option. I'm thinking also of adding a "shuffle paintings entries" option too. Ideally, one could patch the 0x26 command so that it always warps at a random place. So any-how, more serious applications includes very complex mazes, and the "fight all bosses , one after the other" hack that was requested before. In other news, I found Yoshi! Well I mean I already found the geometry a while ago, but now I found the 0x24 command that places Yoshi on the top of the castle. The command is at 454ACC, Yoshi type number is 0x55 (for this level only). Its behavior (13 00 45 38) only makes it appear at specific conditions so we'd have to use another behavior to make him visible. Unfortunately I didn't find a behavior (yet) that makes it behave like he should. In the mean time, I found that the butterfly behavior on Yoshi gave very funny results. at 454ACC in the ROM, replace: 24 18 1F 55 00 00 0C 66 EA 07 00 00 00 00 00 00 00 00 00 00 13 00 45 38 With: 24 18 1F 55 FA D0 01 04 12 38 00 00 00 00 00 00 00 00 00 00 13 00 33 BC You'll get an epileptic Yoshi hovering above the ground like a butterfly... Very funny! While you are at it, look at the few 0xBB values just before that, used in 0x24 commands, change them all to 0x55... Now you get levitating epileptic Yoshies everywhere on the Castle grounds!Have fun! (Edit: Hmmm have I said or did something wrong? None has been replying to this thread since the last 3 days! Should have I provided an IPS patch and/or screenshots? Maybe I offended some by mentioning epilepsy? Ah well I guess that all the usual contributors have better things to do these days...) (edited by VL-Tone on 10-05-05 04:49 PM) (edited by VL-Tone on 10-08-05 09:50 PM) |
| Pages: 1 2 3 4 5 6 7 8 9 10 |
| Acmlm's Board - I2 Archive - - Posts by VL-Tone |
. How did you get the ? blocks, just a texture hack? (Oh, and there are pipes, as seen in the Bowser courses. 