 |
| 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 |
|
| | ||
| 0 users currently in ROM Hacking. |
| Acmlm's Board - I3 Archive - ROM Hacking - General Super Mario 64 hacking / TT64 Progress thread |
New poll |  | Thread closed |
| 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 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 | Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
Raccoon Sam Boomerang Brother Custom Title                     Since: 11-20-05 From: Correct Last post: 6279 days Last view: 6279 days |
| ||
| So, I've heard about this "MIO0" Thing.. If I understand this thing perfectly, It's like a code, which has a bunch of HEX values in the Super Mario 64 Rom.. And, for example, if you change B3 into F4, then a Bob-omb of a certain place will disappear / transform into another thing..
Well, I want to view it / Edit it. But I can't seem to understand what can I do it with.. Can anyone help me out? Note, again that I have a Mac.. |
|||
Smallhacker Super Koopa I AM A Group Of Officially Frustrated Younglings, G.O.O.F.Y. MEMBER |
| ||
| Isn't MIO0 a compression system? | |||
Guy Perfect Since: 11-18-05 Last post: 6281 days Last view: 6279 days |
| ||
| MIO0 is the compression format used by Super Mario 64. It's an implementation of LZ77. All of the levels in the game are compressed with MIO0. Within the decompressed files, however, changing certain values will change which objects they represent.
In order to do this, you'll need to be able to extract a chunk of a ROM, decompress MIO0, change the byte values, recompress MIO0, and insert the new chunk into the ROM. If you can't do each of those, you won't be able to hack the game in this manner. |
|||
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6470 days Last view: 6470 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. |
|||
|
Raccoon Sam Boomerang Brother Custom Title Since: 11-20-05 From: Correct Last post: 6279 days Last view: 6279 days |
| ||
Originally posted by VL-Tone Now this! THIS Is what someone can be proud of! Since there's a such a small amount of editors on Mac OS X, this will be a Blast! Truly magnificent, that's all I can say. The screenshot makes me drool.. Finally, the Nintendo 64 hacking has started to come along nicely! Also, one more question.. Are you planning on making your own super-awesome hack which is made completely with everything overwritten, before releasing the editor itself? It would be nice, thinking that people would see what the editor can do.. Like Super Demo World: The legend Continues. The Ultimate SMW hack made by the author of the emulator itself.. |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6279 days Last view: 6279 days |
| ||
| Hey, regarding that editor... I got to thinking the other day that Nintendo probably used a binary format for storing the levels on-disk, then converted them to a script format before putting them in the game. If you knew what all the script commands did you could convert them back to a binary format*, edit it there, then make a script out of it, rather than trying to edit the script as if it were binary. I imagine it'd be much easier and more flexible.
*for those who are going to ask how he'd know Nintendo's format... just think about it. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6281 days Last view: 6279 days |
| ||
Originally posted by Raccoon SamOriginally posted by VL-Tone Raccoon Sam, don't quote entire posts like this. It's freakishly annoying. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6470 days Last view: 6470 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) |
|||
The Ultimate Koopa Red Paragoomba Account banned at user's request.  Since: 12-24-05 From: England Last post: 6508 days Last view: 6508 days |
| ||
| OMG, this editor is like.. COOL! ER.. I mean it looks cool. I've now seen 2 screenshots of it.. this one (of Bob-omb Battlefield), and a screenshot of Big Boo's Haunt. Can you post some more screenshots? If you do post one of Tick Tock Clock, for example (if that's possible), then can you take the misty foggy layering? | |||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6279 days Last view: 6279 days |
| ||
| Er, no, that's not what I meant. Unless I read the docs way wrong, the levels are stored in the game in a compiled script format, where one command says to place an object, another loads a texture, etc. Since the scripts can contain jumps, calls, etc it can be difficult to edit them as they are in the ROM. I figure Nintendo's editor probably stored the actual level data in files as a raw binary format (just dumping the object structs to a file), and then translated that into this script format when adding it to the ROM. I would think it'd be easier for an editor to translate the script into such a raw binary format (or even XML) and save it to a file, edit that file, and then import it back into the ROM whenever. That is, instead of editing the level in-ROM you edit a temporary file with your own format (doesn't have to be Nintendo's, just the same concept).
The idea is that if you try to edit the data in the ROM, you have to either keep track of the address of everything (like if you want to change the music, the program needs to remember where the 'set music' command is) or re-execute the script every time you need to find a given command. Either one would be rather difficult and require a lot of seeking back and forth through the ROM. Using your own format simplifies it: you only need to execute the script once, dumping the resulting data to a file with a standardized format (like most games store their levels in), edit that file, and then translate it back into a script. This makes adding or removing objects easy; just add/remove data from the file or mark it as deleted. Editing it in-ROM would mean having to NOP out deleted objects (leaving useless gaps) and make adding them quite a hassle. Plus if you ever want to implement file importing/exporting, you'd need to do this anyway. 
For that matter, you might even use XML... I've been buggering around with game engines using it, and it works rather well. Oh yes, and don't forget that these scripts are (probably) optimized... so one group of commands might handle several objects, or some such thing, which would make it that much harder. Editing and re-compiling/re-optimizing the output avoids this problem. (edited by HyperHacker on 12-25-05 04:36 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6470 days Last view: 6470 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 |
|||
|
Raccoon Sam Boomerang Brother Custom Title Since: 11-20-05 From: Correct Last post: 6279 days Last view: 6279 days |
| ||
| My eyes! My eyes!
It's so beautiful! I must be dreaming! Found anything Beta stuff yet by the way? |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6470 days Last view: 6470 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 |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6279 days Last view: 6279 days |
| ||
Yeah, I know you'd have to know pretty much all of the script commands to do something like that. I'm talking distant future here.  |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6470 days Last view: 6470 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. |
|||
Cellar Dweller + Red Koopa   Since: 11-18-05 From: Arkansas Last post: 6288 days Last view: 6279 days |
| ||
| I'm finally getting back to reverse engineering SM64 now that I have an emulator working on my new computer. I'm now running Debian on AMD64, which doesn't have 32 bit libraries. I installed Mupen64 in a chroot jail with 32 bit libraries because there are too many 32 bit-isms to fix before it will compile to a 64 bit binary.
I think that it would be quicker and easier to create a flat text format instead if an XML format for level data. I have been working on a couple of small programs for listing data in the SM64 ROM. One formats GBI(Graphics Binary Interface, the commands that draw graphics) commands as plain text in a format like a developer might use for manual input. The other formats level data as plain text, seperating the raw hex into one command per line, printing a description, and extracting parameters. I have also updated my simple command line MIPS disassembler, which, unlike Jovis's disaembler, uses symbolic register names and can export output to a text file with standard command line redirection. If anyone wants a copy, I can upload the most recent version, but it will need to be compiled. VL-Tone: I've noticed that your SM64 hacking doc uses a mixture of zero based and one based indexing to describe the location of parameters within commands. I recommend zero based indexing for all commands, even though I posted some command descriptions with one based indexing. Also, the music command should have two 16 bit parameters, one for music and one unknown. EDIT: I have found only one parameter that is specified using zero based indexing: the address parameter to command 0x11. I have found that command 0x31 has two one byte parameters. It is only valid inside an area specific block of commands. The first parameter(3rd byte) is an index into a two byte array in the area data structure, and the second parameter(4th byte) is the value that will be placed in the array. If it is used outside an area speific block or with a value greater than one in the first parameter, it will have no effect. I don't yet know what ultimate effect it has. (edited by Cellar Dweller on 01-05-06 10:24 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6470 days Last view: 6470 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. |
|||
|
Cellar Dweller + Red Koopa Since: 11-18-05 From: Arkansas Last post: 6288 days Last view: 6279 days |
| ||
| I lost posts that way too. Also, I once lost a slightly longer than average post because the thread I was replying to (a thread about locking SMW hacks, LM source code, or both) was closed while I was typing.
The level lister tool produces output much like the debug output you described, lines of raw hex, but it also prints a short description of certain commands and formats some of the parameters. For example: (08) 2e 08 00 00 07 00 e9 58 / set solidity data / 07:00e958
This makes the output easy to read, and highlights commands that need more study(with blankness). The little tools I have been writing are written in C and highly portable, so they should compile fine on Windows, Linux, Mac, etc.. A few months ago, I experimented some with GTK+ with OpenGL via GTKGlExt. I wrote a little test app with a mix of C and C++ on my brother's Windows computer and it compiled with no changes to the source files on my 64 bit Linux computer, but I couldn't use the Windows makefile generated by Dev-C++. This looks like a promising approach for a cross platform editor. I did some experimenting with the 0x31 command after my previous post in this thread. I did observe some of the effects, but I did not see the sand. For some reason I can't get textures to appear when using the glN64 plugin, and the only other graphics plugin I have is an unoptimized software rendering plugin that gets only a few fps. If I changed the first parameter, the the terrain would still behave differently, but this could because the game engine is seeing an uninitialized byte that would have been set when using zero as the first parameter. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6470 days Last view: 6470 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 |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6279 days Last view: 6279 days |
| ||
| That's one thing I like about lololol, if your post doesn't go through, hit Back and it's still there.
Anyway, it's interesting to note that Wet-Dry World and Dire Dire Docks have 0x31 commands. Every other level that has them is composed of completely separate areas; you reach them by a warp (the screen fades out to load the area, it often has different textures and music), and if you die inside you skip the star select and restart right there. In these two levels, though, it's as if they were one big area; they load while you're in the tunnel. A third exception is the pyramid boss room; it loads inline as well, but you restart inside it if you die. Just thought that was interesting to note. If we could figure out how to do that whole loading inline thing, we could have potentially massive levels using it that seem like one big area. Wonder how big, exactly? 
Also interesting to note is that Bowser's courses lack these, even though they warp to the Bowser battle arenas.  |
| 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 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 | Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - ROM Hacking - General Super Mario 64 hacking / TT64 Progress thread |
| Thread closed |
