Register | Login | |||||
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
| |
1 user currently in Rom Hacking: |
Acmlm's Board - I2 Archive - Rom Hacking - Mario 64 - Amazing Stuff | | | |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
User | Post | ||
tachyon Octorok Level: 7 Posts: 12/23 EXP: 1089 For next: 359 Since: 07-28-05 Since last post: 5 days Last activity: 10 hours |
| ||
it's back up. yeah, I've seen that one before. thanks. | |||
stag019 Snifit Level: 23 Posts: 293/299 EXP: 62259 For next: 5464 Since: 06-10-05 From: C:\Documents and Settings\stag019\Desktop Since last post: 9 days Last activity: 7 hours |
| ||
I've figured, as I've seen it before. 30 pages. This is getting more activity now! Thanks stag019 for fixing my list No problem When I saw that bowser courses had the same values, it became evident to me that it was the music command. What are the offesets to those levels music? And what other levels do you know? (edited by stag019 on 09-30-05 06:13 PM) |
|||
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7373/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
Most of them would be in compressed files. Even if they're not actually compressed (eg part of the raw part of the compressed data), it'd still be difficult to locate them. | |||
VL-Tone Red Cheep-cheep Level: 23 Posts: 177/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by stag019 I'm not sure what is your question, maybe I didn't explain it well. I simply used my level decoder to output the level layout as formated hex. Then I looked for the 0x36 command inside a few levels. I knew that Level 1 had value 0x03 and then found that Bowser's courses all had 0x11 as a parameter. I could have been wrong, but it turns out to be the music command as I thought. Part of my SM 64 hacking has been like that, figuring out commands by looking at them and their context, and trying to guess what they were used for, and I was usually right, since I already did the same for a similar script format and commands in StarFox. Many of these commands crash when you change a parameter to a value that is not valid, so I couldn't just "corrupt" each of them and deal with repeated emu crashes and weirdiness until I found a correct value that could show the function of each commands. Anyway, the jump table Cellar Dweller found, will be very useful, but my "intuition" can also have it's purpose, as it's not always obvious to find the purpose of a command by looking at the ASM that powers it. Cellar Dweller: I don't know much yet about USF music ripping (yet), do these people have to figure out the actual format of the tunes? Or do they rip out the music playing code and the data without knowing the details of the format? I always suspected that in SM64, music was in MIDI format, or a variation on it. Obviously, the songs were played on a MIDI keyboard and recorded in MIDI format. Part of the Dire Dire Docks song (which rocks ), seem like it was played "live" by Koji Kondo on a pressure sensitive keyboard, as there is a human feel to variations in the intensity of the notes. Also, I looked at the disassembled code, I noticed the off0x36 and off0x38 at the end, does it mean that command 0x38 also loads music? |
|||
Cellar Dweller Flurry !!! Level: 27 Posts: 264/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
The USF Walkthrough document linked to in one of the message board threads I linked to explains in detail how USF ripping is performed. There is no attempt to figure out how all of the games's music code works, just enough to stop all but the music code. Then a tool that runs the music code and records all of the code and data that is part of the music engine is run. It runs until no new code or data has been accessed for a while. After that, all unused data is removed from the rip. According to the docs that I have, there is support for type 0 MIDI sequences built into Ultralib, and a tool to convert type 1 MIDI sequences to type 0 MIDI sequences was included with the IRIX based N64 devkit. For some reason, I have the impression that every N64 game used the MIDI features of Ultralib for music in some way. There is also support for compressesd MIDI sequences in Ultralib. off0x36 and 0ff0x38 are just offsets into a data structure somewhere else in memory. What is interesting about the command 0x36 function is that the way it is coded implies that the music command has two 16 bit arguments. The music command is 8 bytes in size, but the last 2 bytes seem to be there only to pad the command to a 32 bit boundry. |
|||
stag019 Snifit Level: 23 Posts: 294/299 EXP: 62259 For next: 5464 Since: 06-10-05 From: C:\Documents and Settings\stag019\Desktop Since last post: 9 days Last activity: 7 hours |
| ||
Originally posted by VL-Tone I mean like this: 395FCD=Cool, Cool, Mountain Anyone who can help, please do so. VL-Tone, how hard would this be to implement in your next version of your editor? That is, if you keep working on it. (edited by stag019 on 10-02-05 12:28 PM) |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 178/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by stag019Originally posted by VL-Tone oh you mean something like that? Haunted House It seems that more than one 0x36 command can be found in one level. Often, it's used for the hidden slides music. Also while the 6th byte is the song number I identified, the 4th byte is unknown to me, so I'll let you the pleasure of finding it yourself I'm still working on the editor, but maybe it would me more fair to say "I didn't abandon working on it" since I didn't work much on it lately. The main problem is that the newer decoder is incompatible with the editor part, so I would have to make some major changes. Also my new decoder gives me errors while loading some levels, and I didn't feel like debugging it... Anyway until I move to a new host I won't release an update. Cellar Dweller , that 4th byte must be the one you were talking about. As for MIDI, with what you've said, I'm now pretty sure we'll find MIDI files somewhere inside Mario 64, they may not have the standard MIDI header, since I didn't find any instance of it (it starts with "MThd"). (Edit: forgot to address the part about my editor) Edit: Forgot to tell you about some finding I made yesterday. I confirmed that Zelda: Ocarina Of Time, does indeed uses the same polygon object format (with a few new commands). I thought it was a given, but it's nice to see it confirmed (looks like I'm replying to myself). There are a whopping 1400+ Yaz0 files inside OOT (is my decoder buggy or there are some big empty spaces found in some of those?). Anyway Mario 64 fans, don't worry, I won't spend more time on Zelda OOT anytime soon. And to Zelda fans... sorry (edited by VL-Tone on 10-03-05 03:45 AM) (edited by VL-Tone on 10-03-05 03:46 AM) (edited by VL-Tone on 10-03-05 04:02 AM) |
|||
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7412/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
A lot of Nintendo games probably use formats like this. Any idea why there's 4 music bytes in Tall Tall Mountain? |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 179/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by HyperHacker Yes but not as much as you may think. Along the way, Nintendo switched tools, and most third parties used their own format. As for why there are four 0x36 commands in Tall Tall Mountain? This is a very interesting question The first command triggers song 0x03 which is Level 1's song also used in TTM. The three others trigger the slide music... I'm not sure why there are 3 of them. It seems that the level layout data is grouped in 4 main groups. They end or start with 0x31 and 0x20 commands. Are there 3 way to enter the TTM slide? I don't know yet what enable switching between those groups. Actually I found something not so far from that, but it's not directly connected to the groups, I cannot find any offsets referring to them. So what I found is the main use of the 0x26 command. It's used to connect warps, doors and slides! Let's take a look at part of Cool Cool Mountain (which is easier to understand than TTM) 395F04 [24, 18, 1F, 00, FA, 18, 0D, E8, F6, FF, 00, 00, 00, 8C, 00, 00, 00, 0A, 00, 00, 13, 00, 2F, 74] I included the 0x24 commands that are before the 0x26 series because they are connected to the 0x26 command. These objects have a type byte of 00 so they are invisible, depending on the behavior associated with them, they can be an entry or exit point, a warp, a room transition. The 18th byte of these particular commands identify them, and these id numbers are referred by the 0x26 command. The first one has id 0x0A and behavior 13002F74 which is the behavior for Mario's start position in the level. Id 0x1E is for the chimney entry, id 0x1F and 0x20 are warps on the broken bridge on top and bottom of the mountain. The first 0x26 command puts Mario at the starting point of the main level, pointing at the 0x0A position. For some reason, changing the values for this particular command have no effect. I'm not sure if the second command is even used. It warps to the wooden house at the bottom of the slide, like you entered it by the door (which is impossible normally since the door knob disappear when you exit the slide bottom house). The third command is more interesting , it's the warp to the Penguin Slide. 395F74 [26, 08, 1E, 05, 02, 0A, 00, 00] 1E is the entry point, in the chimney. I don't know the use of the 0x05, it's value can vary in other levels, commonly used values include 0x05, 0x06 and 0x24. The 0x02 (fifth byte) selects the slide level, and 0x0A is the id of the position inside the slide area (which is not the same as the 0x0A position in the main level). The fourth and fifth commands warp between the two bridges, from position id 0x1F to 0x20 and back. This happens inside the main level as specified by the 0x01 value. 395F7C [26, 08, 1F, 05, 01, 20, 00, 00] 395F84 [26, 08, 20, 05, 01, 1F, 00, 00] The two last commands are for the level exits,either by dying or taking a star. 395F8C [26, 08, F0, 06, 01, 33, 00, 00] 395F94 [26, 08, F1, 06, 01, 65, 00, 00] F0 is for successful exits and F1 is for a failed attempt. The 33 and 65 values point to the Cool Cool mountain paintings inside the castle. If you change the 0x01 value to 0x02 you can access paintings found higher in the castle. So have fun experimenting with changing those values (edited by VL-Tone on 10-04-05 04:27 AM) |
|||
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7438/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
Awesome. So we could make a secret area in the castle, that the only way to get to it is to successfully complete a certain level; when you do, it kicks you out into the secret room, otherwise you're back at the entrance. Or maybe you can even make it exit into another level? There's only one way to enter the slide mid-level, but I think I might know why there are 3 music-setting points. One sets the music when you go through the wall, one sets it if you die in the slide and jump back into the painting (you restart in the slide), and one is unused but needs to be there, for the warp leading back to the main level from the slide. CCM's data supports this as well by having a defined warp point for entering the bottom building from outside even though this is impossible. It may be a technical limitation (all warp points need to be able to warp both ways even if they don't allow it), or just lazy programming (they didn't bother removing unnecessary warp info, or early development builds allowed warping back for quick access). And even if Nintendo used a different editor for later games, I imagine they'd have used a somewhat similar format. It works, after all. (edited by HyperHacker on 10-04-05 03:31 PM) |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 180/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Dang my Cable Modem ISP (videotron) has been down all day yesterday... Anyway the good news is since I didn't have the net to waste my time reading digg.com I did spend some more time on hacking Mario 64... The result? I found that the 0x26 command can be used to warp at any entry/exit point in the game instantly! From CCM: 395F84 [26, 08, 20, 05, 01, 1F, 00, 00] This command will warp from warp 0x20 in the current level area to Course 0x05 (CCM) --> area 0x01 --> entry point 0x1F. Using the good old SMB level number syntax, it could be written as 5-1-1F. At 2ABE8C in the ROM you can see a bunch of 0x0C commands. As I explained somewhere in the thread the 0x0C command assigns id numbers to levels, storing the related pointers. The 0x0C command at 2ABE8C as an id number of FFFFFFFF and this means -1, the negative values are assigned to title screens and menus. Somewhere after that you'll find 0x0C commands with positive id numbers that refers to levels, and the one with id 00000005 is incidentally Cool Cool Mountain. Also from CCM, the death exit warp is 395F94 [26, 08, F1, 06, 01, 65, 00, 00] 0x06 is the inside of the castle, 0x01 is the first floor area and 0x65 is one of the two exit point from the CCM painting (could we call it Level 6-1-65?). The successful exit point for CCM is 0x33, as defined by a 0x24 command and associated behavior. This means a level could exit to two different locations in the same room as the painting. But like I said, the game can warp to any other exit/entry point in any level. The only problem I found is when you assign an exit with a success painting exit behavior to a non F0 or F1 0x26 command, it will freeze after playing the animation (just like the Castle courtyard I experimented when swapping painting entry points). Note that the painting entry points doesn't use the 0x26 command. If you jump from something that is not a real "warp" to a real warp exit point, you may not have time to regain control of Mario before he gets warped by the warp point he's standing on. (by real warps I mean place you stand and fade away) Other than that, you can warp to anywhere in the game. There are 177 0x26 commands found in the level data. Some may have duplicate "warp to" values, but from a rough estimate there are at least 100-150 different places Mario can warp to. I made a cool little program that I will probably publish, called "Super Mario 64 Shuffle". It randomize entry and exit points in the game. This can lead to a very fun game (or one that is pretty limited depending on how you are lucky). Every-time you enter a double door or jump into a hole, use a warp or enter a mini game inside you will have a surprise. I didn't randomize the death/completed exits values, but that could be an option. I'm thinking also of adding a "shuffle paintings entries" option too. Ideally, one could patch the 0x26 command so that it always warps at a random place. So any-how, more serious applications includes very complex mazes, and the "fight all bosses , one after the other" hack that was requested before. In other news, I found Yoshi! Well I mean I already found the geometry a while ago, but now I found the 0x24 command that places Yoshi on the top of the castle. The command is at 454ACC, Yoshi type number is 0x55 (for this level only). Its behavior (13 00 45 38) only makes it appear at specific conditions so we'd have to use another behavior to make him visible. Unfortunately I didn't find a behavior (yet) that makes it behave like he should. In the mean time, I found that the butterfly behavior on Yoshi gave very funny results. at 454ACC in the ROM, replace: 24 18 1F 55 00 00 0C 66 EA 07 00 00 00 00 00 00 00 00 00 00 13 00 45 38 With: 24 18 1F 55 FA D0 01 04 12 38 00 00 00 00 00 00 00 00 00 00 13 00 33 BC You'll get an epileptic Yoshi hovering above the ground like a butterfly... Very funny! While you are at it, look at the few 0xBB values just before that, used in 0x24 commands, change them all to 0x55... Now you get levitating epileptic Yoshies everywhere on the Castle grounds! Have fun! (Edit: Hmmm have I said or did something wrong? None has been replying to this thread since the last 3 days! Should have I provided an IPS patch and/or screenshots? Maybe I offended some by mentioning epilepsy? Ah well I guess that all the usual contributors have better things to do these days...) (edited by VL-Tone on 10-05-05 04:49 PM) (edited by VL-Tone on 10-08-05 09:50 PM) |
|||
Cellar Dweller Flurry !!! Level: 27 Posts: 266/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
stag019's current name is too big to fit into the name field of the PM form without hacking the form with a text editor. I'm too lazy to do that, so I'll post the message here. Also, this information my be of use to others. Please excuse any crappy grammer/spelling; I need sleep.Originally sent by stag019 Here is the code that seems to have the pointers: 3ac0/80248ac0: 3c 05 00 11 LUI a1, 0x11 (17) The LUI instructions set the upper 16 bits of a register, in this case a1 and a2 are set to 0x00110000. The ADDIU instructions set the first register to the sum of the second register and the immediate 16 bit signed integer. Note that the second ADDIU's immediate parameter is treated as a negative integer and the value of a1 will thus be decreased to 0x00108a40. The third ADDIU sets a0 to 0x2 by adding r0, which is always zero, to 0x2. The JAL instruction calls a function at 0x802787d8. Because MIPS CPUs are highly pipelined, the instruction after a jump/branch/function call will be executed before the target instructions are executed. The 0x802787d8 function loads a MIO0 file into RAM starting at the ROM address in the second parameter (a1) up to the ROM address in the thid parameter (a2), and stores a pointer to the decompressed data in the segment table at the index specified in the first parameter (a0). 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 If you need a MIO0 compressor: http://s91407720.onlinehome.us/acmlmboard_files/romhacking/sm64/mio0enc.exe |
|||
OmegaPirate Newcomer Level: 2 Posts: 2/2 EXP: 13 For next: 33 Since: 10-09-05 Since last post: 23 days Last activity: 3 days |
| ||
Nice Yoshi-flys, VL-Tone... VL-Tone Um i was wondering if any of you (or anyone else) could find Mario Image or Object and change him into something else like an enemy? So like, you could play as them. The Peach head hack seemed close... And thinking of that and the problems when entering other areas of the game... It may not be possible.. (edited by OmegaPirate on 10-09-05 07:05 AM) |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 181/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Cellar Dweller, That's great info, and it will be useful for sure, since it seems the only easy mean of repointing this MIO0 data. Ideally though, I was looking to do the equivalent of changing a 0x18 command (load MIO0 data into a RAM segment) to a 0x17 command (copy uncompressed ROM data into a RAM segment), and repointing the uncompressed data to the end of the ROM, extending the ROM file. It works great and enables direct editing of decompressed MIO0 data right in the ROM. The main interface MIO0 file (Fonts , icons etc.) at 108A40 is one of the only MIO0 file not decompressed with a 0x18 command. Do you think it would be easy to achieve the equivalent of 0x18 to 0x17 switching for the 108A40 file? Originally posted by OmegaPirate The Mario object is inserted into a level using a 0x25 command. I tried to modify the parameters but the best I could do is render Mario invisible Now Mario seems to be a special object, made of smaller objects, which are his body parts. At 0x2ABCA0 in the ROM, is one of the shared level loading script. It loads, amongst other things, the Mario MIO0 file, then uses 0x22 commands pointing to body parts in the file. Each part is assigned an ID number that is used by the game engine. 2ABCA0: By modifying this area of the ROM, it may be possible to change Mario into something else. Maybe it's possible to load another MIO0 file instead, and re-associate the body parts, but other creatures don't use 0x22 commands as far as I know. Their body part arrangement comes from their geometry layout data, which uses another set of commands. Anyway I'll try to transform Mario into Yoshi later tonight, as I didn't experimented yet modifying the values at the start of 0x2ABCA0. The Princess hack was done at the geometry layout level. In the mean time, you can try swapping the ID numbers for body parts and see what it does! |
|||
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7613/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
The 0x17 and 0x18 probably just call 'copy' and 'decompress and copy' functions with the same parameters. I imagine rather than actually using the script engine, the game just calls the 'decompress and copy' function manually for that file. | |||
VL-Tone Red Cheep-cheep Level: 23 Posts: 182/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by HyperHacker Yes that's what I figured out, but I'm wondering if changing this custom call from a "decompress and copy" to a "copy only" command would be as easy at the ASM level. I thought about making a program that transform a Mario 64 ROM to a more editable form. It would automatically change all 0x18 commands in the game to 0x17, relocate all the decompressed MIO0 data after the end of the ROM and repoint the 0x17 commands accordingly, with plenty of padding between each segment so that we could expand them individually without having to move huge chunks of data. The resulting ROM would be then much more easy to edit by an editor. All the MIO0 files decompressed are less than 8 megs, so the ROM may be 16 to 32 megs depending on the padding we want to put between segments. Maybe 24 megs could be a good compromise. But at the price of HD's these days, why stop at 24 megs? It shouldn't be that hard to make such a program, it could be done by generating the padding files, then merging it all in order with decompressed MIO0 files and the original 8 megs ROM. The 0x18 commands locations could be pre-scanned and the new offsets pre-calculated. Anyway to make this one, I'll have to dip my toe a little deeper into C++. In other news, I didn't try to transform Mario into Yoshi yet, but it seems like a lot of manual work, matching body parts. By the way Zelda: OOT looks much more easy to work on, and it seems you can easily put any characters into any levels, as each polygon object is stored in a single YaZ0 file. Not so in Super Mario 64, as specific sets of objects are bunched together into MIO0 files, and different sets are loaded in each levels (though some are shared, like trees, doors, coins, stars etc.) "In the future" a Mario 64 editor may provide more flexibility by letting the user choose which object sets are loaded in each level. I'll try to gather data from the original level scripts to build list of possible 0x22 commands pointer values, and which MIO0 file they are targeting. That could give us a picture of how objects are distributed among levels and MIO0 files, and how much flexibility is possible. 0x22 commands are actually pointing to "geometry layout" data loaded by a 0x17 command. The 8 bytes 0x15 command inside the geometry layout data then points to different geometry data inside a decompressed MIO0 file. I'll try to put up a much improved Mario 64 hacking document that will list all commands I know about, and some info about the structure of the game and the way courses are loaded at the script level. (edited by VL-Tone on 10-13-05 03:39 AM) |
|||
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7661/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
Keep in mind that there's only 32MB of addressable space (IIRC), so that's as big as the ROM can be without some 1337hax. If you use it all for level data, future hackers won't have room for things like graphics and music. | |||
tachyon Octorok Level: 7 Posts: 13/23 EXP: 1089 For next: 359 Since: 07-28-05 Since last post: 5 days Last activity: 10 hours |
| ||
this is off topic, but I can't find anywhere else to put it. I'm using Corn, but I don't know how to run games. I went to the game and clicked run, but nothing happened. I'm probably doing something wrong, but I don't know what. | |||
VL-Tone Red Cheep-cheep Level: 23 Posts: 183/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by HyperHacker Almost all graphics are part of the compressed MIO0 files. I'm pretty sure that only the Mario face demo uses uncompressed graphics at other places. Music files are very small (compressed midi files), though samples may take some more space. But yeah it's a good idea to keep some free space for other things, I didn't know about the 32 megs limitation. So maybe 24 MB could be a good target size. 8 MB for the original ROM data, 8 MB for the uncompressed MIO0 files, and 8 MB distributed between each decompressed MIO0 to allow flexibility in expanding them. Also remember that space currently occupied by MIO0 files would then become available for other things. tachyon I would help you if I could, but I can't... |
|||
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7696/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
Interesting idea on spacing out the files... Guess it's kinda like a filesystem. You would have some option in the editor specifying how much space to pad to (like sector sizes on a hard drive). (I'm hoping any editors that come out would actually compress the data... no reason not to. It only makes it easier to do manually, but that's not an issue when it's being done automatically.) Anyway I'm pretty sure it's 32MB, or possibly 64. Something like B0000000 - B3FFFFFF. I'd have to check my documents at home. |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
Acmlm's Board - I2 Archive - Rom Hacking - Mario 64 - Amazing Stuff | | | |