(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album
05-14-24 08:50 PM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - General Super Mario 64 hacking / TT64 Progress thread New poll | | Thread closed
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 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71Add to favorites | Next newer thread | Next older thread
User Post
Guy Perfect









Since: 11-18-05

Last post: 6297 days
Last view: 6295 days
Posted on 02-25-06 08:22 PM Link
Attack of the Pet Peeve!

ASCII was an old standard that was used in DOS, but was replaced with the ANSI character set once Windows came about. The first 128 characters are the same in both standards, which is probably what confuses many people. But the second half of ASCII is full of table-based formatting characters, whereas ANSI has international text characters.

Windows 95 and up are using Unicode, which isn't likely to be depreciated any time soon. Ordinary text files (*.txt) used on most platforms today are understood to be ANSI, not ASCII.



Anyhow, all of the uncompressed text in Super Mario 64 is ANSI. You can see the text for things like the credits and level select menu, but it would take some additional searching to find text stashed away in those MIO0 files. Bowser's and Yoshi's dialogs don't seem to be out in the open when searching through the ROM.
Deleted User
Banned


 





Since: 05-08-06

Last post: None
Last view: 6295 days
Posted on 02-25-06 08:27 PM Link
Originally posted by HyperMackerel
Isn't the text just ASCII?
You may be thinking on Mario Kart 64. Speaking of Mario Kart 64, it also uses MIO0 compression, and is probably very similiar to Super Mario 64, yet I have heard nothing about it. VL-Tone, if you get the change, look around in there.

Attachments

sm64.txt (551b) - views: 237
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6295 days
Last view: 6295 days
Posted on 02-25-06 08:40 PM Link
I've looked before, most of the text is standard ANSI/ASCII* compressed in the MIO0 files. The phrase "BEWARE OF CHAINOMP" in one of the files' compressed area is a dead giveaway.

*Technically it's neither. I think the game just crashes if you use characters that high.
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6485 days
Last view: 6485 days
Posted on 02-26-06 04:24 AM Link
stag910 + Welcome back! Thanks for the table I'll include a text editing feature in the first release thanks to you! Though I guess I could have found it myself by looking at the font textures

I've look into Mario Kart 64 and yes it uses the same texture and polygon format.

MK64 track editor anyone? Nahhh Too bad I can't clone myself!. A thing in the "more feasible" range would be to import MK64 models into Mario 64! It all depends on how similar the format is. That would probably be more easy to pull off than an import/export to a 3d program.

Those other n64 games with a green elf with a sword... I forgot the name... well these also use much the same polygon format I wish I could work on that too, but I suspect someone else will do it.

Not all games use this format though, GoldenEye uses a different one for example, like most of the Rare games.

------------------------------------------------------------------------------------------

BGNG wrote this:ASCII was an old standard that was used in DOS, but was replaced with the ANSI character set once Windows came about. The first 128 characters are the same in both standards, which is probably what confuses many people.

I guess you got confused too... ASCII is 7-bits, 128 characters. A is decimal 65. But DOS didn't use Standard 7-bit ASCII.

DOS uses a proprietary variation of ASCII called OEM that descends from the original IBM PC, and uses 8-bits. The lower 128 are almost the same as ASCII, and the upper characters are used for a few accented characters, some graphics etc. At best it could be called Extended ASCII http://en.wikipedia.org/wiki/Extended_ASCII Since the term seems to encompass every 8-bit extension of ASCII used on various platforms.

But Unicode since Windows 95? hmmm... this is from a page on microsoft.com:

The problem was the difficulty in supporting a Unicode application on Windows 95/98/ME; developers had to support those customers as well. Because those platforms do not have the native Unicode support provided by the NT family of operating systems, it was just easier to write non-Unicode applications.

However, times have changed....

Starting with the Windows XP RC1 version of the Platform SDK, the Microsoft Layer for Unicode on Windows 95/98/ME Systems (MSLU for short) can help you solve this important challenge. This component provides a layer over the Win32 API on Windows 95/98/ME so that you can write a single Unicode version of your application and have it run properly on all platforms.


Cool, Windows 95/98/ME got a "real" unicode layer when Windows XP RC1 was released...

From all I've read on Windows related sites, the support for unicode before Windows 2000/XP was mediocre at best. Microsoft now admits it...

The vast majority of developers stuck to ANSI until XP for these reasons, and many still do.

ANSI is not a character set by itself, its more of a switchable dynamic character set, a Windows re-implementation of a hack they used in DOS to "switch code pages", which is a way to have multiple and extended character sets. On a Windows 95/98/ME English system ANSI uses code page 1252 by default, and this is probably what you always used yourself on these OSes. http://en.wikipedia.org/wiki/Code_page_1252

Page 1252 contains an 8-bit character set that was "inspired" by ISO-8859-1 aka Latin-1 found on the Web. http://en.wikipedia.org/wiki/ISO-8859-1 It's also an extension of ASCII, with the first 128 chars being about the same, A is still 65.

There are differences between Latin-1 and Windows Page 1252 but they cannot be seen in the credits and level select. It could be standard ASCII for all we know since it uses only the lower 128 characters. ANSI Page 1252 is a Windows thing, as far as I know, other platforms don't use it natively except for translation purposes.

Nintendo is not known to integrate MS "standards", and they were working on SGI platforms that likely used ISO-8859-1. Please find me text in any in-house Nintendo game that is without a doubt Windows ANSI...

So to summarize, the Credits and Level select text in Mario 64 is ASCII for all that matters since this text doesn't even use any of the upper 128 characters. There is no way to prove in one way or the other that its based on any particular ANSI code page.


(edited by VL-Tone on 02-26-06 03:26 AM)
Raccoon Sam

Boomerang Brother
Custom Title








Since: 11-20-05
From: Correct

Last post: 6295 days
Last view: 6294 days
Posted on 02-26-06 06:09 AM Link
Whoa..
Thanks for the info.

And about the Mario Kart 64 thing, don't forget that the Mario Kart 64 drivers aren't models.
They're sprites.
Guy Perfect









Since: 11-18-05

Last post: 6297 days
Last view: 6295 days
Posted on 02-26-06 02:05 PM Link
DOS used a variant of ASCII, Code Page 437, which is what most people in this community will encounter. It's not "true-bred" ASCII, as it were, but it was the "computer standard" ever since IBM got ahold of it. What people have been working with since Windows, however, is specifically ANSI.

Windows 4 (the 9x/ME family) supports Unicode through software, as it's more of a DOS front-end that acts like NT. Since Win95 came after WinNT, it had many workarounds to provide the same functionality as NT, but managed things in a different manner to do so. Visual Basic 4 (my favorite version) 32-bit, for example, which was first released in 1995, would always store String variables as wide characters, which were directly compatible with the Unicode structure of NT and the workarounds that Windows 4 provided.

Installable Language Packs could extend the functionality of the kernel to provide more international characters for use in Windows, Internet Explorer, etc. Among them is the monstrosity that is the font Arial Unicode MS, which contains every Unicode character and measures up to a 22.1MB font file. It can be used directly from any Win32 application, as all 32-bit Windows platforms provide functionality for wide characters. The difference is that Windows 4 doesn't support verbatim "unicode strings."



Regardless, using the texture-mapping font table described a few posts ago, the text in question is neither ANSI nor ASCII. It's a proprietary character set that depends on the contents of the font textures.
proffessor_gad

Red Koopa








Since: 01-27-06
From: Mars

Last post: 6325 days
Last view: 6325 days
Posted on 02-26-06 11:35 PM Link
LOL!


Funny, but strange. It was supposed to be- "BEWARE OF PROFFESSOR!" Oh well. Strangely enough, "PRESS START" and the big list of credits are all in regular text. Modifying them makes the game crash in project 64, but in 1964 it works perfectly! Perhaps we could add our names to the ending credit screen?



We could also change "PRESS START" into "PRESS ENTER".

I think the reason for this text or code issue is because "PRESS START" and the credits are in mario-type font, but other text is not. "Super mario 64" was a model, not text!

By the way, here are some other funny screenshots I got-

He looks like a baby!

??????

I got him to sleep and fly underwater to! Just goes to show what you can do with a little bit of gameshark.
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6295 days
Last view: 6295 days
Posted on 02-26-06 11:48 PM Link
I'm actually working on Mario Kart 64 right now. The purpose of this was to scan save states from all 20 levels for the contents of every compressed file in the ROM, in order to generate a list of which files are loaded in which levels. This should help give me a general idea of which files contain what. Since two of the participants never actually sent back any results (wtf guys) I've got a P233 I threw together chewing on 3 of the remaining save states, and I'll have this computer tackle the remaining 4 tonight (and while I'm at school if need be). Unfortunately I didn't add any sort of indication of how much time is remaining*, so I don't know how long the other box is going to take, but it's been scanning for about 3 or 4 days now, so hopefully much longer. (This box, being about 7.2 times faster, would have taken 4.5 days to scan all 20 files. As only 3 are being scanned, if I did the calculations right, it should take about 1 or 2 more days.)

Anyway once that's done I'll have a nice list of what files are loaded in each level, so then I can try to filter out any that most likely aren't what I'm looking for. I'll also be checking to see if any patterns in the non-compressed areas are similar to Mario 64's level format.

*I would have, but I wrote the program to run in pure DOS so I could gain some speed by not having to load the Windows environment, giving all available resources to the program. I have little DOS programming experience and thus didn't know of any good way to time something (dunno how to get a millisecond count). Though it turns out programs compiled with MinGW won't run in pure DOS anyway, so it's a moot point.
proffessor_gad

Red Koopa








Since: 01-27-06
From: Mars

Last post: 6325 days
Last view: 6325 days
Posted on 02-27-06 12:20 AM Link
I am having to much fun!
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6485 days
Last view: 6485 days
Posted on 02-27-06 01:54 AM Link
The DOS code page 437 is not more (or less) a variant of ASCII than ANSI code page 1252, ISO-8859 or the old Mac Roman for that matter. All four use much the same first 128 characters with a few differences in control characters. Incidentally, Unicode too...

As for what you call "ANSI":

This is from a Microsoft pdf at http://download.microsoft.com/download/5/6/8/56803da0-e4a0-4796-a62c-ca920b73bb17/21-Unicode_WinXP.pdf

The term "ANSI" as used to signify Windows code pages is a historical reference, but is nowadays a misnomer that continues to persist in the Windows community. The source of this comes from the fact that the Windows code page 1252 was originally based on an ANSI draft, which became ISO Standard 8859-1. However, in adding code points to the range reserved for control codes in the ISO standard, the Windows code page 1252 and subsequent Windows code pages originally based on the ISO 8859-x series deviated from ISO. To this day, it is not uncommon to have the development community, both within and outside of Microsoft, confuse the 8859-1 code page with Windows 1252, as well as see "ANSI" or "A" used to signify Windows code page support.

Talk about confusion...

I guess I got it wrong too about ANSI, its neither a character set nor code page support.

You wrote, in bold: "as all 32-bit Windows platforms provide functionality for wide characters."

My point was that Windows 4 didn't natively support Unicode, as in "the whole enchilada". How do you explain my other quote from the MS site admitting that real Unicode developer support was almost non-existent in Win 4 and was hard to develop for? As far as I know Unicode =! Wide characters. Sure you could view web pages and unicode text, but making an application that used it effectively to create and edit documents was a seemingly complicated process.

Anyway if we are only talking about files that most people in this community encounter, then your reference to Unicode only added more confusion, as these people don't use it.

DOS used an extension of ASCII, and so does the English version Windows even today with the "standard" code page 1252. So your whole point falls flat (sorry, I don't like to say that). Everything you could say to explain your use of the term "ASCII" to describe the standard DOS character set can be used to say that all English versions of Windows used ASCII as a standard.

In other words, if you say DOS used ASCII, then by inference what you called "ANSI" is ASCII too.

----------------------------------------------------------------------------

Ok I'm wasting too much time debating about this...

Proffessor Gad, nice pictures but I don't think they deserve to be here. There are tons of things that can be done with a gameshark, but this is not the point of this thread (I guess that discussing text encoding is neither but text takes less space). But hey don't stop having fun because of this

----------------------------------------------------------------------------
HyperMackerel

This is great news! I thought it was Zelda OOT: Master's Quest for some reason... (OOT has 1400 YaZ0 files, so I figured out that maybe OOT MQ had around 2000)

I'll continue this reply tomorrow since I work early this Monday.


(edited by VL-Tone on 02-27-06 01:00 AM)
proffessor_gad

Red Koopa








Since: 01-27-06
From: Mars

Last post: 6325 days
Last view: 6325 days
Posted on 02-27-06 08:34 PM Link
Vl-tone said-

Ok I'm wasting too much time debating about this...

Proffessor Gad, nice pictures but I don't think they deserve to be here. There are tons of things that can be done with a gameshark, but this is not the point of this thread (I guess that discussing text encoding is neither but text takes less space). But hey don't stop having fun because of this




(edited by proffessor_gad on 02-28-06 04:42 PM)
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6485 days
Last view: 6485 days
Posted on 02-28-06 09:18 PM Link
Proffessor Gad:
I don't know how behavior code works, it's customized for each objects, while what you are asking would be technically possible, I don't know how to do it, and for now I don't intend to look for the answer any time soon.

Update on my progress:

Almost all the dialog text is contained in MIO0 file 00108A40. There are two (or three?) lists of pointers for the text. One is at FFC8 inside the same MIO0 file, and each of the item in the list is 16 bytes.
Here is the first item, which points to the first message you get in Level 1.

[00 00 00 01] [06 00 00 1E] [00 C8 00 00] [02 00 7D 34]

The last 4 bytes are the segment number and offset of the text in the segment (in this case the segment number is always 0x02, which is the one containing the data from this MIO0 file decompressed from 00108A40 in the ROM). The first 12 bytes are parameters that presumably set the kind of dialog box that appears, and which sound it plays. The first 4 bytes are almost always [00 00 00 01] and [00 C8 00 00] seems to be used 95% of the time.

There are 170 in this list, and if I'm not mistaken, you can choose anyone of those using one parameter byte used with the behavior for signs, pink bob-ombs and other talking fellows.

At 10A68 (in the MIO0 file) there is another list of 170 items, this time each item is only a 4 byte segment-offset pointer, there are no parameters attached so maybe they are more generic dialogs.

Then at 10F68 a smaller 4 bytes pointer list can be found, this time 26 of them.

---------------------------------------------------------------------------

So I started to make an editor for text dialog when I remembered that I couldn't edit this particular MIO0 in my extended ROM.

Currently, I edit an extended 16 MB ROM that has all MIO0 files decompressed and appended at the end of the original ROM. All 0x18 commands are changed to 0x17 so the game loads raw uncompressed data instead of decompressing a MIO0. Then, the start and end pointers are changed to point at the decompressed data in the extended portion of the ROM.

There are two problems with this approach:

1. The MIO0 file 108A40 is a special case, it's decompressed and loaded with a custom command that cannot be easily changed to a 0x17 command. (I know how to re-point it though, thanks to Cellar Dweller)

2. The command 0x1A which is used about once per level loads a compressed texture segment like the 0x18 could do, but when I try to re-point it to decompressed data and changing the command from 0x1A to 0x17, the game crashes. So some texture would not be editable.

I could bring the MIO0 decoder to a good speed thanks to faster disk access, but the re-compression is still a problem... I cannot find a way to build a fast enough compressor in Director. Scanning the 4096 last read bytes for matches for each bytes read is taking too much time. I tried to use the offset command (which finds a string position) to get a good speed, but it's case-insensitive so it's useless to deal with byte data. There are commands to find position of properties or items in lists, but not multiple items (bytes) at the same time.

Maybe there is something I don't know about searching lists in Lingo that could give acceptable speed. Yes I know It's pretty bad because after all MIO0 compression is simple...

Whatever... I don't think that keeping the data decompressed is a bad thing in itself.

So what can I do to get around the two problems mentioned earlier? I found the answer yesterday, and I wonder why I didn't think of it at the beginning of all this.

It's simple, MIO0 files don't have to contain compressed data! You can make a perfectly valid MIO0 file that doesn't contain anything compressed. Just make a valid header, building a data map table that has all bits set to 1, the raw uncompressed data follows the header, unmodified. This way I'll be able to save all MIO0 files in 1 second instead of much more.

This way the game will work as intended, loading valid MIO0 headers, but the data inside the MIO0 files will be easily editable without having to compress-decompress.

If for you BGNG and Hyper, MIO0 compression and decompression is quick and trivial, then go for it, re-compress everything after editing, but this is not the approach I'll take, I don't have much choice. As a bonus, I'll avoid having to deal with MIO0 files that change size after re-compression.


(edited by VL-Tone on 02-28-06 08:19 PM)
(edited by VL-Tone on 03-22-06 04:41 AM)
Guy Perfect









Since: 11-18-05

Last post: 6297 days
Last view: 6295 days
Posted on 02-28-06 10:42 PM Link
If possible, I recommend using byte arrays instead of strings for file data. I think you said before that you can only load chunks of data from a file into a String (as opposed to one byte at a time), but it would make sense if there was some kind of conversion function at your disposal that will let you use the loaded string as though it were an array of bytes.

Using the data as raw numbers will greatly increase performance as opposed to converting each character into its corresponding number every time you use it.

MIO0 decoding is indeed fast and simple with the languages that I use. I don't have much other advice for you as far as making yours faster is concerned.



As for compression, though, HyperHacker and I have both encountered an anomaly when attempting to code MIO0 compressors. For an unknown reason (which I plan to investigate in the future), reading through the unencoded file linearly and simply checking with the previous 4096 bytes seems to yield larger files than the ones we decompressed from various ROMs. Apparently, a linear approach is not optimal, but neither of us have much of a clue as to why or how.

Fortunately, none of the data in F-Zero X that will be edited needs to be compressed, as MIO0 is only used for graphical data in that game. I know many people point their noses in the air in regards to editing graphics, but no graphics editing will be provided in my editor.


(edited by BGNG on 02-28-06 09:43 PM)
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6485 days
Last view: 6485 days
Posted on 03-01-06 01:45 AM Link
I'm fully aware that working with byte arrays is faster, but the last time I checked that BinaryIO Xtra was the best option, but it was limited.

So I checked again, and it seems that I missed out a better solution. It's called BuddyFile Xtra. The license is cheaper and from what I read I don't need it since the editor won't be a commercial product. It doesn't have a nag dialog, and best of all it can directly read data and return an integer list... That will solve most of the problems I had.

Director doesn't support byte arrays as is. Variable lists used in Director are much like 1D arrays, but they can contain a variety of data types.

listvar=[0,1,2,3,"abc",#symbolA,65537,-10,[1,2,3]]

As you can see, a list can contain other lists so you can build multi-dimensional arrays too.

The Buddyfile Xtra will return a linear list that could look like [0,0,2,255,255,128,10,12] with each value being equivalent to a byte having been read. Then I can read back the data much more directly instead of having to use chartonum(). I can just do byteread=bytelist[x] to get the decimal value at position x.

It won't help that much for the compression problem though, since the problem is that I would not be able to search for example for a match of [255,128,10] in that list, I can only find the occurrence of individual bytes, so the matching routine will be as slow. But anyhow, seeing that it's not really important to anyone that I re-compress the data or not, I won't try to do it.

I'm currently building a small program that will reposition all MIO0 files, build new header and copy the uncompressed data after each header, and repoint the 0x18 commands offsets. I had made a similar program that didn't include the MIO0 header aspect, but it was slow anyway, so I'm starting a new one.

I'll probably release it as a small stand-alone program in the next few days, so that you guys can have a concrete example of what the editable ROM will be like, and maybe manually edit some things in the MIO0 if anyone feels like it.


(edited by VL-Tone on 03-01-06 12:45 AM)
(edited by VL-Tone on 03-01-06 12:47 AM)
(edited by VL-Tone on 03-01-06 12:48 AM)
Guy Perfect









Since: 11-18-05

Last post: 6297 days
Last view: 6295 days
Posted on 03-01-06 02:55 AM Link
Searching in arrays doesn't really leave you with a lot of flexibility. The simplest way I can think of is to simply have an N-element array and search for the first value in a second array, then, if found, search for the remainder of the values.

In a movement that shocked the whole world, I prepared a programming example in C instead of BASIC! Here's some sample code I just made (and tested) for searching one array for the contents of another and returning the index of the first occurence (or -1 if it's not found). Feel free to give it a try. If it ends up being effective, then it should help you make a MIO0 encoder in the future.

// Search[] is the array of values to search for
// Target[] is the array to search in for Search[]
// Max is the upper bound of Target[]
// N is the upper bound of Search[]
// Search[] and Target[] have a lower bound of 0
// Found is a flag stating if a match is found
// Pos is the position of the first occurence of Search[] in Target[]
// I and E are integer variables
// Search[] contains at least 1 element


Found = 0; // Loop through target array
for (I = 0; I <= Max; I++) {
// If the first value matches
if (Target[I] == Search[0]) {
Found = 1; // Set up a flag variable

// Check for the remainder of the search values
for (E = 1; E <= N; E++) {
// Check for upper bound
if (I + E > Max) {
I = -1;
break;
}

// Check for value mismatch
if (Target[I + E] != Search[E]) {
Found = 0;
break;
}
}
}

// End loop if match is found
if (Found == 1) break;
}

// Finalize position value
if (Found == 1)
Pos = I;
else
Pos = -1;

// Return the value
return Pos;
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6295 days
Last view: 6295 days
Posted on 03-02-06 11:25 PM Link
Can you load and use DLLs in Director? I imagine that'd be thousands of times faster, and it'd be easy to make a simple binary I/O DLL.
Originally posted by BGNG
As for compression, though, HyperHacker and I have both encountered an anomaly when attempting to code MIO0 compressors. For an unknown reason (which I plan to investigate in the future), reading through the unencoded file linearly and simply checking with the previous 4096 bytes seems to yield larger files than the ones we decompressed from various ROMs. Apparently, a linear approach is not optimal, but neither of us have much of a clue as to why or how.

I remember you mentioned going through the file backward. I haven't tried this yet; have you?
Either way the output is still perfectly valid, just bigger, so it needs to be repointed. Maybe someone needs to look at RAM addresses 800404C0 and 800410C0 in Mario Kart 64 - they appear to be part of a compression routine. The game compresses Time Trials ghosts on the memory card using MIO0.
Deleted User
Banned


 





Since: 05-08-06

Last post: None
Last view: 6295 days
Posted on 03-04-06 11:33 PM Link
the pics here are awesome.....
Omega45889

Shyguy


 





Since: 11-18-05

Last post: 6328 days
Last view: 6342 days
Posted on 03-05-06 12:22 AM Link
Awesome work on this. I cant wait to make my own level .
proffessor_gad

Red Koopa








Since: 01-27-06
From: Mars

Last post: 6325 days
Last view: 6325 days
Posted on 03-05-06 01:54 AM Link
I just downloaded a version of super mario 64 ds.nds, and after looking at it....

Lets just say that I can't wait until an emulator comes out that can emulate it!

Inside of the rom I found (just to name a few) - normal_obj, vrbox, mario_cap_puton_true, mario_model, obj_star_silver, coin_blue_poly, obj_door_keyhole, water_bomb, L_tex_body, Y_head_eat, Y_tex_sleep, door_open, obj_mario_cap, the list keeps going and going!

All of these found items were in btp, bca, and bmd file format. Of course it was not all in this type of code, there was alot that I did not understand! But still, I think that hacking super mario 64 ds will be 50% easier than hacking super mario 64. But as I have said, nothing I can do until a working emulator comes out. If any of you know of such an emulator, please say so!!!!!!!!

P.S.- DesMuMe will not work, it only emulates the title screen, and then it crashes or makes a weird looking screen.
Raccoon Sam

Boomerang Brother
Custom Title








Since: 11-20-05
From: Correct

Last post: 6295 days
Last view: 6294 days
Posted on 03-05-06 08:13 AM Link
Whoa.
How can you view/open those types of files?
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 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - ROM Hacking - General Super Mario 64 hacking / TT64 Progress thread | Thread closed


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.065 seconds; used 483.44 kB (max 626.37 kB)