N64 Texture Image Extraction
- Thread starter BGNG
- Start date
OP
BGNG
New member
- Thread Starter
- #22
Alright, bit of an update... I've been slacking off a bit, but I have an update nonetheless. My main reason for posting this particular reply is for Anton, who's been wanting an encoder. I've written an encoder, and it works. However, for an unknown reason, it's anyone's guess as to if the resulting file will be greater than or less than the data in a ROM. It compressed Big Blue track textures in F-Zero X more than the data in the ROM, but it made a larger file for the Master Splash Screen than what was in the ROM... And for the life of me, I can't figure out why...
But it makes MIO0 files, Anton. You can perchance use it to make MIO0 data for Super Mario 64 and they may be compressed enough to use. I compiled it as a Windows EXE in case you don't have Visual Basic, and that's in the ZIP file. You'll need the VB6 runtime to use it, but that can be found at Microsoft.com if need be. NOTE: The nature of encoding LZ77 is very CPU-intensive, and takes a long time to process. In a worst-case scenario, the encoder needs to look at every single byte in the file, one-at-a-time, so be patient. I've included a progress indicator, but that's why it takes so long.
In other news... I've modified the decoder program once more, making it even faster. On my computer, it's near-instantaneous when extracting those beloved track textures that caused me to start this topic in the first place. Working with some MipMapping in OpenGL, I bypassed the need to resize the textures, and now I can use them immediately from the ROM image.
The mioDecodeMIO0 and mioMemDecode functions still use the same syntax, so I won't re-post that. If you're interested in using the encoder, though, here's what you might do:
I haven't made a mioEncodeMIO0 function, because I'm not yet satisfied with the performance of mioMemEncode... But without any further ado, here's the ZIP:
But it makes MIO0 files, Anton. You can perchance use it to make MIO0 data for Super Mario 64 and they may be compressed enough to use. I compiled it as a Windows EXE in case you don't have Visual Basic, and that's in the ZIP file. You'll need the VB6 runtime to use it, but that can be found at Microsoft.com if need be. NOTE: The nature of encoding LZ77 is very CPU-intensive, and takes a long time to process. In a worst-case scenario, the encoder needs to look at every single byte in the file, one-at-a-time, so be patient. I've included a progress indicator, but that's why it takes so long.
In other news... I've modified the decoder program once more, making it even faster. On my computer, it's near-instantaneous when extracting those beloved track textures that caused me to start this topic in the first place. Working with some MipMapping in OpenGL, I bypassed the need to resize the textures, and now I can use them immediately from the ROM image.
The mioDecodeMIO0 and mioMemDecode functions still use the same syntax, so I won't re-post that. If you're interested in using the encoder, though, here's what you might do:
Code:
Dim RetVal As Integer, Buffer() As Byte
Open "Something.blah" For Binary Access Read As #1
mioMemEncode 1, Buffer()
Close #1: Open "Something.mio0" For Output As #2
Print #2, StrConv(Buffer(), 64);
Close #2I haven't made a mioEncodeMIO0 function, because I'm not yet satisfied with the performance of mioMemEncode... But without any further ado, here's the ZIP:
Last edited:
OP
BGNG
New member
- Thread Starter
- #23
Woo hoo! Here's the update you all may concievably have been waiting for!
I've completely wrapped up my MIO0 experiences, and this topic can now successfully come to a close.
It turns out I multiplied by 2 a few too many times when writing the encoder. I take that out, and it works like a charm. However, in F-Zero X at least, the encoder magically doesn't compress data quite as much as Nintendo did. It's always just a few bytes larger... Not much to shake a stick at, but enough to throw off an inline offset... I'll have to find out why it does that.
No, there aren't any more speed upgrades for the decoder... I'm pretty sure it's as fast as VB can make it right now.
Here's a list of the prototypes of the codecing functions:
The "Horrible MIO0 Encoder" has been changed to "MIO0 Codec Kit," because I made a fully-functional little tool out of it. I abbreviated it M0CK, which is kinda approperiate. Note: The "Offset" field is 0-based and decimal.
In addition, I reformatted the documentation "MIO0.txt" into a non-typoed, color-parsed "MIO0.html"! So, basically, this post wraps up everything I've been doing since I started the topic.
Contents of the ZIP:
Within the ZIP file attatched to this post, there is a compiled Windows EXE of M0CK (which needs the Microsoft VB6 runtime, availible at their site), the latest version of the modMIO0 Visual Basic module, the newly-formatted MIO0 HTML documentation file, and a ZIP file containing the source code to M0CK.
And below is a picture of M0CK, just to let people see if it's what they want before they download it.
I've completely wrapped up my MIO0 experiences, and this topic can now successfully come to a close.
It turns out I multiplied by 2 a few too many times when writing the encoder. I take that out, and it works like a charm. However, in F-Zero X at least, the encoder magically doesn't compress data quite as much as Nintendo did. It's always just a few bytes larger... Not much to shake a stick at, but enough to throw off an inline offset... I'll have to find out why it does that.
No, there aren't any more speed upgrades for the decoder... I'm pretty sure it's as fast as VB can make it right now.
Here's a list of the prototypes of the codecing functions:
Code:
Function mioDecodeMIO0(InputFile As String, DataOffset, OutputFile As String) As Integer
Function mioEncodeMIO0(InputFile As String, OutputFile As String) As Integer
Function mioGetErrorString(ErrNum) As String
Function mioMemDecode(FileNum, DataOffset, Buffer() As Byte) As Integer
Function mioMemEncode(FNum, Buffer() As Byte) As IntegerThe "Horrible MIO0 Encoder" has been changed to "MIO0 Codec Kit," because I made a fully-functional little tool out of it. I abbreviated it M0CK, which is kinda approperiate. Note: The "Offset" field is 0-based and decimal.
In addition, I reformatted the documentation "MIO0.txt" into a non-typoed, color-parsed "MIO0.html"! So, basically, this post wraps up everything I've been doing since I started the topic.
Contents of the ZIP:
Within the ZIP file attatched to this post, there is a compiled Windows EXE of M0CK (which needs the Microsoft VB6 runtime, availible at their site), the latest version of the modMIO0 Visual Basic module, the newly-formatted MIO0 HTML documentation file, and a ZIP file containing the source code to M0CK.
And below is a picture of M0CK, just to let people see if it's what they want before they download it.
Last edited:
Anton
I like beer
Cool!
Thanks!
I'll try it in couple next days.
Ah, a question. When I'll figure out how all this works - can I put this tool to my site (zelda64rus)? (full credits to you, for sure!)
And I'd be very appreciate for a "readme" file (what games tested/supported, some examples of usage, etc)
Thanks again!
Thanks!
I'll try it in couple next days.
Ah, a question. When I'll figure out how all this works - can I put this tool to my site (zelda64rus)? (full credits to you, for sure!)
And I'd be very appreciate for a "readme" file (what games tested/supported, some examples of usage, etc)
Thanks again!
Anton
I like beer
BGNG - could you please give me your e-mail - Me and one another guy, interested in translation of Mario would like to contact you..
It seems that there is an error in compression code...
Here what I did:
1. Uncopressed Mario rom (not byteswapped) with N64 uncompressor.
2. Found a file with fonts (00108a40)
3. Extract png image with N64GFX
4. Edited it a bit in photoshop
5. Imported edited png image to this file (00108a40)
6. Compressed it with your tool
6. via "RomPut" tool (also tried via copy paste in hex-editor) inserted compressed 00108a40 back into rom.
when loading rom in Ultrahle - the "super mario 64" logo starts to appear - and then the game hangs.
So I think this is a small error in code... I'm not a programmer, but I can't see any other answer..
Any help from you would be appreciated.
Thnx.
It seems that there is an error in compression code...
Here what I did:
1. Uncopressed Mario rom (not byteswapped) with N64 uncompressor.
2. Found a file with fonts (00108a40)
3. Extract png image with N64GFX
4. Edited it a bit in photoshop
5. Imported edited png image to this file (00108a40)
6. Compressed it with your tool
6. via "RomPut" tool (also tried via copy paste in hex-editor) inserted compressed 00108a40 back into rom.
when loading rom in Ultrahle - the "super mario 64" logo starts to appear - and then the game hangs.
So I think this is a small error in code... I'm not a programmer, but I can't see any other answer..
Any help from you would be appreciated.
Thnx.
OP
BGNG
New member
- Thread Starter
- #32
Heh... Aren't I bashful... Um.... Yeah, I forgot all about M0CK, Anton. I'll get right back to work on that. Sorry for keeping you waiting.
Also, I originally sought MIO0 so that I could make an F-Zero X level editor, which is currently in production. I'm still fighting against the mysterious math Nintendo used with the twist vectors, but I did take some screenshots when hacking the course data:
Also, I originally sought MIO0 so that I could make an F-Zero X level editor, which is currently in production. I'm still fighting against the mysterious math Nintendo used with the twist vectors, but I did take some screenshots when hacking the course data:
i have a prob with this.It's regarding packing data back into the rom.i used N64UNC to get all the images decompressed (i dunno why your doesn;t work,it always says error,even if i enter offset) then i open the first one (00108A40) edit it in Tile Molester (just made the coin a diferent colour).Then i use ur proggy to compress it.Use RomPut to add it back to the rom (non byte swapped off course) at the same offset as teh files name (00108A40).Anyways,when i byteswap it(to load up in emu) then load up i get mising models,reandom lock ups,and corrupted/white textures and BSP data all over the place.What am i doing wrong ?
Anton
I like beer
rajkosto said:
This doc (by me) has some info about n64 editing, file sizes, etc
http://www.shedevr.org.ru/zelda64rus/n64translation_how-to_eng.zip
YAY ! MARIO'S HEAD (NUMBER OF LIVES) IS NOW A STAR !
without any errors.What i did is compare the original rom with my rom (with inserted compressed image) and since the new compressed image was SMALLER than the original,there were some left over bits from the original one.So i just hex edited all that remaining bits to 0's till the next MIO0 header.It worked ! Quite tedious but hey hey it worked.BUT what to do if file is bigger ? then i have no idea....U could make your MOCK select the compressed file,uncompress it,then after editing,when u compress it,tries to do it the same size as the original if not then just append 0's at the end.
without any errors.What i did is compare the original rom with my rom (with inserted compressed image) and since the new compressed image was SMALLER than the original,there were some left over bits from the original one.So i just hex edited all that remaining bits to 0's till the next MIO0 header.It worked ! Quite tedious but hey hey it worked.BUT what to do if file is bigger ? then i have no idea....U could make your MOCK select the compressed file,uncompress it,then after editing,when u compress it,tries to do it the same size as the original if not then just append 0's at the end.