 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by VL-Tone |
| Pages: 1 2 3 4 5 6 7 8 |
| User | Post | ||
VL-Tone Paratroopa                  Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
I love beta stuff!  Too bad there is not much of it left inside SM64. Like HH said, there is a lot of cool stuff in Zelda OOT. I found a lot of jpeg files in Zelda, some I think are unused, but I'm not sure since it's been a long time since I played the game trough from start to finish.
This is the Yoshi beta egg in Mario 64. 
And here is the normal and "metallic" wings textures. 
The metallic wings can only be seen if you take a wing cap when you are metal Mario, which is not possible in the original game. You need a GS code or a level editor to do this: 
Aside from that and the debug stuff there is an unused animated flower which I'm too lazy to find now, but that's about it, I didn't find any unused level parts or enemies. There is an invisible 0x24 object over the "Luigi is Real 2041"/"Eternal Star" sign in the castle courtyard, but as far as I know it doesn't do anything. For those who still don't know, you cannot find Luigi in an unmodified Mario 64 ROM! This SMB3 beta stuff made me think about the infamous "Super Mario Bros. 3 Lost Levels" http://www.themushroomkingdom.net/smb3_lost.shtml, which I feel should be more publicized since some of them are really neat, yet only a few people know about it among the millions who played the game. The levels are in the ROM, and you can see them in a level editor, but you need a patch to put them on a map. Oh well, first post since the "Game Aver". How is it going in here guys? I'll try to post a new thread soon to tell you about the status of my Mario 64 level editor etc. (edited by VL-Tone on 12-08-05 04:34 AM) |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
Hello there, long time no see By the way you guys are doing amazing hacks, many of you have great design talent 
Here is a silly screenshot of a Mario 64 hack I made. 
I call this one: "Too many Yoshies" The game slows down to a crawl when there are too many Yoshies!  You can go talk to each one and they'll tell you the same story, then jump in the waterfall and disappear. Actually that's why I had to put the Yoshies on the roof, because they disappear when they are lower than a certain Y coordinate.(edited by VL-Tone on 12-08-05 05:05 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
Originally posted by Gavin Thanks I just got myself a nano, I put all my Mario 64 hacking screenshots on it so I can show them to my co-workers, though the screen is pretty small. But I wanted portability and a color screen, so nano was the smallest and cheapest 4gigs flash-based mp3 player.
Anyway, moving back to the topic: 
Yeah I managed to replace Mario with Yoshi. As you can see though, aside from the head and upper body, the other body parts are acting crazy because the motion capture data is made for Mario. It will be possible to do better than this when I understand more of the "Geometry Layout" format. The other problem is still that the Yoshi MIO0 file is only loaded in the Castle Grounds level, so the game crashes when you enter the castle. Oh and I'm sorry, no IPS patch for now, it's a screenshot thread after all  |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
| Oops, I didn't even see that thread...
Look again HyperHacker, Mario's butt is actually a separate part There is an upper body part, and lower body part, acting as a butt, and making the pivot for the legs.
But yeah ShadowSonic, you should use that Nemu plug-in, since exactly recreating 3d objects from sight is not easy. Unless this is what you wanted as a challenge. At 0x1279B0 in the ROM you can find the geometry layout data for Mario. It's extremely complicated and lengthy compared to geometry layout data for other characters such as Yoshi, as there are different versions of Mario depending on the distance from the camera, and some other stuff complicate its layout data. Look for the "15 04 00 00" commands in this data, the following 4 bytes are pointers to geometry data inside the Mario MIO0 file found at 0x114750. Example: 15 04 00 00 , 04 01 DD E0 points to some Mario body part (I haven't documented which ones are which yet). 04 is the RAM segment number, and this segment happens to contain the Mario geometry MIO0 file. So at 01DDE0 in the MIO0 file you can find that body part geometry data. I'm still figuring out the format of this data, but I'm progressing, and I know some commands can scale geometry parts, as I found the command that scales Tiny/Huge Island. It doesn't automagically scale the collision data unfortunately, but I could scale the collision data vertices positions to match the change. So maybe there are commands in that data that scale individual body parts for Mario, but you could also swap/replace the pointers found in the 0x15 commands, to make some parts disappear. More about that, eventually |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
Originally posted by Risio Unfortunately, this is a recurring problem in Mario 64 hacking: the MIO0 (compressed) file containing the Yoshi egg is not loaded in every level so the game will crash if it has to show a Yoshi egg and the MIO0 file is not loaded. The blue Thwomps are in the same file, so it would ony work in levels that have blue Thwomps. It maybe possible though to move the egg data into a MIO0 file that is always loaded, but it would require more than a GS code... Anyhow, I don't want to turn this thread into a M64 thread. I'll try to keep that in mind as an interesting hack to do. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
Did you also search for 2A00E0D1? (BADC format) there's two instances of it, close together and part of a list of similar pointers.
|
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
| Take 3! I hope to be more helpful this time...
The game is probably copying some chunks of ROM data somewhere in RAM when it starts up, or when a level is loaded. The pointer table you are talking about may be copied as part of a bigger RAM segment so its RAM offset is not directly/logically related to its ROM address. And that's also why you cannot find a pointer directly referring to the start of this text pointer table in ROM, since its not at the start of the copied data chunk. You'd have to find out more about how the game manages ROM to RAM copying to find the exact answer, ideally using a tracer... If you subtract 0x800398A0 from each offset in the text pointer table you can find the ROM position of the text. Subtracting the same number from other pointers that are just before the text table and text. At 0xDF934 for example, you'll find the smallest pointer of this bunch: 0x801190F4, if you subtract 0x800398A0 you get 0x0D54F8, which is where you can find the beginning of a data pattern starting with 00110000. The pointers following after 0xDF934 also lead to coherent results when you do the same subtraction. Obviously it doesn't work for all the pointers in the game, but only those part of this "segment". If you can find the start address in ROM and RAM of this particular segment it would help you very much. By comparing this part in ROM and its "mirror" in RAM near 0x801190F4, (using a savestate for example) you may be able to find where it starts, just go back until the data doesn't match and bingo! |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
| Ok I guess I have to answer this one... If this is an disguised attempt to get me posting about my editor well you won
Racoon Sam you may be interested in the following: I'm currently working on a level editor for Mario 64 that will take care of the hex and MIO0 stuff for you, this editor will enable you to fly through all levels and you'll be able to move and rotate all objects, switch them to other objects, you'll also be able to view and replace textures. The editor will probably feature an expert mode which allow more things to be changed. The geometry of the levels will be editable eventually, but probably not for the first public release. The release will be PC and Mac compatible, because yes I do work on a Mac. I'm using Macromedia Director which can produce programs for both platforms. I may eventually move to Java, if I find a good 3d API. (side note: I'll buy an intel based Mac probably soon (the rumor is January '06), so I'll be able to run all Windows ROM hacking utilities at almost full speed, inside OS X using Virtual PC or DarWINE, or by dual-booting with XP.) Currently, my development version can recreate all levels almost intact, though I would say 2 or 3 levels are missing some big parts. The objects in levels are displayed as wireframe boxes and most of the time the polygonal version is also present, and will move/rotate at the same time as the box. Many objects inside levels still don't show as polygons, and that's why the boxes can be useful. There are two types of objects that can be edited, and each have a different set of polygonal objects available. To change the type of an object you can access a menu that scrolls from the right that only the objects that can be used in this particular level, since not all objects are available in all levels. At the top left you have a list of object types that each have their own custom item editor, some of them will only appear in the expert mode. At the bottom left is a list of the objects of a particular type found in that level. You can click on objects in the list at left to select and edit each of them. As for polygonal objects, you can either type a new position or rotation angle, or use the arrow buttons and rotation controls. The public release will include keyboard control for position and rotation. I also added a feature where when you click on an object in the list, and the camera will be relocated near the selected object, pointing at it so you can see it. I'll add a button and/or key to turn this on or off. I will also add the option of having the camera following the selected object while you move it. Also planned is a bookmarking system for camera positions. This is a photo of a prototype, Don't pay attention to the Rotate Cam and Select Object buttons, as they are badly scaled (actually, it's more of a mask problem). And the whole interface is far from final anyway. 
So I guess what you and many want to know is when will I release it to the public? I can't promise anything, but I guess that the first public beta will be released in the first or second month of 2006. Also, by then my site will have moved and will have a complete redesign. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
Originally posted by Raccoon Sam I'm not sure I'll make my own complete hack, I would rather spend the time improving the editor
But at least I may make a 1-2 levels hack. Originally posted by HyperHacker I think you got it backward. What's in the ROM IS the binary format, and a higher-level structure/language was used to make levels in their own editor. Levels scripts are essentially a "compiled" series of commands. Nintendo's own m64 level editor probably saved uncompilled versions on disk, that had "labels" instead of actual ROM/RAM offsets, when the level is compiled those labels are replaced with real offsets. I don't see how knowing what every command would enable us to recreate the exact same pre-compiled format that Nintendo uses. At best we could create something simillar in structure, but not more than that. It seems to look so obvious to you, but how the heck would I know Nintendo's own format for their own Super Mario 64 level editor? You seem to think it's in some very generic format, it's more than probably the oposite, a very custom format. Your premise seems to be that I'm doing it the wrong way and that I should instead decompile all commands and figure out what they do before doing anything else. Well in an ideal world this would be the best solution, but while I have experience in decompiling ASM (I did my own diassembler for StarFox), I don't know much about the MIPS processor. So if anyone wants to do this part they should go ahead, but I'm sure what I'm doing will be also helpful, as disasembled code is not always obvious without some other cues. If I didn't already figure out %90 of the level script commands with my own custom tools and by looking at the data and experimenting, it would have been much harder to figure out all commands only by disassembly. I'm not trying to dismiss the use of command disassembling, but don't expect me to do it unless I cannot figure out a command by other means. For know, I know of enough commands to build a useful editor. If you and/or Cellar Dweller want to disassemble and figure out all commands, go for it, it would be helpful for sure. I could help you and you could help me, but all in all, lets do it for the sake of Super Mario 64
Unfortunately, I'm going on xmas vacation until dec. 28, and won't be near the internet, so you'd have to start without me
Edit: Since it's most likely my last post before the 25th, I might add: Merry Decemberween to everybody at the acmlm board! (edited by VL-Tone on 12-24-05 12:35 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
| Back from snowy vacations!
Ok I guess I understand what you mean now HyperHacker. Here is how my editor currently works: When you load a level, the script is read and decoded, and objects are added to list variables. There is one list per type of object, and these lists are combined into a meta list. Each item in the list contains the offset in ROM of this particular object, and its content. After the level is loaded, the editor works from these object lists and doesn't have to redecode it each time. It's not so far from the XML model you described. Actually, Director includes XML tools so I could use them to make an XML file that could be saved. The only problem I could have is if I wanted my editor to be able to insert new objects. I don't know the exact reasons why the script has this structure. Here is a simplified "typical" level script. The level starts to be decoded at 09C, as specified in a 0x00 or 0x01 command. These two commands load the chunk of ROM containing the level script into a RAM segment, then jumps at a specified offset. As you can see, the 0x24 commands are placed before the start offset.
These are what I call the macro objects, and they are the objects you made a list for in the old thread. Fortunately, this list is linear, but unfortunately, this data is sometimes sandwidched between geometry data inside a MIO0 segment, so to expand the list I would need to move things around inside the MIO0 file, which is far from being easy to pull off at this point since there are still a few unknown commands and data in there. If I move data that is refered by a command I'm not aware, it will cause problems. I recently found that at EC7E0 there is the list of predefined behavior and object id's used by the 0x39 objects. For example 1300472C 00C0 0001. First is the behavior pointer 1300472C, then 00C0 is the object id as defined by a 0x22 command, and the two last bytes are parameters for the behavior.
After that there are a few other commands that ends the script I don't know much about yet. 0x02 is the End level script command. So... All that to show you a typical level's "skeleton". As you see in this example there are three "groups" of 0x24 commands that are loaded using the 0x06 jump command. I don't know why these are not put there in a linear way, since they are found in the same segment. There must be a reason for this, maybe for object clipping or z-sorting. So if the user wants to add an object, in which group should it be put? I guess I would have to deal with the group aspect in the interface and make the user chose which group. Level scripts could be recompiled without much trouble, but as for what's inside the main level MIO0 files, that's another story. At best I could expand these and relocate the 0x39 data at the end of the MIO0 data, or maybe even insert it in the level script segment. The other main problem with inserting new objects is that too many objects could crash the game. The original Nintendo editor must have had tools that calculated how much RAM was needed to load the level they were working on. We don't have these tools, and I don't know enough about the n64 and Mario 64 engine to do that, as there are too many factors involved. I guess that the debug features of Mario 64 could help, but I don't want to release an editor that has too much chance of making a game crash and require using the debug code. There must be other limitations than RAM itself, something like a limit on the number of individual polygon models the game can keep track of. I know you want to steer me into doing a very flexible complete editor with a clean format. But while the idea of decompiling/recompiling the level data is simple, in practice it involves many little things that add up, it will require a lot of work and planning, and that "only" to be able to insert objects, which may cause problems by itself because of the engine and hardware limitations. I work toward this kind of flexibility in editing, but I don't want that to stop me from doing things I'll have to do anyway, and that may be useful in creating a decompiled level format. Lastly, here is another screenshot, in Tick Tock Clock as requested. 
Click there for a full version: http://i26.photobucket.com/albums/c105/Starxxon/M64Edit4.jpg |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
Originally posted by Raccoon Sam Well I only found a few little things, mostly textures. Look in this thread to see some of them: http://board.acmlm.org/thread.php?id=794&page=1 |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
Originally posted by HyperHacker So then I agree with you, we should ultimately work on making an open-source XML format to store the Super Mario 64 raw level scripts, but not now Still, your post got me thinking about the possibilities. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
| Hey Cellar Dweller, welcome back!
I wrote a long reply the other day, but somehow lost it before I could post it (by closing the browser window, doh!). I was a little discouraged by this so I took a few days before making another post. That flat text output idea makes me think about my (unfinished) StarFox level editor http://pages.infinit.net/voxel/SFXed_Download.htm, where you edit level commands directly, and where the level is shown as a list of level commands, in a format not so far from english. I had made myself a meta format used to describe where the parameters where for each commands, and how to display them (hex or signed decimal for example). StarFox and SM64 have very similar level formats, which is not surprising, but I wanted to take a more visual and easier approach for Mario 64. So I didn't implement this direct level command list editing, nor my meta format, which could have been useful for Mario 64. I do have a debug text output that I used since the beginning to figure out the format. It outputs addresses and raw hex data, separating commands with carriage returns. Anyway, your text based format approach is very interesting, though XML hierarchies could have their use too (I guess indentation could work with a text format). Obviously, the little programs you are working on interest me I would like to try to compile them for my "unix-based" platform. Is it in gnu C++ or something like that? I did manage to recompile the YaZ0 decompressor for my platform with only one line change.
As for the "one based indexing" found in my doc. When I assembled this doc, I already had some lists in base one and some in base zero, but the majority was in base one, so I did convert the rest to "one based indexing", even those that you posted. Actually, I knew it could bother you, but it would have required me an hour or two of tedious manual editing to convert all of these to zero base. The reason I mainly used one based indexing, is that it fits with the way my editor is programmed. It's not in C++, and there are no "structs" in Lingo/Shockwave... I load data chunks in variable lists, and the first item in a list is referred as 1, not 0. I realize now that it's a pain in the *** for you to work with these in C and other "real" languages, so I'll try to see what I can do. I'm thinking about building a small script that will convert the indexing base automatically in my document. Now as for command 0x31... I didn't even try before to know what was its use, but since you brought it up, I did some little experimenting. Here is a list that shows all the 0x31 commands found in all levels:
Notice a pattern? The first parameter byte is always 00. The second byte is tied to areas in levels. Value 05 is used in water levels, value 06 in slides, 02 in snow levels, 03 is for sand, and 00 and 01 is used mostly everywhere else, while 04 is exclusive to Boo's haunted house. From what I found from good old byte hacking, this value sets what type of terrain the level will have. Value 06, used in slides, makes every slant very slippery. If you change the Bob-Omb's battlefield value to 06, you'll find that Mario can slide on flat ground for a very increased distance if you make him slide (very funny!), and you'll also find that Mario will start to slide every-time he encounters a hill, even a very flat one. If you change the value of the 0x31 command for a slide from 06 to lets say 01, you'll find that Mario can walk normally all over the track, and not slide so easily, and he can also climb back the slide hills, all the way back to the starting line. So this value has to do with the way the ground behaves. In the sand mode, you'll see that Mario is generating sand particles when he walk on some specific terrain. With the snow mode, Mario can fall halfway trough the ground if he falls from a certain height. I'm not sure of the difference between 01 and 02 though, and I didn't try to change a water level into a normal one yet. To conclude: its an interesting command I wonder if there are other possible values not used in the game. I tried 07 08 09 and FF, but it behaved like 00. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
| I sometimes compose in a text editor to avoid issues like that, but since I got spell-checking built into my browser, it's tempting not to, even if its a matter of two clicks
Funny you give the solidity data command as an example, I was about to ask you for some help about it. The example provided is from Level 1, the content of segment 07 in this level is the MIO0 file found at 3FC2B0. At offset E958 in this decompressed MIO0 file, you find 00 40 02 3A. 00 40 seems to be the command number. The value 0x023A (570 dec) is the number of vertices. Each vertex takes 6 bytes, 2 bytes for X, Y and Z (16-bits signed integers). So to find the end of the vertex data you multiply 570x6. That brings you to offset F6B8. The first two bytes there are always 00 00. After that, you get a sequence of 16-bit values. These refer to vertex in the previous list. They are used to connect vertices together, though last time I checked it wasn't triangles. The problem I have is that I don't know how to find the end of this data with a sure method. The number of 16-bit vertex pointers doesn't seem directly related to the number of vertices in the list. I cannot find any value telling me how many 16-bit pointers there are in this list and I didn't find any relevant reference to 0700F6B8 or 00F6B8 in the ROM. I thought that the first 16-bit value might be it, but I cannot find a correlation between it and the number of vertex pointers. The end of this list is at 10FBC where you can find: 00 41 00 43, which is also found at the end of all levels solidity data. But I cannot count on using "00410043" to detect the end of this data, because there is the possibility of vertex 0041 being followed by vertex 0043, and it does happen in a number of levels. Actually, I'm also interested in what follows the 00410043, and I cannot find anything pointing to this offset either, or near. I guess that 041 is the end of the vertex connection data and 0043 is the start of an object list. At 10FC0, just after 0043 (+2 bytes) is a list of in-game objects, not unlike the list pointed by the 0x39 command, but it has different uses. These special objects are placed in the level using x,y, and z coords. This list is used for trees (0x79), some doors, Bowser himself (only in the right level, he's object 65 or 66), the flag with a turtle shell and many others. This list is placed just before the object list pointed by the 0x39 command, so its sandwiched between the 0x39 list and the solidity data which begins with 0042. I cannot find any commands in the level script that points to this data. Maybe it's loaded with the solidity data, but I don't know how to find the end of vertex pointer list. Cellar Dweller, please for Pete's sake! Could you solve this?
As for the sand particle thing, it only works on certain terrain, like the path in Bob-Omb's Battlefield. Also, I tried to change the 0x31 second parameter for a water level to 01, and it doesn't change how water behaves, as expected |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
| In all my browsers, including lololol, I can do the same thing, but my problem was that I closed the window. When I tried to bring up the page with the History menu, my post was gone...
I know it was even more easy "in the days" to lose a post with some other browsers if it didn't get trough and you hit the back button. I guess you implied that IE still does that? One more reason not to use IE
But back to the topic: 
As you can see, the Wet Dry world tunnel is part of both areas. It means that both never appear simultaneously. So you need a door or tunnel to hide the fact that part of the scenery disappears. 
There is also the Tall tall mountain slide, which is divided amongst 3 areas. There even a music command for each of the 3 areas which all trigger the same slide music. The game seamlessly switches between 3 different track parts when you go trough tunnels. I'll try to pull the "walk on slides" trick using the 0x31 commands in those part, so I could walk back and see where and how the switch happens. The game can also manage big levels in other ways. Inside the castle, there are three areas, staircases (and locked doors) are used to separate them. But it doesn't stop there: each area is subdivided in rooms. The geometry layout data for inside the castle, contains multiple sets of references to rooms in the polygon data found in RAM segment 07 (using command 0x15). Some of these sets in that case contains individual rooms. Other sets contain two or more rooms reference. For example, one contains the main castle lobby room, and the level 1 room at the same time. This set is used when Mario transition from room to room the door. This would have mean a seamless transition in theory, but there is a timing problem in the actual game, ie: when you exit the level 1 room, the cam is in the lobby, and you can see Mario walking out the other room. Unfortunately, you see the other room disappear before the door is completely closed, ruining the effect. I wonder if we could fix that... There is only a few levels using the room sets method: Inside the Castle, Boo's haunted house and Hazy Maze Cave. I added a feature in my editor so I can instantly chose what sets of room is visible. Command 0x02 is used inside the geometry layout data to read those room sets, its 8 bytes long, it uses a room number parameter, and a pointer to make the decoder jump to this address, then one or more 0x15 commands (8 bytes each) are read from starting at this position, until command 0x03 (4 bytes) is reached, then it jumps back to the command following the 0x02 command. I also recently found that commands 0x04 and 0x05 are used to group parts inside the level geometry, in some kind of hierarchy. Each one is 4 bytes long. They act in the same logical principle as parenthesis and you can find groups inside groups inside groups... Each 0x04 command has its associated 0x05 command somewhere after. Maybe it's some kind of BSP tree? If you want to look at the geometry layout data for area 1 of Inside the castle, it's at 0x3D04D0 and ends where the following MIO0 data begins. You find this address with the 1F command for this level. I'll have to update my doc since it doesn't contain the 0x02, 0x03, 0x04 and 0x05 commands As for the mysterious "Luigi is real" 0x24 object, it doesn't behaves like a sign, it doesn't have a parameter number (signs have a parameter byte that sets the text it reads). 
I tried to move it and it doesn't change anything. I tried changing the object type byte from zero to something else, and it has no effects, the object doesn't appear. There would be more to investigate though by looking at the behavior code. The behavior pointer is 13003C90. Segment 13 is uncompressed data starting at 219E00. Add 0x3C90 and you get 21DA90 where you can find this: 00, 08, 00, 00, 0C, 00, 00, 00, 80, 2F, 09, 50 08, 00, 00, 00, 09, 00, 00, 00 I don't know much about this yet-another-sets of command, except that command 0x09 is used to mark the end of the behavior data. Obviously, it's not the actual code for the behavior like I first thought it would be, but rather pointers to it. Most other behavior data chunks contain other commands too, it seems that this particular object mainly contains the command 0C, which point to address 802F0950 in RAM... |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
Originally posted by HyperHacker Of course its not, do you really think I'm that dumb?
There are two level exits for Level 5 in the courtyard. They are at the same location, on the edge of the fountain, in front of the mysterious "Luigi is real" object, one is for successful level completion, and the other for when Mario dies. The mysterious object has 0000 for parameters, so it couldn't be a warp exit, since those have "warp id's" defined in the second parameter byte. Warps never use 00 as an id. The successful exit warp in front of it uses "0A" as a warp id, while the "Mario lost a life" exit uses "0B". If you look at 0x26 commands defining how warp are connected in level 5, you'll see that the two possible exits lead to the courtyard, in warp 0A and 0B. Anyway, just go in level 5, and exit it by dying or getting a star, and you'll see by yourself, Mario doesn't jump out of the Star statue. Note: the screenshot is reduced, the editor now has a 800x600 window (a little larger than before). I moved the interface around and some things are out of place for now, like the stars. I'm currently integrating a way to modify and save text descriptions for objects. Parameter labels like "Warp id" will be associated with behaviors, and those will also be editable. That means that even if I don't put description for all objects, behaviors and parameter labels, people will be able to add them, and send me the updated description file. (edits: typos) (edited by VL-Tone on 01-13-06 12:47 AM) (edited by VL-Tone on 01-13-06 12:47 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
| A tracer in Mupen64! neat!
Yes, the whole menu interface works using "level-like" scripts as their basis. The menu selection screen is a level with a negative number. The entry point of the whole script structure seems to be at 0x108A10 where you can find this little script: 1B 04 00 00 03 04 00 02 34 04 00 00 13 04 00 00 00 10 00 14 00 26 9E A0 00 26 A3 A0 14 00 00 00 05 08 00 00 10 00 00 00 -- The important command here is: [00] [10] [00 14] [00 26 9E A0] [00 26 A3 A0] [14 00 00 00] [0]: Command number [1]: Length Byte [2,3]: Segment number [4,5,6,7]: Start offset of data in ROM [8,9,10,11]: End offset of data in ROM [12,13,14,15]: Segment number and offset to jump too. This command loads uncompressed data into a specified segment then jumps to the offset (0000 in this case) in a segment, which is always the same as the one data is loaded in (0x14 in this case). I'm not sure yet what goes on in the 269EA0 segment, but it's the core of the level initialization process. At one point in this script, you find this command: [01] [10] [00 14] [00 2A 61 20] [00 2A 65 B0] [14 00 00 00]. Command 0x01 works much like 0x00. I think one or both of these commands might use a stack to store jump-back addresses. Command 0x02 found at the end of script subroutine would jump back to after when the last 0x00 or 0x01 command was called. So at that point, the content of segment 0x14 is replaced by data from 2A6120 to 2A65B0 in the ROM and jumps to offset 0 there. At one point in that script, you can find command 01 10 00 15 00 2A BC A0 00 2A C6 B0 15 00 00 00 Which loads the data starting at 2ABCA0 into segment 0x15 and jumps to offset 0. I know a little more about the script starting at 2ABCA0. As described in the old thread, this part loads the main segments shared by levels, including the Mario MIO0 file and another containing common polygonal objects. Then a sequence of 0x22 commands point to geometry data for each object and associate a number to them. These objects can be used in all levels. After that at 2ABE78 the script jumps back into segment 14 (2A6120) at offset 0x118 which means 2A6250 in the ROM. I'm not sure what happens at 2A6250, but it seems to come back at 2ABE78 when it's finished there (using the 0x02 command). At 2ABE78 it jumps to 0278 in the current segment 15 (2ABCA0), which can be found at 2ABF18 in ROM. So this is the interesting part, after the 3C command, there is a series of 0C commands. 3C 04 01 03 [0C] [0C] [02 00] [00 00 00 04] [15 00 03 F4]-- 0x0C is a conditional branch. It branches if the current level id number matches parameters [4,5,6,7] in this case it's 00000004. If this particular level is selected, the script jumps to 03F4 in the current segment which is at 2AC094 in ROM. At 2AC094 you find : 00 10 00 0E 00 38 28 C0 00 38 39 50 0E 00 04 18 --Which jump to the actual level script of this course. Other 0C commands after 2ABF18 can load any normal level. At 2ABE8C, there is an interesting sequence of 0C commands that point to negative levels. These are for the title screen, menu select, debug menu and game over sequence... So there you go, another lengthy confusing explanation leading to that little blurb of relevant information
Just look at 2ABE8C, you'll find the 0C commands that points to commands loading the main script of the file menu and other title related sequences. (Note I'm pretty tired, I hope at least one person can make sense of this post )(edited by VL-Tone on 01-13-06 04:25 AM) (edited by VL-Tone on 01-13-06 04:26 AM) (edited by VL-Tone on 01-13-06 04:28 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
| That's a very useful code snippet you got there!
I guess it means that the 0x2E command for solidity, the 0x39 command and the other objects in between are all loaded from a single function? From a preliminary look, I can see the 0x40, 0x41, 0x42 and 0x43 commands in the listing. The basic structure of this data usually looks like this:
Command 0x1E is used to end the 0x39 listing. I guess it has something to do with that line? if (*arg4 >= 0 && *arg4 < 0x1e) {
I have to admit that I'm not too familiar with the c++ syntax. Mainly it's the symbols like && * etc. that confuses me, if only because I don't know all of them. I'll have to do some little research before I understand all of this code. But I don't think it'll be hard, I have hundreds of years of programming experience, though mostly with either high-level languages, or low level stuff like ASM and binary formats. From what you found, do you think that the level is "drawn" as the level script is loaded, or that the level script only loads a bunch of pointers and data in memory, and only after that a "draw level" routine is executed, using pointers and data defined by the level script? By looking at that function you decompiled, I would say it's the latter. As for the other little /* returns pointer to virts */ function: By "virts", do you mean vertex positions or vertex connection pointers? The vertex position list is easy to load, as there is a "number of vertex" value after command 0x40. It's the vertex connection pointer list I have to find the length or number of entries value. Anyhow, great work Cellar Dweller! |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
| Is this from Level 1 solidity data? And while I'm here, what do you mean by "virts" again? | |||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6481 days Last view: 6481 days |
| ||
 Wow at last I found a use for this "surprised eyes" smily!
What's funny is that I figured that out a few seconds ago while trying to corroborate your findings, just before seeing your post... I should have figured this out before, it's so simple :/ For some reason, I thought that there was no commands between 040 and 041, since these are all commands with lists of vertex pointers (triangles). Now it's so obvious to me, even more with this picture you got Each of these commands in between 040 and 041 can produce a particular type of solidity, for different terrain types. Command 0x31 previously discussed seems to have something to do with these. I guess that these commands also include water solidity data? |
| Pages: 1 2 3 4 5 6 7 8 |
| Acmlm's Board - I3 Archive - - Posts by VL-Tone |
