 |
| 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 - Super Mario 64 Hacking discussion thread - READ THE FIRST POST BEFORE POSTING! |
New poll |  |  |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
|
Deleted User Banned                Since: 05-08-06 Last post: None Last view: 6271 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 ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Posted on 12-24-05 12:27 AM Link Originally posted by Raccoon Sam -------------------------------------------------------------------------------- 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.. -------------------------------------------------------------------------------- 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 -------------------------------------------------------------------------------- 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. -------------------------------------------------------------------------------- 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! -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 12-24-05 12:35 AM) 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. 000: 0x24 object 018: 0x24 object 030: 0x24 object 048: 0x07 command to jump back 04C: 0x24 object 064: 0x24 object 07C: 0x07 command to jump back 080: 0x24 object 098: 0x07 command to jump back --This is where the level script starts to be decoded. 09C: 0x1B command to start loading RAM segments 0A0: 0x18 Decompresses a MIO0 file in RAM 0AC: 0x17 Copy ROM data in RAM 0B8: 0x1D end of RAM loading part 0BC: 0x25 sets Mario's id number (01) and behavior pointer. 0C8: 0x06 command. This one is used to jump in another RAM segment containing script data shared by all levels. Usually, these are 0x22 commands that assign id numbers to geometry layout data offsets. 0D0: 0x06 Jumps again to load another list of shared 0x22 commands. 0D8: 0x22 command. This one is part of this level's script. 0E0: 0x22 command. 0E8: 0x1F Points to the current level geometry layout data that is just after the level's script. Also marks the start of an area inside a level (ie. main level vs slide area) 0F0: 0x06 These jump commands are used to jump inside this RAM segment, at offset 000. 0F8: 0x06 Same principle, jumps at 04C in this script to "load" another group of 0x24 object. 100: 0x06 Same thing, jumps at 080 to load the third group of 0x24 commands. 108: 0x2E Loads collision data (and tree position data?) found inside the level main MIO0 segment. 110: 0x39 Loads the other set of level objects found in the main MIO0 segment (07). 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. 118: 0x36 command that sets the music for this level area. 120: 0x31 short command that seems to mean "the end of this script part" 124: 0x20 short command to separate level areas inside a level script 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 ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Originally posted by Raccoon Sam -------------------------------------------------------------------------------- My eyes! My eyes! It's so beautiful! I must be dreaming! Found anything Beta stuff yet by the way? -------------------------------------------------------------------------------- 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 ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Posted on 01-02-06 07:44 PM Link Originally posted by HyperHacker -------------------------------------------------------------------------------- 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. -------------------------------------------------------------------------------- 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 ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt 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: Haunted House 382E34 [31, 04, 00, 04] Cool Cool Mountain 395FD0 [31, 04, 00, 02] 396038 [31, 04, 00, 06] --Penguin Slide Inside Castle 3CFDCC [31, 04, 00, 01] 3CFEC0 [31, 04, 00, 01] 3CFF98 [31, 04, 00, 01] Hazy Maze Cave 3E6EFC [31, 04, 00, 01] Shifting Sand Land 3FBDF0 [31, 04, 00, 03] 3FBEC4 [31, 04, 00, 01] --Pyramid 3FBF10 [31, 04, 00, 01] --Boss Room Bob-Omb's Battlefield 405E68 [31, 04, 00, 00] Snow Man's land 40EAEC [31, 04, 00, 02] 40EB6C [31, 04, 00, 02] Wet Dry World 41A484 [31, 04, 00, 01] 41A4D8 [31, 04, 00, 05] --Underwater City Jolly Roger Bay 424384 [31, 04, 00, 05] 4243EC [31, 04, 00, 05] Tiny Huge Island 42CB00 [31, 04, 00, 00] 42CBB0 [31, 04, 00, 00] 42CC50 [31, 04, 00, 00] Tick Tock Clock 43760C [31, 04, 00, 01] Rainbow Ride 44A764 [31, 04, 00, 01] Castle Grounds 454C08 [31, 04, 00, 00] Bowser 1 Course 45C2E0 [31, 04, 00, 01] Vanish Cap 4613DC [31, 04, 00, 01] Bowser's Fire Sea 46ACB0 [31, 04, 00, 01] Secret Aquarium 46C2D4 [31, 04, 00, 05] Bowser 3 Course 4780F8 [31, 04, 00, 01] Lethal Lava Land 48D2EC [31, 04, 00, 01] 48D354 [31, 04, 00, 01] Dire Dire Docks 495E00 [31, 04, 00, 05] 495E7C [31, 04, 00, 05] Whomp's Fortress 49E1FC [31, 04, 00, 01] Castle Courtyard 4AF838 [31, 04, 00, 01] Peach's Secret Slide 4B7FCC [31, 04, 00, 06] Metal Cap 4BEB40 [31, 04, 00, 01] Wing Cap 4C2824 [31, 04, 00, 01] Bowser 1 Battle Platform 4C425C [31, 04, 00, 01] Rainbow Clouds Bonus 4CDAE0 [31, 04, 00, 02] Bowser 2 Battle Platform 4CEB28 [31, 04, 00, 01] Bowser 3 Battle Platform 4D1748 [31, 04, 00, 01] Tall Tall Mountain 4EB7AC [31, 04, 00, 01] 4EB818 [31, 04, 00, 06] --Slide part 1 4EB864 [31, 04, 00, 06] --Slide part 2 4EB8CC [31, 04, 00, 06] --Slide part 3 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 ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt 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 ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Posted on 01-13-06 12:40 AM Link Originally posted by HyperHacker -------------------------------------------------------------------------------- That is interesting... sure it's not just the level 5 exit though? -------------------------------------------------------------------------------- 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) -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 01-13-06 12:47 AM) (edited by VL-Tone on 01-13-06 12:47 AM) 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 ) -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (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) 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: *0040--Start of solidity data. *16-bit value for the number of vertex position in the list (multiply by 6 to find the byte length) *Vertex position list, each entry is 6 bytes *16-bit length value for vertex connection list (?) (I'm not sure about this one, it doesn't match the length in any obvious way) *Vertex connection pointer list, each entry is a 16-bit integer pointing to a vertex position in the previous list. *0041 *0043 *List of special objects, like trees *0042 *List of 10 bytes objects pointed by command 0x39. The 9-bits type value points to what I call a "macro" object in a list at EC7E0 in the ROM. Each entry in this list contains a type byte (the same as in 0x24 objects), a behavior pointer and 2 parameter bytes. *0000001E 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 ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Is this from Level 1 solidity data? And while I'm here, what do you mean by "virts" again? -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt 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? -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt There you go, I've got it working too! Thank you very much Cellar Dweller for this help, even though I should have figured this out before... The first polygon data I stumbled upon was the solidity data, but didn't manage to get conclusive results at the time so I focused my efforts on the textured polygon data. Edit: I hope I'm not sounding like I want to keep the credit all for myself and minimizing your efforts Cellar. You are a better programmer than me and have a much cleaner/modular approach, and since the beginning you have been more than useful Ok here is a second picture of solidity data, that one inside the castle (first floor). Look at where paintings are... weird eh? There seem to be 3 separate areas defined both in front and behind, for a total of 6 different solidity values for each painting. I really wonder what they are used for... why 3 in front and 3 behind? If I remember correctly these are defined by commands Dx or Fx. From what I found, command 79, 85, 1D and 21 are followed by lists with items that are 8 bytes long instead of 6, so they include an extra 16-bit parameter. The first 6 bytes are a triangle like other commands. Command 0x88's items are 12 bytes long, and also contains a triangle. Command 0xA0 is only 4 bytes long. I started decoding the other sets of objects that is found after 0x43 and before 0x42. Very interesting stuff in there, as predicted it includes Bowser, trees and other stuff like doors. In these objects I found the command that places the castle main tower on top (I had to do it manually before). The problem I have is that I cannot find the link between its object type value (0x65) and value 0x03, which is the value defined by the 0x22 command for the tower... It doesn't seem to use the same set of type/behavior/params macros that command 0x39 object use (found at EC7E0). -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt I considered this possibility, but I thought it was a weird way to detect that, and from memory I was pretty sure that there was more than 3 different horizontal positions for the ripple effect. But after reading your post I decided to check... And it seems that you are right Lordlazer! There seem to be only three possible horizontal positions for ripples in paintings, but the vertical position seems to be more precise. The 3 areas in front are for when Mario enters the painting, and the 3 areas at the back are for when Mario exits paintings. But you shouldn't have to worry about posting in this thread. If you have questions about the Mario 64 editor, even basic things, don't hesitate to ask them in this thread, at least until I decide myself to post a more official thread... From what I found, these areas define the terrain type in some instances and are there to detect if Mario is stepping on a specific floor part in the level, to trigger some specific event. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Originally posted by Lordlazer -------------------------------------------------------------------------------- Q: Is this editor going to work similar to GTKRadiant [editor for Quake III] or something of the sort? If so, editing will be somewhat of a breeze for me. -------------------------------------------------------------------------------- I don't know much about the GTKRadiant editor so I couldn't tell. I guess you can create levels from scratch? The first release of my M64 editor won't enable you create new model geometry, I may add a way to edit the geometry shape by moving vertices, but I'm still not decided if I will include that in the first release. As its basis, geometry editing (not importing) would be a simple feature to add, but to be useful, it should be more than being able to move individual vertices. Selecting and moving multiple vertices at the same time would be very useful, and scaling and rotating groups of vertices would be very practical. I'm thinking about implementing a way to match the geometry vertices to the solidity vertices so they would move in tandem. Though it would be very cool to be able to create entirely new geometry and importing 3d data into Mario 64, I feel that this is too much of a task for me, and even with Cellar Dweller's approach, I'm betting that it will take years until we achieve that. There is much more things than vertex and triangles in the geometry format, there are pointers and other stuff that no 3d program deal's with. The format is actually a series of graphic processor commands, that have to follow specifications. An importer or geometry creator would need to keep track of many things to make sure the texture or triangle cache doesn't overflow for example. With the many limitations of the chip and engine, many things could go wrong. We may have much more space for levels by extending the ROM, but memory will still be limited. Making sure a level doesn't make the game crash will require taking many variables into account. Sure, individual issues will be dealt with, but the sum of them may mean a lot of work ahead of us. I may be a little pessimistic about this: To build Mario 64, Nintendo used a 3d program called N-World by a company called Nichimen. There was a plug-in to export models to N64 graphic commands format, so it may not be so hard to replicate similar functionality. Edit: By the way Nichimen is now called IZware http://www.izware.com/, N-World was renamed Mirai a few years ago, and IZware's products were used to animate Gollum's face in LOTR. I'm currently looking for more information about N-World, here is one of the interesting pages I found on the internet archive: http://web.archive.org/web/19980712203000/nichimen.com/products/nworld/game-exp -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 01-23-06 11:19 PM) (edited by VL-Tone on 01-23-06 11:35 PM) Lordlazer: I'm not sure how mesh are used in the Quake editor, but meshes can be 3d, and the term mesh can apply to just about any 3d polygon group. So yes the Mario 64 levels can be described as 3d meshes. The editing would work by moving around vertices, thus changing the shape. I guess the equivalent of brushes exist in Mario 64. Some levels, like Whomp's Fortress, or Wet Dry world (area 1) rely on level objects for platforms and many level elements. The Whomp's Fortress tower for example, is an object. You could move the tower, or put three of them if you want, by changing other object in the level into towers. The rotating platforms in this level are also individual objects you can move and tilt, and "duplicate" them at other positions. For fun, I once made the tower use the rotating platform behavior so the whole tower would rotate! It worked, but for some reason the tower lost its solidity. Here is how mesh editing could look, though a wireframe view could be an option. Vertex are represented as red spheres in this example. Each of these spheres could be moved, enabling you to change the shape of the Secret Slide for example. Maybe a slide editor could be a start -------------------------------------------------------------------------------- Cellar Dweller thanks for reassuring me, I get a little paranoid sometimes. Very cool that you found the geometry layout command's function table, this is one area I don't know that much about yet. I know just enough to decode levels and simple objects. Mario has an incredibly complicated geometry layout, and by understanding it more we'll be able to replace Mario with other characters. (But it obviously has more uses than that, as every object and level part has geometry layout data) Like I explained earlier in this thread, command 0x02 is used in the level geometry layout to jump to different room sets in multi-room levels (Boo's House, Inside Castle and Hazy Maze Cave). In this case, each 0x15 commands point to a particular room GBI polygon commands. I don't know how the game identify room sets though, as no command seem to indicate room sets numbers as is. I didn't know about the second byte use though, but in levels, it's always 0x01. Command 0x03 is used to jump back to the stored address. Now, take a look at Yoshi's Geometry layout data, which is way simpler than Mario: 1575340 [16, 00, 00, 01] [00, C8, 00, 64] 1575344 [04, 00, 00, 00] 1575352 [1D, 00, 00, 00] [00, 00, 40, 00] 1575356 [04, 00, 00, 00] 1575368 [13, 01, 00, 00] [00, 00, 00, 00] [00, 00, 00, 00] 1575372 [04, 00, 00, 00] 1575384 [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 26, F0] 1575388 [04, 00, 00, 00] 1575400 [13, 01, 00, 64] [00, 00, 00, 00] [05, 02, 24, F0] 1575404 [04, 00, 00, 00] 1575416 [13, 01, 00, DE] [00, 00, 00, 00] [00, 00, 00, 00] 1575420 [04, 00, 00, 00] 1575428 [0E, 00, 00, 02] [80, 29, DB, 48] 1575432 [04, 00, 00, 00] 1575440 [15, 01, 00, 00] [05, 01, DA, 58] Head 1575448 [15, 01, 00, 00] [05, 01, DA, 80] Head eyes closed 1575452 [05, 00, 00, 00] 1575456 [05, 00, 00, 00] 1575460 [04, 00, 00, 00] 1575472 [13, 01, 00, 4C] [00, 31, 00, 00] [00, 00, 00, 00] 1575476 [04, 00, 00, 00] 1575488 [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 13, 98] Lower jaw 1575492 [05, 00, 00, 00] 1575496 [05, 00, 00, 00] 1575508 [13, 01, 00, 33] [00, 37, 00, 61] [00, 00, 00, 00] 1575512 [04, 00, 00, 00] 1575524 [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 17, 60] Leg? 1575528 [04, 00, 00, 00] 1575540 [13, 01, 00, 4A] [00, 00, 00, 00] [05, 02, 16, C0] 1575544 [04, 00, 00, 00] 1575556 [13, 01, 00, 45] [00, 00, 00, 00] [05, 02, 15, 78] 1575560 [05, 00, 00, 00] 1575564 [05, 00, 00, 00] 1575568 [05, 00, 00, 00] 1575580 [13, 01, 00, 33] [00, 37, FF, 9F] [00, 00, 00, 00] 1575584 [04, 00, 00, 00] 1575596 [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 19, E8] 1575600 [04, 00, 00, 00] 1575612 [13, 01, 00, 4A] [00, 00, 00, 00] [05, 02, 19, 48] 1575616 [04, 00, 00, 00] 1575628 [13, 01, 00, 45] [00, 00, 00, 00] [05, 02, 18, 00] 1575632 [05, 00, 00, 00] 1575636 [05, 00, 00, 00] 1575640 [05, 00, 00, 00] 1575644 [05, 00, 00, 00] 1575656 [13, 01, FF, FF] [00, 1B, 00, 5F] [00, 00, 00, 00] 1575660 [04, 00, 00, 00] 1575672 [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 1D, C0] 1575676 [04, 00, 00, 00] 1575688 [13, 01, 00, 64] [00, 00, 00, 00] [05, 02, 1C, 78] 1575692 [04, 00, 00, 00] 1575704 [13, 01, 00, 5F] [00, 00, 00, 00] [05, 02, 1A, 88] 1575708 [05, 00, 00, 00] 1575712 [05, 00, 00, 00] 1575716 [05, 00, 00, 00] 1575728 [13, 01, FF, A7] [FF, C2, 00, 00] [00, 00, 00, 00] 1575732 [04, 00, 00, 00] 1575744 [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 1F, 20] 1575748 [05, 00, 00, 00] 1575760 [13, 01, FF, FF] [00, 1B, FF, A1] [00, 00, 00, 00] 1575764 [04, 00, 00, 00] 1575776 [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 23, 90] 1575780 [04, 00, 00, 00] 1575792 [13, 01, 00, 64] [00, 00, 00, 00] [05, 02, 22, 48] 1575796 [04, 00, 00, 00] 1575808 [13, 01, 00, 5F] [00, 00, 00, 00] [05, 02, 20, 58] 1575812 [05, 00, 00, 00] 1575816 [05, 00, 00, 00] 1575820 [05, 00, 00, 00] 1575824 [05, 00, 00, 00] 1575828 [05, 00, 00, 00] 1575832 [05, 00, 00, 00] 1575836 [05, 00, 00, 00] I know that the 0x15 command points to polygon data, command 0x13 also point to polygons (but not always) and I don't know the use of the first 7 parameter bytes. I added indentation for the 0x04 and 0x05 commands, which seem to act like parenthesis surrounding sub-groups, forming a hierarchy. This may well be something akin to bone hierarchy? Or maybe it's some sort of BSP tree? It's unclear how the game keeps track of each body part. Everything else I found in the game has somekind of ID attached to it, not in this case. Maybe they are referred as positions in groups and sub-groups? Yoshi really has two heads , one with the eyes opened, and one with the eyes closed. Mario has 8 of them for its animated eyes. Ultimately, all heads refer to the same vertex and triangle sets, but with different textures. They are loaded sequentially one after the other using 0x15 commands, and with no ID attached to them. One possible scenario is that these ID's (and their polygon data pointers) are created and stored as the geometry data is read, then referenced by bone animation routines. By the way, this Alias document is full of very interesting stuff! What's funny is that it's not even from the internet archive, this site is still working even after all those years! Edit: added screenshot that I struggled to upload at photobucket earlier. Another Edit: Some phrase made no sense...yeah it's late... and why is there a blank 3rd page on this thread now? -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 01-25-06 04:18 AM) (edited by VL-Tone on 01-25-06 04:23 AM) Originally posted by UZI in my pocket -------------------------------------------------------------------------------- Hey. Theres a PERSON that is Claiming this Editor. Ill give you the Link. LETS TAKE THIS BITCH DOWN. http://www.moviecodec.com/topics/10692p1.html His name is ALAN somthing? -------------------------------------------------------------------------------- Yeah I already found it, as you can see I posted there as v-twin. Anyhow, he cannot prove anything anyway... I can find if these guys start to link to my page by looking at referrers, so I don't think they can do much without me knowing it... -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Welcome to the board spydark! Pardon my ignorance, but what is VGDC? I guess that the VG means Video-Game, but the DC... DreamCast? Could you please post the thread url so I can take a look? I'm not sure if I'll include the possibility of editing the warps in the first release. What you are asking would be possible for all levels except the last one. The end sequence is more custom stuff, and I don't know much about it yet. I'll experiment to see if it's feasible. ---------------- BGNG, you are right it's no big deal, and even if some people used my nick to claim the editor is theirs, it would only spread the name So please people, don't start a war on the moviecodec thread.... But yeah this is one of the reasons I won't release the source code of my editor. Like you tough, I'll publish a document with all the info necessary to build an equivalent editor. If someone wants to copy my editor without crediting me, at least they'll have to work for it -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt For those who didn't see it, here is the video I made to "prove" that I was working on the editor: http://www.youtube.com/w/Super-Mario-64-Mod-2006?v=LC2SIXvs1mo HyperHacker, I first thought about putting my name in a texture as a proof, but I thought it was too easy, and there are already tools to do it. But yeah I get your point, I could have used it as a kind of watermark in the video. The watermark I put is not always easy to view, mainly because of youtube's re-compression. But even if he grabbed some image where they are hard to see, I'll can always point to my entire video as the source of the screenshots, and at times in the video the vl-tones are easy to spot. Anyhow, this Alan guy is a troll, and I guess I fell for it...But that got me into producing this fun little movie ---------- proffessor_gad, welcome to the forum, I hope you are not still doubting The space limitation regarding geometry creation, are a RAM limitation, not ROM space. SM 64 cannot use the RAM expansion pack as is, so we would be limited by existing space. But this is one of the reason why it will take some time until this is possible. Currently, I decode the level geometry to display the level and objects in the editor. But there are many things I don't take into account when decoding the data, so creating valid polygon data is more complicated. Also I would have to either write a 3d creation/editing program (not a small task), or write an importer to import standard 3d files from an external 3d program. The problem with the latter is that there are many things (like pointers etc.) other 3d programs cannot generate that are essential to the game. So that's why it will take some time before we can create entirely new levels. ---------- Cellar Dweller, I have a quick question: Do you know the hex equivalent in SM64 for the GBI geometrymode and cleargeometrymode commands? I started to implement texture coloration, some vertex have a an RGB color value, while some contain a vertex normal. From what I've found these two GBI commands can be used to switch between vertex based coloration and Gouraud shading (which uses the normals). -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt proffessor_gad: yeah I knew about this, the Mario model was extracted using an emulator that can export the current 3d scene to a file. Note that the textures pict you posted differs from how the textures are stored in the ROM. The skin color and cap color (red) under the M logo are not included in the original texture. spydark and others asking to be beta testers, the program is currently in alpha state and couldn't be used by a beta tester. It will take a few weeks until I provide a beta version to test. I'll keep your names in mind when I'll begin the testing Hosma293: yeah I thought about making an exporter, it wouldn't be that hard, I did one for my StarFox level editor, though it didn't include textures. Like I just mentionned, there is an emulator that I forget the name of, which can export 3d models from n64 games. Spazzup™: Aside from me and Cellar, other people deserving a kudos are: BGNG for reverse-engineering the compression format (MIO0) since without that this wouldn't be possible. HyperHacker, fffffff, ChickenLump and others also made great contributions. If I forget anyone, sorry Without bragging about it, I did find 80%+ of what was found in SM64, others could have done it too, but I had a head-start, having worked on a StarFox level editor pretty much on my own and SM64 has a similar format for polygons and levels. Cellar Dweller: Thank you very much, that was very helpful, I managed to implement texture/polygon coloring and now many levels are more faithful to the original. The hills surrounding the Castle are now green at last, and there are now shadows, for example, under the bridge. I'll try to post screenshots later. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Yeah I knew this was possible with the GS By the way I forgot to post this: http://pages.infinit.net/voxel/SuperMario64mod2006b.ips It's an IPS patch of the edited Castle Ground level featured in the video! It requires a ROM with the ABCD byte order. If you can find the string "yoshi" anywhere in your the ROM using an hex editor, that means you have the right byte order. The warp pipe on the ground leads to the warp pipe on the top of the castle, and vice-versa. But these pipes could instantly warp to any position in any level! Try that on a PSX A cool simple hack could be to put warp pipes all over the castle level field, each warping to a specific level and area. Ideally, a message would appear, saying "Welcome to the warp zone!" (Edit: I changed the link to version b, since the first version I posted was for an extended ROM) -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Ok sorry about that, I should have thought about these details... Yes you do need the US version. If you cannot find the .Z64 version of the ROM, use this tool: http://dextrose.com/files/n64/build_tools/bswap.zip to change byte ordering to ABCD on the US version. proffessor_gad: You need an IPS patcher program to apply the patch to the ROM, like the one mentioned by Spazzup. You can find the excellent Lunar IPS, and other IPS patcher programs at http://www.zophar.net/utilities/patchutil.html -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Drats... I gave you the patch for the extended ROM... (with repointed MIO0 files) This version should work (I just tested it and it works). New version that works on an 8 megs US Mario 64 ROM with ABCD byte order: http://pages.infinit.net/voxel/SuperMario64mod2006b.ips -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Originally posted by proffessor_gad -------------------------------------------------------------------------------- Ha ha ha! It worked! How about an ips with edited bobomb battlefield? -------------------------------------------------------------------------------- I'd rather work on making the editor useable for beta testers than spending my time on doing level edits and releasing patches. So no more level edits until I release the beta. Chainlink1061: For now, the editor doesn't edit the polygon geometry, and it wont until version 2. (edit: Hmmm, I hope that didn't sound too harsh, I forgot to reply to the rest of your post, but here it is: Thank you for the compliment but I'm not a genius! Interesting bug you got with the Goomba, I guess they are never normally found in levels that contain a vanish cap box to prevent this bug from happening?) But even if geometry editing won't be available at first, the following levels still could have major structure edits since they are built out of multiple platform objects that could be moved without editing the geometry. Note: these are new screenshots, before that, these levels didn't display all platforms, but thanks to Cellar Dweller's help I implemented most of the remaining object types. As for texture coloring, here is the Castle, with the green hills at last! The window on the tower doesn't appear, this is a bug I should try to fix (in my first images, I positioned the tower manually, but now it's positioned from level data). Trees are implemented at last, but they suffer from a texture repeat problem, and a z-ordering problem in some particular context. Here are the shadows that now appear on the castle and under the bridge. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 02-01-06 10:58 PM) (edited by VL-Tone on 02-02-06 12:49 AM) (edited by VL-Tone on 02-02-06 12:49 AM) (edited by VL-Tone on 02-02-06 12:50 AM) Originally posted by Chainlink1061 -------------------------------------------------------------------------------- To VL-Tone: Can you add objects and enemies directly, or do you have to change existing ones? -------------------------------------------------------------------------------- Sorry guys, I was busy these last few days. Chainlink1061, to answer your question, the first release won't enable you to add new objects. This is the kind of thing I'll work to add in version 1.5 or 2.0. I decided to rewrite some part of my editor from scratch, as it was a little patchy and got too much overhead. I'll adopt a more OOP based approach. Also, I decided to get rid of HEX values in the main interface. I'll do an inventory of all the polygon objects found in the game, and assign them numbers (in decimal). Same thing for behaviors, and MIO0 banks found in the game. That will make the editor much more easy to use. At the same time I'll keep some power user features so that you can find what hex pointer the decimal numbers refers to, and possibly these values them when it could be useful. I already partly implemented a feature where beta testers will be able to contribute by adding description to objects and behaviors, when they are not already defined. Then, by sending me back a .txt file, I'll be able to integrate those back into the editor. You'll be able to add descriptions for each polygon asset, behavior pointer, labels for the 2 parameter bytes used by specific behaviors, and descriptions of possible values for those 2 parameters (either as 2 separate bytes or a single 16-bit value). I'll try to add descriptions before releasing the beta, but for any missing ones, people will be able to contribute if they want -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Wow, thanks for all the suggestions, they are all great ideas Even if I don't choose any of your suggestions, it's very useful to get external ideas. I must admit that TOADSTOOL is the one that caught my attention more than others. I know one word is better but how about "Toad's Tool"? Or maybe "Toad's Tool 64"? But, I have an idea myself, tell me what you think: Carpenter 64 I was about to post something about it yesterday (but again, I closed my browser window by mistake), explaining why I think Mario is more of a carpenter in his soul than a plumber. It was a long explaination and I don't feel like rewriting it. Is Mario a plumber or a carpenter? I think that he's both, but I think his plumbing jobs were "on the side", while his main profession is still carpenter. It's debatable, and that's what makes it interesting as a name, as it would generate some light debate each time the name of this new Mario 64 editor is brought up in some forum. Edit: removed that off-topic part about where my nick comes from. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 02-10-06 12:51 AM) (edited by VL-Tone on 02-10-06 03:18 AM) Originally posted by dcahrakos -------------------------------------------------------------------------------- I think he is more of a plumber then a carpenter...I dont think he has ever built anything has he? or uses wood like a carpenter would. but he goes down pipes, and does other plumber stuff... how about Plumber's Toolbox or something like that. -------------------------------------------------------------------------------- Ok, aside from the big green pipes, what other plumbing stuff does he do? (please exclude SMS) Originally posted by Kyoufu Kawa -------------------------------------------------------------------------------- They have a gig in a hotel's basement and from there, they go straight to SMB1. -------------------------------------------------------------------------------- Oh please don't take into account the scenario from that awful Super Mario movie I clearly remember Miyamoto saying in an interview (years ago) that the plumber stuff came from the US marketing department, with the movie and the (also awful) cartoon. He contradicted himself on that more recently, but I think he just gave up on explaining it, and since the overwhelming majority thinks he's a plumber, he decided to treat him as such, starting in Super Mario Sunshine with the water stuff. For me it always made sense, but I just found that I didn't have the right definition for the word carpenter. I had the French word "charpentier" in mind when I read or heard carpenter, and it has a wider and different meaning. The thing is, "charpentier" fits the Mario series much better than plumber and carpenter. It's possible that the Japanese translator also spoke French, and did the same mistake as I did when translating Mario's job for english documentation. He's probably the same that is responsible for the "Donkey" in DK, which is also a mistranslation. The word "carpenter" has latin roots, but it likely comes from Italian or French. In French, "charpentier" has two meanings. The oldest, is close to the English definition: "Person skilled in woodworking". The most recent definition for "charpentier" is: Person that is responsible for designing and/or installing a building frame or "skeleton", which is called in french "la charpente". He also has to install stairs and other related things. Building frames were made out of wood until the last century, where metal frames and cement started to be used in the construction of high rise buildings. Metal beams used in high rise building frames are often called I-beams, and V-beams, and the letter I and V being related to their shape. If anyone wants to stick to the English definition of carpenter, which I suppose most everyone will, then tell me where is the woodwork in Donkey Kong and DK jr.? Barrels? Look at the levels in DK (and DK jr.), they are built out of metal beams, V-beams and I-beams. There are also ladders, elevators, rivets, conveyor belts and cement like the one you would expect on a 191x high rise metal frame being built. Wood barrels and metal barrels with oil also fit very well in this context. I'm sure everyone here has saw in one form or another a cartoon or old black & white movie where some character is walking on the metal frame of a high rise building in construction, avoiding obstacles and jumping over gaps along the way, and later finding himself on a moving platform (often an I-beam or metal pipe with a rope tied in the middle). It's obvious (to me at least) that Miyamoto had that mind when creating Donkey Kong. As for Mario Bros. I think it was released at a time when Nintendo of America started to handle the marketing in the US. So NOA probably wrote a little scenario for the instruction manual and decided that since there were pipes in the levels (and water at the bottom that has no gameplay purpose), that the Bros. were plumbers. Maybe NOA called Miyamoto to tell him that carpenter was not a good thing to use, explaining that the english definition of the word didn't fit well. This is speculation so I could concede that they were plumbers in that game, but only in that one. A charpentier has to be skilled when it comes to walking and jumping on narrow platforms. This is the skill that Mario predominantly uses in all games in the main series, and that can even applied to the dreamland of SMB2 US. Still, there are other clues that Mario is still a charpentier in SMB1. His duty is also to make sure everything fits well with the frame, and that includes working with bricklaying guys. A charpentier having to renovate or realign the frame of an already built brick house will have to dismantle the bricks to access the frame. The [?] boxes found in SMB1 are also a typical element of a building frame some kind of metal box or plate with 4 screws in the corners. You can also find moving platforms in SMB1 made of I-beams. The structure of levels in SMB1, SMB3 and SMW are similar to unfinished buildings. In Super Mario 64, there are tons of brick patterns, elevators, concrete, metal and wood platforms and narrow platforms where Mario has to be careful just like on a high rise construction site. Kicking a giant wooden board (in Whomp's fortress) to make a bridge is something a cartoonish charpentier would do. Another thing to note: there are very few pipes in SM64... But hey I'll probably come out as a wacko for this theory, I've never seen anything about it on the web. "Who does he think he his to assume that carpenter was a mistranslation because the translator also spoke French?". To me, it all fits too well. I guess it's hard to believe for anyone that doesn't speak French (and/or hate French), since I could have invented the definition. You could try to translate this page with google: http://fr.wikipedia.org/wiki/Charpentier_%28métier%29 though the result maybe confusing Sorry if it was long, I got carried by my theory because I found (today) that it made much more sense with the French definition. Maybe I could write a thesis on that! Seeing all I had to write to back up my claim, I won't be using "Carpenter 64" and don't worry, I won't use "Charpentier 64" either! I don't want to have to explain that again each time I present the editor. I hope at least a few of you found my theory interesting, though I'm sure some will find it a little wacky. I guess we're back with ToadsTool. I would like Toad's Tool 64 better. Or maybe Mario 64 Architect? I don't know... nothing is set in stone yet! -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Oh well thanks for the correction. that throws my whole theory out of the window Nahhh not really, Miyamoto doesn't speak English very well, and probably even less in those days so he probably had someone translate Mario's job description for him and that's where the mistranslation happened. The core question that I would like anyone here to answer is: If Mario was a wood worker (carpenter), then why, aside from barrels, is there no wood in DK? By a weird coincidence, the levels in DK look like metal building frames, which is in French called a charpente. And the job of a charpentier happens to include walking on building frames and platforms, sometimes high in the air, climbing ladders and carrying tools like hammers, putting rivets to install metal beams, working with cement etc. So it fits perfectly with the DK setting. But yeah this is getting out of topic. Go Monkey Kong 64! Yeah this is a screenshot from a crappy DK port on the TRS-80 CoCo 2 that is really called Monkey Kong. Edit: Ok to really get back on topic, I compiled a list of all 3d objects refered by the game, and there are 478 of them! They are defined in 49 different geometry layout segments. I also built the list to include which MIO0 files these geometry layout segment use for the polygon and texture data. That will be useful to be able to manage segments. The editor only provide access to objects that have their segments loaded using 0x18 0x1A and 0x17 commands. Geo:1279B0 MIO0:114750 Ptrs: [0, 28, 56, 132, 156, 292, 360, 444, 560, 644, 11732] Geo:132850 MIO0:12A7E0 Ptrs: [0, 24, 484, 584, 612, 652] Geo:134A70 MIO0:132C60 Ptrs: [0, 288, 576] Geo:13B5D0 MIO0:134D20 Ptrs: [0, 776, 808] Geo:145C10 MIO0:13B910 Ptrs: [0, 104, 268] Geo:151B70 MIO0:145E90 Ptrs: [0, 1448, 1508, 1552, 1604] Geo:1602E0 MIO0:1521D0 Ptrs: [0, 272, 876] Geo:1656E0 MIO0:160670 Ptrs: [0, 260, 540, 840] Geo:166BD0 MIO0:165A50 Ptrs: [72] Geo:16D5C0 MIO0:166C60 Ptrs: [0, 192, 216, 392, 436, 548, 628] Geo:180540 MIO0:16D870 Ptrs: [0, 1040, 1128] Geo:187FA0 MIO0:180BB0 Ptrs: [0, 48, 444, 656, 808] Geo:1B9070 MIO0:188440 Ptrs: [0, 144, 176, 2756, 2880, 3004, 3068] Geo:1C3DB0 MIO0:1B9CC0 Ptrs: [0, 644, 756, 804, 908, 1044, 1104, 1128] Geo:1D7C90 MIO0:1C4230 Ptrs: [0, 184, 208, 532, 856, 1152, 1488, 1516] Geo:1E4BF0 MIO0:1D8310 Ptrs: [0, 996, 1096, 1456] Geo:1E7D90 MIO0:1E51F0 Ptrs: [240] Geo:1F1B30 MIO0:1E7EE0 Ptrs: [0, 28, 220, 416, 560, 916] Geo:2008D0 MIO0:1F2200 Ptrs: [0, 40, 424, 448, 472, 1228, 1252, 1276, 1304, 1488, 1552, 1600, 1644, 1684, 1764, 1976, 2292, 2608, 2648, 2736] Geo:218DA0 MIO0:201410 Ptrs: [0, 32, 64, 168, 316, 416, 512, 612, 708, 808, 904, 936, 1084, 1232, 1528, 1676, 1824, 1972, 2152, 2332, 2512, 2692, 2736, 2832, 2860, 2956, 3052, 3140, 3212, 3236, 3312, 3388, 3496, 3604, 3716, 3744, 3796, 3876, 3948, 3992, 4020, 4072, 4096, 4120, 4168] Geo:3828C0 MIO0:371C40 Ptrs: [1456, 1480, 1504, 1528, 1552, 1576, 1600, 1624] Geo:395C90 MIO0:383950 Ptrs: [992, 1024, 1052, 1084, 1132, 1188, 1228, 1268] Geo:3CF0D0 MIO0:396340 Ptrs: [3840, 3864, 5400, 5424, 5448, 6464] Geo:3E6A00 MIO0:3D0DC0 Ptrs: [1328, 1352, 1392, 1416, 1440, 1464, 1488] Geo:3FB990 MIO0:3E76B0 Ptrs: [1472, 1496, 1560, 1584, 1844, 1892, 1940, 1964] Geo:405A60 MIO0:3FC2B0 Ptrs: [1088, 1112, 1136] Geo:40E840 MIO0:405FB0 Ptrs: [864, 888, 912] Geo:419F90 MIO0:40ED70 Ptrs: [1408, 1432, 1472, 1512, 1552, 1576, 1600] Geo:423B20 MIO0:41A760 Ptrs: [2304, 2328, 2352, 2376, 2400, 2424, 2448, 2480, 2504, 2536, 2560] Geo:42C6E0 MIO0:4246D0 Ptrs: [1456, 1480, 1520] Geo:437400 MIO0:42CF20 Ptrs: [576, 600, 624, 648, 680, 712, 736, 760, 784, 808, 832, 856, 880, 904, 928] Geo:44A140 MIO0:437870 Ptrs: [1632, 1656, 1680, 1704, 1728, 1752, 1776, 1800, 1824, 1848, 1880, 1904, 1928, 1952, 1976, 2000, 2024, 2048, 2072, 2096, 2120, 2144, 2168, 2192, 2216, 2240, 2264, 2288, 2312, 2336, 2368, 2392, 2416, 2440, 2464, 2488] Geo:4545E0 MIO0:44ABC0 Ptrs: [1632, 1780, 1804, 1828] Geo:45BF60 MIO0:454E00 Ptrs: [960, 984, 1008, 1032, 1056, 1080, 1104, 1128, 1152, 1176, 1200, 1224, 1248, 1272, 1296, 1320, 1344, 1368, 1392, 1416, 1440, 1464, 1488, 1512, 1536] Geo:461220 MIO0:45C600 Ptrs: [496] Geo:46A840 MIO0:4614D0 Ptrs: [1200, 1224, 1248, 1272, 1296, 1320, 1344, 1368, 1392, 1416, 1440, 1464, 1488, 1512, 1536, 1560, 1584, 1608, 1632, 1656, 1680, 1704, 1728, 1752, 1776, 1800, 1832, 1856, 1880, 1904, 1928] Geo:477D00 MIO0:46C3A0 Ptrs: [1072, 1096, 1120, 1144, 1168, 1192, 1216, 1240, 1264, 1288, 1312, 1336, 1360, 1384, 1408, 1432, 1456, 1480, 1504, 1528, 1552, 1576, 1600, 1624, 1648, 1672, 1696, 1720, 1744, 1768, 1792] Geo:48C9B0 MIO0:4784A0 Ptrs: [2528, 2552, 2576, 2600, 2624, 2656, 2680, 2704, 2728, 2752, 2776, 2800, 2824, 2848, 2872, 2896, 2920, 2944, 2968, 2992, 3016, 3040, 3064, 3088, 3120, 3152, 3184, 3216, 3248, 3280, 3312, 3344, 3376, 3408, 3440, 3472, 3504, 3536, 3560, 3752] Geo:495A60 MIO0:48D930 Ptrs: [1104, 1144, 1184] Geo:49DA50 MIO0:496090 Ptrs: [2016, 2080, 2144, 2168, 2192, 2216, 2280, 2304, 2368, 2392, 2464, 2488, 2512, 2536, 2560, 2624, 2648, 2712, 2736, 2760, 2784, 2808, 2832, 2872, 2912, 2936, 2960, 2984, 3016, 3040] Geo:4AF670 MIO0:4AC570 Ptrs: [512] Geo:4C2700 MIO0:4BEC30 Ptrs: [352] Geo:4CE9F0 MIO0:4CDBD0 Ptrs: [368] Geo:4D14F0 MIO0:4CEC00 Ptrs: [656, 680, 704, 728, 752, 776, 800, 824, 848, 872, 896] Geo:4EB1F0 MIO0:4D1910 Ptrs: [1808, 1840, 1864, 1912, 1960, 2008, 2056, 2096, 2136, 2176, 2216, 2256, 2296, 2336, 2376, 2416, 2448, 2496, 2544, 2584, 2624, 3348, 3404, 3460, 3516, 3572] The pointers are in decimal, they are to be added to the Geo address. the MIO0 pointer indicates which segment is used by that geometry layout script, so that particular MIO0 file has to be loaded in order to use that geometry layout script. (Yet another edit: I removed 4 entries in the list that didn't make sense) -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 02-11-06 02:28 AM) (edited by VL-Tone on 02-11-06 02:31 AM) (edited by VL-Tone on 02-11-06 02:34 AM) (edited by VL-Tone on 02-11-06 02:45 AM) (edited by VL-Tone on 02-11-06 02:46 AM) Some update on what I'm currently doing in the editor. (I guess I should do that more often) I'm working on improving the speed of the level drawing routines. Levels with hundreds of objects can take a long time to draw (a minute or two for the whole level and objects). But take into account that my computer is also reeeeeaaaalllllyyyy slow and very old though, but I'm getting a new one that will be much faster, at the begining of March. It still won't be a powerhouse computer, but will be in line with what people have here on average. But anyway don't worry, there is room for improvement, because currently the level drawing routines take a very dumb approach. The editor reads the script, and then draw every 0x24, 0x39 and 0x43 objects, by reading and decoding the GBI (n64 graphic lib) commands from the ROM on the disk. It does that each time, even for objects that are duplicated... I'm currently working on a feature that detects if a 3d object was already decoded and built, and procede to clone the 3d model instead of decoding it again. Another feature I'm working on is having wireframe selection boxes that have a size that is relative to the object so that the object always appear inside the box. I'll stop using 3 colors on each box, and instead use color coding to differentiate the 3 types of objects, and which one is selected. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Just to be sure you don't think I'm that dumb, I don't reload and redecode objects each time they are moved. Your approach is ideal, but is not as easy to use with SM64 There are 478 objects found in the game, and each of those can be made of multiple parts. I still haven't figured the geometry layout data in its entirety, and its relation to the "skeleton" data. Many of the 478 objects are themselves composed of sub-parts which are put in a hierarchy in the geometry layout data. The thing is I still don't know how parts are positionned in space. Most objects that are one or 2 parts and don't have any pivots can be displayed correctly, but the animated characters have their body parts drawn all at the same position. But let's get back to my point, creating display lists (that contains polygon data right?) for all those 478 objects and their sub-parts would take too much time, well at least in Director/Shockwave. Maybe I could pre-calculate those lists and include them in the editor but that would be ehmmm... not good? Since Mario 64 can only use specific sets of objects in a given level, I decided to load objects for specific levels only when they are needed in a level, to shorten the time it took to load the level. Also this approach was implemented at a time when I didn't have the list of all 478 objects. It's not a list of offset found somewhere in the ROM. I had to write a not so simple routine to generate it. What I think I will do (for now) is generate/draw meshes on a level basis, creating/drawing only those that can be used in a given level, then cloning them when the level is actually drawn. When the user changes the object type, the old one is deleted then the replacement is created by cloning the corresponding model. Creating a mesh from a displaylist is not as straightforward in Director and would add too much overhead, cloning is faster. I guess I shouldn't have said how much time the biggest levels took to load on my very old computer, don't worry, it will be much much less than that. (let's say 15 seconds in the worst case on a 1.2 GHz computer) One of the main culpit (beside the current redundency when loading objects) is disk access, which has to be done byte by byte because for some reason Director stops reading on byte "00". This could be solved by using an Xtra, which is a plug-in used to extend Director. One of these, the BinaryIO Xtra, is much faster than the built-in disk acces. The only thing, it's shareware, and the unregistered version displays a dialog each time you start the .exe version of the Director movie. Yeah it's a pain, but Lingo is what I know... -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Oh great, I lost a long post again.... (This time the board ate it!) I guess I'll have to summarize what I wanted to post... 1. Something about not knowing what to say, and being shamefull about the current speed. 2. Then I explain that yeah it's a disk access speed problem, and the fact that I read/decoded object multiple times is also a major factor. Director is not that slow in itself, it can performs tens of thousands of operations per second, if not hundreds, on any computer sold in the last 3 years. 3. The BinaryIO Xtra is the solution, it could load all ROM "banks" found in M64, in a second or two, and it would only need to do this once you open a ROM. The only problem is that it will display a small nag dialog each time the editor starts. 4. Explaining that it would be much better anyway, even with the BinaryIO nag dialog, and maybe hope that someone donates the license, after the editor is released. 5. Making sure everyone understands that the editor itself is freeware, and that I need only one license to remove the dialog for everyone. 6. Trying to address the fact that some will say that my editor is crap based on the current performance of the unreleased alpha on an ancient <400Mhz computer. 7. Something about saying that BGNG is a much better programmer than me, but that the difference between speed is also exagerated by other factors. 8. Trying to explain that in the end, I do this for fun, not fame or money. And that I'm confident that I will improve the speed vastly, and that's what's important for me now (compared to worrying about the doubts I created). 9. There was nothing worthy after that -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Well the first GUI based Notepad program released in a commercial manner was included in the original Macintosh in 1984. Actually it was a "Desk Accessory" which is kind of like the Widgets are in Konfabulator or OS X's Dashboard. It was included in Mac OS 1-9, but was retired starting with OS X. But anyway there always been a bare-bones Text-editor included with the Mac OS, called TeachText, then SimpleText, then in OS X it was replaced by "TextEdit" which is also basic but also includes powerful features. It can open Word .doc files, do spell checking, render html and many other things. But enough Mac blabbering. The dialog for BinaryIO is small, includes text some text about registering it and an OK button. It is the only annoyance, and it doesn't prevent you from using the editor. Again I have to state that the editor is and will always be Freeware! I won't personally nag people to donate for the license, but obviously I wont refuse if someone donates the license. Here are the good news. After some preliminary tests, I found that I can load all 131 possible data segments in memory in 8 ticks! That's more than 8 megs of data, in 8/60th of a second, and on my dinosaur Mac. By comparison, with the old built-in byte by byte method, it would have taken 5 minutes There will still be some little overhead since Director cannot store raw byte data in variables. In this case the BinaryIO copies the bytes as text in a variable list, so to read them I have to use the chartonum() function. BinaryIO can also read bytes in a more "numerical" fashion, as signed integers, long integers, float etc. but it can only read one of these at a time. The command I used in my experiment can load multiple bytes in one chunk, but only as text. But anyway its the best way to store and access bytes in a variable in Director, without using an I think I'll do a major rewrite of the editor, it's getting too patchy, as I added special cases to deal with objects formats I just found about. Yesterday I imported the main decoding routines in a new project. I'll work on making them read the data from the segments stored in variables using the Xtra, instead of using the old method. After that I'll have to decide if I recopy the new routines to my old project, or if I try to build a new one after it. It could end up being faster to do that instead of trying to work with the patchy version I have now. The current editor evolved from nothing, and grew as I discovered new thing in M64, and incidentally parts of this program was used to reverse-engineer the game. I should have separated the two before, but it's not a bad situation. Now that I have a clearer overview of the format in my head, I know I can write new version with simpler and optimized code, and I already experimented with different interfaces. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt I was hesitant to do a rewrite, but now that I think about it, it will be more easy and pleasant to start from scratch. I won't completely start over, as I will use some parts of the "old" code too, and reuse parts of the graphic interface. The only important thing missing is that I don't know how articulated objects are built. As I said, I'm still puzzled about how to find the position of the body part joints on objects like Mario. I know how they are stored as hierarchies, but this data doesn't include position of these parts. For now, I'm stopping there, finding how this works is looking to be very complicated. Cellar Dweller was on this particular case the last time he posted, he may be the one that brings the answer to this problem. Still I will consider the possibility that he may not find the answer, so I will build my editor around this limitation. It's very propbable that objects with animated articulations won't display properly in version 1.0b. Static or rotating objects are fine though. There will be boxes around every objects (that you can hide if you want), so you'll be able to select and position invisible objects. Menus will have descriptions so you can chose these object types even if they don't display. I don't mind having this limitation in version 1.0b, it's more of a cosmetic thing than a functional one, even if visual cues are useful too. The tool will still be very powerful for what it will do, and will lead to interesting discoveries... By the way I've found the beta yellow fish found at the bottom of this beta Mario 64 picture: More about it soon... Edit: And soon enough, here is more about it: I don't know which behavior pointer it should use, so I used some static object behavior, though I could try to use one from another fish. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Originally posted by BGNG -------------------------------------------------------------------------------- I'd hate to burst your bubble, VL-Tone, but that fish is in the game. Check the beginning of Dire, Dire Docks. -------------------------------------------------------------------------------- Oh crap, it was late, I was tired and the only place I remembered seeing this fish is in that beta picture... And the description of the picture said that this fish wasn't in the game. It's the description's fault Also, I found that it was "loaded" in Wet-Dry World using a 0x22 command, but is not used. I didn't search much more though, as I would have found it in Dire Dire Dock... Currently, DDD doesn't load anymore in my editor, since I recently implemented the decoding of special objects positions in the solidity data. There must be a command that I didn't define a length for, it's only a matter of finding its length (trivial). Anyway, next time I find what I think is a beta object, I'll make sure it's not used in the game! As far as I know, no Mario 64 beta were ever leaked. Here is a very small video from the beta version, dating from 1996 that only few of you may have seen: ftp://www.gamezero.com/video_files/mario64.avi I had found this video a while ago trough archive.org, but I traced back the website that was credited at the end of the video (gamezero), and it still exists!. The site has archived content dating from 1996 until now! The site owner seems to have some fixation with cartoons of muscular women, anyway I just wanted to warn you if you visit the rest of its site -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Raccoon Sam: These old .avi files would play on Quicktime in OS 7-9 with a plug-in called "intel indeo video". But this plug-in wasn't rebuilt for OS X. Fortunately you can use a program called VLC to play the video, it can play just about everything QT cannot play (including DIVX and others). For WMV files, you may be interested in the free Flip4Mac WMV QT plug-in, which enables you to play WMV videos in Quicktime. To download the Mario64.avi instead of having it opened by the QT plug-in, option-click the video link or do a right-click and select "Download file" -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 02-15-06 02:00 AM) (edited by VL-Tone on 02-15-06 02:01 AM) (edited by VL-Tone on 02-15-06 02:11 AM) Well thanks for taking care of the video mirroring, transcoding and everything By the way BGNG, ogg video does play using VLC on my machine. (But I still needs a new computer for other reasons) So what do you guys think about the video? I remember seeing part of it on TV in 1995-96, I wish I had a full resolution version... Anyone got any idea on how we could find this? Maybe contact some old video-game magazine that were there at the time? Or the guy that runs that game-zero site? I'm sure someone somewhere has this on VHS... -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 02-15-06 11:30 PM) Originally posted by BGNG -------------------------------------------------------------------------------- I know a guy who's official Nintendo press. I might be able to get the video from him. -------------------------------------------------------------------------------- Cool Edit: I deleted the rest of the post, since it ended up being useless, and this is getting off-topic. So ehm... I guess I'll post some filler like new screenshots... later -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt TS_Death_Angel: these are nice videos you found there! Many of these I've never seen before and they are much better quality than the little Mario.avi I had. To get back on topic, here's is an update of my progress. I started rewriting the core of the command loading process. Here is a code snippet so that you can see how Lingo (Director's scripting) can look like. Warning! Geek Alert! Most of you may not understand a thing to this code, because they are either not programmers, or are confused and unfamiliar with the Lingo synthax. on loadcmd bankoffset, cmdpos,strucs global metaram ram= metaram.getprop (bankoffset) repeat with onestruc in strucs pos= cmdpos +onestruc[1][1]-1 len=onestruc[1][2] case onestruc[2] of #int: paramvalue= chartonum(ram.char[pos]) #intlong: paramvalue= longint(chartonum(ram.char[pos]),chartonum(ram.char[pos+1])) #int3bytes: paramvalue= wordint(0,chartonum(ram.char[pos]),chartonum(ram.char[pos+1]),chartonum(ram.char[pos+2])) #intword: paramvalue= wordint(chartonum(ram.char[pos]),chartonum(ram.char[pos+1]),chartonum(ram.char[pos+2], chartonum(ram.char[pos+3]))) #sigint: paramvalue=sig(longint(chartonum(ram.char[pos]),chartonum(ram.char[pos+1]))) #hexstring: hexstring="" repeat with i=1 to len hexstring=hexstring & hex3 (chartonum(ram.char[pos+i-1])) end repeat paramvalue=hexstring #declist: declist=[] repeat with i=1 to len add declist,chartonum(ram.char[pos+i-1]) end repeat paramvalue=declist #hexlist: hexlist=[] repeat with i=1 to len add hexlist,hex3(chartonum(ram.char[pos+i-1])) end repeat paramvalue=hexlist #bin: paramvalue=charToBin (ram.char[pos]).char[9..16] otherwise paramvalue=0 end case pos=pos+len onestruc[3]=paramvalue end repeat return [#bankoffset:bankoffset,#cmdpos:cmdpos,#strucs:strucs] end The Loadcmd function will read bytes from a memory segment and place them in a list template. The actual data of each segments is stored in text chunks inside the variable metaram. This metaram variable is itself a property list, where the property labels for each item is the position in ROM of the segment. The ram=metaram.getprop (bankoffset) sets the variable named ram to the right segment. So bankoffset is an input variable that will hold the start offset of the requested segment. The variable basepos is the offset inside the segment where the command is found. bankoffset+ basepos= the address in ROM of this command (in uncompressed data). The variable strucs contains a property list that is fed as a template. An example of a simple strucs template that could be used, for command 0x22. strucs=[#objectid  [4,1],#int,0],#banknum[5,1],#int,0],#offst[6,3],#int3bytes,0]]
What the Loadcmd function does is to replace the zeros (third item of each sub list) with actual data read from the segment. The format of each item in the strucs list is something like that: #propname position_in_command,length], #paramformat, actualdata]
#objectid [4,1],#int,0] will read byte 4 of the command and store the result in item 3 of the
list (where the 0 is). I've included other possible data formats such as 3 bytes integers, signed integers, words, long integers. You know the kind of thing that is easy to deal with in C++  I guess it gives
me more flexibility, as I could add other formats. I won't use this function to load every commands, but only those that will be editable (or eventually editable). For example, here's the strucs input for a 0x24 command: [#actvalue [3,1],#bin,0],#objtype[4,1],#int,0],#xpos[5,2],#sigint,0],#ypos[7,2],#sigint
,0],#zpos [9,2],#sigint,0],#xrot[11,2],#sigint,0],#yrot[13,2],#sigint,0],#zrot[15,2],#
sigint,0],#param1 [19,1],#int,0],#param2[20,1],#int,0],#behav[22,3],#int3bytes,0]]
The level parser will use the loadcmd function to build the list of 0x24 objects and store it in a variable called obj24data. The output of the loadcmd function is [#bankoffset:bankoffset,#cmdpos:cmdpos,#strucs:strucs]. Which is a property list with labels having the same name as the variables used in loadcmd. That means once the level script is decoded, I can refer to any parameter of any 0x24 objects. For example obj24data[10].strucs.xpos[3] will return position x of 0x24 object number 10. When the data is modified and needs to be converted back to raw bytes for subsequent saving, all the needed information will be available in each obj24data item. obj24data[10].bankoffset will retrieve the segment, and obj24data[10].cmdpos the offset inside the segment for this command. obj24data[10].strucs.xpos[1] will return the position and byte length of the xpos parameter, and obj24data[10].strucs.xpos[2] will return #sigint, meaning that it needs to be converted back as a 16-bit signed integer. Lists built with the loadcmd function will contain enough info to be used by the editor to display, modify and save changes to objects. The complexity will come from build the user-interface, and I'm not talking about button layouts. To be useable by mere mortals, the editor will have to provide menus containing only valid values, and a description of each item. Behaviors will have to be described too, and custom labels for behavior parameter will be possible, as their meaning is often specific to the behavior. But I've already planned all this, it's just a matter of re-implementing it. The polygon decoding routine is also on the list of things I have to rewrite soon, but only when I finish the level decoding rewrite. (Edit: Somehow, the pre tag messed up the layout of the whole page) -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 02-19-06 12:42 AM) (edited by VL-Tone on 02-19-06 12:43 AM) Originally posted by TS_Death_Angel -------------------------------------------------------------------------------- Originally posted by VL-Tone -------------------------------------------------------------------------------- Heh, thanks. Added another one for ya -------------------------------------------------------------------------------- Thanks again By the way, don't worry guys, I won't make another geeky post that none understand -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt I don't know why I posted it either... I guess I needed to see if I wasn't taking a completely dumb approach... Should I delete this post? Lingo is originally based on HyperTalk, the scripting language of HyperCard, an older development program from Apple built by Bill Atkinson, MacPaint's creator. HyperCard was one of the main inspiration for the World Wide Web. But bragging-rights aside, HyperTalk was a very high-level language. Lines of codes could almost be read aloud as a correct english phrase ie: "put 10 into x" or "put z after character 10 of line 2 of field hello". The term "for" was not self-explaining so it was not used, repeat made more sense. At first, Lingo was very close to HyperTalk, but it evolved in subsequent versions (I started on Director 2.0 in 1991, and the current version is 10) to include dot notation and eventually an alternate java-script syntax. The "repeat" is still used instead of "for" because of backward compatibility, not for the sake of being different. But while both FOR and REPEAT can be used to make loops, they don't work the same anyway, so what's so crazy about replacing the word FOR by something that actually makes sense? This is the kind of thing that you only have to learn once. "IF THEN" structures use "else" not "otherwise", just like about every other language: If x=1 then dosomething else dosomethingelse end if It's "case" structures that uses the "otherwise" keyword to avoid confusion with IF structures. case X of 1: dothisifXis1 34: dothisifXis34 otherwise dothisifXisneither end case Anyway I guess I sound again like ranting, but I find that these particular observations of yours are nitpicking. Director/Lingo has weaknesses I won't argue about it, but using REPEAT instead of FOR is a non-issue IMHO. BGNG, I'm not angry at you, I guess that it's the only things that could be said about this boring routine post As for the skybox, do you have a screenshot of this? What kind of texture mapping does it use? -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt was about to ask if you were sure if they were spheres, because I figured out that you assumed that from seeing multiple triangles in the sky, and I knew it simply could be the 32x32 pixels tiles. So the screenshot and your theory matches what I thought it was. The 32x32 tiles are stored in a linear way, but from what you found it seems that some tiles are reused to extend the background. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Originally posted by HyperMackerel -------------------------------------------------------------------------------- Hey, I just realized something. The game has those extra 55 stars, which IIRC are unused Castle Secret Star entries. 55 stars is enough for 7 more levels and another 6 stars (maybe more hidden in the castle). If we could get it to use those for levels, we could potentially add 7 levels! Two problems with this idea, though: 1) Nowhere to store the high score for coins. (I don't think there's any unused entries for them.) 2) The game uses a single byte to tell which star you've selected/grabbed. It has one entry for each star, and one for Castle Secret Stars, making 106 entries. Anything above 127 crashes the game (presumably a signed byte). We'd have to repoint the table of star names and fix the crashing (which could just be because it goes past the end of the table) to add stars. Of course we could just add another 55 Castle Secret Stars. Have to be a big castle though. -------------------------------------------------------------------------------- From what I've found it's possible to add "courses" to levels, as there is the possibility to use 8 course stars in a single level. You can assign a course number to a star, or make it level independent. So we could have levels with 8 courses, including the all-coin star. By the way, anyone has the text table file for SM64? Not that I couldn't find it myself, but if anyone has done it already, I'll take it! Spazzup™: I never said that, actually, the ROM will need to be expanded to at least 16 megs to use the editor, and I'll provide a small program that will do this for you (and repoint MIO0 files to the upper 8 megs). It will be impossible to make an .ips patch for the original ROM, but I don't think there's any way around it even though version 1.0 won't let you add things, as the re-compressed MIO0 can take more space than the original, and everything fits tightly in the original 8 megs ROM. I have a weird schedule at work these days, but the editor is still progressing. I'm currently rewriting the texture loading routine. It's still too slow for my tastes in some situations, it seems that the .char() function slows down when it accesses a very big variable, like the one containing the Mario MIO0 file (which is a shame...), and I may have to chop the loaded ROM segments in 32k or 64k blocks to avoid that. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt stag910 + Welcome back! Thanks for the table I'll include a text editing feature in the first release thanks to you! Though I guess I could have found it myself by looking at the font textures I've look into Mario Kart 64 and yes it uses the same texture and polygon format. MK64 track editor anyone? Nahhh Too bad I can't clone myself!. A thing in the "more feasible" range would be to import MK64 models into Mario 64! It all depends on how similar the format is. That would probably be more easy to pull off than an import/export to a 3d program. Those other n64 games with a green elf with a sword... I forgot the name... well these also use much the same polygon format I wish I could work on that too, but I suspect someone else will do it. Not all games use this format though, GoldenEye uses a different one for example, like most of the Rare games. ------------------------------------------------------------------------------------------ BGNG wrote this:ASCII was an old standard that was used in DOS, but was replaced with the ANSI character set once Windows came about. The first 128 characters are the same in both standards, which is probably what confuses many people. I guess you got confused too... ASCII is 7-bits, 128 characters. A is decimal 65. But DOS didn't use Standard 7-bit ASCII. DOS uses a proprietary variation of ASCII called OEM that descends from the original IBM PC, and uses 8-bits. The lower 128 are almost the same as ASCII, and the upper characters are used for a few accented characters, some graphics etc. At best it could be called Extended ASCII http://en.wikipedia.org/wiki/Extended_ASCII Since the term seems to encompass every 8-bit extension of ASCII used on various platforms. But Unicode since Windows 95? hmmm... this is from a page on microsoft.com: The problem was the difficulty in supporting a Unicode application on Windows 95/98/ME; developers had to support those customers as well. Because those platforms do not have the native Unicode support provided by the NT family of operating systems, it was just easier to write non-Unicode applications. However, times have changed.... Starting with the Windows XP RC1 version of the Platform SDK, the Microsoft Layer for Unicode on Windows 95/98/ME Systems (MSLU for short) can help you solve this important challenge. This component provides a layer over the Win32 API on Windows 95/98/ME so that you can write a single Unicode version of your application and have it run properly on all platforms. Cool, Windows 95/98/ME got a "real" unicode layer when Windows XP RC1 was released... From all I've read on Windows related sites, the support for unicode before Windows 2000/XP was mediocre at best. Microsoft now admits it... The vast majority of developers stuck to ANSI until XP for these reasons, and many still do. ANSI is not a character set by itself, its more of a switchable dynamic character set, a Windows re-implementation of a hack they used in DOS to "switch code pages", which is a way to have multiple and extended character sets. On a Windows 95/98/ME English system ANSI uses code page 1252 by default, and this is probably what you always used yourself on these OSes. http://en.wikipedia.org/wiki/Code_page_1252 Page 1252 contains an 8-bit character set that was "inspired" by ISO-8859-1 aka Latin-1 found on the Web. http://en.wikipedia.org/wiki/ISO-8859-1 It's also an extension of ASCII, with the first 128 chars being about the same, A is still 65. There are differences between Latin-1 and Windows Page 1252 but they cannot be seen in the credits and level select. It could be standard ASCII for all we know since it uses only the lower 128 characters. ANSI Page 1252 is a Windows thing, as far as I know, other platforms don't use it natively except for translation purposes. Nintendo is not known to integrate MS "standards", and they were working on SGI platforms that likely used ISO-8859-1. Please find me text in any in-house Nintendo game that is without a doubt Windows ANSI... So to summarize, the Credits and Level select text in Mario 64 is ASCII for all that matters since this text doesn't even use any of the upper 128 characters. There is no way to prove in one way or the other that its based on any particular ANSI code page. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 02-26-06 03:26 AM) The DOS code page 437 is not more (or less) a variant of ASCII than ANSI code page 1252, ISO-8859 or the old Mac Roman for that matter. All four use much the same first 128 characters with a few differences in control characters. Incidentally, Unicode too... As for what you call "ANSI": This is from a Microsoft pdf at http://download.microsoft.com/download/5/6/8/56803da0-e4a0-4796-a62c-ca920b73bb17/21-Unicode_WinXP.pdf The term "ANSI" as used to signify Windows code pages is a historical reference, but is nowadays a misnomer that continues to persist in the Windows community. The source of this comes from the fact that the Windows code page 1252 was originally based on an ANSI draft, which became ISO Standard 8859-1. However, in adding code points to the range reserved for control codes in the ISO standard, the Windows code page 1252 and subsequent Windows code pages originally based on the ISO 8859-x series deviated from ISO. To this day, it is not uncommon to have the development community, both within and outside of Microsoft, confuse the 8859-1 code page with Windows 1252, as well as see "ANSI" or "A" used to signify Windows code page support. Talk about confusion... I guess I got it wrong too about ANSI, its neither a character set nor code page support. You wrote, in bold: "as all 32-bit Windows platforms provide functionality for wide characters." My point was that Windows 4 didn't natively support Unicode, as in "the whole enchilada". How do you explain my other quote from the MS site admitting that real Unicode developer support was almost non-existent in Win 4 and was hard to develop for? As far as I know Unicode =! Wide characters. Sure you could view web pages and unicode text, but making an application that used it effectively to create and edit documents was a seemingly complicated process. Anyway if we are only talking about files that most people in this community encounter, then your reference to Unicode only added more confusion, as these people don't use it. DOS used an extension of ASCII, and so does the English version Windows even today with the "standard" code page 1252. So your whole point falls flat (sorry, I don't like to say that). Everything you could say to explain your use of the term "ASCII" to describe the standard DOS character set can be used to say that all English versions of Windows used ASCII as a standard. In other words, if you say DOS used ASCII, then by inference what you called "ANSI" is ASCII too. ---------------------------------------------------------------------------- Ok I'm wasting too much time debating about this... Proffessor Gad, nice pictures but I don't think they deserve to be here. There are tons of things that can be done with a gameshark, but this is not the point of this thread (I guess that discussing text encoding is neither but text takes less space). But hey don't stop having fun because of this ---------------------------------------------------------------------------- HyperMackerel This is great news! I thought it was Zelda OOT: Master's Quest for some reason... (OOT has 1400 YaZ0 files, so I figured out that maybe OOT MQ had around 2000) I'll continue this reply tomorrow since I work early this Monday. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 02-27-06 01:00 AM) Proffessor Gad: I don't know how behavior code works, it's customized for each objects, while what you are asking would be technically possible, I don't know how to do it, and for now I don't intend to look for the answer any time soon. Update on my progress: Almost all the dialog text is contained in MIO0 file 00108A40. There are two (or three?) lists of pointers for the text. One is at FFC8 inside the same MIO0 file, and each of the item in the list is 16 bytes. Here is the first item, which points to the first message you get in Level 1. [00 00 00 01] [06 00 00 1E] [00 C8 00 00] [02 00 7D 34] The last 4 bytes are the segment number and offset of the text in the segment (in this case the segment number is always 0x02, which is the one containing the data from this MIO0 file decompressed from 00108A40 in the ROM). The first 12 bytes are parameters that presumably set the kind of dialog box that appears, and which sound it plays. The first 4 bytes are almost always [00 00 00 01] and [00 C8 00 00] seems to be used 95% of the time. There are 170 in this list, and if I'm not mistaken, you can choose anyone of those using one parameter byte used with the behavior for signs, pink bob-ombs and other talking fellows. At 10A68 (in the MIO0 file) there is another list of 170 items, this time each item is only a 4 byte segment-offset pointer, there are no parameters attached so maybe they are more generic dialogs. Then at 10F68 a smaller 4 bytes pointer list can be found, this time 26 of them. --------------------------------------------------------------------------- So I started to make an editor for text dialog when I remembered that I couldn't edit this particular MIO0 in my extended ROM. Currently, I edit an extended 16 MB ROM that has all MIO0 files decompressed and appended at the end of the original ROM. All 0x18 commands are changed to 0x17 so the game loads raw uncompressed data instead of decompressing a MIO0. Then, the start and end pointers are changed to point at the decompressed data in the extended portion of the ROM. There are two problems with this approach: 1. The MIO0 file 108A40 is a special case, it's decompressed and loaded with a custom command that cannot be easily changed to a 0x17 command. (I know how to re-point it though, thanks to Cellar Dweller) 2. The command 0x1A which is used about once per level loads a compressed texture segment like the 0x18 could do, but when I try to re-point it to decompressed data and changing the command from 0x1A to 0x17, the game crashes. So some texture would not be editable. I could bring the MIO0 decoder to a good speed thanks to faster disk access, but the re-compression is still a problem... I cannot find a way to build a fast enough compressor in Director. Scanning the 4096 last read bytes for matches for each bytes read is taking too much time. I tried to use the offset command (which finds a string position) to get a good speed, but it's case-insensitive so it's useless to deal with byte data. There are commands to find position of properties or items in lists, but not multiple items (bytes) at the same time. Maybe there is something I don't know about searching lists in Lingo that could give acceptable speed. Yes I know It's pretty bad because after all MIO0 compression is simple... Whatever... I don't think that keeping the data decompressed is a bad thing in itself. So what can I do to get around the two problems mentioned earlier? I found the answer yesterday, and I wonder why I didn't think of it at the beginning of all this. It's simple, MIO0 files don't have to contain compressed data! You can make a perfectly valid MIO0 file that doesn't contain anything compressed. Just make a valid header, building a data map table that has all bits set to 1, the raw uncompressed data follows the header, unmodified. This way I'll be able to save all MIO0 files in 1 second instead of much more. This way the game will work as intended, loading valid MIO0 headers, but the data inside the MIO0 files will be easily editable without having to compress-decompress. If for you BGNG and Hyper, MIO0 compression and decompression is quick and trivial, then go for it, re-compress everything after editing, but this is not the approach I'll take, I don't have much choice. As a bonus, I'll avoid having to deal with MIO0 files that change size after re-compression. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 02-28-06 08:19 PM) (edited by VL-Tone on 03-22-06 04:41 AM) I'm fully aware that working with byte arrays is faster, but the last time I checked that BinaryIO Xtra was the best option, but it was limited. So I checked again, and it seems that I missed out a better solution. It's called BuddyFile Xtra. The license is cheaper and from what I read I don't need it since the editor won't be a commercial product. It doesn't have a nag dialog, and best of all it can directly read data and return an integer list... That will solve most of the problems I had. Director doesn't support byte arrays as is. Variable lists used in Director are much like 1D arrays, but they can contain a variety of data types. listvar=[0,1,2,3,"abc",#symbolA,65537,-10,[1,2,3]] As you can see, a list can contain other lists so you can build multi-dimensional arrays too. The Buddyfile Xtra will return a linear list that could look like [0,0,2,255,255,128,10,12] with each value being equivalent to a byte having been read. Then I can read back the data much more directly instead of having to use chartonum(). I can just do byteread=bytelist[x] to get the decimal value at position x. It won't help that much for the compression problem though, since the problem is that I would not be able to search for example for a match of [255,128,10] in that list, I can only find the occurrence of individual bytes, so the matching routine will be as slow. But anyhow, seeing that it's not really important to anyone that I re-compress the data or not, I won't try to do it. I'm currently building a small program that will reposition all MIO0 files, build new header and copy the uncompressed data after each header, and repoint the 0x18 commands offsets. I had made a similar program that didn't include the MIO0 header aspect, but it was slow anyway, so I'm starting a new one. I'll probably release it as a small stand-alone program in the next few days, so that you guys can have a concrete example of what the editable ROM will be like, and maybe manually edit some things in the MIO0 if anyone feels like it. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 03-01-06 12:45 AM) (edited by VL-Tone on 03-01-06 12:47 AM) (edited by VL-Tone on 03-01-06 12:48 AM) I leave the forum a few days and what happens? Like BGNG said, I don't think that working on Super Mario 64 DS is a good idea, for many reasons. If anyone wants to, they can... in another thread. The game is different anyway, they may have use some polygon data and textures from the original, but the engine is completely different. So we won't learn much from diging into the DS version. -------------------------------------------------------------------------------- Ok so BGNG about the code snippet you posted, it looks like the first thing I tried. It worked but it was too slow, that's why I was trying other methods. -------------------------------------------------------------------------------- Hyper: Actually, the "Xtras" plug-ins for Director are .DLLs on Windows. They have to be built following some specifications though. Maybe I could try to look how easy it could be to build an Xtra. The thing is, I would have to build versions for both platforms. But anyway, I just got a brand new (overpriced) Mac mini! It may not be the fastest thing on the market, but it's definitely much much faster than my old iMac which was incredibly ancient and slow. I'll have to make some tests to see how fast my projects run on it. I'm still in the process of transferring stuff and reinstalling programs, and I will install Director MX tonight. From the speed I get from the Shockwave Peach Castle thing, it's really encouraging. Though the Shockwave thing doesn't do File I/O, the slowness I experienced in my editor was probably mainly due to the simple fact that my other computer was simply too slow. With a "decent" computer at last, I'll have much more motivations to work on the editor. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone-neko on 03-07-06 05:59 PM) 1-Can you predict when the editor will be finished? I thought I heard someone say 2006,Feb. or March. And it's March right now. Let's say the public beta will be released before the Revolution. 2-Will the editor be able to place water where one wants to place it? For example, the person could move around "cubes of water" Maybe this will be part of the editor, but as for now, I don't know what defines water areas. 3-If the editor is still a long time away, can you at least release a very small princess slide editor?[wait...I don't think I'm alowed to ask for editors...] No, and what you should understand is that my editor won't be able to modify the actual geometry of things (at least not until version 2.0), so in the Princess slide, the only things you would be able to move and change are coins and other objects found on the slide. I'll post other pictures eventually don't worry -------------------------------------------------------------------------------- Good news my first tests reveal that my editor is much much faster on my new comp. Levels load in 3-15 seconds depending on the size, but that's with the old method which has a lot of redundancy, decoding the same objects multiple times. (It use to take more than a minute to decode some levels + all objects) Also, I made a routine that pre-loads all textures when you open a ROM. The bad news are that it takes up to 25 seconds to load 850 textures found in the game. I'm working on improving that before continuing the rewrite. I may release a texture editor as a first testbed, to get an idea how the process of extending the ROM and loading texture works on other systems. On the current working editor I've implemented key controls to move and rotate objects, and new camera controls to make it orbit around the selected object, zoom in and out. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 03-09-06 10:10 PM) Originally posted by proffessor_gad -------------------------------------------------------------------------------- Nice. Can't wait till it is done. By the way, I accidently changed some terrain values in the game. Clumby me! But my point is that editing terrain is possible. Changing one value, such as B3 to F4 can make the terrain around the castle's cannon higher!( It makes it like the terrain around the second cannon in bobomb battlefield ) But it does not change the actual polygon, so you walk around in the air. Just thought that it would be helpful if I told you... -------------------------------------------------------------------------------- Thanks for wanting to help, but I never said that editing the terrain was impossible. I already know how it can be done. I don't want to explain yet another time why I won't put polygon editing in version 1.0, just re-read the thread. You can always try, but I don't think you can help much now, I know what I need to know to build the kind of editor I want. I'm still missing the bone/animation data format for characters and objects with moving parts, but I doubt that you can find how it works. I hope it doesn't sound too rude, don't stop trying to find things and have fun hacking Mario 64 Originally posted by creaothceann -------------------------------------------------------------------------------- Originally posted by VL-Tone -------------------------------------------------------------------------------- Also, I made a routine that pre-loads all textures when you open a ROM. The bad news are that it takes up to 25 seconds to load 850 textures found in the game. I'm working on improving that before continuing the rewrite. -------------------------------------------------------------------------------- Can't you save the result to a file, and load that when the program starts? (I'm assuming that the decoding takes the most time.) If not... well, at least a progress bar would be nice. -------------------------------------------------------------------------------- I thought about saving the textures to disk beforehand, and this is how I used my editor before, but here is the problem: what if you open a ROM with textures already edited? The textures would have to be loaded anyway. Maybe I could put a checkbox option that reads "Load custom textures" in the editor. Another thing I could do is write a small table in the ROM that keeps tracks of which textures have been edited so it only loads them. A completely edited ROM would still take as much time though. I'll work on releasing a bare-bones texture editor and a ROM expander/repointer so that you guys can test it on your systems. It wouldn't surprise me that it's faster on most of your PC's since Director has faster disk access on Windows. So until then, here is a "sprite sheet" of all the 850 textures. I think it covers every texture in the game, except the fonts and interface icons. The full resolution version is too big for Photobucket (it's a 900k PNG), and I don't know where to host it, I don't feel like putting it on my own web server. Wasn't there a thing called "commons" or something like that on this board? I can't find it anymore... was it removed? Can anyone here host this file? -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- This is nothing that wasn't possible before, decoding the textures from Mario 64 has been possible since a long time. I'm sure people working on the High-Res pack have seen these before. But if you only used a bitmap viewer and peeking in the MIO0 files, you would have to spend time finding those textures, aligning their bytes and the pixel width (16, 32 or 64), since many are found in between polygon data at various offsets and with different sizes. Some are grayscale and some are RGBA. I built a list of all texture offsets, their size and bitmap mode, by decoding all the objects found in the game, and adding these properties to a list, each time a texture command is encountered. This list is already calculated and stored, and it was used to load all of the textures sequentially. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Here is the full resolution sprite sheet for Super Mario 64 (well click on this thumbnail to get it) creaothceann: if you mean decompiling the ROM ASM and recompiling, well I don't think anyone here is close to do that (unless I'm mistaken) and I don't see how it can solve my problem. I don't see anything wrong with storing some editor data in the ROM. It has to be extended/modified anyway, and there is plenty of space for that. And this doesn't prevent another editor from opening the ROM. But I'll start by making a little program that people can test and give me feedback on the speed. proffessor_gad: Sorry I won't release the Luigi patch, I promised someone that I wouldn't. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 03-13-06 10:52 PM) Originally posted by proffessor_gad -------------------------------------------------------------------------------- So you say that editing textures will be possible... But will editing models be possible with your editor? -------------------------------------------------------------------------------- No. I thought I made it clear enough, but I guess it wasn't. Maybe in version 2.0, but definitely not in version 1.0. -------------------------------------------------------------------------------- In other news: I'm almost done with the "ROM extender" program, there is only one thing left to add, which is the routine that will repoint MIO0 bank 00108A40, which is a special case (it doesn't use a 0x18 or 0x1A command). Also I have to write some documentation. It will be released (probably) tomorrow. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt professor_gad, if you continue to ask questions like this on I'm gonna start ignoring your posts. It was getting pretty obvious that you were trolling, and now you just admitted it. I try to be tolerant and polite, but starting a few posts ago I had to restrain myself from calling you names, because you keep asking questions that can be answered by reading this thread and the archive. If you are really interested in this project, you should have known all this. So do us a favor and stop trolling. (and if you weren't trolling, well just don't ) -------------------------------------------------------------------------------- Cellar Dweller, I hope you are reading this, I'm having problems implementing a pointer swap for bank 00108A40. Here is from a previous post from you: ----------- If you want this code to load a MIO0 file that is somewhere else: 1. split the start ROM pointer into two 16 bit halves eg. 0x00108a40 => 0x0010 0x8a40 2. if the lower 16 bits is greater or equlal to 0x8000 add 1 to the high 16 bits eg. 0x0010 0x8a40 => 0x0011 0x8a40 3. place the high 16 bits at 0x3ac2 in the ROM and the low 16 bits at 0x3ace 4. do the same thing for the end pointer, except the high 16 bits go at 0x3ac6 and the low 16 bits go at 0x3aca ----------- I don't know what's the problem, but the game crashes on start when I try to repoint the segment that starts at 0x108A40 and ends at 0x114750. Here's what's found in the original game. 3AC2: 00 11 <--- High 16-bits from start pointer (+1) 3AC4: 3C 06 3AC6: 00 11 <--- High 16-bits from end pointer 3AC8: 24 C6 3ACA: 47 50 <--- Low 16-bits from end pointer 3ACC: 24 A5 3ACE: 8A 40 <--- Low 16-bits from start pointer Here's the modification I did to re-point the segment to 0x800000, ending at 0x81BB62. (note that the size is different, since it's a valid MIO0 file that contains uncompressed data) 3AC2: 00 80 <--- High 16-bits from start pointer 3AC4: 3C 06 3AC6: 00 82 <--- High 16-bits from end pointer (+1) 3AC8: 24 C6 3ACA: BB 62 <--- Low 16-bits from end pointer 3ACC: 24 A5 3ACE: 00 00 <--- Low 16-bits from start pointer Unfortunately it doesn't work If you want to test it yourself: 1. Expand a ROM to 16 or 24 MB, 2. Download this MIO0 header: http://pages.infinit.net/voxel/MIO0Header800000.bin 3. Copy and Paste it at 0x800000 in the ROM. 4. Copy the uncompressed MIO0 data from segment 108A40 and Paste at 0x803154 in the extended ROM. The resulting MIO0 file should end at 81BB62. 5. Try to change the pointers at 3ACx. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 03-14-06 10:57 PM) Fair enough Next time, just make sure that the question wasn't answered before. Yes it can happen, just don't do it every single time! -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Originally posted by BGNG -------------------------------------------------------------------------------- I just got done playing through The Legend of Zelda - Ocarina of Time - Master Quest and I find it rather peciuliar. Most if not all of the geometry data for the levels is the same. The only differences are the objects and actors in any given room. You can definitely make one tough Zelda game using the exact same level geometry as another one, so... I see no reason we can't have a Super Mario 64 - Master Quest. I mean, who wouldn't love to see Bullies on the floating islands in Whomp's Fortress as you attempt to catch the rabbit for a star? -------------------------------------------------------------------------------- I understand your point and you are describing why my editor will be able to create interesting "remixes" of Super Mario 64, even though it doesn't edit geometry. There are sometimes hundreds of objects found in a given level. Many of them can be course/act specific so they only appear in specified courses. In Whomp's Fortress, floating islands are objects, and they can be moved around, and you can add some by changing other objects to floating islands. Bowser's levels are entirely made of platforms that could be moved around. Couple that with text editing and texture replacing, and you'll be able to make a Super Mario 64 Master's Quest. You can't put MIPS in other places than inside and outside the castle, unless you load its MIO0 bank and geometry layout data in a level. This is the kind of things you'll be able to do in version 1.5. It looks simple to implement, but I want to add safeguards in the interface and that may be more complicated. If you simply change a bank loading command, the game will crash when this level is run. That's because objects defined with the 0x22 command point to objects that are not in the MIO0 you swapped. I'll have to put some mechanisms that warn the user and highlights invalid objects when a bank is swapped. The editor for 0x22 commands (also due for 1.5) will present a list of objects that can be loaded with the current banks. Version 1.0 will be able to do really nice things, particularly in modular levels. Once I get around the disk access limitations, I'll finish the interface. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt It does work for every other MIO0 segments. Maybe it crashes when the starting address is more than 0x800000? I'll try relocating this MIO0 file elsewhere in the original first 8 megs of the ROM to see what it does. Since the original compressed MIO0 are not used in the extended version, there is plenty of space to do that. Anyhow, I'll try to figure it out on my own -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt professor_gad this is not exactly right, but it's ok I'm not angry...It's normal that you may have gotten confused about this. Yes MIO0 is a compression algorithm, but it has been cracked a long time ago by Nagra and because he didn't want to release the source code, BGNG figured it out by himself and released documentation and source code (so BGNG is the real hero here ). What I did figure out is the format of the polygon data inside the MIO0 files (Cellar Dweller and others did help me). The format of things inside the uncompressed data: polygons, textures etc. is not related at all with MIO0, the same data could have been uncompressed without any trace of MIO0 compression. There are already programs that can completely decode MIO0 files, there are a few of them actually, decompressing MIO0 is not a problem in itself. Recompressing is another thing, even BGNG didn't manage to build a compressor that can produce files that are as small as the original. Couple that with the fact that if you change the data inside to something less compressible you get a bigger file when re-compressed, and that mean the MIO0 files have to be moved out of their original location, to an extended part of the ROM, where there is more flexibility for space. I'm about to release a program that moves and re-point all MIO0 files automatically but there is still one or two hurdles I have to get around. ----------- ShyGuy: The reason why the default sprites of the mushroom and other things are squishied is that the sprites "wrap" around 3D models to keep a definite and official shape. Right, though these are special n64 objects that always stay oriented toward the camera. This is a problem in my editor, since there is not built-in function to do that, I would have to keep track of all these special models and make them rotate toward the camera at every frame. The textures of Metal Mario all stop their thing and change to that one Metal Texture Square Sprite. Of course. I'm not sure what you mean by that, the Metal texture is actually round in shape. It works using a special mode that scrolls the texture on the model depending on the camera angle (I can do that in Shockwave). There is a hidden Yoshi egg sprite in there. Not much intelligence on this fact. I just think it's so awesomely cool. Yeah it's a cool item, I wonder what was its original use. With the editor you'll be able to put Yoshi eggs in some levels (like Whomp's fortress) There are various unused eye sprites. There are also unused shifty Mario Eyes. (left right up etc. excluding the sprites of the following eyes in the start screen. Them's different. Trust me.) Like this? I didn't even realize the shifty Mario eyes are not used in the game. Maybe in the end scene with Toad and Peach? Yeah Mario's face in the title screem is different, way different, it has a different polygon and texture format (for the flying stars) than the rest of the game. The eyes are actually entirely made of polygons, and the eyes can move smoothly. Interesting to note: Giles Goddard programmed the Mario's face title screen. Mr. Goddard was from Argonaut, and was one of the two main programmers of StarFox (the other is Dylan Cuthbert). VL-Tone is the greatest bipedal creature to ever use the internet. This is common knowledge. No. Not really I'm not bi, nor a pedal. Oh you mean having two legs? I have more than two! -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 03-17-06 06:45 PM) Originally posted by Hosma293 -------------------------------------------------------------------------------- Since you can't release the Luigi Hack, will we be able to make similar versions of it in Version 2.0 (Yes I said 2.0 not 1.0 ) of your editor? Lol, don't mind me, I was just looking forward to getting my hands on it somehow.. Edit: Also, (When you get this project done of cause) what are the chances of you making a Zelda OoT or MM level editor? -------------------------------------------------------------------------------- Yes it will be possible to make a similar Luigi hack with version 2.0. I may put a polygon color editor in version 1.5, so only the head geometry modification would be needed to do the same hack, but you'll be able to modify the body parts to. Version 2.0 may be released in a year, so you'll have to learn to appreciate version 1.0 for what it does, not thinking about what it doesn't do. -------------------------------------------------------------------------------- Raccoon Sam, I don't know anything about the sound except changing which music plays in what level (which will be editable in v1.0) What I would really like to find is the compressed MIDI files, and also a way to decompress them since they are stored in a Nintendo-specific format. -------------------------------------------------------------------------------- proffessor_gad: What do you mean by "play the decompressed data"? Fire up an emulator with M64, and you'll be able to play decompressed data Seriously, there are some programs that can open/edit textures found in MIO0's, though they don't take care of re-compressing the data, and you have to manually find and align textures. There are many types of data inside MIO0 files aside from textures, they also contains polygon geometry data, animation data, collision data and some objects defined in levels, like the positions for trees, coins and others. Some object positions/type/behavior parameters are stored outside the MIO0 data. Until recently, (August 2005) their formats were unknown. So if you want to know why there aren't any programs that edit data inside MIO0 files, the reasons are about the same as the reasons why my editor is not released yet. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 03-20-06 06:14 AM) My editor will take care of all these problems. There is no way around it, even a perfect MIO0 re-compressor will produce bigger files than the original, if the edited data is harder to compress. Take a MIO0 file, decompress it, replace its data with completely random bytes, and re-compress it. You can bet that the MIO0 will be bigger. So to make the data editable, it has to be moved out of its original location, since it's surrounded by data that cannot be moved to make more space. My editor will create a special extended version of the ROM that has all the MIO0 data decompressed inside. Once transformed, the ROM will be 24 megs instead of 8 megs, and runs normally in an emulator. The 24 megs version is the one that will be edited by the editor, so it won't have to deal with varying re-compressed data sizes since all editable data will be already decompressed. The only problem I still have is that the MIO0 file containing the text and interface icons and fonts is a special case, Cellar Dweller thought he knew how to repoint it, but it doesn't work. I'll still go forward with the project, even if it means that these (text and interface icons) won't be editable until someone finds how to repoint that particular MIO0. -------------------------------------------------------------------------------- Great news, I found a plug-in in Director (Shell Xtra) that can trigger external command-line utilities in both Windows and OS X, and optionally retrieve the stdout in Director. That means I could write external cross-platform C commands that deal with some of the slow loading problems I have with Director, like loading textures. BGNG was kind enough to build a custom MIO0 decoder for me that I'll be able to integrate in my editor. I was able to easily compile a Mac version with gcc, so it will keep my editor cross-platform. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 03-21-06 01:37 AM) (edited by VL-Tone on 03-21-06 01:40 AM) Originally posted by Raccoon Sam -------------------------------------------------------------------------------- Tiger, Panther, Jaguar, Puma what? -------------------------------------------------------------------------------- I'm not sure it's a good idea to be a smartass about OS X versions names here It should work on Mac OS X 10.3 and 10.4 (and probably 10.1 and 10.2). As for Windows, I guess it will work on any Win32 OS, which means 95 and up. I would support Linux if I could, but I simply can't... I'm sincerely sorry about that Someone else will have to do that, and I'll help this person if necessary. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 03-21-06 04:21 PM) (edited by VL-Tone on 03-21-06 05:48 PM) hehehe For now, I'll only use it for external commands, and maybe someday port the whole editor, to C or something like that, but don't count on it, I'm not that young anymore, I already learned too many (useless) things in my life, like how to load a program from an audio tape using a 16k Timex Sinclair 1000 micro-computer. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 03-21-06 11:58 PM) Originally posted by BGNG -------------------------------------------------------------------------------- The first megabyte of PRG-ROM data after the boot code (that is, 0x1000 to 0x101000) is checked against two checksums in the ROM header at offsets 0x10 and 0x14. I believe Super Mario 64 uses the CIC-NUS-6102 boot chip, so you'd have to recalculate the checksums accordingly if you change any data in this portion of the ROM. Originally posted by VL-Tone -------------------------------------------------------------------------------- 1. The MIO0 file 10A68 is a special case, it's decompressed and loaded with a custom command that cannot be easily changed to a 0x17 command. (I know how to re-point it though, thanks to Cellar Dweller) 2. The command 0x1A which is used about once per level loads a compressed texture segment like the 0x18 could do, but when I try to re-point it to decompressed data and changing the command from 0x1A to 0x17, the game crashes. So some texture would not be editable. -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Actually, it's a typo, which I corrected. I meant "The MIO0 file 0x108A40 is a special case" which is outside of the first meg. But the code Cellar posted is at 0x3AC0 so it is part of the checksum. This code contains the pointer to the MIO0 found at 0x108A40, and that's what must be modified to be able to edit this particular re-pointed MIO0. I didn't stumble on this checksum problem until I tried to edit some table at 0xEC7E0. The rest of the level data is outside the first meg. I downloaded the n64sums.c file. I think I found a potential endian issue in that command: #define BYTES2LONG(b) ( (b)[0] << 24 | \ (b)[1] << 16 | \ (b)[2] << 8 | \ (b)[3] ) This is the same function I had to edit to make the YaZ0 compressor work on PPC. Can I modify it under GPL? (I'm pretty clueless about these licenses) What do I have to do if I modify it? -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Ok, I compiled the n64sums program on gcc without any errors, and it seems to work without any modification. For a mario64.z64 ROM I get: BootChip: CIC-NUS-6102 CRC 1: 0x635A2BFF Calculated: 0x635A2BFF (Good) CRC 2: 0x8B022326 Calculated: 0x8B022326 (Good) I can read back this output in Director and automatically patch the ROM accordingly, so it's all good! -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt The ROM will be converted to .z64 anyway using the byte swapper. n64sums will be run after as the last process. Thanks for the compile! -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Some little update before this thread gets burried My "Super Mario 64 ROM extender" is almost ready. It works on my Mac, but the Windows version doesn't... I just installed Windows XP on Virtual PC, and I'll try to find and squash the bug. For some reason, the shell_cmd Xtra doesn't call anything on Windows. Once this one is fixed, I don't think I'll have many other cross-platform problems, Director projects, even complex ones, usually run exactly the same on both platform. A few basic issues can happen with path separators, but these are taken care off now. This program will be useful for other reasons than my editor. The ROM it produces can have its textures edited without having to deal with compression. The font and text MIO0 will now be editable, thanks to Cellar Dweller and BGNG. Once the ROM extender is released, I may release some simple quick text and texture editor, and/or some interesting IPS patches to be used with the extended ROM No Photoshop involved I swear! Yes I could put 5 Bowsers. As for moving him in other levels, this won't be possible in my editor until version 1.5, as it involves switching which bank is loaded in which level, and inserting a special object. Actually, putting extra Bowsers require deleting and adding objects, which won't be possible in v1.0 It's much harder to battle 3 Bowsers at the same time. While you pick one by the tail and start spinning, the other two will toast you Bowsers have no collision detection between themselves, and act independently, each one will become a key if you beat them. At first, the extra Bowsers will look stunned and won't attack, you have to pick them and throw them so they wake up. It seems that the behavior code will decide which kind of Bowser you get depending on which level you are. So maybe it will be hard anyway to move it to other levels. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 03-25-06 12:32 AM) Originally posted by BGNG -------------------------------------------------------------------------------- I always thought a video clip of tossing Bowser off of the mountain in Bob-omb Battlefield would make for one nice hype-inducing promotional video. -------------------------------------------------------------------------------- I'll do my best to make this possible, but I cannot guarantee it. Personnaly I would like to battle Bowser on the top of the castle -------------------------------------------------------------------------------- Great news, Windows version of the ROM extender is ready and working! (Mac version later today.) I'm confident enough to release it now: http://rapidshare.de/files/16368233/M64ROMExtender_1.1b.zip.html It's on rapidshare, you have to click the free button and wait a few seconds until the download can be started. A Read Me file is included. Have fun! -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 03-25-06 04:35 AM) (edited by VL-Tone on 03-25-06 04:38 AM) (edited by VL-Tone on 03-25-06 04:42 AM) Here you go Racoon Sam, the Mac version: http://rapidshare.de/files/16430880/M64ROMExtender1.1bMac.zip.html By the way, Tile Molester, is a Java application and works on OS X too. And for those who didn't read it the first post on this page, the Windows version of the ROM extender can be found there: http://rapidshare.de/files/16368233/M64ROMExtender_1.1b.zip.html If anyone wants to host at least the Windows version, it would be welcomed. It's a little bloated I admit, weighting about 4-5 megs (2.4 megs zipped), but it's not because of the code and interface itself, but because of the runtime engine. So the program worked for both of you Shiryu and stag910? I would appreciate some feedback from others that tried it, if they can. Did you try it with a .v64 or .z64 file? It should work on both. Did you try to run the extended ROM in emulators? The decompressed MIO0 files are found starting at 0x800000 in the extended ROM. The font and text is inside the first MIO0 file, stag910 posted a table file somewhere in this thread. Some MIO0 files are pure textures, but others are found between polygon data, at various random offsets. I will release a list of those texture offsets soon. The text offsets are inside the first MIO0 file. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt HyperMackerel, you're right, thanks for the tip Actually, what I said about the editor preventing you from saving was something I made up while writing the comment, it wasn't planned or well thought about. Yeah I can see now how it would be a bad idea. I'll try to make my editor suitable for advanced ROM hackers, yet not too intimidating for beginners. I'll try not to make any compromise, at worse I'll add some "expert" mode. I'll try not to make that a global setting, so that the expert options can be activated on a per-module basis. -------------------------------------------------------------------------------- Jelbo, your Yoshi egg is nicer than mine Somehow I was sure I optimized the palette for the animated GIF, but it's clear now that I didn't, and there was some unneeded pattern dithering. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 04-08-06 02:34 AM) I'm happy to see that you guys can now hack Super Mario 64 I'll get back at reworking the level editor. The thing is, in case you didn't know, I decided to rewrite a good part of the editor, so you won't see much of it until I get back to where I am with the current version. I decided that I'll try to make it possible to insert new objects in levels, and that in version 1.0. And I don't mean new polygons, just new objects. It'll be only possible for x24 objects, but you'll be able to put much every type of objects available in the level, including objects displayed with the 0x39 macro object command (which are referring to parameter presets that can also be used in a 0x24 command). In my rewrite, I'm considering building a basic polygon editor, but nothing fancy like I plan for version 2.0. One thing I decided that will probably make it in version 1.0 is the possibility of editing which colors and textures are used by each polygon mesh parts. The real problem with editing the level mesh is that the collision map also has to be edited in much the same way. But remember, version 1.0 will be mainly about moving and swapping objects around in levels, editing text and textures. Still it should be plenty of fun for all -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Racoon Sam: I recommend that you use the command-line version of UIPS for OS X, at: http://www.kyngchaos.com/software/ since I had trouble with the GUI version. But if you still want to try the GUI version, the first file is supposed to be the original unmodifed file, and the second the modified version. -------------------------------------------------------------------------------- Magic_Vampire_Joe: As for a music editor, like I said before, it's compressed MIDI. I'm not sure I feel like writing a complete MIDI editor while hundreds already exists. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Magic_Vampire_Joe, somehow, the music editing discussion is now in this thread: http://board.acmlm.org/thread.php?id=4310&page=1 I started to work again on the editor, I'm still at basic stages of rewriting, but this is because many important structure design decisions had to be taken. Things about the basic structure of the format are mostly finalized now. I decided that I'll add some jump points in the level scripts to be able to add objects after the script instead of inserting them. The new version can now load and decode all level scripts in a fraction of a second. I will release version 1.5 of the ROM extender soon. It will repoint the uncompressed level script segments too, and add more space between segments. The text editor will still work on both extended formats, but be aware that your other patches may not work with the new format. I'll try to never do that again Version 1.5 will be the "final" version of the extended ROM format. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt I know that if the original data is edited it won't change size when uncompressed. There are only a few texture-only MIO0, the rest is a combination of both inside the same file. There's plenty of empty space at the end of the ROM anyway. Even for texture-only MIO0's I'd like to leave some space... what if an advanced hacker wants to add a texture? -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt evilryu: The answer is NO. Please stop asking for it, not even beta testers have a copy of my level editor, as it's currently being rewritten and is non-functionnal. If I could share it I would, I'm not keeping it for myself for the sake of it. It would be pointless to release the original project, it would create confusion, especially if it gets on p2p networks. -------------------------------------------------------------------------------- Here are some clarifications for everyone that just joined, and others too: I reverse-engineered most of the level and polygon format with the help of some people here. I built a program that helped me in this task, and that program evolved into a level editor as I discovered new things. You can find screenshots of this unfinished editor in the thread. I never released it, since it was buggy/unfinished and much too slow at decoding levels and textures. Because this program evolved at the same time of my knowledge of the format, many parts of the code were patched to accommodate new findings, and the overall structure of it is not very modular. Since I got to the point where I knew enough about the format, I decided to rewrite it from scratch, but doing a lot more planning that I couldn't have done on the original version, since I didn't find much about the format at first. -------------------------------------------------------------------------------- Some updates about what the heck is happening with that elusive Super Mario 64 level editor: I'm currently rewriting the basic code that will read and parse level script commands into a standard internal format in arrays variable. This part is essentially finished, and the program can load and decode level script from all segments that contains them in a fraction of a second. This array list contains sub lists for each segment, and each segment list contains all level script commands as read sequentially from start to finish. Each level script command item is itself a "property list" that contains parsed parameter values from each command I made a routine that outputs this list as some human readable text, you can take a look at all level scripts segments parsed and decoded in the zipped text file I attached. Note that these don't take account of the jump commands and all, it just list the commands sequentially as they are found in the ROM. I'll keep this sequential list as a basis for the editor. A routine (that I'm working on now) will read the content of the array list, then produce a new list that takes jumps into account. This new list will contain reference pointers to the sequential level script list and will be ordered just like the game decodes it. That way I can work on the original sequence of commands (to insert commands for example) while having another ordered list representing how the level is decoded by the game. From this point, it's "just" a matter of building a user interface to edit the content of these lists. I also have to rewrite the polygon decoding routine, and work on a new system for selecting 3D objects. I'm doing a lot of planning these days, and that's why it doesn't seem to evolve rapidly (that and some "I do have a life" reasons). But once I'll have made all the basic design decisions, re-building the new interface should be relatively quick. Attachments M64LevelScriptsSequential.zip (36935b) - views: 86 -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Originally posted by Marioman64 -------------------------------------------------------------------------------- Textures... if an advanced hacker wants to add a texture he/she can, but what about people that can't hack that good? Are you(VL-T) going to put an "Add Texture" thing in your editor? It would help the clueless. -------------------------------------------------------------------------------- Yes, eventually, though maybe not in version 1.0b. I'm aiming at making my editor usable even by the clueless, though it will feature an expert mode. Originally posted by BGNG -------------------------------------------------------------------------------- I can inform you with my experience on the F-Zero X editor that making a GUI is a snap once you have the underlying program setup complete and everything works with itself internally. While you will have to create a system where various user controls can interact with each other, the task itself is relatively simple and takes very little time. -------------------------------------------------------------------------------- Yeah most of it will be a snap but still, with Super Mario 64, there is a little more to it. For example I have to build a sub-menu system to be used with some parameters (3d sprite type, behavior type and behavior params). These have to take into account what are the possible values depending on which segment is loaded in this particular level, and provide only usable values. I have to build a structure to accommodate the "description label" of each of these possible values and tools to edit/add labels. As I've said before, the first release will miss some labels, and I'll ask beta testers to add them through a built-in interface and sending me back a little .txt file. There are many safeguards I have to implement since most of these values are not just X, Y and Z, and some commands depend on the occurrence of a previous command (like warps). The interface for warps requires me to find all behaviors that use warp objects, and maps it's parameters to a list defined by previous commands. And these are just examples. Each of these issues are not that hard to deal with, but there is a lot of them, and I'm trying to build a uniform, modular interface structure to encompass all of it. Anyway, overall, it won't be that hard to pull off a very fun and usable SM 64 level editor before the summer... So today, out of nowhere, I'm announcing the official release date for Toad's Tool 64 v1.0 beta : June 21st 2006. Mark your calendars. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Raccoon Sam: What I wrote is that the June 21st release will be beta. The testing phase will probably begin about 2 weeks before. -------------------------------------------------------------------------------- As for the name, Teresa Obake is cool, but it's too obscure. I want a name that convey the use of the program. For Toad's Tool 64, I can imagine a splash screen where Toad is seen operating a crane to move an box in Bob-omb's Battlefield. Actually it would be fun to actually integrate a virtual crane in the editor I also thought about Carpenter 64 or Mario 64 Carpenter Tool, but later found that in english the word is more restrictive than I thought (and then went on a crazy theory about Mario really being a "Charpentier".) -------------------------------------------------------------------------------- I don't know yet how water regions are defined, they are probably among the special objects found after the solidity data, or maybe in the solidity data itself (there are many types of solidity polygons, some of which I didn't really figured out yet). I'm not sure if you can only put one water region in an area, but that may well be that way. I think that somewhere, a "sea level" is defined so these kind of pools would be impossible. I can imagine that it would be very cpu intensive to calculate if Mario is inside or outside a complex 3d region like that, usually this kind of detection is made using boxes, not complex polygons. -------------------------------------------------------------------------------- A SMB 1 level in Mario 64, is that what you meant? I did that a while ago... The "?" boxes and bricks are all "!" boxes with new textures. These boxes have a tendency to explode when hit from the side, and also, they are too big. The level was built using a custom program that takes the actual level data from SMB1 and creates a list of 3d sprite commands, that I then inserted back in that level. It's very hard to play, you have to be very careful not to fall down. Also, at the place I put this level, the Lakitu Cam had limited movement. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Chainlink1061: Yes. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Marioman64, you got tough questions I'm really sorry, I don't have the answer for any of your questions, though some may be answered eventually. -------------------------------------------------------------------------------- Update progress... The rewritten editor now loads level scripts in order taking jump command into account. It also builds a list with all commands, classified by command number. That list of list is used by the interface described below. Here is a preliminary prototype interface. Clicking on the top "menu" selects the level (and area). Then you can select which type of command you want to be listed in the orange menu. Selecting a command will list all occurrences of a particular command in that particular area, or commands that are shared by all areas inside a level. Each line in the list contains an item number, and all parameters found, converted to the appropriate format. The "inlevel" means that this particular command is found in the level script itself. Other values can be "shared" or "xternal". The former means that this command is found outside the level script, inside a chunk of commands that are shared by two or more levels. While "xternal" means much the same thing, but this time it means this chunk is only used by this level. Most of these shared and external scripts are found inside the script segment at 2ABCA0 in the ROM. This segment and two others (2A6120 and 269EA0) are not level scripts, their commands are shared amongst all or some levels. 2ABCA0, at its start, contains commands that are first executed each time you load a level. So the shared scripts are referred using the 0x06 command (jump to address) from inside each level scripts. The 0x07 commands inside the shared script then jumps back into the level script. There are 19 of these sub-segments that are referred by the level scripts. The scripts usually contain 0x22, 0x26 and 0x24 commands. 0x24 commands (3D sprites) are never shared but sometimes external. I wanted to make the 0x22 commands editable, but editing shared commands could lead to unexpected results. The 0x22 command determines which number is associated with a particular polygon sprite. This number can be used by all 0x24 commands to refer to this polygon sprite. If you change one that is shared by 10 levels, you'll have to keep track of all the possible changes. Maybe I'll only make the "inlevel" or "xternal" commands editable. But there is a solution around this problem. Since we have much more space in the ROM, maybe the level scripts could be recompiled to remove the need for jump commands, by duplicating and inserting the corresponding external or shared data where those jump commands are. The process would add something like 100k of data and would enable more control over which objects are useable in which level. For now, I'm building a program that's able to edit every type of commands. But editing the 1B command would be pointless since it's always 1B 04 00 00. I'll make a beginner mode where only the main and simplest commands are displayed in the blue menu. Then an expert mode will show more commands, including those that can easily crash the game if you don't know how it works. Maybe an intermediary level could be a good idea too. At the bottom of the screenshot, you see a non functional editor interface for the selected command. This is what I'm currently working on, a routine that automatically generates this kind of parameter editing bar, for any kind of command. It will create a second or third row if it needs too. A pop up menu will be available for most of these commands, containing valid values, and each item in the menu will have an optional text description. So for example, the "destlevel" popup menu would contain a list of all usable level ID numbers, with their names. In the released version the text description for the current parameter value will be displayed on the right of the value on the editing bar. The descriptions will be editable, or you'll be able to add new ones if they are missing. It looks simple from that point, but like I tried to explain, there are many subtleties that don't make the rest as straightforward as you might think. Hopefully, I have a lot of it already planned out. After/while working on the editing bar generator code, I'm planning to build a list of pointers for all possible polygon sprites found in the game, and each of their mesh parts pointers. The descriptions labels will be attached to items in this mega list. The 0x22 and 0x24 commands will have to refer to this mega polygon pointer list to find the text label associated with this geometry layout pointer or type byte. There is no 3d in this new editor yet... But as soon as I build this comprehensive database of geometry layout and polygon pointers, I'll start rewriting the polygon loading command. I'll build some basic model viewer that enables you to browse through all objects found in the game, optionally selecting only sub-parts. Then, when I get a "good enough" model viewer, I'll start to write and build a vertex editing interface. At each vertex, a sphere will appear, you'll be able to select multiple vertices and move them around, rotate or scale them. I will try to build this part in a modular way so that the same routines will be used to deal with multiple 3D sprite selections in levels. The editing bar will also deal with multiple selection, so that values that are the same across all selected objects are displayed. This will for example enable you to assign sprite types or coordinates to multiple objects at the same time. If a param value is different in at least one object, the value will be displayed as "--", but if you change the -- to some other value, this value will apply to all selected objects. I designed some very cool camera controls in the other unfinished version, and I intend to re-implement them in the new version. It's an optional mode where the camera follows the selected object at a 45 deg top down view, you can rotate the camera around the selected object, zoom in and out. The camera moves with the object if you displace it. I guess with multiple objects I'll have to find use center point (I don't know how to do that... by averaging 3d vectors?). OMG! I just realized the length of this post! Ouch, maybe I'll beat a new record Poor you that had to read all of it -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt The Joypad option could be interesting, there's probably a plug-in to use those with Director... I'll have to check that. I thought about placing/moving objects with the mouse before, and from what I concluded it would be too confusing... And setting the Z value according to the terrain would probably lead to many bugs/problems. I may add a "drop to ground" button so that you can easily put something on the ground, but I wouldn't base a mouse interface on this... By the way, my Castle 64 online demo is currently being dugg at a furious rate... http://digg.com/gaming/Online_3D_Viewer_for_Mario_64_Peach_s_Castle You should see the visitors log updating... I currently get multiple hits per second! I had to put it at the place of Metroid Cubed (which is on my isp 5 megs host) because it was being served with my Cable modem with a 150K/s maximum upload rate. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 05-01-06 12:49 AM) proffessor_gad: actually, I may implement your proposed feature after all, but as an option, not as the main way to put objects in levels. This feature is useful, but imposes limitations on where you can put or move objects. I wasn't sure of what you meant at first. What you want is to be able to click on the 3D viewport, and place/move an object at the point on the polygon surface under the cursor? That would also mean that you could stick things to walls just by clicking there, which is not a bad side effect at all. Maybe I underestimate you, but I'm not sure you realize all the implications of calculating this point. It's not simply about calculating the intersection between a vector and triangles. Did you take into account perspective? Objects that are farther away are smaller so their relation to a mouse click is on a different scale. The rays coming out of the camera are not parallel. So you have to calculate the angle in relation to the camera field of view angle. You also have to take into account the size of the 3d viewport. Far from impossible, but not straightforward. Anyway thanks for proposing the code example, but I don't think I'll need it, as Shockwave 3d commands takes care of this whole process with only a few commands. Here is an excerpt from a Director/Shockwave website: the command aCamera.spriteSpaceToWorldSpace(a2DPoint) will return a vector point. This point is directly under the sprite position defined by a2DPoint, and on the plane inside the 3D world where one 3D world unit is the same size as 1 pixel. This is a fairly abstract definition, and you will rarely use the result directly. Combining the distant point with the position of the camera will, however, give you important information: tCameraLoc = myCamera.worldPosition tDistantLoc = myCamera.spriteSpaceToWorldSpace(tSpriteLoc) tRay = tDistantLoc - tCameraLoc tRay.normalize() So I'll use some similar code in my editor. tRay will contain a normalized direction vector pointing in the direction of the 3d point where the object should be placed. It could then be multiplied by a high number, lets say 10000, to create a line that will intersect with polygons To find the actual coordinate, I'll have to use the modelsUnderRay command, which can return a list of all the 3d models in a scene that intersect a given ray, and how what proportion of that ray is outside the model(s). Multiplying that number with the length of tRay (10000) and adding the camera position will return the coordinate we're looking for, which is the point where the line going forward under the cursor meets with the closest visible polygon in that line of sight. But anyhow that will be a neat option, if it works well. But to place objects that float in the air, and have complete control of their positions some more traditional X,Y,Z controls would be needed. And for multiple selection and polygon vertex editing anyway, it would be required. For now though, I still have some work to do on rewriting the basic structure of the editor, I'm not into rewriting the 3d part yet. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Originally posted by Raccoon Sam -------------------------------------------------------------------------------- Heh, interesting but yet amusing.. Are you going to release a "You can do stuff but can't see anything in 3D" -version first? I mean, you wouldn't have to code the 3D-part. -------------------------------------------------------------------------------- It's possible that I'll release a non-3d version before June, but rest assured, I got the 3d working on the older version, it's only a matter of rewriting a better version. proffessor_gad: Rays are pretty much synonymous with vectors in that context. BGNG: Very interesting interface elements... May I steal the basic concept? I already thought of a click-and-drag approach for the angle interface widget, though it was with a round control, and the angle formed from a line rotating around the center. Holding shift would give you 15 degrees steps. Anyway, maybe a picture would help I would use the widget for the coordinates, but use it differently. I would put a cross in the middle of the middle of the square, and make it look like some graph paper or radar, with the X and Y axis labeled as such. Clicking on the center wouldn't move the object, but as you drag away from the center it would start to move, and faster as you drag away from the center. The Z axis (vertical widget) would work much the same way, but with an horizontal line in the middle to show the zero point. I'll also put options to swap axis so the square could control the X/Z coordinates while the vertical slider would be used for the X, and maybe options to invert coordinates. I got my "parameter bar "system working, though what you can see now is the "raw" version. My design include ways to insert control widgets of any type to the right of each value. Angles could have specific rotary controls, other values up/down arrows etc. Each element on the bar is resized to take the control buttons into acount. The 3d controls though would be outside of the bar interface. Also, each value could display a description label that describes the current value. A pop-up menu control will enable you to use some pre-defined values, with their labels. Also I'm working on including extra parameters that would control multiple values at the same time. I'll call these "presets". That will be very useful to pair sprite types and behaviors, or behaviors and their 2 parameters. It could be also useful to pair banks and offsets values, which are linked together. Here is a property list I made to define how most types of values are displayed and edited in the interface: actvalue,Act,8,binstars,0,1 objtype,Sprite Type,3,popmenu,40,0 xPos,X Pos,5,coord,0,1 yPos,Y Pos,5,coord,0,1 zPos,Z Pos,5,coord,0,1 xRot,X Rot,3,angle,0,1 yRot,Y Rot,3,angle,0,1 zRot,Z Rot,3,angle,0,1 behav,Behav,6,popmenu,40,0 param1,Param 1,3,none,0,1 param2,Param 2,3,none,0,1 objid,Type ID,3,none,0,1 banknum,Bank ID,2,popmenu,20,0 geolayout,Object Layout Pointer,6,popmenu,20,0 bankstart,Bank Offset,8,none,0,0 bankend,Bank Offset End,8,none,0,0 warpid,Warp ID,3,popmenu,0,0 destlevel,Destination Level,2,popmenu,25,0 destarea,Destination Area,1,areanum,0,0 destwarp,Destination Warp ID,popmenu,0,0 musictrack,Music Track,3,popmenu,25,0 solidoffset,Solidity Data Offset,6,none,0,0 macroobject,Macro Sprites Offset,6,none,0,0 LevelID,Level ID,3,popmenu,25,0 jumpoffset,Level Script Offset,6,popmenu,25,0 The first item is the symbol used to label this parameter internally. The second is the human readable description that will replace labels you see on the screenshot. The third item, is the number of char in the displayed value. It will be used to determine the width of the value fields (currently it's based on the length of the content, so it's narrower with 0 than 100). The fourth item is the name of the control widget to be shown at the right of the value field. The fifth item determines if there is a value description label. If not, it equals 0, if yes it equals the number of characters shown by the label. The last item is a boolean to say if the text field for this value is editable or not. Many won't be editable by default, but I'll include a way to make any value directly editable if you feel adventurous and/or do things like creating and loading new MIO0 banks. But these field will be locked by default for a reason: menus and presets will be able to provide all the valid values, that don't crash the game. You may try to hunt for beta stuff I didn't found, but you'll most likely crash the game for any value you manually enter unless you really know what you are doing. Behavior parameters (param1 and param2) though will be editable because their meaning depend on which behavior is used. Param 1 and Param 2 editing will be not that easy to implement because of that. Also, sometimes the two params are used as a 16-bit number, I'll have to make the interface switch accordingly depending on with behavior is used. I'll also add a way to have custom labels like "star number" appear instead of param1, for the star behavior. Some of these labels and description may be missing when the editor is released, Behaviors in particular, don't always have obvious uses, but it should be found quickly with many people editing the game. Users will be able to contribute in adding more descriptions and labels, and sending them to me via a small text file so I can include them in the editor. (Edit: edit frenzy!!) -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 05-05-06 02:32 AM) (edited by VL-Tone on 05-05-06 02:35 AM) (edited by VL-Tone on 05-05-06 02:37 AM) (edited by VL-Tone on 05-05-06 02:40 AM) (edited by VL-Tone on 05-05-06 02:51 AM) Originally posted by BGNG -------------------------------------------------------------------------------- I recommend having the dragging motion itself move the coordinates. And if you're not dragging, there's no movement... and so forth. -------------------------------------------------------------------------------- Well I guess I'll put a simple option to switch between absolute and relative controls, because I like the "relative" control better. Both have their inconvenients. The fly-by demo is far from ideal as there is no obvious center and neutral-zones where it doesn't rotate. The click-and drag control would have the center, axis and neutral-zones well defined graphically, and I don't think the camera control in the fly-by demo really equates moving objects over X, Y and Z planes. There will be a speed slider that for both control methods, much like the drag speed value you have in your editor. HyperMackerel, I considered the idea but it wouldn't be obvious in which direction the object would move on the screen relative to the mouse dragging, and moving it relative to the camera would cause the object to move at unwanted angles. But I think I'll implement a Top Bottom Left Right Front Back camera setup, and that could enable easy drag and drop of objects using some Shockwave 3d commands I described in another post, without the camera angles problems. It would work like most 3D design programs, which is certainly not a bad thing. The top view would be the most useful, to move objects horizontally, parallel to the ground. I guess that a feature to keep the object on the ground or wall could be very useful too, with a TBLRFB camera. About the interface size... my current working project has a width of 1024 pixels... which I guess is too much? I won't go lower than supporting 800x600 that's for sure. As for using Pointer instead of ptr, its not a problem since this parameter is part of a short command that only has three params. The 0x24 commands are the longest, and it'll be worse with Sprite and behavior labels. I taken that into account when making the parameter bar generator code. It works like word wrapping , there are 3 bars in my prototype, each one representing a "line". If there are too many parameter items on the first line, they'll wrap on the second line etc. That may look a little awkward when parameters don't use all the space on a line, but the advantages will be a very flexible interface. For example, I could add a little button to show and hide description labels for specific parameters and the bar would resize accordingly. Also, for example, the "expert" mode would show you more parameters, or a raw hex mode could be implemented in a snap without having to worry about creating a new interface layout. It's not that creating interface layouts is so hard, but this kind of modularity makes it easier to experiment and make changes. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 05-06-06 03:24 AM) BGNG, there are two main reasons why I won't use external windows for version 1.0b. First I don't have much experience in dealing with external windows in Director. Actually, external windows are other Director movies (projects) that can be controlled by the main movie. Director can only edit one project at a time so it can be a pain to switch back and forth between projects. Anyway the second reason is that I like the idea of using a single window interface. External windows are not bad by themselves, but they don't necessarily save screen space. I find that I usually spend to much time just trying to find a layout where they don't overlap while having no wasted space. I won't cram everything in the window at the same time, some less often used interface elements will slide into view when needed. The only thing is that that single window won't be resizable, at least not in version 1.0b -------------------------------------------------------------------------------- Cellar Dweller, I didn't notice that about the 0x13 command yet, I'll look into it since I'm about to rewrite the "geometry layout" data reader that contains those 0x13 commands. Director has a few commands that could help me do the "drag objects around from the 3d viewpoint" part. I described how I could do it a few posts earlier, and the math behind it is probably not so far from how Super Mario Galaxy uses the star cursor to point at things. -------------------------------------------------------------------------------- BooUrns: Thank you for the kind comment Yes there will be a page about it, but remember it will be released as a beta, not as a mainstream app. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Originally posted by proffessor_gad -------------------------------------------------------------------------------- One thing I did note while playing the game- Terrain data almost never overlaps. That is probably why they had so many objects... Cool cool mountain, and teresa obake are exeptions. I think that teresa obake was probably seperated into several parts, just like tall tall mountain's slide and wet-dry world. Was the floating isle in bobomb battlefield an object, or part of the terrain? -------------------------------------------------------------------------------- I'm not sure what you mean by the terrain data not overlapping. The floating isle in Bob-omb's battlefield is part of the main terrain data, it cannot be moved. I suspect that this level is the original test level. The original goal was to race with MIPS and get to the top of the mountain. (Miyamoto described this in an interview) The floating islands found in Whomp's Fortress, and the tower itself are objects that can be moved, and like I said before, the Bowser courses are almost completely built out of moveable objects. The Castle main tower is a special object that can also be moved, the "fall into the castle" glitch happens where the castle terrain meets with the moveable tower. I'm gonna have more time to work on the editor today and tommorow, I think I'll be able to meet the deadline even if there's many little things to do. At most, it will be delayed to June 23rd, which I found is actually the 10th anniversary of the Japanese release -------------------------------------------------------------------------------- Rusty Hackleford: Sorry my post was a little short, I was tired that night. It will be possible to put warps to anywhere in the game. Using Bowser in other levels is something that may be possible in a subsequent version. -------------------------------------------------------------------------------- Spikehead777: I forgot to reply to you... sorry I was tired When you say the "mushroom level, 4-2 from Super Mario Bros" I guess you mean the 6-7-8 warp? Or maybe level 4-3 is what you meant, with the yellow and red mushroom platforms? That may be possible, in Tall Tall mountain. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Originally posted by proffessor_gad -------------------------------------------------------------------------------- Well the floating isle in bobomb battlefield is a good example of where terrain data overlaps. There is land underneath the isle that was mapped out digitally. I find this interesting because I myself have not yet been able to achieve this in my games. -------------------------------------------------------------------------------- This is the collision data for Level 1, note that the isle is part of it, it's not a height map, it's 3d polygons. I'm not sure what you are trying to do in your games, but I'll assume that it's collision detection on the ground. I think you haven't taken the right approach to deal with that. Do you use a height-map? If you are, then you shouldn't, if you want to have overlapping areas. From what you described, you calculate the height using the triangle data directly? Whatever you do, you have to check only for the triangle that's under the character you want to place on the ground. You'll have to Z-order triangles and intersecting triangles would break things. You'd be better off using commands included in your development environment 3d engine. Originally posted by Spikehead777 -------------------------------------------------------------------------------- I wonder though, will there be a way to import terrains into the program, or will that have to wait until a later release? -------------------------------------------------------------------------------- Much later release, it's not that simple. Originally posted by BGNG -------------------------------------------------------------------------------- I've noticed that Director bloats things to orders of magnitude of the nth degree, but I still expect the finished file to be less than 10MB. -------------------------------------------------------------------------------- While both the ROM extender and the text editor appear to be bloaty, it's not as bad as you think. The problem is that a Director application contains the run-time engine (player) which takes like 5 megs. The current rewrite project .dir file, is currently at 2.1 megs, but the Shockwave compressed version that would be added to the player is actually 356k... So an .exe version would weight about 5.36 megs. There is still stuff to be added, but unless I add huge bitmaps, the whole thing shouldn't get over 6 or 7 megs. I use vector stuff and small bitmaps for the interface so it won't be a problem. Originally posted by Rusty Hackleford -------------------------------------------------------------------------------- don't sweat trying to make the editor perfect before the release you can always make an update or let someone else improve on it, vl-tone I am curious about how courses vary depending on what star you select when entering the level they wouldn't be stored as seperate levels or they wouldn't have made say for example star 4 able to obtain when entering in star 1 on some levels so how do you edit that? could I put the sub in Jolly Roger Bay or in front of the castle assuming theres enough space...? -------------------------------------------------------------------------------- There are three main types of objects that can be placed in levels. The main type, the x24 objects contains a binary parameter value. The last 6 bits of this value represents each one of the 6 possible star entry. If a bit is set to 1, then this object will appear when this star entry is used. It's called in the editor, the "Act" parameter. It will be editable by clicking 6 little stars icons. You could, for example, make a coin appear in act 1 and 3, or in all of them. The act parameter is not used by the two other types of objects. Fortunately, the x24 command can use objects of all kinds, with more parameters than when using the two other formats. Originally posted by Magic_Vampire_Joe -------------------------------------------------------------------------------- So VL Tone, have you decided whether or not you are going to intergrate the SM64 Text Editor and/or your Expanding thing into the Level editor? It would be good to intergrate them, cos then there wouldn't be the problem of fumbling around with a load of open windows and it would be simplistic! Really eager to download! -------------------------------------------------------------------------------- They'll be integrated, as it wouldn't be a good idea to duplicate the 5 megs player for each utility. Originally posted by jensthecomposer -------------------------------------------------------------------------------- Hi, I got a question. I want to edit the textures on SM64 and got myself ''n64gfx''. It asks me to put in an image adress in the room in hex code. Somebody knows some codes I can put in?? Or maybe you would recommend another application to edit the graphics?? -------------------------------------------------------------------------------- A complete list of the location of all textures in the extended ROM still doesn't exists, I had built one in the "old" version, but I'm about to reach the point where I can output one for the new extended ROM. As for an editor, the only one I know is TileMolester (but I haven't look for others). This way you could find the textures "visually". Start at address 800000 (hex). -------------------------------------------------------------------------------- Wow I don't think I ever replied to that many people in the same post. Here is some screenshots of the new interface bar. First is the one for x24 objects (3d sprites) which uses three rows: Here is the bar for the x26 commands (warps). This is for the x22 command, which associates an id number to the address of the geometry layout data (polygons). Note the 195 value is the one then used by the example x24 command. The ABCDE... are place-holders to what will be more descriptive names. The upward arrows with horizontal lines will bring up a pop-up menu with possible values and descriptions to be used by that particular parameter. I'll add special parameters using the same kind of menu, but that can set multiple parameters at the same time, from a list of presets. For example, there will be an added param that can set the sprite type and behavior values at the same time, giving you a choice of all combinations used in the game (and for which the data bank is loaded). The order in which the parameters appear will be changed before the release for some parameters. The binary representation of the act param is not really useful, the little stars are better, so it will be hidden. There will be ways to switch to a simpler interface, and hide stuff that only experts should edit anyway. So don't worry if you don't understand all of the current interface bars. There will be more other more intuitive ways of controlling the X Y and Z values, like described before. And don't worry experts, the simple interface won't cripple the expert mode. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 05-20-06 10:36 PM) Originally posted by HyperMackerel -------------------------------------------------------------------------------- That's awesome. I might end up using a similar system in something. Just a shame the creators of Director never heard of dynamic linking. -------------------------------------------------------------------------------- Director's "Xtra" plug-ins are Dynamically Linked Libraries written in C++ or assembly. Projects can also dynamically link to "external casts" which are external Director libraries that can contain media and Lingo script code. Director can also use Windows .DLLs via a built-in Xtra. I could create a player "stub" as they call it. It's the run-time engine as an .exe file, that contains a simple script that opens a Director project file and run it, replacing the stub movie. I guess that the advantage you're looking for is that updates would be much smaller if the runtime engine doesn't have to be re-downloaded each time... This is the way I could do it, thanks for giving me the idea The first download will be 6 megs, but subsequent updates are gonna be around 500-1000k. The only downside is that some people may download only the update and complain it doesn't run. But it will be very useful in the public beta testing period. -------------------------------------------------------------------------------- Edit: As for the parameter system, it's designed to be modular enough so that it could be used to edit other games with some relatively minor modifications. I could eventually use it as a basis to easily build a Zelda OOT editor, especially since it uses the same polygon format. But please, let me finish and improve the Mario 64 editor first, and forget about the Zelda OOT editor for now. *VL-Tone puts sunglasses, uses a MiB gadget and FLASH! You don't remember anything about it -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Some little update on my progress: I rewrote the geometry layout decoding routine. There are 478 3d sprite types found in the game. Cellar Dweller, thanks about the tip for the x13 command. I really don't know why I didn't see it before but the x13 command does include a x,y,z displacement factor. This is good news since it means that many 3d sprites will now display correctly. In other words, I now know how the characters body parts are positioned. I don't know about the rotation aspect though, it must be controlled by the animation routines. I'm gonna work on making the geometry layout commands editable, so you'll be able to move and switch body parts. I'm now at rewriting the GBI (Graphic Binary Interface) command loading routine so that polygons can be displayed. Once I get that right, the rest will be mainly a matter of finishing the interface and gluing all this together. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 05-23-06 03:44 PM) Originally posted by Magic_Vampire_Joe -------------------------------------------------------------------------------- What, switch body parts? meaning what exactly? stick a bob-bomb instead of koopa the quick's head? -------------------------------------------------------------------------------- Wow let's join the sarcasm and say it's a great picture The only problem in your example is that Bob-ombs have multiple body parts too, and you won't be able to replace one body part with multiple ones. I didn't mention it but this feature probably won't be part of the first release, but I had to take the feature into account while rewriting the core of the editor. Originally posted by Rusty Hackleford -------------------------------------------------------------------------------- question sorta related to the act stuff -would it be possible to make an object in another area apear/disapear when a certain star is obtained say for example could I make the/a sub apear in front of the castle when star one in dire-dire docks is obtained or a ship like the one in Jolly Roger Bay apear in stars 2-6 of Dire Dire Docks after star 6 in Jolly Roger Bay is obtained about the # of stars -can I just add stars like make a level have 7 or 8 -would this affect the front yard cannon -can I control how many stars open the front yard cannon levels\areas -can I make entirely new levels, as in courses not stars or do I just have to edit the existing ones other -i've decided to divide my posts into sections to make them easier to read -------------------------------------------------------------------------------- -I don't know the answer to that first question... about the # of stars -I know you can make a star object behave like the sixth star instead having to collect all coins. But I don't remember what happens when number 7 or 8 is assigned to a star. -The cannon is activated when you have 120 stars (or more) period, the stars can come from anywhere. -I don't know where to find this one, it's not in the cannon object params. Same goes for Yoshi, and MIPS which appear when you get a certain number of stars. levels\areas no. I guess I should include that in my signature, since people keep asking. I hope people will focus on what the editor can do, not what it can't. This may be possible in version 2.0 though. other It's always a good idea to separate ideas into paragraphs I remember that when I started posting on forums, I wrote monolithic blobs of text, and people complained. Since then I've been trying to make small paragraphs, even though I have a tendency to write long post (I broke some record on acmlm...). Originally posted by Cyclone777 -------------------------------------------------------------------------------- A question to VL, will the editor have an extensive help file on the beggining version, or will we have to wait for an update? Also, it's not long til the supposed release date of the editor. Other than your photo album, I haven't seen anything to do with the editor(on your website). Only a suggestion, but why not put a bit of info on your site about the editor and it's capabilities to keep our mouths watering? -------------------------------------------------------------------------------- I'll provide a help file that should be easy to understand, but remember this will be a beta. After the initial beta release I will concentrate on fixing bugs and adding value descriptions. I will not be able to provide support outside of bug fixing in the first weeks after the release, but I'll try to make the help file helpful even to less knowledgeable people. My website was not really updated since last Christmas for some reason. The main reason being that I lost my lycos free web account because I was leeching my the Shockwave files off their servers, embeding them in html pages stored into my 5 megs isp web account. I couldn't find another free host that would accept off-site loading of Shockwave files. Recently, some kind donator gave me access to a fast dedicated linux server with multiple gigs of space and unlimited bandwith. I just got actual access today. Anyone ever dealt with Webmin before? I'm trying to remotely configure and start Apache, and it doesn't look simple at all. (well I don't want to get off-topic here...) So when I manage to get this running, I'll put out a new website. Maybe not the complete redesign I planned, but a new look, with a page for the Super Mario 64 level editor. Originally posted by Rusty Hackleford -------------------------------------------------------------------------------- I hope ill be able to play my hacks on the wii -------------------------------------------------------------------------------- As much as I like the Wii, I hope this won't happen. I don't want to get Nintendo on my back for encouraging piracy on the Wii... Super Mario 64 will be sold on the Wii, and with DRM... If my editor is seen an incentive to hack the Wii to play pirated ROMs, that could be a bad thing. I don't think it'll be the case, I just want to distance my project from anything related to hacking the Wii and the DS, until 10 years from now when they become retro Originally posted by jensthecomposer -------------------------------------------------------------------------------- Will I be able to edit or add water polygons?? -------------------------------------------------------------------------------- You can find the answer earlier in this thread, and the short answer is no. Not in version 1.0b. I'll try to find this when the first version is complete. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 05-27-06 08:37 PM) (edited by VL-Tone on 05-27-06 09:32 PM) DavePhaneuf: I'm sure you could think of many other things to ask, and many others would have many other similar thing to ask, but this is the kind of question I cannot answer now. You have great ideas, but I haven't experimented enough with a working editor to know if these are possible. (maybe I could answer a few, but I don't have the time to start answering questions like that) Just to make sure everyone understands. Version 1.0b of the editor will let you: -Move, rotate the hundreds of 3d sprites found in levels. -Change which polygon object each 3d sprite uses. -Change which behavior each 3d sprites has. -Modify the behavior parameters. -Change the music played in each level. -Edit most of the text found in the game. -Swap textures. -Edit how warps exits and entry points connect. -Add or modify item descriptions. You, me and others will have to figure out the details, once the editor is out, like which objects and behaviors triggers what event. Findings will be incorporated in updates. The modular aspect of my design will make it easy to update. Other features like swapping body parts and editing polygon meshes, or changing which objects/banks are loaded in levels won't be in version 1.0b, but I'm planning those features in the current build. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt There is a command to scale sprites, to be used in the geometry layout data. It's command 0x1D. The Tiny-Huge Island geometry layout uses this command for example. Other levels don't include it but it could be eventually added. The only thing though is that the collision map is not scaled with it, so Tiny-Huge Island uses two different collision maps. Maybe one day I'll add a way to scale the whole level, including objects. The 0x1D command is also used in the geometry layout for 3d sprites like enemies, characters and boxes etc. Some objects don't include the 0x1D command so they can't be scaled unless some command is inserted. But that won't be in version 1.0b. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Ok too much things to reply to... sorry if I don't reply to everyone, thanks to the people that answered questions for me The sommer-sault in the video is a side sommer-sault, just run in a direction, suddenly go the opposite way and jump. Mario's colors are found at 0x823B64 in an extended ROM. They are in RGB(A) format with 1 byte per color. Half of those colors are for the light shading and the other half for dark shading. I wanted to put an editor for these colors, and those of other characters, but this is one of the feature I decided to cut back from 1.0b due to the lack of time. Here is the current state of the editor... with only 8 days to go. This is not the final interface... many things in the blue list won't be there in v1.0b, and many things will be simplified. There will be more options for the camera, and widgets to move objects around (the one based on BGNG's widgets). And overall, it will look better than this I struggled to rewrite the polygon commands (GBI) decoder, but it works now, better than in the older version. I stumbled across a problem... Decoding all 1100+ polygon objects in the game when you open the ROM takes a long time... around 30 seconds on my machine. I don't have much time left to optimize it. The work around is that the editor will read/decode the polygon commands only the first time that the editor opens a ROM. After decoding it will save a 6 megs file containing the decoded data, and will load this file instead of re-decoding each time you open a ROM. Subsequent openings of ROMs will only take a few seconds (4-8 seconds). And that even if you quit and restart the program. The polygon data won't be editable in 1.0b anyway so that shouldn't be much a problem to use external polygon data that doesn't change. At worse, if you want to regenerate a new polygon data file, just delete it and it will be re-decoded from the next ROM you open. My efforts are now in getting this thing out of the door by June 21st and pre-released a few days before. So here's a (now reduced) feature list of ToadsTool 64 v1.0b *Moving, Rotating objects found in all 30 levels. (the x24 objects, the one pointed by the 0x39 command, and the ones after the solidity data) *Change the object type (change a goomba into a coin for example) using a list of those available in this level. *Change the object behaviors using a list of those available. *Change which music track play in a given level. (You cannot edit the music) *Edit the warp connection commands.(0x26) *Various camera options like "follow the selection". *Top Bottom Left Right Front Back camera controls. *Wireframe mode *Selection boxes around objects will have the width,height and depth of the polygon object (with a minimum size) Unfortunately the text editor may or may not be completely integrated in time for the June 21st release... Same for the ROM Extender. But I'll try to at least reduce the redundancy by having only one runtime engine for the three tools. Here's features that were supposed to make it into 1.0b and that won't... Most of them are close to be implemented though. Many of them were to be found in the "Expert mode" which won't make it in v1.0b. The first version will be somewhat equivalent to the planned beginner mode, but with some hex data. So the following features are not in 1.0b but will likely be found in version 1.1 which shouldn't be that far away after 1.0b. *Changing which banks (segments) are loaded in each level *Editing which objects from those banks are used and what are their ID number *Exporting/Importing textures *Browsing all 478+ 3d sprites individually *Edit colors found in a given 3d sprite *Chose which texture is used in a given 3d sprites *Edit the various positions of sub polygon objects in some 3d sprites *Handling of warp behaviors *Better handling of behaviors parameters, more complete list of descriptions *Other various level script commands made editable for the expert mode Something important to note so that you don't get your expectations too high, some objects won't display correctly in v1.0b the levels themselves and platforms will be okay, but characters with rotating joints or those that use 2d sprites will have problems. The selection boxes and menus will help you in that case. But please concentrate on what v1.0b will do, not what it won't do. And for now, I should do that too... These posts take me too much time for now, I won't post much until the pre-release around June 18th. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 06-13-06 11:31 PM) Thanks Hyper for reminding me about the size issue... I'll try to take that into account and reduce the window a little. I fixed the blurb about the music track in my post so that people don't think they can edit the music. The joystick option won't be in version 1.0b, and in the mean time the keyboard feature could be a good alternative (Just map the keys to your joystick). Prof_Gad Racoon Sam wrote: "And on a side note, when does the Beta testing era start ?" Maybe I should repeat yet again that THE SUPER MARIO 64 LEVEL EDITOR RELEASED JUNE 21ST WILL BE BETA. (Hmmm sorry for shouting... actually this is all my fault, I was supposed to release it a week before the 21st for beta testing matters) Then it should be obvious enough that the "Beta testing era" officially starts on this date (June 21st). I'll probably do a limited pre-release around the 18th or 19th, to check if it at least run on other machines. The June 21st version will be Beta as I always said since I announced this date. -------------------------------------------------------------------------------- Another thing, great GameShark codes you have there, but may I suggest you start a thread about it? Actually I'm not even sure you could in this particular board since it's not ROM hacking... If you can point to the equivalent ROM location of the bytes modified by the GS code, then this could be more on topic, but not to sound harsh but this is not the GameShark Creators Club board here... Anyhow, I'm not a mod and I hope not to make anyone feel bad about it...You can continue posting GS codes, but I won't pay attention to them unless you provide a ROM pointer. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 06-15-06 12:04 AM) Ok... I'll try to keep it simple: First, as of now, the pre-release will be the 21st, not the 18th... Second, what would be your reaction if there was a small delay of a few days (maximum 4)? I promise I will keep you updated every single day starting today until the actual release. -------------------------------------------------------------------------------- Update: It's hard to admit, but these are still missing in the rewrite as of today: -3d selection boxes -Specialized 3d controls to move objects and camera (keyboard and interface widgets) -Descriptions for items, most of them are now shown as "Unknown". -Save feature for item description list. (You can save them in memory, but not as a file yet) -Speed. Most of this is not hard to implement. The 3d control stuff is much more simple than you would think, it's about moving x,y and z coordinates. The decoding part and interface structure building was much more complicated. Descriptions will take some time to add, but it's the fun part... This first release will be a collaborative effort in a way because you'll be able to add missing descriptions and take the description list and send it back to me so I can merge it with the main list. Some objects are obvious to describe, but invisible objects with a behavior require more investigation. Speed will have to be improved especially for the first time you run the program. In any case, I'm sure many of you will still appreciate what you can do with Toadstool 64 v1.0b when it's released... soon. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 06-19-06 02:44 AM) Welcome tahu363 and others that joined this thread. I don't have time to adress your questions, but many of the things you are asking won't be answered until I actually use my editor instead of just building it. So please wait until the release before asking: "will the editor be able to do this or that?" Tahu363, thanks for trying to help with the thread you made, but I'll make a new thread when I release the editor, and that's where people will be able to ask questions. If there are too many "n00bs" then we'll try to find a solution by then. About the new release date... June 23rd will mark the 10th anniversary of the n64 release (and Mario 64) in japan. Though I think it would be a great date, I don't want to delay my editor twice, so I was thinking more about the 25th, since my days off from work are the 23rd and 24th. Since I talked about the 23rd date with BGNG before, he thought that I wanted to delay until then... So now there's some confusion about the date... I'll have a page for the editor when it's released. -------------------------------------------------------------------------------- Ok now here's the daily update (in my time-zone, it's still the day after I announced daily updates, so I kept my promise ) I implemented the selection boxes and started to implement other 3d controls. I stumbled across some little problem. The coins, aside from not being rendered correctly, produces too many polygons. Every frame of animation appear on top of each other, and all different coin size animations are included. With a lot of coins on the screen, the editor tends to slow down (maybe because it has to try to layer too many transparent polygons on the same plane?). As I said before, some objects won't display correctly, it was part of the original plan for v1.0b. I don't understand exactly how to deal with animated polygons, and decided it wasn't a priority. I'll have to find a solution for coins. Now I'm working on integrating the special objects found after the collision data. In the screenshot, blue boxes are for x24 objects and green for the x40 objects (from the x39 pointer). Well I have to eat too so I'm gonna take a snack and then continue. Maybe you'll see another update by the end of the night. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Here comes my daily update... I didn't post an update yesterday since the board was down at the time, and I decided to go to bed, and today I was working. I have my next two days off and this is when I'll finish the release version, I won't sleep if it takes that Here's a screenshot of Rainbow Ride, with all three main types of objects. I changed the colors for the selection boxes. Red is for x24 objects, blue for x40 macro objects and green for the x43 "special objects". I'm currently rewriting 3d controls to move objects and the camera. Aside from that, descriptions for items is the main thing missing. As for IPS patches, they should be small, because you have to make them using an extended ROM as a basis, and people that want to apply the patches will have to extend the ROM before applying the patch. Only the differences between an extended ROM and a modified one will be contained in the IPS. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt I was joking about not sleeping Note that my real job is from 4 to 10pm and I don't work until Sunday afternoon. I'm used to go to bed very late and get up in the afternoon, so I'm working on the editor this night for example and get to bed later as usual. -------------------------------------------------------------------------------- I didn't know that about the ips format I thought ips had a limitation on patch size, not offset. Oh well anyway, I'd rather not have people use this first beta release to publish hacks. I'm sure many will try anyway... but what can I do... I'll still release it in time, so people will have a good idea of better things to come. I don't care much if this release doesn't become mainstream, it wasn't intended to. Maybe I shouldn't call it version 1.0b so that people don't expect it to be a finished editor. By the way I won't announce precise release dates anymore unless the release is ready, as I don't want to go trough the same thing again. After the 25th I'll release updates to address issues and add functionality. I'll fix the main bugs quickly, don't worry about that. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- hmm.. I said that I won't give precise release dates anymore... Anyway... Here's my daily update before I go to bed...I have to finish this before I get to bed tomorrow. Still a "little" work to do, but I'm confident that I'll "finish" it by tomorrow. And by finishing I mean to be ready for the public release sunday. In this image, perspective is turned off, you can toggle it using the two little buttons with cubes on them. Another thing to note is that all three object types selection boxes are shown, when actually using the editor, only the boxes for the command type you currently edit is visible. I put two 3d controls widgets inspired by a BGNG idea. These have yet to be labeled but the one on the left moves/rotate objects while the one on the right moves/rotates the camera. I successfully implemented the mechanism to click directly on 3d objects to select them, and you can actually drag them around the 3d viewport. It only works when the camera is at the top Front/Back/Top/Bottom/Left/Right. Here's the official logo: Yeah lots of colors and all, but this is Super Mario 64 we're talking about! It uses the font found in the game. I'll try though to get rid of the green/blue/red color scheme for the parameter bar, which was just a placeholder scheme until I assign colors to specific commands and parameters. Ok that's it for now, see ya! -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 06-24-06 06:35 AM) So... I was sick all night (Murphy's Law?) and had to work at my job earlier than I was supposed to. Anyway, I don't know how I could conclude that I could have released it by today...Maybe I was blinded by the pressure to meet the deadline. The truth is that I simply cannot release the editor in its current state. In other words: Not Today (again) So I guess your question is "When?" I said I won't announce any other precise release dates until it's ready to be released. Don't worry, it won't be canceled or pushed by a month. It is really close to be finished, much more than the original version was. I mainly have to fix bugs, add some very little features, add descriptions and the mechanism to save and load them. I also have to design a way to bundle the Text editor and ROM editor without duplicating the run-time engine. Documentation have to be written, and the web page has (yet) to be created. Let's say about a week should be the maximum, but I don't guarantee it (I'm pretty sure it will be under a week, but I don't want you guys to get all hyped again) It was going to be a rushed release, now it won't be. I'll try to debug it as much as I can so you won't act as guinea pigs. I'll try to make a web page for the editor tonight or tomorrow (or whatever day, don't count on it until you see it). I may also release a little movie soon of the editor in action, so you have something more tangible than screenshots to chew on. To summarize, there will be a delay of about a week, but it shouldn't be more than two. Ideally it should be out by next saturday, but don't base your life on this, it could be later too. In the mean time you could either, discuss what you want to do with the editor, or how about going outside, take a walk in a park and relax? -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Originally posted by HyperMackerel -------------------------------------------------------------------------------- Originally posted by VL-Tone -------------------------------------------------------------------------------- the mechanism to save and load [descriptions] -------------------------------------------------------------------------------- Screw that. Just put them in an INI file that people can edit. -------------------------------------------------------------------------------- Why an INI file? It'll be saved in an external .txt file. Yes you'll be able to edit the file manually. What did you expect? That I wanted to use some crazy proprietary format? The point is to have this easy to share file that people can send me so I can update the main release. Inside the file, on even lines, you'll find the description text, and on odd lines, values that uniquely identify the descriptions. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Ok I had written a long post about something else, then I realized that I didn't really read BGNG post correctly, or maybe my mind blocked it off because of the implications Maybe I'll repost the other post I had, but I have to address that first: In short, I recommend that the community does choose to undertake a Super Mario 64 editor to be open-source in a contributory manner. I volunteer myself to participate in such a project. All that VL-Tone would be needed to do is provide information on what bytes in ROM do what. I cannot be against that. But... The first public version of the editor is close to be finished. I feel that at this point I'd rather spend time on improving the editor than to spend time explaining it's inner workings. My editor is a tool that in itself will help others to build an open-source version, and will help me understand more about the formats in SM64 so I can provide better and more complete information to the community. It's a chicken-and-egg situation, and I don't think it should be broken now by having me describe in details many things that would be much more easy to understand with the editor released. You guys have to be a little more patient. There's already enough info in my doc and the threads to start. But do I formally accept this deal? I cannot say no, but I cannot say yes now, because this is still too vague. The fear I have is about the high pressure to release all the editor's info in details in a timely manner, and having to re-explain everything to countless people that don't understand it. I will be happy to see an open-source editor happening, but as the sole source for some of this particular info, I may get overwhelmed by the number of questions and requests. I'm not a kid having his summer days off from school. I have to make a living, working 7 hours a day, 5 days a week. Overall, I like this idea, but I'd like to see something about protecting the actual humans involved in those open source software licenses."Authors and contributors should not be harassed into releasing info" And, can we add "You shall not use this software to hurt humans."? Seriously -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 06-28-06 05:44 AM) Originally posted by Marioman64 -------------------------------------------------------------------------------- I think I'm going to miss the big release day. I'm going to Deleware from tomorrow until Sunday (night?). Ah well. BEFORE ASKING A QUESTION, READ THE ENTIRE THREAD. -------------------------------------------------------------------------------- And why didn't you read it yourself? I didn't say it would be released any particular day. I gave a rough estimate of one week, but I also said it could be a little longer and to not base your life around any date. I needed a break from all the pressure, but now I'm back at finishing the editor. I have my now usual 2 days off (friday and saturday) so I will probably bring it close enough to a release, but it's possible that some things like documentation won't be ready for sunday. -------------------------------------------------------------------------------- Welcome to everyone posting for the first time here, thanks for the kind comments. I don't have the time required to answer all of your questions now about what can be done or not with the editor. Please refer to the rest of the thread. -------------------------------------------------------------------------------- About the open-source thing. The only problem I had is that BGNG was proposing that I provide all the info needed to build an open-source editor just before I release my own editor. Providing all this info and explain all the details of it would take time I should use on finishing my editor. And I'll be in much better position to give information when the editor is finished and that I did have time to experiment with it. I didn't find it insulting as is, but it gave me the impression that many simply didn't care if my own editor never saw the light of the day. (Because it doesn't run on linux and is built using a bloated "proprietary" platform?). The reaction from many here shows that many do care about my editor. Like I told before, the release of my editor will help people build an open-source version. -------------------------------------------------------------------------------- About the logo: Well it's not a final logo. I wanted to include Toad in a splash screen, not in the title logo. What I envisioned on the splash-screen is Toad operating a big crane, lifting an object in some level from M64. I would like the splash screen to be 3d rendered, not pixel-art. As much as I like pixel-art, this is Mario 64 we're talking about... I would be happy if someone that is really good in 3d design could build a 3d crane with Toad sitting at its commands. It wouldn't have to include the level BG and object being lifted, I would do the layering myself. I wouldn't want amateurish designs, Toad must look like the real deal. So if someone thinks he has the talent to do it, just tell me here or via private message. I'm very picky about things like that, so I might reject any design I don't like. If you are not a 3d pro, don't even try, and if you do, don't feel bad if I don't use your design. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 06-30-06 12:26 AM) Dang I leave for 2 days and you add 4 pages to the thread! But it's only questions I've already answerered, or Game Genie Codes (which as I said before, I won't acknowledge) so I won't reply to these. mustardseed: Thank you very much for the picture, it's nice, but it's not what I'm looking for, it's not the kind of crane I had in mind. Hmm I shouldn't have asked people for it... I hate rejecting someone's idea Here's pretty much what I want, but with Toad sitting in the crane: I did this part myself and someone pm'd me, he has a nice 3d model of Toad from SMS (which is a much easier game to reverse engineer than SM64) We're working on integrating his model into the crane. -------------------------------------------------------------------------------- As for the editor itself, it's going forward, but not as much as I expected during my two days off. My mother was in town, so I had to see her (which I don't mind). I did fix a few bugs in the camera system, and now I'm working on the menu interface and description system. I'm hesitant to give any estimates on when I will release it, but it is "not so far from being ready". -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Well in SMS, everything is neatly organized into files with a filesystem. There are files for vertices locations, files for polygon (triangles) connection data. Others for textures, collision data etc. In Mario 64, there's no directory for things like that. To find where all the textures are for example, you have to decode all level scripts to get the pointers for geometry data. Then decode all the geometry data to find all polygon pointers and then decode the polygon data to find all unique textures. Same goes for vertices data and many other things. Also, in Mario 64, the triangle data is part of an ASM-like script that controls the graphic chip directly. The 0x4 command loads a limited number of vertices found somewhere else, then the 0xBF command draws triangles using those vertices. So it's impossible to build, for a particular model, a complete list of all vertices and their locations in the ROM without parsing the graphic commands first. In SMS, just load the corresponding vertices file, triangles file and texture file(s) and you're good to go. But I'm not into GameCube hacking, as I find the console to be to much recent for hacking, and there's no really functional GC emulator yet, so no real possibility of an editor. If you really want to know more about it, check out the threads on emutalk.net. -------------------------------------------------------------------------------- Ok you're lucky I'll answer another question for you since I wanted to reply to this one before and apparently didn't... To do this move in Mario 64: Run, press A to Jump, press B to dive, then while diving press B again (or A) making Mario spin so he doesn't land on his belly. I do this all the time to go faster. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 07-03-06 03:14 AM) Originally posted by Doritokiller -------------------------------------------------------------------------------- Just a quick question. How long do you work on TS 64 on average each day, VL? -------------------------------------------------------------------------------- It varies. I do have a real job as I said, and have to work there 6-7 hours a day, 5 evenings a week. When I do work at my job, I spend less time on TT64 (ToadsTool 64). It can be from about 3 hours to maybe 5 on those days. Friday and Saturday I may work on it even more, sometimes up to 8 hours. Unfortunately I was busy much of my last days off, so I didn't work on it as much. When I get back from work, I'm not always in the mood for programming. As much as I like working on the editor, sometimes I need to relax and do other things. So that's about it... I'm gonna publish something later that may help you wait, which is a list of offsets of all textures I found in the game, with their size and type. It will then be much easier for people to find and edit textures using TileMolester. It will only work for an extended SM64 ROM. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Oops! I went to bed earlier yesterday, forgetting to post the texture location list. Here it is, attached to this message. There are 849 textures in this list, and it doesn't include fonts and other menu graphics. Textures with type 0x10 should be decoded as 16-bit RGBA 5551 color. The ones with type 0x70 are also 16-bits but 8 bit grayscale with an 8 bit alpha mask. It's possible that some are missing, since like I explained, the whole level and polygon data must be decoded to find texture locations. Attachments SM64TextureList.txt (19613b) - views: 158 -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Ok first, please don't fight each other over anything! -------------------------------------------------------------------------------- Update about the editor progress: I decided to implement a way to copy/paste one or multiple parameters between objects. This wasn't planned for the first release, but it will make it really useful, especially since the first release won't allow you to insert new objects. I'm thinking about including the texture editor/swapper in the first release. I also implemented a revert button so you can revert to the saved command/object. I will make the Text Wrangler load the font from the ROM when the next version is released along with the editor. -------------------------------------------------------------------------------- I feel I may have exagerated the number of hours I work on the project. When I say 8 hours on my days off, it includes some breaks... I don't program 8 hours non-stop And before June, I didn't work on it much, and that's why I didn't meet the deadline. Since then I work on it almost every day, but I do sometimes take days off programming, which I don't tell you about, since I feel bad about not releasing the editor soon enough. I never said I didn't work on the editor fridays and on week-ends. Actually I work on it more since they are my days off for my "real" job, the one that pays the rent etc. Actually, I'm tired of discussing this aspect. Do I really have to explain my daily schedule in detail to justify the time it takes? -------------------------------------------------------------------------------- Ok... About newbies or "n00bs", whatever you called them. Don't you notice a pattern here? You could say it's their fault for not reading the whole thread, but explaining that to newbies doesn't fix the problem, they just keep on coming, and by definition, they are new, so they can't know what you said to other newbies. Actually, It's my freaking fault... I should have at least a web page in my sig explaining when the editor will be released (and the answer is "soon") and other frequently asked questions. Maybe a simple text only FAQ could do the trick. I can do it myself, but I wouldn't mind if someone was kind enough to prepare one for me... I'll proof read it and correct it if necessary. -------------------------------------------------------------------------------- About the splash-screen. I will keep that tower crane idea for sure, whatever what some people think. As for the title text, I'm open for suggestions. Personally I liked the idea of some bubble-wrap effect over the pixelized M64 font, but it seems it's too weird for some... I wanted to name the editor Toad's Tool 64 more than ToadsTool 64, but people seemed to like ToadsTool better. Maybe I'll call it Toad's Tool 64 anyway, nothing is set in stone for now. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt A picture is worth a thousand words doesn't it? I will include the "Basic Advanced Expert" modes after all, but there will be separate settings for the command list, and for the parameter bar. I use "Basic" instead of "Beginner" because the basic modes can be useful even for experts. In the Basic mode, the command list will show only the five commands seen on the screenshot. 0x24, 0x40, 0x43, 0x36 and 0x26. The Advanced mode will show more, and the Expert mode will show just about all the level script commands. The Basic mode for the Param bar will show only the Sprite Combo and XYZ pos and rotation. The Expert mode all the possible params for this command. The Advanced mode something in between. The color palette is to adjust the background color of the 3d view. I changed the color scheme for the parameter bar so it's now meaningful. The red parameters are "Combos". They are values that don't exist in the ROM. They are sets of other multiple other parameters. Note that the Sprite Combo param is not currently totally functional (hence the lack of value there) The blue and green parameters are both used for normal, in ROM parameters. The alternance of blue and green is there to separate groups. (I should make the Act param blue) Just about every platform in Rainbow Ride is moveable. The red boxes are only for the 0x24 commands, and the yellow box is for the selection. In case you didn't notice, there's no Save command in the screenshot... I have to admit that this is one of the main thing missing. The whole structure that will enable saving is there, but there's a few things left to implement. You have to remember that I have an older version that did save, so it's not like I never tried. There are a few interface elements left to be added. I'll add some buttons in the empty blue bar below the 3d view. The new scroll-bars and the window title bar are specific to my own computer, as they will show the OS native look. (I used an OS-wide ShapeShifter theme) -------------------------------------------------------------------------------- As for closing the thread momentarily, I'm not against. With all the respect due to people here participating in this thread, just about everything discussed here will make more sense once the editor is released. And as you can see, I'm not that far from a release. While the thread is closed, I won't have to worry about answering questions or giving updates. Don't worry guys, the editor is near completion. At the same time, I feel sad about closing this thread, slamming the door in the face of those who got involved in it. donrayiv, I'm sure you're well intended, but the hype surrounding this thread will bring newbies after newbies that won't read your advice. If this thread does get closed for a moment, you and others shouldn't take this personally. I'm really getting stressed about this thread, and I was about to announce that I wanted to get away from the thread for a week. But I realize that if I did that, the thread would have gotten worse, with more newbies asking "where is VL-Tone?", and regulars here having to deal with them. I don't want to have the last word on this, but to me, it's either being able to think by myself for a week or two VS. giving freedom to those that want to talk about TT64 here. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Oh well keep the thread open then I didn't even saw the name change for the thread when I posted the post about closing the thread... Anyway I simply didn't know what to decide about this, it sounded like this thread didn't make any sense for the moment. But with the new title, I guess it's alrighty The only problem is that a great affluence of newbies create opportunities for trolls, who can try to pass as newbies. Some of them are becoming very obvious, and I won't name names... -------------------------------------------------------------------------------- So what do you think about my latest screenshot? Too glossy? Sorry but I in that mood, and that effect is trivial to add in Director. (But yeah I know, Director has its limitations too) Oh and I just realized that I should have written "Flying Carpet" instead of "Flying Rug". Incidentally, there's a retro-computer related story linked to that particular mistake. The first time I read and learned the meaning of the word "rug", was while playing a text adventure+graphics game called "Calixto Island" on my Tandy CoCo 2 (64K). One of the first puzzle was to type "PULL RUG" to reveal a trap door underneath the rug. Of course you needed to collect some stuff like a flashlight before going into the trap. So since then, whenever I'm using a computer and I have to think about a word for "carpet", I think of the word "rug" first Ehm, to get back on topic, while Zelda OOT has an engine based on M64, there are some key differences that wouldn't make it that easy. But I've rewritten my editor in a modular way so it could adapt to new commands and parameter formats, making it easier to adapt it for another game. But please Zelda fans, let me finish and polish TT64. Don't count on it from me either, I may chose to concentrate on other projects after TT64 2.x is released and debugged. -------------------------------------------------------------------------------- Chainlink1061: Just saw your post after posting. That's a good mini FAQ. I'm currently implementing the texture export/import, and copy/paste texture functions. It may not be included if I run into a major problem (this is the type of thing that could go wrong since I never tried it and the export relies on an Xtra I never used before.) Maybe some line about the camera controls could be included. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 07-11-06 03:54 AM) Hi, just a quick post... I did take a week break. I said I wanted to take a week break earlier, but I admit I kind of "disappeared". Oh well, I'm back Edit: I stumbled across a few problems with the editor, to really explain them, I'll need a very complicated explanation There are 3 types of 3d sprites objects: Type 0x24 is found in the level script data, which is uncompressed in the original ROM. This type of object command offers the most flexibility, enabling you to change the sprite type and behavior type independently as well as the behavior parameters. You can change the X, Y and Z position value and the rotation angle for all 3 axis. The 0x42 type (mislabeled as 0x40 in the screenshots and in the editor, its type is not in front of each sub command so I did a little mistake when deciding which label it should have ) comes from commands found at the offset found in the 0x39 command in the main level script. These 3d sprite commands are found inside the MIO0 data for a particular level, they don't actually feature the 0x42 type, they are simply a sequence of the same type of object commands. Each one of these is 10 bytes long. With these you can change the X, Y Z position, but only the horizontal rotation. The sprite type and behavior pointer are fusioned in a single byte+ 1 bit from the horizontal rotation byte. This gives 512 possibilities. The table referred by this value is found at 0xEC7E0 in the ROM. Each entry in the table is 8 bytes long and contains a sprite type value (same kind as the 0x24 sprite type) and a behavior pointer (in bank 13) as well as 2 one byte parameters for the behavior. So with the 0x42 command 3d sprites you are restricted to a specific set of sprite type/behavior combo. It does include 2 bytes that can override the behav params from the table. The list of 0x42 sprites ends with a 0x1E or 00 object type. Now as for the 0x43 3d sprite type. It's found after the solidity data. The solidity data can be found at the offset pointed by the 0x2E level script command. The solidity data is complicated in itself, as there are different types of solidity triangle data. The editor currently doesn't directly deal with the solidity data, but it has to be decoded anyway since its the only way to find the offset of the 0x43 command. Since it's not part of my hacking document, I'll explain it. The first command in the solidity data is 0x0040. It's 4 bytes long in total, including the 0040. The two last bytes are the number of vertex point in the following list. So after the command is the solidity vertex list, with each entry being 6 bytes (signed 16-bits values for X Y Z). So to find where the next solidity command is just skip the number of vertex in the 0040 command multiplied by 6. After the 0040 vertex list, various solidity commands can be found, each of them creating different types of solidity triangles. These are the solidity triangles commands used in the game: "001E", "000E","002C", "0024", "0025", "0027", "002D" 001E works much like 0040 but is instead followed by a list of triangles instead of vertices. The command itself is 4 bytes long including the 001E and the two last bytes define how many triangles there are in the list. Each triangle entry in the following list is 6 bytes. The rest of the solidity triangle commands "001E", "000E","002C", "0024", "0025", "0027", "002D" mainly work like 001E, but their triangle entries are 8 bytes each, so each triangle has additional parameters which meaning varies depending on the command. You may find the 0x0041 command which is only 2 bytes and doesn't load a list. Once all the solidity triangle commands and their list have been decoded, you will encounter the 0x0043 command. The 0x0043 command is what I wanted to talk about. This command makes the game load the following 3d sprites commands, that are in yet another format different than the 0x42 and 0x24 command. The sprite commands following work much like the 0x42 commands but with a twist. The sprite type value is only 8 bits (not 9), and refers to a table at 0x0ed358 in the ROM. The difference in this table is that while the 0x42 sprite type value refers directly to the n'th data chunk in the 0xEC7E0 table, this table at 0x0ed358 uses the first byte of each entry to define which byte will be used by 0x43 sprite type values. What I just found is that if a 0x43 uses a value that is not referenced in the 0xEC7E0 table, it falls back to the 0x0ed358 table... So essentially, the 0xEC7E0 table is patching the first 256 entries of the 0x0ed358 table. By the way if you edit either of these tables, you'll have to recalculate the checksum, unlike the rest of the editable data. The game will also use these table entries in not-easily-predictable ways, as the sprite type they contain, is like the one from the 0x24 command and refers to the 0x22 commands that point to the geometry layout data. These values change depending on the level. So sprite type 0x03 means the castle Tower in some level, and a platform in another level. But for some reason (prevent duplicate table entries), they both use the same sprite type/behavior combo in a 0x43 command. That complicates things because if you edit one of the table entry thinking about one level, you may find weird things happening in another level. So I don't recommend serious hacking of these tables. Because of that and other reasons, editing this table falls into the realm of version 2.0 and beyond. The checksum is not a problem, as I had to do it in the ROM extender. Also... The 0x43 sprite commands have a variable size depending on the sprite type. "7A","7B","79","1D","21","7D": 8 bytes, contains x,y,z pos, sprite type (using 0xEC7E0 or 0x0ed358 table) "83","CD": Unkown use, 6 bytes. "88","85": 12 bytes, like the 8 bytes commands plus 2 behavior params override params plus 2 unknown bytes. "A0": Unknown use, 4 bytes "C0": Unknown use, 12 bytes "00": Unknown use, 10 bytes "CE": Unknown use, 6 bytes "44","42","1E": End of solidity and 0x43 commands list. For any other values before the end of the list, the byte length is 10, and it works like "88" and "85" sprite types without the 2 extra bytes. Bowser for example is a 0x43 command, its type is 0x21. This type happens to be the only 8 bytes type in the Bowser battle levels. So while my editor could switch other object into duplicate Bowsers, I just recently realized/remembered that this would corrupt the game. In the 3 Bowser hack I did, the editing was done manually in hex to get around this problem. So that's the problem I now have to solve. Even if I accommodated the varying length of 0x43 sprite commands it could likely overflow in the following data found in the MIO0 bank. To get around this I would have to copy the solidity data at the end of the MIO0 banks, and change all 0x2E pointers to reflect the new position of the solidity data. Same for the 0x17 commands (0x18 in the un-extended ROM) that point to the MIO0 data. I could make the ROM extender set the end MIO0 pointers to include the 32k of empty space that exists between the decompressed MIO0 data segments. -------------------------------------------------------------------------------- Ok now... Why is it so complicated ... Mr. Miyamoto? Or maybe Mr. Tekuza could answer? Hehehe don't worry I'm not delusional. But Mario 64 is very "patchy" in its nature, and it's understandable. Mario 64 was developed at the same time as the n64 itself and the UltraLib API's. That's why I'm sure Zelda OOT will be simpler to deal with, as they learned from their mistakes in Mario 64. It looks like they started by using an 8 bits value for the sprite type, thinking that they wouldn't need more than 256 different object presets. But they they ran out of possibilities, so they decided to use one bit in the horizontal rotation to double the number to 512. But then, they still ran out of numbers, and couldn't easily move things, at a time when they were trying to fit everything into 8 megs. So they decided to add other sprite objects commands at the end of the solidity data, but in a format where space is maximized, using variable length commands based on the sprite type referering to a table patched to make use of new objects while keeping the access to some original sprite types used by 0x42. Between the sprite types used in the 0x43 objects, and the actual polygon data, there are like 5 layers of different data formats. It's not that easy to visualize all these layers and how they interact. Maybe I should make a diagram with boxes and arrows... that would help Hey that's an idea... even with my lengthy explanations, I'm sure many of you would like to understand the structure of the game in a visual way. I have very good visualization skills, but something tangible like a graphic would probably also help me in this project. That's it for now, these are my days off work so I'll work on the editor as much as I can. Edit: Here we go, the diagram of the Mario 64 level formats structure, or whatever it should be called. I finished it before going to bed last night. For a bigger version click this url: http://i26.photobucket.com/albums/c105/Starxxon/M64Diagram.gif -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 07-21-06 12:36 PM) Originally posted by bloodzero -------------------------------------------------------------------------------- But half of what you said i didn't understand -------------------------------------------------------------------------------- Well this post was not intended for everyone as a whole. Many of these things are findings I did in the last days of the older editor prototype, and weren't explained or documented anywhere. My problem is that I forgot about these unfinished commands from the first version, and I'm only now at the point where latest rewritten editor brings up those problems. This post was also a good reminder that the Super Mario 64 level format is complicated. My editor aims at making the editing simple, but it still requires the whole complicated structure to decode and store things and chose which valid values are available to the user. The graphic I added represents data elements in the game and their relationships. Many commands depend on which memory bank is loaded. (I know I should call them segments... but bank is shorter and conveys a better meaning) Other elements depends on tables that are defined by other data elements that are level specific. Object numbers for 0x24 3d sprite commands are defined by the 0x22 command for example. But let's not get too technical again I'll try to make a movie of the editor in action, that should be more interesting to some... -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Hello, friends and foes Happy 64th page First I'd like to mention, the editor cannot be delayed, since there's no release date set. The issues I described in that long post are not that hard to fix, just hard to explain I'm still working on making a movie of the editor, I did a few experiments but I'm not sure yet what I'll put in the movie. Any suggestions? Screen recording is a little slow when recording the whole window, so I may only show the 3d viewport. One of the reason the movie is still not done is that while trying to make it, I got the incentive of fixing bugs and implementing missing features like copy/paste and revert, so I guess it's not a bad thing, as the editor is progressing. Next week I'll have a week of from work so I'll have much more free time to try to finish version 1.0. I may release a pre-release beta with saving disabled (which is a good way to prevent this version from spreading all over the web). I still wont commit to even an approximation of the release date, for reasons I mentioned before. It doesn't mean it will be released in a long time either. Aside from that, any suggestions on what should I show in the movie? Any levels you'd like to see featured? As for me narrating the movie, it's actually not such a bad idea. I could describe features and things happening in the movie. But... I'll probably put the M64 credits music instead -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Goomba Fondue, you're weird, not necessarily in a bad way, and you don't have to be sorry about it I'm taking some of your suggestions into account... Here's a little "teaser" video in mpeg-4 format. It's around 3.6 megs so it's even suitable for dial-up. http://65.111.164.51/Toad'sTool64demo1.mp4 -------------------------------------------------------------------------------- Edit: Raccoon Sam I just saw your post after posting mine. I planned to do something clearer, this is just a little demo movie. It's not easy to coordinate a demonstration session and do it without messing up, it's like movie acting with the mouse pointer -------------------------------------------------------------------------------- Shiryu I'll try to answer your questions: Is the wing cap switch level the same as the wing cap level where you see mario falling? Same level. if so, then is there an object or level propertipes that makes what's mario current state when the level starts? I didn't find it yet. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 07-27-06 05:41 AM) (edited by VL-Tone on 07-27-06 05:42 AM) (edited by VL-Tone on 07-27-06 05:43 AM) (edited by VL-Tone on 07-27-06 05:45 AM) Originally posted by Raccoon Sam -------------------------------------------------------------------------------- Nice video, but something bugs me about the vertical scrollbars. In Mac OS, they're usually "Down arrow >> Up arrow >> Scrollbar", but in your editor, they're "Down arrow >> Scrollbar >> Up arrow" if you get what I mean. The best ASCII example I can give is Horizontally. [<]_____(_____)_____[>] [<][>]_____(_____)_____ Upper = No Lower = Yes Sorry if it's unclear. -------------------------------------------------------------------------------- Raccoon Sam, since when are you a Mac user? Because the Mac OS had button-bar-button scroll bars since 1984... They were the default until Mac OS X. Other optional variations were added in Mac OS 8-9, like up-down-bar, and a hidden feature enabled up-down-bar-up-down scroll bars like Kyoufu Kawa had. In Mac OS X, by default you get the up-down-bar setup you seem to use. These are nicknamed "NeXT style arrows" since this is how they were in NeXTStep Open System Preferences/Appearance and you'll see that the first option is what I used: "Place Scroll Arrows: At top and bottom". Like I said, this one is just like the classic Mac OS scroll bar. (Please don't call this "the Windows order") Double double arrows are possible in OS X (up-down-bar-up-down). Open the terminal and type: defaults write -g AppleScrollBarVariant -string DoubleBoth And hit return. Relaunch your apps and voila! Double double arrows! Other keywords can be used instead of DoubleBoth: DoubleMax: Default in Mac OS X (what you use) Doublemin: Single arrow pair like DoubleMax, but at the opposite side of the bar. Hidden feature. Single: Like Classic Mac OS/Windows: up-bar-down (available in System Prefs / Appearance) ANYHOO... Like I stated before, my editor will use standard native scroll-bars from your own OS, and they will act just like you set them to in your OS preferences. I don't have anything to do about how the scroll bar behaves in the editor, it's your OS that decides. By the way there's a little mistake in the video demo: the four towers at the end should have yellow boxes as they are selected. There's currently a bug with the paste command, that deselects (visually) a selection after pasting. -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt -------------------------------------------------------------------------------- (edited by VL-Tone on 07-27-06 03:17 PM) (edited by VL-Tone on 07-27-06 03:18 PM) Well... sorry about the scroll-bar rant. I realize it was a stupid rant and if you add 1+1 you can understand why I didn't feel like posting on this thread in the last few days. -------------------------------------------------------------------------------- From what I've learned, Beta is a stage where all features are implemented and only bug-fixing is left. I'm currently in the Alpha stage for this editor, which means that some features are still missing. -------------------------------------------------------------------------------- tahu363 please learn to be patient in life. You should know that the video was created with the older version that was since rewritten almost from scratch into the current development version. This older version was hard coded for the older ROM extender format and won't ever be released. The new one is much more flexible regarding the ROM format, and many other things. The current version couldn't be released. It would generate errors too often and you'd have to restart it each time. To me it's useable because in the development environment, errors like this just stop the playback, and I can quickly restart where I was without having to reload everything. -------------------------------------------------------------------------------- I'm having a week vacation from my job starting today, and intend to stay here. I'll have much more time and motivation to work on the editor. It's possible that by the end of the week, I'll be close to release at least a demo with no save function. But it's also possible that it will be later. I'm not teasing anyone, I just don't know and don't want to be tied to a release date for now. -------------------------------------------------------------------------------- Goomba Fondue: Bravo! you basically nailed it. (tahu363 brought a good point but then went on a crazy rant... ) The behavior code contains pointers to an animation index in a format I don't know much about yet. The meshes pointers for each body parts are stored it what I call the "geometry layout data" for a particular 3d sprite. But what defines the mesh numbers used by the animation data is not so obvious. The meshes are arranged in a hierarchy which I think is a BSP tree. For now, 3d sprites with bone animation will be a weak point in this editor, as they wont display correctly. Fortunately, the level and platform meshes are not animated. I must also warn that the editor might have some z-sorting issues in some situations. I'm trying to get around that bug, but it's a Shockwave 3d issue. -------------------------------------------------------------------------------- I'm thinking about renaming the editor "DoesntEditPolygons 64 1.0b" -------------------- VL-Tone ----------------- Super Mario 64 Hacking information: http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Ok these are all VL-Tones posts in the other thread, I just copied and pasted but the pictures he posted didn't come out for some reason. I don't think anyone will read all of this though..... (edited by Watcher on 08-09-06 11:57 AM) |
|||
Yoster Red Koopa        Since: 02-03-06 From: Holland/The Netherlands Last post: 6371 days Last view: 6371 days |
| ||
| Wow... That's probably the longest non-spam post I've ever seen.
I think it would be a better idea if u put that all in a text file and upload that instead. Would save a hell of a lot of space .
You could ofcourse also put it on the Wiki page. |
|||
|
Deleted User Banned  Since: 05-08-06 Last post: None Last view: 6271 days |
| ||
| If I put it in a text file less people will actuall read what VL-Tone posted. And anyone can post it in the Wki now thats its here but give me credict. | |||
tahu363 Red Paragoomba Since: 05-31-06 Last post: 6396 days Last view: 6396 days |
| ||
| Actually, it is spam, ive been watching that thread for awhile and its some guy pretending to be VL Tone, so lets not just copy and past everything connected to sm64 hacking please! | |||
Tanks Spiny  Since: 06-19-06 From: Eagle Land Last post: 6270 days Last view: 6270 days |
| ||
Originally posted by tahu363 What do you mean? That huge post is all from the old thread. Unless there was something i missed... if your talking about the idiot who claimed his brother was making an editor and took credit for VL's work thats not on here. Oh wait your talking about nighttalker then yeah thats fake. next time tahu quote so i dont do that again. Pgad- Thanks, hacking the rom works better now. nothing screws up. |
|||
|
Deleted User Banned Since: 05-08-06 Last post: None Last view: 6271 days |
| ||
| Those are VL-Tone's posts. Its not a fake VL-Tone! What do you mean? Aghhhh, we are getting offtopic already! | |||
SuperLuigi64 Snifit  Since: 07-22-06 From: TN My PC Specs Last post: 6364 days Last view: 6364 days |
| ||
| Back on topic.
What is the behavior for let's say.... the giant gombas (in the castle front lawn, from VL-Tone's IPS). Maybe they could be changed into chomps, or is it the same as the code in rstewart's document. (edited by SuperLuigi64 on 08-09-06 03:34 PM) |
|||
FreeDOS + Giant Red Koopa Legion: freedos = fritos  Since: 11-17-05 From: Seattle Last post: 6270 days Last view: 6270 days |
| ||
| Yes, please go ahead and post whatever is relevant, you do not need any permission from moderators to do so. My emphasis on adding information to the wiki is that it can be easily found, organized, updated, etc without the hassle of forums!
Now we're getting off-topic, so onward, James! |
|||
|
nighttalker Newcomer  Since: 08-08-06 From: Colorado Last post: 6463 days Last view: 6463 days |
| ||
Originally posted by TanksOriginally posted by tahu363 what do you mean by, "Oh wait your talking about nighttalker then yeah thats fake," I actually copied some of vltone's posts and put them on a word file. I'm not pretending to be vltone tahu363! |
|||
|
Deleted User Banned Since: 05-08-06 Last post: None Last view: 6271 days |
| ||
Originally posted by SuperLuigi64 They can all you have to do is change the behavoir code, unless they are not loaded on that area. |
|||
|
SuperLuigi64 Snifit Since: 07-22-06 From: TN My PC Specs Last post: 6364 days Last view: 6364 days |
| ||
| Ok, that helps, thanks.
While I am here, my more SSBM looking castle. 
 |
|||
|
Deleted User Banned Since: 05-08-06 Last post: None Last view: 6271 days |
| ||
| Actually it just looks like the castle has been worn out or droughted. But I like it better like that. When VL-Tone comes back here to post, how will he know to post in this one, cause there that other thread "down" there. Someone should PM him. telling him that. | |||
jensthecomposer Paratroopa Since: 05-18-06 From: Norway Last post: 6274 days Last view: 6270 days |
| ||
Originally posted by Watcher This is a sticky, so Vl won't miss it. About placing chainchomps, to place proper chain chomps where we want we have to find it's object ID. The object ID decides which head chain chomp gets when placed with a 24 18 command. EDIT: Superluigi, make the border on the princess picture in the same color as the bricks. It looks so sticked on as it is now. (edited by jensthecomposer on 08-09-06 06:22 PM) |
|||
|
SuperLuigi64 Snifit Since: 07-22-06 From: TN My PC Specs Last post: 6364 days Last view: 6364 days |
| ||
| yeah, i have it that color in the Alpha of the castle, don't know why i changed it back.
EDIT, LITERALLY:  (edited by SuperLuigi64 on 08-09-06 07:30 PM) |
|||
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: 6271 days Last view: 6271 days |
| ||
That looks much better. BTW:
Originally posted by SuperLuigi64 The texture on top of the bridge guardrail is smeared here. |
|||
|
Goldensunboy Snifit  Since: 12-30-05 From: Georgia Last post: 6275 days Last view: 6275 days |
| ||
Originally posted by HyperHackerIt was already smeared in the original game, but his lightness and darkness of graphics have gotten a little stronger, so now it's just more apparent. (edited by Goldensunboy on 08-10-06 12:04 AM) |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6461 days Last view: 6461 days |
| ||
| Dang I'm so glad that I don't have the weight of the other thread on my shoulders anymore, seriously...
Maybe others are better to deal with this kind of pressure, but it was too much for me and I felt the other thread was so full of... filler content and redundancy. So here's the deal. I'll give you some updates and post here when I feel like it, but don't ask me any questions in this thread until I release the editor. Feel free to ask "legitimate" questions here, but don't direct them at me, I won't answer them (sorry!). Also, don't redirect questions to me.It's not that I don't want to share info or anything of the sort, I just don't want this new thread to become the "ask VL-Tone" thread like the other was. Now about Toad's Tool 64: Don't worry I won't suddenly cancel or abandon the editor. I still won't give you a release date, but the editor will be released before the tenth anniversary of the US n64+ Mario 64 release, which will be this September 29th. I don't want to have to justify the time between my post and updates here. I may go another week without posting here, we'll see... I'll take the time I want to complete the editor, but I want it to be out before Sept 29th. One major milestone in the editor progress: the feature set and interface layout is pretty much frozen now, which means I'll stop wasting time deciding which features should be included and how they'll work. The last main feature I added before freezing the feature set is the ability to save up to 8 camera sets for each level. Each camera set will contains positions and rotation for the top/bottom/left/right/front/back/fly/orbit camera. I felt it was important to add this feature as 3d editing requires you to often move the camera. By saving/loading camera positions, you can easily get back to a particular view of a level that you were editing. I'm glad to see you guys starting to do some manual hex hacking of M64. Just keep in mind that while the 0x24 object commands are relatively straightforward, the 0x42 and 0x43 objects found in the MIO0 data are not that simple. Jenscomposer said that I did not share info about these commands, well it's not true, though it took me some time before publishing all the details about it. Remember that big post that many people said that they didn't understand half of it? The one with a graphical representation of the game structure? The info about these object commands is all in there... And the complexity of it shows why the editor is not as simple as only editing the 0x24 commands. Warning, the rest is pretty much off-topic. Guy Perfect, If you read this: I removed any mention of a "sprite" in my editor to avoid confusion. I'll call the 0x24, 0x42 and 0x43 commands "3d objects" instead of "3d sprites", and the "sprite ID" has been changed to "model ID". I think though that your definition of sprite is skewed. I come from a parallel world where a sprite is more of a container with parameters that can display an image, not image itself. To me, sprites are discrete image elements that have a x,y position and optionally some display parameters. Maybe I'll post something about sprites in another forum on this board, because I feel I have many things to say/debate about it, and I don't want to get this thread out of topic. But one last out-of-topic thing: Voxels... Guy Perfect this is not aimed at you since you seem to understand the meaning of voxels. It's more about the following posts about voxels I found in the other thread. As the author of Metroid Cubed (and other voxel based demos/games), I cringe every-time I see someone mentioning Novalogic games like Red Alert as using voxels. Sorry but height map terrain generation using vertical lines is not what I call a voxel-based engine. Novalogic call this "Voxelscape" but that doesn't mean they're voxels. At best (to me it'd be at worst) you can heavily skew the definition of voxels until it fits the Voxelscape concept, but at least, when you mention NovaLogic, please mention it's a very limited and non-standard sub-set of voxel technology. Again, I don't want to start a debate about this in this thread, if anyone wants to debate with me about the definition of sprites and voxels, start a thread in another forum on this board (and tell me about it). (edited by VL-Tone on 08-10-06 02:40 AM) |
|||
|
jensthecomposer Paratroopa Since: 05-18-06 From: Norway Last post: 6274 days Last view: 6270 days |
| ||
| Sorry VL, I should instead said that you didn't write it in the info document. | |||
|
SuperLuigi64 Snifit Since: 07-22-06 From: TN My PC Specs Last post: 6364 days Last view: 6364 days |
| ||
Originally posted by GoldensunboyOriginally posted by HyperHackerIt was already smeared in the original game, but his lightness and darkness of graphics have gotten a little stronger, so now it's just more apparent. Here's a before and after. 
If anyone knows how to make it less noticeable, please post. |
|||
|
Yoster Red Koopa Since: 02-03-06 From: Holland/The Netherlands Last post: 6371 days Last view: 6371 days |
| ||
| You should be able to fix it with some good quality graphic editing software (I'm assuming you're editing the textures for this). |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - ROM Hacking - Super Mario 64 Hacking discussion thread - READ THE FIRST POST BEFORE POSTING! |
| |
