 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by VL-Tone |
| Pages: 1 2 3 4 5 6 7 8 |
| User | Post | ||
VL-Tone Paratroopa                   Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
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. (edited by VL-Tone on 03-13-06 10:52 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by proffessor_gad 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 Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| 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) 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 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. (edited by VL-Tone on 03-14-06 10:57 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| 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 Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by BGNG 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 Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| 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 Paratroopa  Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| 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!(edited by VL-Tone on 03-17-06 06:45 PM) |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by Hosma293 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. (edited by VL-Tone on 03-20-06 06:14 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| 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. (edited by VL-Tone on 03-21-06 01:37 AM) (edited by VL-Tone on 03-21-06 01:40 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by Raccoon Sam 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.(edited by VL-Tone on 03-21-06 04:21 PM) (edited by VL-Tone on 03-21-06 05:48 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Here is an old doc I made describing the item data format:
http://pages.infinit.net/voxel/MetroidItemData.txt
(edited by VL-Tone on 03-21-06 09:08 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| 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. 
 (edited by VL-Tone on 03-21-06 11:58 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by BGNG 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:
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? (edited by VL-Tone on 03-22-06 04:58 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| 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 Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| 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 Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| 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. (edited by VL-Tone on 03-25-06 12:32 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by BGNG 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! (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) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| 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. (edited by VL-Tone on 03-25-06 08:18 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by AlexAR That's a quick but very interesting question, here is the very long and boring answer. This is some theory I made up sometime ago, some of it may actually make sense: The Japanese version of Metroid was on the Famicom Disk System. Originally Metroid was set to be a game that would utilize the FDS to its maximum and aimed at improving the slowing down sales of the not that popular disk system in its later days. With 64k on each side it provided a whopping 128k of space that could be used to build a huge world. The writable aspect meant that they could store many details of a game progress, like the status of every red doors in the game. But, somewhere along the project, Nintendo realized that RAM prices had dropped to the point they could begin to sell 128k cartridges. And just about the same time, they developed a chip, the MMC that allowed the NES to use more than 16k of PRG data in a cart. So with that in mind, the team/management decided to build the game both for the Japanese and US market. The funny thing is that they ended up trying to sell the Japanese version as a way to sell more FDS, and the Japanese public didn't appreciate that, especially those that found about the US release on a cart. To use 128k on the FDS, the game would require to flip the disk in the middle of the game to access each 64k side, so the world had to be split in two and swapping had to be minimal. But with the MMC chip, they had another problem, the chips enables switching between 16k chips, but doing this would result in some glitching and flickering. The also ended up fitting all FDS writable data in a password. The FDS version didn't need a password and had better music and sound fx, but that's about it. The 128k NES cart contained 8x16k chips. They decided to use 3 for the main program and 5 to build separate areas with each their tiles, structures, rooms layouts and music. So Brinstar, Norfair, Kraid, Ridley and Tourian are each contained in one chip on the motherboard of the game. The elevator was chosen as a way to switch areas without to much flicker and problems. On the FDS, there was 3 areas on one side, and 2 (and probably 3, one being repeated) areas on the other side. One could say that Samus travels from chip to chip on the cart? And to go further in this crazy theory, maybe motherboard+cpu=motherbrain? As far as I know, the name of the areas and enemies were translated by someone in the Japanese team, not by Nintendo of America. Just read the story in the title screen! Some of the names seems to be clever play on words, something Japanese like to do more than the NOA early translation team. It was stated that the Metroid team was at least in part influenced by the movie Alien, with Ridley Scott being the Director. If you rearrange the letters from Metroid, you can get ROM EDIT. Since it's the name for the ROM EDITion of the japanese game originally destined only for a disk, and that the game was (almost) secretly constructed with that in mind, so they could also release the NES version, I think this coincidence fits nicely. I suspect that Hirokazu "Hip" Tanaka is behind these names
So, that's what's making elevators so special in Metroid. The same concept was used in Metroid Prime, to reduce disk access, that's why some GC froze in the elevators, since a defective drive was more likely to fail at that point. Some of what I wrote is not all factual, and some is made from assumptions. But many facts could back up at least some parts of this theory. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| As long as this thread is not abandoned, I'm fine with doing another thread. Just keep posting things here about editing the actual content of MIO0 files. The other thread will be for feedback about this particular program and will be abandoned when there's nothing to add which is probably pretty soon, since it's a simple program after all. |
| Pages: 1 2 3 4 5 6 7 8 |
| Acmlm's Board - I3 Archive - - Posts by VL-Tone |
) of your editor?