 |
| 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: 6504 days Last view: 6504 days |
| ||
After some delays, at last I'm releasing the Super Mario 64 ROM Extender!
Yeah, not only it's not a very original name, and it doesn't exactly convey it's real use. This program will produce a usable decompressed version of the Mario 64 ROM. It means that instead of struggling to fit re-compressed edited data in the ROM. The decompressed data inside the extended ROM can be edited directly, and it can run as is in an emulator. Note: This is not a level editor. You can download the Windows version at: http://rapidshare.de/files/16368233/M64ROMExtender_1.1b.zip.html And the Mac OS X version at this url: http://rapidshare.de/files/16430880/M64ROMExtender1.1bMac.zip.html Here is in geekier terms what it means: (Copy/paste from documentation)
The program is straightforward. Click the Open ROM button, chose a .v64 or .z64 US version of Mario 64. Wait until it's done (a few seconds only) and there you get a 24 megs version of the ROM, with .ext.z64 appended. Ultimately, this ROM format will be used by my Super Mario 64 Level editor that will be released later this year. But until then, it can have many uses. The documentation includes a list of where the MIO0 files are moved/decompressed. Even if you are a newbie, you can make some good use of this program if you know how to use a graphic/tile editor. Tile Molester will open the extended ROM and enable image viewing and editing, if you set it to RGBA 5551. You'll have to find the textures yourself, starting at 0x800000 in the ROM. The first part at 0x800000 also includes the game text. I may provide a text editor soon. I wouldn't mind at all if someone would host the Windows version somewhere, and if anyone wants to make a smaller version of this ROM extender, just PM me, I'll provide the details. Some people in the past argued that it would be best to only move compressed data after the end of the ROM, instead of being de-compressed, to save space... I had a few arguments against it, and at least in appearance it looked like I wanted a decompressed version only because I had problems writing a fast compressor in Director. Now that I found I can call command-line utilities, this point is moot. I still think it's a better idea to standardize around a decompressed format. Why? I found some good reasons... Being able to use standard tools like Tile Molester is one. Also, anyone wanting to write an editor for Mario 64 wouldn't have to implement MIO0 decoding and encoding in their program. Other benefits include being able to generate standard IPS patches (Unless you put some padding, MIO0 files would move around when their compressed size change), and also generating patches without having to re-compress all the MIO0 data beforehand. (Edit: Arghh to many edits!) (edited by VL-Tone on 03-25-06 10:59 PM) (edited by VL-Tone on 03-25-06 11:00 PM) (edited by VL-Tone on 03-25-06 11:00 PM) (edited by VL-Tone on 03-25-06 11:02 PM) (edited by VL-Tone on 03-25-06 11:34 PM) |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
Originally posted by stag910 + It was intentional  Nahh I wrote this before going to bed yesterday (actually this morning in your time zone). And I get nervous with releases... |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
| In a normal Mario 64 ROM, textures, polygons and some object data are stored in 79 data banks/segments that are found all over the ROM. These segments are compressed using a format called MIO0.
The problem is that if you edit the content of these segments, then re-compress the data, you may end up with a bigger segment and it won't fit in its original location. To get around this, these 79 segments have to be moved after the end of the ROM. Also, hundreds of segments pointers have to be changed to match the new positions. For the reasons I stated before I decided to not only move the 79 segments but also decompress them so that the data can be edited directly instead of dealing with compression. There was a few little things that needed to be found to achieve this, like finding how to make the game use uncompressed data. A few details were missing to make the process complete, and it all was resolved in the last few days. This program is not extraordinary in itself, but is a step in the good direction. Good luck trying to do this manually. One of the reasons why the ROM is 24 Megs, is that I decided to put 32k of "FF" between the segments, to allow "future expansion". That makes the decompressed data go just over 8 megs. (actually it may not fit anyway). So that would make the total ROM size just over 16 megs. N64 ROMs need to be a certain size, like 8, 16, 24 or 32 megs. So that means the next size I had to use was 24 megs. And that makes a lot of free space at the end, which is not necessarily bad in itself. Segments could be duplicated there for example. The level editor will eventually make use of this space. Now that I have this new basis, I'll continue my work on the level editor. (edited by VL-Tone on 03-26-06 01:05 AM) |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
| HyperMackerel: Thanks, it's noted. I have to do some little changes to the documentation, one to fix the double 3 typo, and add a thank you notice to you and others for your help and support. I'll send you that tomorrow. I'm working early monday morning, I have to get to bed early so that post will be it for tonight...
As for a table-enabled Hex editor for Mac. I don't have time to get involved in this. But I'll release a cross platform program that can edit the text. HexEdit, the main editor I use on my Mac is open-source, maybe someone could add in code table support. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
I'm sorry that I cannot support Linux 
The program is not complicated though and already relies on some C externals that could be easily compiled for Linux. Anyone with knowledge of C could recreate my program without too much fuss. The thing is, you only have to use this program once. At worse, boot in Windows, convert the ROM then get back to Linux. From that point, keep the extended ROM locked as a backup, and simply make copies when you want to edit. So just to make that clear, you don't have to run the program each time you want an extended ROM. Just duplicate the extended ROM at will. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
| Here is my very old online Shockwave demo of a Metroid Music editor that was never released.
http://pages.infinit.net/voxel/metroidmusiceditor.htm It was based on Acmlm's (himself) findings, though I had to figure out some stuff he didn't. I'll try to dig the old text file and post it here. The demo is a little unstable, buggy and unfinished, and it doesn't actually edit the ROM data, but rather some included copy of the music data (not 100% ethical, but whatever, I'm sure Tanaka doesn't mind... I could ask him, I know how to contact him.). Even in its current state, the editor could still be very useful to you to help you figure out the format. You can hold the ctrl key to get the hex value for each commands. I'm sure you would want me to publish the finished editor so it could help you meet the deadline, but I have other projects that I have to work on, like the SM64 editor... Maybe I'll have time this summer. (edited by VL-Tone on 03-26-06 10:05 PM) |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
Originally posted by proffessor_gad It would help if you was more precise on what exactly doesn't work. Your codes don't work as usual? Does your emu report an error when you try to apply a GS code? It's possible that some codes won't work anymore because some data has been moved. Please provide more details about the problem. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
Originally posted by Raccoon Sam That's cool Raccoon Sam, though I'm not sure that many here know or care about Cocoa (I do, but I'm the minority I guess), hence the lack of replies 
Anyway don't mind this. I started to build a text editor for the Mario 64 text, if you need help building one, just ask. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
| It's possible that the checksum is responsible for the missing GameShark codes.
I know that one of my emulators decided that my older save-states didn't belong to the new extended ROM, because it identifies them by checksum. The checksum only needs to be changed when the extended ROM is created (and the ROM extender takes care of that). Changing the content of MIO0 data and level scripts doesn't affect the checksums. Thanks SoNotNormal! for the kind comment. The extender is a good step toward an editor, but for those who don't know the editor is already fairly advanced, but it need to be rewritten in part. For now it's in a state that would make unusable for anyone of you. (edited by VL-Tone on 04-01-06 06:52 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
| Shiriyu, that was a good suggestion, I thought about naming the editor Teresa Obake for the same reason, but these names are too obscure.
The general consensus seems to be around "ToadsTool" or "Toad's Tool". The final name will probably be "Toad's Tool 64"... RomekG: It would be impossible to fit this uncompressed data in the original 8 megs ROM. It could fit in 16 megs (with only the text and fonts) but I don't see how it would make the IPS patch smaller. The thing is, to patch an original 8 megs ROM, you'd have to produce a patch that contains copyrighted data to be added at the end of the ROM. To avoid that, you have to create a patch that only contains the changes between two already extended ROMs. If you only modify text, the resulting patch will be the same size for a 16 megs or 24 megs. Actually it will be probably small. The "catch" is that this patch can only be applied on an extended ROM. Sure it's far from ideal, but it's about the only way to avoid including copyrighted data in an IPS patch that modifies MIO0 data. There may be another way. If you can fit the re-compressed MIO0 for text and fonts in the original location, you could get way with it, keeping the original 8 megs space. This may or not happen depending on the changes you make since the size of the re-compressed data varies depending on the content. Also, none here has made a perfect re-encoder, the current ones produce bigger data even when not changing anything. (edited by VL-Tone on 04-02-06 11:03 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
| I thought about adding a "re-calculate checksum only" option in my program, I guess I can see one reason to add it now
I'm pretty far ahead in the text editing program (for the compressed data that uses the small font). Here is the symbols (aside from 0-9, A-Z and a-z) of the text table, with some updates. 3E=' 3F=. 50=[Up] 51=[Down] 52=[Left] 53=[Right] 54=[A] 55=[ B] 56=[C] 57=[Z] 58=[R] 6F=, D0=> D1=[the] D2=[you] 9E= 9F=- E1=( E2=)( E3=) E4=<-> E5=& E6=: F2=! F4=? F5=“ F6=” F7=~ F9=$ FA=[star] FB=[x] FC=[•] FD=[emptystar] FF=[End] I almost completed the main text editing engine. You edit text in a normal text field, and the bitmap version using the original is updated at about the same time. Symbols that have no keyboard equivalent are created by typing things like "[star]" or $ for a coin. You'll also be able to create raw hex values if you want, for example by typing {E0} to get the number of stars missing for a particular door. I also included a mechanism that prevent you from adding text when all the original space is used. So to add text somewhere, you have to delete some at another place. The program will take care of re-pointing text elements, so that should give you plenty of flexibility, provided that you delete text first to make free space. I may release a quick online demo so that you can experiment with the basic text editing features. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
The "Special Characters" box was something I already planned, and actually implemented yesterday. Here is a screenshot for the online demo prototype version. The stand-alone version will have a couple more features, like hex editing of dialog parameters, and a save button...
 |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
| Genius? nahhh...
Here you go, an online prototype beta of the "Super Mario 64 Text Wrangler 1.0b" in Shockwave: http://pages.infinit.net/voxel/M64TextEdit.htm Have fun! Oh, and try to figure out by yourselves, I'm too tired to explain it (edited by VL-Tone on 04-04-06 04:54 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
| The [End] is automatically inserted when it's missing, just try to delete it...
I guess what you'd like is that it'd be invisible? This was planned at first, but some bug made it reappear at some point, and I decided to keep it that way. As for [the] and [you], here is my reasoning. I wanted some uniform mechanism to deal with special characters. To compress the [the]'s found in the text, I'd have to scan for every occurrence of "t", then look if the next character is "h", then look for the "e". With the brackets the programs only have to do that if it finds a "[". I'd have to add a special routine just for those two, since I cannot do the same for the others, for example the [A] has to be different than a plain A. The text is re-compressed, then de-compressed each time there's a change in the text field. I do that to be able to calculate the size "live", and to remove unwanted characters. This routine is already slow enough for my tastes, scanning for "the" and "you" wouldn't improve things. Another reason why I use brackets around "the" and "you" is to provide feedback to the user, so that they know that these take only one byte instead of three. Sure, "the" and "you" should always be compressed, but if there was no brackets, you'd have to manually scan the text with your eyes to know where compression saves you space. That was the reasoning behind this... I'm not totally against removing the brackets for these, maybe it could be added as an option. I'll look into it. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
Originally posted by Chainlink1061 Doing that would crash the game when you start this level, unless the Pokey is part of a MIO0 file that is also loaded by Cool Cool Mountain. This type of crash won't be possible in version 1.0b anyway, since you'll be only able to chose enemies and objects that don't crash the game. Version 1.5 will enable you to change which MIO0 files are loaded in each level. The feature by itself is easy to implement, but other things need to be changed when a different MIO0 file is loaded, and you have to make sure that the current objects don't try to load an object in a MIO0 file that is not loaded anymore. So I'll have to build some interface that takes care of this, for example by highlighting those "orphan" objects, and refusing to save until you correct the problem. I'll also have to make sure that the MIO0 files you chose to load don't fill up RAM. All those safe-guards are not that easy to implement, and that's why it'll be in version 1.5. Regarding the text editor, I'll try to release a program by the end of the week-end. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
| That's great, I hope to hear about your translation soon
The text editor program should be released soon, probably before the end of the week. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
| 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.(edited by VL-Tone on 04-08-06 02:34 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
Ok I'm two days late, but here it is: The Super Mario 64 Text Wrangler 1.0b!
Documentation (in html) is included. Here is the main Download link for the Mac and Windows version: http://romhacking.deadbeat-inc.com/?page=utilities&action=search&title=Super%20Mario%2064%20Text%20Wrangler You can also get it on rapidshare (which is more annoying than fast) Download the Windows version: http://rapidshare.de/files/17737499/M64_TextWrangler1.0b.zip.html And of course... the Mac version: http://rapidshare.de/files/17737765/M64_TextWranglerMac1.0b.zip.html The program is fully tested on both platforms, it shouldn't have any major bugs. The downloads are still on Rapidshare, HyperHacker, if you read this: I wouldn't mind if you could host at least the Windows version... Now look how much fun you can have with this program
(edited by VL-Tone on 04-11-06 10:28 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
| Ahhh that was a good siesta....
I won't add automatic returns, at least not now. The preview was supposed to show you where the text could be cut off, but ehm it doesn't work. I estimated the width of the preview pane from the length of the longest line found in dialogs. But I assumed that the text was mono-spaced... I just realized that the text is proportionally-spaced... that means "l" for example doesn't have an 8 pixels width like it does in the font bitmap. So I'll have to calculate the width of each characters before I can implement an adequate preview. Now, as for a menu bar. It's not that I cannot do it, Director can manage menu bars, but I didn't feel the need for it. I used to be an interface freak, wanting standard interface widgets everywhere, but since then I changed my mind a little about it. I find it's not always best to use menus. Instead of having to 1. click the "File" menu 2. move the mouse over Open... 3. click You just have to click on the Open ROM... button. Same thing for Save and Revert. For the update speed option, I guess you'd like it better to open a menu, chose an item, adjust speed value inside a dialog box then click the Ok button? There is only 4 buttons needed for now that could be in a menu. The menu bar is supposed to save screen space, but I would be actually wasting space if I added a menu bar just to contain a File and Bla bla menu, because I could not use the remaining horizontal space and the right of the menus. As for the smallness of the buttons, well I must say I recently got my first LCD screen, and I'm just amazed at the crispness of it, compared to a CRT, even the smallest hand drawn pixel text is readable on my screen. I guess not everyone has an LCD and I should have taken that into account. In real life though, you just have to read these little labels and button once, because by then their use become obvious. They are color-coded so you don't actually have to read each button letter by letter each-time before clicking it. I guess that the only real inconvenient is that the buttons are harder to target with the mouse. That being said, I didn't make the button small just to piss people off. I wanted the interface to fit in a 800x600 screen, and I needed sufficient vertical space for the preview and the symbol palette. I'll find ways around it... Now for the text-to-speech thing, that was more of a joke than anything. But, I won't rule the possibility of including the feature... Listen to this .mp3 file http://pages.infinit.net/voxel/PrincessPeach2006.mp3
(edited by VL-Tone on 04-11-06 07:20 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6504 days Last view: 6504 days |
| ||
Originally posted by DarkSlaya Well thanks for the reply I managed to put it on my isp host though, I had enough space left...
http://pages.infinit.net/voxel/PrincessPeach2006.mp3 I'll attach it anyway... Edit: Here is a better link to download the The Super Mario 64 Text Wrangler: http://romhacking.deadbeat-inc.com/?page=utilities&action=search&title=Super%20Mario%2064%20Text%20Wrangler (edited by VL-Tone on 04-11-06 10:26 PM) |
| Pages: 1 2 3 4 5 6 7 8 |
| Acmlm's Board - I3 Archive - - Posts by VL-Tone |
