Acmlm's Board - I2 Archive - Rom Hacking - Mario 64 - Amazing Stuff
| User | Post |
VL-Tone
Posts: 200/200 |
Originally posted by tachyon
whoa! how good IS your compression?! I did what you said, and the new file was about 7500 kb smaller! anyway, how do you know if the lines ( I'm talking about the rows of bytes at a certain rom address such as the first line of the rom, sorry I don't know the word for that) you find are 0x18 pointers or not?
Look at the format of the 0x18 command earlier in the thread, it always begins with 18 0C. So you should find 18 0C a few bytes before the pointers. As for the compression, it's not even a matter of a good or bad implementation. You should understand that even a single byte change can change the size of the compressed file, and you can't really predict what the compressed size will be until you compress it. Actually, if you change something and the re-compressed file is the same size, then you were lucky...
(Edit: 200 posts! Wow did I really post 200 times?) |
HyperLamer
Posts: 8056/8210 |
It's not my compression, it's Nintendo's. And my implementation actually isn't as good as theirs.  |
tachyon
Posts: 23/23 |
whoa! how good IS your compression?! I did what you said, and the new file was about 7500 kb smaller! anyway, how do you know if the lines ( I'm talking about the rows of bytes at a certain rom address such as the first line of the rom, sorry I don't know the word for that) you find are 0x18 pointers or not? |
VL-Tone
Posts: 199/200 |
Originally posted by tachyon
okay, thanks. I think I'm ready to start hacking now. 
EDIT: ok, I ran into a problem. I changed a byte in one of the decompressed objects and recompressed it, and when I tried to run the ROM on pj64, it said it was not a valid rom. so far so good, I assumed I had simply changed a vital byte and corrupted the rom. but when I changed it back and recompressed the file back in, it gave the same error. this fixes when I delete the rom and start from the backup rom. I assume it's some problem with compression, and has to do with your quote "you need to do a bit of hex-editing with the output before you can stick it back into the ROM". what kind of editing is necessary?
Hmmm, first, are you sure you get a MIO0 file that is the same size? You can't just insert a differently sized MIO0 file back and thus making the ROM a different size, because even if your emu didn't warn you of a wrong size, the game will more than likely crash when run.
So first, verify if you get a MIO0 file of the same size when you recompress. If it's the same size, paste it over the original. If it's smaller, paste it over too, but keep the rest of the data so it doesn't change the ROM size. If it's bigger you'll have to extend the ROM and paste it somewhere else in the extended part.
For both a bigger and smaller MIO0 file, you'll have to find the 0x18 command that loads the file (sometimes there are a few of them) and change the start AND the end pointers so that they match the new MIO0 file. To find these commands, you can usually search for the MIO0 file start address, and almost all the occurrences you should find are part of 0x18 commands.
You can also change the 0x18 in the command to 0x17, and paste the UN-compressed version of the MIO0 file into an extended ROM. Don't forget to change the start and end pointers too. That way you can edit bytes directly into the ROM without having to re-compress and insert the data each time.
In other news, I started fixing my pictures in the first 7 pages of this thread, which were 404. I'll continue the rest in the next few days. |
tachyon
Posts: 22/23 |
okay, thanks. I think I'm ready to start hacking now.
EDIT: ok, I ran into a problem. I changed a byte in one of the decompressed objects and recompressed it, and when I tried to run the ROM on pj64, it said it was not a valid rom. so far so good, I assumed I had simply changed a vital byte and corrupted the rom. but when I changed it back and recompressed the file back in, it gave the same error. this fixes when I delete the rom and start from the backup rom. I assume it's some problem with compression, and has to do with your quote "you need to do a bit of hex-editing with the output before you can stick it back into the ROM". what kind of editing is necessary? |
HyperLamer
Posts: 7990/8210 |
You could open them in a hex editor, sure. Depends what you want to do. As for re-compression, the only semi-working tool I know of is mine, which is near the beginning of the thread; you need to do a bit of hex-editing with the output before you can stick it back into the ROM, but it should do the trick. |
tachyon
Posts: 21/23 |
then what do I use to open them, a hex editor? and how do I recompress it? |
HyperLamer
Posts: 7979/8210 |
......
It's not supposed to change the ROM. It's supposed to put a bunch of files named as hex addresses in the folder with it. Those are the decompressed MIO0 files. |
tachyon
Posts: 20/23 |
nope, I tried it in all three byte orders, it turns up 6 (file was not valid mio0 data). maybe I should use n64unc. why does it put a bunch of files named as hex addresses in my downloads and not change the rom? or maybe it did and I didn't notice. a decompressed rom won't run on an emulator, will it? |
VL-Tone
Posts: 198/200 |
Originally posted by tachyon
that's the order it's in. does it have to have a .mio0 ending or something?
I used .Z64 when I used the program (in DOS), or maybe it was .n64? Anyway it's the ROM you have to open, the program will search for MIO0 files inside the ROM for you and extract all of them in one sweep.
BGNG: That Java 3d API looks really neat, I'll look more into that...
I did some work on my editor lately, I'm currenting experimenting a new interface layout. Please don't mind the gaps in the interface, they'll be filled by future features, and I'm currently shifting things around.
Just to be sure it's clear enough, this is not a release, it's a peek into what I'm experimenting with the editor.
(Dang this time I used photobucket!)
If you click "Load Level" you will be presented with a list of every level in the game and its sub areas that you can click to load a particular level area. For now there are a few areas that won't load.
The white text list in the upper left corner is to select what kind of objects you want to edit in the game. If you select Objects (0x24), the editor will behave much like the old version, but with some new things like the list of object you find just below the edit mode list (small green text).
By clicking on lines on this list you can select an object to be edited with the interface at the bottom. The same applies to the other edit modes. The 0x39 objects, which I call "Macro Objects" because they can spawn multiple objects, like 3 Goombas at the same time for example, or coin formations, are called by a single 0x39 object found in an area, which reads a list found in the main level MIO0 file. They are represented for now in the 3d view as blue diamonds, and the 0x24 objects are still tri-color cubes. When in Macro Object editing mode, a different kind of list is presented with a description based on the list of objects made earlier in this thread. I'm also implementing an editor for the music values for each area (easy), and warp values (not so easy).
Many other types of object editors could be added to the list, for 0x22 commands or 0x18 commands for example. Maybe I could put an "expert mode" where those would appear.
I have other kind of features in mind, like camera position bookmarking, where you can save camera positions to go back later. I added a feature where the camera will automatically position itself to have a good view near an object that you select.
Ok that's it for now, I gotta sleep sometimes , and I work more early tomorrow. |
tachyon
Posts: 19/23 |
that's the order it's in. does it have to have a .mio0 ending or something? |
stag019
Posts: 299/299 |
Originally posted by tachyon
does it need to be a certain byte order?
Yeah, it needs to be ABCD.
I use this Byteswapper. |
tachyon
Posts: 18/23 |
thanks!  but if n64unc only extracts objects, does that mean I can use only it and be able to decompress everything in the game so I can edit it?
EDIT: right, downloaded it anyway. then it put a bunch of files in my downloads and I couldn't be bothered to find out why, so I tried VL-tone's decompressor again. it says the file isn't a mio0 file. it's a sm64 ROM, will that work? does it need to be a certain byte order? |
BGNG
Posts: 275/276 |
I've not experiemented with 3D in Java firsthand, but I will mention (for future reference) that there is an official Java 3D API by Sun that looks to be quite the graphical powerhouse and is suitable for animation. The development kit for it appears to be an extension of the JDK, but it's apparent that the graphics it produces are self-contained and necessarily independant from any specific hardware configurations. |
VL-Tone
Posts: 197/200 |
Originally posted by tachyon
sorry to ask for another utility, but where can I get n64unc? I googled it and checked the dextrose site, but got nothing.
Don't be sorry, it's hard to find
There you go, here is the address:
http://www.dextrose.com/index.php?s=3&m=8&f=270#f270 |
tachyon
Posts: 17/23 |
sorry to ask for another utility, but where can I get n64unc? I googled it and checked the dextrose site, but got nothing. |
VL-Tone
Posts: 194/200 |
Originally posted by BGNG
The #1 solution for cross-platform for years has been Java. Contrary to popular belief, Java code actually is fast, as the virtual machines are geared towards the processors of the machines they run on. While those .class files are compiled to a special, processor-less "byte code," Sun structured that byte code in such a way that practically any processor out there could run it well.
One of the more popular tools in the ROM hacking scene, Tile Molester, is programmed in Java and works like a charm.
One of the plusses to Java is that the programs can be run either from the shell or embedded in a web page. It supports 3D graphics (I think OpenGL) and does a good job with file I/O. The chaps over at Equinox have been making demos for Java for quite a while, and some of their stuff is downright impressive.
Definitely look into that one if you're looking for something versatile. Java takes some getting used to, but it's very flexible.
Yeah actually Tile Molester is one of the few ROM hacking tool that can run "natively" on the Mac OS, thanks Snowbro! (Yeah I like to thank him, he started it all!  )
I had Java in mind before, but got under the impression that it was not very good at 3d graphics. You seem to say that it's not the case, and I believe you, but I'm pretty sure that Java cannot drive OpenGL inside a web browser without downloading something extra. Anyway I don't mind, it's not a requirement for me that it works online, even if I did publish online demos of editors in the past, like the StarFox editor, which was not exactly "good" since it had to contain part of the ROM data.
There was one version of Director in the past that supported "exporting" to Java directly, but it only made sense for small programs, and many things wouldn't be translatable. Some helper would tell you which lines to change, but for anything big it became too complicated. The feature was latter dropped. The current version of Director does supports Java syntax for scripting, which will probably help me make the transition, even if I currently mostly use the Director/Lingo syntax which is not so far from Java anyway.
So Java it will be I keep getting recommendations for AJAX, so I guess I'll give it a try. I don't know why I got so inclined to go to C++, maybe because I needed raw power. But Java is also on the list of languages I want to learn, and I kinda forgot how fast it was for disk I/O.
Santa Claus: I have a picture of Miyamoto San himself having a Mac at his desk, but it's an old photo so it doesn't mean he still use them (though I would personally assume so). Nintendo does use Windows for part of their development. Intelligent Systems http://intsys.co.jp which is a spin-off of Nintendo's R&D1 (or are they R&D1?), is responsible for such games as Metroid Fusion, the (Advanced) Wars series, Fire Emblem, Panel de Pon (Tetris attack) and others, is also producing some of the Nintendo development tools for the n64, GB(A), DS and Gamecube. If you look on their page you can find that many of these tools also exists for the Mac OS, which implies that at least Intelligent Systems uses some Macs to make Nintendo games.
I know it's a drop in the ocean of Windows using developers, but I just wanted to dispel the myth that only dumb people buy and use Macs. Many people that you admire use them, and not necessarily just because they look "cool".
But let's move on, I'm starting to learn Java, which is by definition cross-platform, and I expect to learn it pretty quickly considering my years of experience at programming in a not so different language. So I guess I'll try to port my Super Mario 64 editor to Java piece by piece (first the level decoding routine, then the 3d part). |
BGNG
Posts: 274/276 |
The #1 solution for cross-platform for years has been Java. Contrary to popular belief, Java code actually is fast, as the virtual machines are geared towards the processors of the machines they run on. While those .class files are compiled to a special, processor-less "byte code," Sun structured that byte code in such a way that practically any processor out there could run it well.
One of the more popular tools in the ROM hacking scene, Tile Molester, is programmed in Java and works like a charm.
One of the plusses to Java is that the programs can be run either from the shell or embedded in a web page. It supports 3D graphics (I think OpenGL) and does a good job with file I/O. The chaps over at Equinox have been making demos for Java for quite a while, and some of their stuff is downright impressive.
Definitely look into that one if you're looking for something versatile. Java takes some getting used to, but it's very flexible. |
HyperLamer
Posts: 7904/8210 |
It'd be funny for Nintendo to use a Microsoft OS, now wouldn't it?  |
VL-Tone
Posts: 193/200 |
Originally posted by BGNG
Our good buddies over at FreeBASIC have made a VERY handy and powerful BASIC compiler that goes for Windows, DOS and Linux. They've got NeHe's OpenGL tutorials all ported to BASIC so you would be able to use this to do your dirty work. It also has native support for such things as multithreading and inline Assembly.
Fancy thing about FreeBASIC is that the source code for it is in FreeBASIC. Now THAT'S what I call product effectiveness. (-:
Ok, I guess I should have been clearer on what I meant by "not Windows specific". Yes I meant multi-platform, but I was under impression that it was a well known fact here that I'm not working on Windows or DOS, nor Linux, because of my rant in the Hardware/Software forum. But I guess that you didn't know. My native platform is ehm *cough* Mac OS X *cough*, I have friends who use Windows so I can test stuff there, and I can run DOS in an emulator (I could run Windows too ,albeit a little slowly, but I lost my Win 98 boot disk image).
Macromedia Director/Shockwave can produce programs for both platforms, so it didn't really matter until I realized that the disk I/O routines were too slow to move large chunks of data, and that my Shockwave MIO0 decompressor is too slow to be useable (though I guess it could be optimized). That's one of the reason I was not too keen to mention it before that point, because it didn't really matter and I didn't want to be labeled with pre-concieved ideas. OS X is a FreeBSD UNIX variant, and most Linux/UNIX programs can be recompiled without much change. I recently ported the YaZ0 decompressor with only one small change. By looking at it, I could probably port the MIO0 compressor and decompressor too. But anyway it doesn't matter much to you I guess.
All that to say that FreeBASIC looks like a good solution, and the fact the source is written in FreeBASIC is really neat, but it's not natively supported on my platform even though it would be probably easy for them to port it. I'll try to find another solution, and many exists, to support all three platforms. Don't bother looking for me if you don't feel like it, and I suspect you won't.
I assume that a somewhat large percentage of people on this board have negative views of Mac OS X. I can understand that, for anyone interested in video game ROM hacking, because while OS X has zero viruses, it also has just about zero ROM hacking programs, aside from a few emulators, IPS patchers, hex editors, UNIX ports, a GBA devkit and my own level editors.
The Windows hacking tools and editors can be run in emulation (Virtual PC), and next year when I buy an intel equipped Mac, it will emulate them at 80%-90% of the native speed using the Mac port of WINE. But anyway for people doing ROM hacking on Windows (probably all of you ) the Mac is simply not a viable platform for them and I don't see how I could argue otherwise. Still, this is the platform I chose and like, and I happen to like to hack ROMs and reverse engineer them with tools I build myself, I don't mind the limitations and lack of tools, I learned to appreciate the challenge of it. But what should I do? Should I stop contributing to this thread because I don't use the best and latest tools to reverse-engineer Super Mario 64? Should I put a warning in my sig? If so, I guess it's another sign that the ROM hacking community is in a sad state...
So, now you know. Sorry for the off-topicness, though it's relevant in a way. Don't worry I don't have anything to add.
Ok, I'll add just a little useless "fun" fact. Try to guess what the president of Nintendo Satoru Iwata uses as a personal computer, see the answer in the link: http://pages.infinit.net/voxel/IwataTGS2005.jpg |
| This is a long thread. Click here to view it. |
|
hukka
