Jul -- Posts by VL-Tone

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 85/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-13-07 06:46:00 PM, in SM64 Music Editing; last edit by VL-Tone on 09-13-07 06:46 PM

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by KyoufuKitty
This talk about compressed MIDI makes me think of Sappy, whose data is converted from .MID files with all the unneeded stuff removed and delta-time sigs replaced by wait commands.

Same concept?

I guess so, it's probably a similar process. Looking at the music data in SM64, it looks like it uses standard midi events opcodes like 0x80 for note_off and 0x90 for note_on. That means it should be relatively easy to reverse-engineer.

I'm almost sure that Zelda OOT must use the same format, since it's also built using the UltraLib. So if anyone knows the location of the music data in that game, we could try to move songs from OOT to SM64

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 86/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-13-07 06:55:53 PM, in Help/Questions about Toad's Tool 64 and SM64 hacking

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by nevum
Is it bad if I bought the licence for hypercam 2? I mean did I waste my munee?

Well, remember that the guy or guys had to work several hours to built this program, improve it and support it. Paying them the shareware fee is certainly not "wasting" your money.

That being said, if others are too poor to afford it or have other priorities, I don't care much if they use a pirate serial and/or simply don't pay. But just don't give the impression that it's stupid to pay for people's time.

(BTW I've worked hundreds of hours on TT64, for a grand total of 0.00$ in donations... but whatever...)

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 87/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-15-07 03:35:15 AM, in SM64 Music Editing

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

I remember taking a peek inside the content of Yaz0 files a while ago. The polygon drawing commands are pretty similar to those in SM64. The main thing I couldn't find is where to find the textures to be applied to specific polygons (it doesn't use the same bank/segment system as SM64, and anyway I don't know where are the commands the specify what is loaded in which segment). BTW if you didn't know already, there are some JPEG files found in some Yaz0, which are used for the big backgrounds of panoramic scenes. JPEG files start with FF D8 FF E0 00 10 4A 46 and end with FFD9. Anyway, like you said this is a SM64 thread after all

But it would be useful/fun if we could try OOT music in SM64.

Now as for midi commands...

Don't ask me where I got this, but it's exactly what we need:

    /* For distinguishing channel number from status */

    ChannelMask         = 0x0F,

    StatusMask          = 0xF0,



    /* Channel voice messages */

    ChannelVoice        = 0x80,

    NoteOff             = 0x80,

    NoteOn              = 0x90,

    PolyKeyPressure     = 0xA0,

    ControlChange       = 0xB0,

    ChannelModeSelect   = 0xB0,

    ProgramChange       = 0xC0,

    ChannelPressure     = 0xD0,

    PitchBendChange     = 0xE0,



    /* System messages */

    SysEx               = 0xF0, /* System Exclusive */



    /* System common */

    SystemCommon            = 0xF1,

    TimeCodeQuarterFrame    = 0xF1,

    SongPositionPointer     = 0xF2,

    SongSelect              = 0xF3,

    Undefined1              = 0xF4,

    Undefined2              = 0xF5,

    TuneRequest             = 0xF6,

    EOX                     = 0xF7, /* End of System Exclusive */



    /* System real time */

    SystemRealTime  = 0xF8,

    TimingClock     = 0xF8,

    Undefined3      = 0xF9,

    Start           = 0xFA,

    Continue        = 0xFB,

    Stop            = 0xFC,

    Undefined4      = 0xFD,

    ActiveSensing   = 0xFE,

    SystemReset     = 0xFF,

    Meta            = 0xFF      /* MIDI Files only */



    VOLUME_CTRL         = 0x07,

    PAN_CTRL            = 0x0A,

    PRIORITY_CTRL       = 0x10, /* use general purpose controller for priority */

    FX_CTRL_0           = 0x14,

    FX_CTRL_1           = 0x15,

    FX_CTRL_2           = 0x16,

    FX_CTRL_3           = 0x17,

    FX_CTRL_4           = 0x18,

    FX_CTRL_5           = 0x19,

    FX_CTRL_6           = 0x1A,

    FX_CTRL_7           = 0x1B,

    FX_CTRL_8           = 0x1C,

    FX_CTRL_9           = 0x1D,

    SUSTAIN_CTRL        = 0x40,

    FX1_CTRL            = 0x5B,

    FX3_CTRL            = 0x5D



    META_TEMPO          = 0x51,

    META_EOT            = 0x2f





BLOCK_CODE           0xFE

LOOPSTART_CODE       0x2E

LOOPEND_CODE         0x2D

CNTRL_LOOPSTART      102

CNTRL_LOOPEND        103

CNTRL_LOOPCOUNT_SM   104

CNTRL_LOOPCOUNT_BIG  105

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 88/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-15-07 03:36:55 AM, in TT64 Version 0.5.9b Released! Bug reports here.; last edit by VL-Tone on 09-15-07 03:59 AM

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Dark Mario, send me the .ppf of your modified ROM so I can check what's the problem. (PM me about it)

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 89/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-15-07 03:53:40 AM, in Ask me the stupidest questions ever!; last edit by VL-Tone on 09-15-07 03:55 AM

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by The Glitch
Did porn ever help you make a potato gun that you use to shoot kids who skateboard on your property?

Why do you think I bought a 250 GB HDD?

Originally posted by Kaze Kawl
DO BRAINS MAKE SQUISHY SOUND IF ME STOMP IT FLAT?

Ask Goombas.

Originally posted by Jameowsup
wen i play mario 64 if i prez a he jumps wtf mai game is br0ken D::::::::::::::::::::::::::::

You're not playing mario 64, you're playing Super Mario Bros. on a NES.

Originally posted by Darkdata
What is 0xC0FFEE?

What came first, the weeeeeeeeeeeeeeeeee or the ajfohsalkglkashoiedurknewkmnbfiuh2klbnrjhgtfu1h24klemnoiasyfkusndoitgu8egriknsdalkfhi?hadgkjaslkdgj
skldjglkdjaflgjdajflkh sd
df
gh
df
h?

I guess you spilled coffee on your keyboard again?

Originally posted by Higsby
if H + J = I what does K stand for?

K = J + L

Originally posted by xpCynic
i want dl toad stool 64
where iss iy
com on i wan hax it lol
lol
lol

lol

How many times should I tell you guys, it's "wax", not "hax". As in "How do I wax Super Mario 64?". And the answer is "With Koopa Turtle Wax".

Originally posted by The Glitch
Is it true that VL is such a good hacker there are no nipples under his shirt, there is only more hands he uses to type with?

I got perfectly normal nipples. Some people may think I have a third hand in my pants, but that's another story...

Originally posted by HyperHacker
dud how i add cool mp3 to mario help plz

also tt46 don't work

On a serious note, how do you put up with all the n00bs?

To add cool mp3s to mario, you first need to put your mp3 player in the freezer for 3 hours.

And to answer your serious question: I can put up with n00bs because my "real job" involves supervising and training a bunch of n00bs

I learned to be patient with them over the years.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 90/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-17-07 04:09:57 AM, in TT64 Version 0.5.9b Released! Bug reports here.; last edit by VL-Tone on 09-17-07 04:20 AM

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Dark Mario
Originally posted by VL-Tone
Dark Mario, send me the .ppf of your modified ROM so I can check what's the problem. (PM me about it)

Ya it was my modded rom i guess having a modded rom causes the messup.
(Note to people: roms edited with previous version mess up occasionally.)

Dark Mario You still didn't send be your .ppf patch... I'm waiting...

Since version 0.5.7b, every modified ROM I opened did NOT generate an error. So I absolutely need to open your modified ROM to know what happens, since you're the only one that had a bug like that since I updated from 0.5.5b to 0.5.7b.

And I don't understand the idea behind this "note to people:". You're the only one having this bug, and you didn't offer any proof of it.

fiercelink and Me-me, you have a different problem, where your ROM crashes when run in an emulator.

So you're saying that if you start with a totally clean unmodified ROM, just change a single texture and then the ROM will crash in an emu?

Or is this problem happening with a ROM that was previously modified?

If it's the case, it may not be the fault of TT64. Like I said before, and like it's explained in the Read-me file, some changes you make in a level may result in a crashing levels. SM64 is a complex game, and it's hard to predict how the game will behave when modified.

I tried to do my best to make TT64 prevent you from using crashy combos, but in some cases a modification may cause a crash, especially if you generate "undefined combos". Always try to keep track of changes you make, and try playing the ROM often in between changes.

If the game crashes just after the first game menu, the problem must be located in Castle Grounds. Use TT64 to try to find what change might have caused the problem. If you try weird combinations like using Bowser's behavior on a Koopa model, don't blame TT64 if your game crashes.

Version 0.6b will try to help you dealing with these problems, by providing you a way to revert an object or level to the original game data if you mess up, and also with ways to save and load individual levels as .txt files which can be used to move levels in between ROMs.

TommyPower: Don't listen to Count Drekken, you'll only get more confused

The texture folder is used when you want to EXPORT all textures at once, as images. It's normal that it's empty when you first get the program.

Same thing with the ROM extender, the MIO0 file folder is empty when you get the program, it's normal. It's content is generated once you extend a ROM, and is only needed temporarily.

BTW Count Drekken: It says below your name: "I'm back!". I don't remember seeing you here before. Did you have another name? If so, what was it?

Edit:

The Glitch:

Doh! I had this problem before, it's an "off-by-one" bug with the old texture-import function. The bug was fixed, and the new function is used when checking the "load custom textures" option is checked, or when using the "Revert From ROM" button. The problem is that the built-in textures were imported using the old buggy function by mistake. If you use the "load custom textures" option, it should fix the problem, at least temporarily, though levels will load more slowly. I'll try to upload version 0.5.8b (sigh!) soon with the fixed built-in textures.

The second bug is actually linked to the texture bug. Because of the bug, some textures have a one pixel hole in their alpha-mask. Because of that TT64 turns the transparency on for these polygons, and Shockwave 3d (Director's 3d engine) can get very glitchy when there's too many layers of transparent textures.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 91/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-19-07 01:45:23 AM, in TT64 Version 0.5.9b Released! Bug reports here.

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Dark Mario
Originally posted by VL-Tone
Dark Mario You still didn't send be your .ppf patch... I'm waiting...

I lost it i was probably because of me messing with te objects and setting ****ed up function for them so if i gave you a .ppf patch you would have 10 pages of errors and i restarted because it was glitch ed ingame.

If you don't give me your .PPF, I can't fix your bug. Sorry. You're the only one having this bug since version 0.5.7b. Others that posted here (like fiercelink and Me-me) have a different bug which I'm working to fix. Considering your history of trolling the board here, I even wonder if you didn't invent the whole bug. Unless you send me a .PPF patch, you'll have to stop complaining about this bug.

Originally posted by Me-me
Yeah i start with a completly clean and new extended rom,
and then i changed ONE texture and i didn't even touch
a single button in the level editor.
It just crashes. But when i edit with
TT64 0.3b it works just fine...
Woah how wierd.

Me-me: I really need something even more specific here. I need to be able to reproduce the bug on my own. I need to know which texture you edited that gives you this problem.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 92/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-21-07 08:17:37 AM, in TT64 Version 0.5.9b Released! Bug reports here.

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Oh well, yet another bug fix release :/

Download version 0.5.8b at: http://homepage.mac.com/qubedstudios/ToadsTool64.htm

Bug Fixes in 0.5.8b:

•Some of the bundled default textures were corrupted and were causing some display problems, this has been corrected.
•Fixed some problems when editing 0x22 commands.
•Loading ROMs containing 0x22 pointing to non-existant banks shouldn't cause a script error anymore.
•Fixed a potential bug where in some context the box sizes wouldn't match the objects with some modified ROMs.
•Now includes an already generated M64Geometry.m64 file, so the first run should be much faster.
•Generating the M64Geometry.m64 file from an already modified ROM could lead to potential problems so that's why I include it now.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 93/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-21-07 09:45:11 AM, in Animation Commands Hacking (Geeky Stuff!); last edit by VL-Tone on 09-21-07 09:51 AM

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

As many experienced TT64 users found out, when you try to apply behaviors from an enemy to a different model, you usually end up with an epileptic and glitchy character. For example, applying the Goomba Walk behavior to MIPS the rabbit result in the mutant rabbit you've seen in the TT64 2007 demo patch.

The reason why it happens is that the animated rotation values are applied to the wrong joints, and if the model you use has more joints than the behavior animates, the rest will end up pointing up to unrelated values in RAM, which creates seemingly random glitchy movements in the remaining joints.

I used to think that the relation between the behavior and model was hard-coded in the ASM behavior functions, and thus would be hard to modify or transfer from one model to the other.

But I found it's not quite the case since rstewart215804 found a very interesting command used in behavior scripts.

The command is 0x27. I updated my "decompiled" behavior script document to reflect this new find.

http://homepage.mac.com/qubedstudios/SM64Behaviors.txt

[27] [26] [00 00] [05] [00 61 6C]



[0]= 0x27 is the command byte.

[1]= Always 0x26?

[2,3]= Always zero, unused?

[4]= Bank number.

[5,6,7]= Offset of the animation data in the bank.

The 0x27 command points to animation data which is usually found in the same bank where the related model polygon data is (most of the time, it's just after the polygon data for a given model).

I don't know the exact format of this data, but it often includes jump offsets so the data is not linear, and I assume it's structured in a hierarchy fitting the model body part structure.

If you want to take a look at this animation data, and maybe try to find more about its format, here's how to find it:

Let's take the Goomba animation data as an example.

The "Goomba Walk" behavior pointer is 1300472C.

The behavior script bank (0x13) is loaded from 00219E00 in ROM. So 00219E00 +00472C= 0021E52C.

You can use the SM64Behavior.txt document to look it up.

Here's the Goomba Walk behavior script from the document:

ROM Addr: 0021E52C Hex Behav: 1300472C

Description: Goomba Walk

21E52C/00472C  00 05 00 00

21E530/004730  11 01 20 49

21E534/004734  1E 00 00 00

21E538/004738  27 26 00 00 08 01 DA 4C

21E540/004740  2D 00 00 00

21E544/004744  30 00 00 00 00 28 FE 70 FF CE 03 E8 03 E8 00 00 00 00 00 00

21E558/004758  0C 00 00 00 80 2F F4 08

21E560/004760  08 00 00 00

21E564/004764  0C 00 00 00 80 2F F9 6C

21E56C/00476C  09 00 00 00

You can see that the 0x27 command is found at 21E538 in the ROM.

27 26 00 00 08 01 DA 4C

It means that the animation data is found at offset 0x01DA4C in bank 0x08.

Where is bank 0x08? You'll have to use TT64 to find out.

Open a ROM in TT64, and load a level where you can put Goombas, it could be Bob-Omb Battlefield, but let's use Castle Ground in this example, which as most of you know can also contain Goombas.

So load the Castle Grounds level if it's not already loaded.

Set the Commands mode to Expert and click on the "0x17 Copy Data to RAM Bank" line in the command menu.

Set the mode to Hexadecimal by clicking on the appropriate checkbox.

Look at the 0x17 commands list. The 12th line is "012 i h08 h00A8181C".

If you click on it, you can see that in this levelbank 0x08 is loaded from data found in ROM, starting at 0x00A8181C and ending at 0x00AAA40C. The important number here is 0xA8181C, since it's the begining of the bank in the ROM.

If you add 0x01DA4C (Goomba animation data offset) to 0xA8181C, you'll end up with 0xA9F268, and this is where the animation data entry point is in an extended ROM.

Looking at 0xA9F268 in the ROM with an hex editor, the first four bytes you can find are 08 01 DA 34.

Hmm... 08, what a coincidence, it's the bank number we're at! 01DA34 is indeed a valid offset inside this bank. To make it easier to find where it is in the bank data without having to add 0xA8181C each time you encounter an offset in bank 08, what you can do is copy all the data from 0x00A8181C to 0x00AAA40C and paste it into a new empty document (in your hex editor). That way you can easily find an offset in bank 08 just by looking at the address column on the left.

Like I said, I don't know much about the actual format there. Outside of the offsets, which seems to make the data jump around the place in that bank, there are some sequence of data which seem to be series of angles.

If you want to help cracking the format, and have previous ROM hacking experience, this could be your starting point.

But let's get back at the 0x27 command level, since we don't know the animation data format.

By swapping around 0x27 commands in behavior scripts, we can do very very interesting things...

Let's say we want to make a MIPS rabbit that acts like a Goomba.

Start with a freshly extended ROM.

In TT64, in Castle Grounds, select a butterfly. Make sure you're in the Expert Paramater Bar mode so you can see the Model ID and Behav params. (That's just below the Activate Level Select check box).

Click on the menu icon for the Model ID param, and select MIPS as the model(Model ID 100). Then, click on the menu icon for the Behav param, and select the Goomba Walk behav (18220).

Click on Save. Try the ROM in your favorite emulator.

Ok so while MIPS acts like a Goomba, it's all glitched and mutant...

That's because the game applies the animation data from the Goomba (the 0x27 command found in its behavior script) to the MIPS model, and its body part hierarchy simply doesn't match.

Let's try to fix that with what we know now...

Take another look at this document: http://homepage.mac.com/qubedstudios/SM64Behaviors.txt

We try to find the MIPS behavior script.
Here it is:

ROM Addr: 0021E2FC Hex Behav: 130044FC

Description: MIPS Rabbit Behavior

21E2FC/0044FC  00 04 00 00

21E300/004500  11 01 04 09

21E304/004504  27 26 00 00 06 01 57 24

21E30C/00450C  10 2A 00 02

21E310/004510  1E 00 00 00

21E314/004514  23 00 00 00 00 32 00 4B

21E31C/00451C  10 05 00 00

21E320/004520  0C 00 00 00 80 2F 84 90

21E328/004528  08 00 00 00

21E32C/00452C  0C 00 00 00 80 2F 8D AC

21E334/004534  09 00 00 00

Ok, so MIPS' animation command is 27 26 00 00 06 01 57 24.

Looking at the Goomba Walk behavior script:

21E538/004738  27 26 00 00 08 01 DA 4C

We see that the Goomba Walk animation command is at 21E538 in the ROM.

Open the ROM you just modified, go at 21E538, and replace 27 26 00 00 08 01 DA 4C with 27 26 00 00 06 01 57 24. Save the changes.

Load the ROM in the emulator, go to Castle Ground... Oh! That's better, MIPS is no longer a mutant, and he acts like a Goomba!

The only thing is that he seems to be stuck in his "idle" animation routine while he walks, instead of his walking animation, so he looks like he's sliding, while looking around. He does have a different animation when he starts running toward you, and it's pretty funny. It's not perfect but it's still much much better than the mutant version.

But there's a big problem. We've now modified the Goomba Walk behavior script so that it uses the MIPS animation. What happens if you put a Goomba in Castle Ground using this ROM? Well he'll be glitched...

And what happens when you go to Bob-Omb battlefield in this ROM? It crashes... That's because the Goomba Walk behavior script now relies on the animation data from MIPS, which is expected to be found in bank 0x06. But in other levels (except inside the castle) bank 0x06 in RAM doesn't contains the MIPS polygon data and its animation data, it contains some other bank.

So when swapping 0x27 commands, you really have to know what you're doing. You must be sure that the content of the bank which is referred by this 0x27 command will always be present in levels where this behavior script is used. Always work on backups, don't try to experiment with this on the only copy of your masterpiece TT64 mod.

Also, if you're a n00b and try swapping 0x27 commands, don't come here to complain that it crashes your ROM.

Because of all these potential issues, it would be hard to integrate any fool-proof method of editing the 0x27 commands in TT64.

A way to get around some of these problems would be to extend bank 0x13 (the behavior script bank) and duplicate existing behavior scripts to create new ones that could be only used in a particular level. Still, managing all this would end up being very complicated.

Eventually, managing and editing behavior scripts and animation commands will be possible in TT64, but certainly not soon.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 94/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-21-07 05:17:34 PM, in TT64 Version 0.5.9b Released! Bug reports here.; last edit by VL-Tone on 09-21-07 05:20 PM

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Junk
I think Rom extender cannot run on Japanese OS...
My rom must be correct US version ROM.

Hi! Welcome to the forum.

It's a shame if the ROM Extender doesn't work on Japanese OSes

I would sure like to fix that, because after all, Japanese people made SM64 in the first place

First, if you're on a Mac, make sure the ROM name is less than 32 characters. For some obscure reason one of the command-line utility truncates the name and add a unique ID number if it's more than that , which makes the ROM Extender fail. (Some legacy name-length bug which I usually never encounter on OS X).

If you're not on a Mac and/or this doesn't work, I would need to see the debug log. Click on the little debug arrow icon before opening a ROM. Open the ROM, dismiss the error dialog, then copy the debug log, paste it in a post here so I can look at it.

Edit: Another suggestion, make sure you avoid using Japanese characters in the ROM name.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 95/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-22-07 07:40:04 AM, in TT64 Version 0.5.9b Released! Bug reports here.; last edit by VL-Tone on 09-22-07 07:43 AM

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Thanks for that debug log, it's very useful.

I want to know, once the ROM is extended correctly (using VPC for example), can you open it without problems in TT64 running on the Japanese system without VPC?

I believe that you do have the right ROM, but there's a problem in the ROM Extender on Japanese systems. You can see that somehow the 0x8B byte was skipped while reading the checksum...

I've read that Director may have issues with the chartonum function on asian systems. The ROM Extender was using the chartonum function to convert the binary-string data from the "readbytes" command provided by the Binary IO Xtra into hex data. It was a little silly to use this command to read the checksum, but readbytes command is used in all the rest of the ROM Extender to read/write large chunks of data quickly.

Here's a version that reads the checksum as numbers directly instead of converting an ascii binary string into numbers.

http://homepage.mac.com/qubedstudios/M64ROMExtender1.3a.zip

It should fix that checksum check problem... Try it and tell me what happens (with a debug log if you get an error).

But I suspect that there's a much bigger problem behind all this, and that fix won't really help your case.

Still, let's try this first, and if it doesn't work I'll explain what the problem might be and that it may require a partial rewrite of the ROM Extender, and a switch to a different file access plug-in (Xtra). TT64 itself shouldn't be affected by this since it already uses another file access Xtra and deal with data as lists instead of ASCII strings.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 96/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-22-07 07:47:25 AM, in I need help

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

m@rio_luig1: Please look around before you post.

While people might be nicer, there's already a thread that explains how to make a .PPF patch, and there's also the TT64 Help thread.

Anyway I don't like how this thread started and I don't like where it's going so it's now closed...

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 97/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-23-07 06:25:59 AM, in TT64 Version 0.5.9b Released! Bug reports here.; last edit by VL-Tone on 09-25-07 06:50 AM

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Ok guys, I'm really sorry about this bug... I'm a little ashamed to admit this, but for this bug I didn't even try to reproduce it myself. I assumed that since I made zero changes in the texture saving part of the editor, these were weird issues that only some people were having.

But no, this bug was actually affecting everyone since 0.5.6b. Simply going to the texture editor and back would corrupt the ROM.

This had something to do with a new feature I was toying with but that was writing its changes at the wrong place, and corrupting a command in the ROM.

The new feature will resize Mario's shadow to match any change in its overall size. Since the size data is saved automatically when you quit the texture editor, the corruption would happen just by visiting the texture editor.

I just released version 0.5.9b which will fix this crashing ROM bug. To fix your ROM, open it with TT64 0.5.9b, and just go to the texture editor (then back to the level editor). This will automatically save the size and shadow data, AND fix the corrupted data. You don't need to click save, and you don't even need to edit anything, but you must go to the texture editor once. Further changes won't corrupt the ROM (obviously).

You can download version 0.5.9b at the usual address: http://homepage.mac.com/qubedstudios/ToadsTool64.htm

Version 0.5.9b attempts to fix an issue with checksum verification that would happen on Japanese and other asian Windows systems. Opening an already correctly extended ROM should now work on Japanese systems.

Note that this DOESN'T fix the problem with the ROM Extender on Japanese systems. This problem will require a partial rewrite of the app.

The problem with the ROM Extender is from the Binary IO Xtra. This Xtra enables very fast reading and writing abilities to Director MX. It's fast because it loads the binary data in ASCII string variables, instead of converting them to lists variables (arrays). The problem is that on Japanese systems, Director seems to have a different internal representation of string variables, which corrupts the binary data read into those strings. To fix it I'll need to use another Xtra, and read/write large amount of data with some conversion to list variables, and that will make it much slower. I'll probably have to split the program in two version, so that the fast, but less compatible version is still available.

This leads me to this question:

Is anyone here experienced enough in C or C++ command-line programming to help me write an all-in-one portable command-line version of the ROM Extender?

I could provide the source code for all the hard parts (MIO0 decompression, checksum calculation). Essentially, the rest is relatively simple, it's a matter of decompressing the MIO0 data, adding 16MB of padding to a copy of the ROM, then copy the decompressed data at some specific addresses, modify all the related pointers, then recalculate the checksum.

Having such a program would be very useful for TT64. First, it would fix a few issues some people are having with the program on some systems. It would work on Japanese OSes, amongst other things.

It would also provide better Linux support for TT64. While TT64 doesn't run natively on Linux, it does run under WINE. But the ROM Extender doesn't because on its reliance on Windows-specific command line utils. A C or C++ version of the ROM extender could be easily ported to Linux, Windows and OS X.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 98/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-23-07 07:19:20 AM, in The General Project Screenshot/Videos Thread...; last edit by VL-Tone on 09-23-07 07:20 AM

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Darkdata: Not to discourage you or anything, but there's already an official English release of Hello Kitty world...

Still, so far, your translation is much better than the official one. Please continue and forget what I just said

I didn't play this game very much, but I know it for one thing: its really nice music...

Hello Kitty world (1992) is the last NES game that features music from Hirokazu "Hip" Tanaka. (Mastermind behind the music and SFX for Donkey Kong, Balloon Fight, Balloon Kids, Duck Hunt and many other early Famicom/NES games, Metroid, Kid Icarus, Dr. Mario, he "invented" and worked on the GameBoy Camera and wrote some of the early Pokemon TV show tunes).

Here's the NSF, for those who care!

http://homepage.mac.com/qubedstudios/hkittywd.nsf

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 99/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-23-07 07:45:06 AM, in My clock is haunted.

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Older alarm clocks that plug into the AC outlet relied on the 60HZ current phase to keep time. These can't really go faster or slower, unless your local power plant has some very serious problems.

But more recent AC clocks will instead rely on an internal Quartz crystal to keep time. It's possible that the Quartz crystal or its soldering becomes flaky and has some random glitches.

When I was younger, we had a microwave oven that suddenly became haunted. At totally random times (including the middle of the night), it would go "beeeeeeeeeeep" without stopping, turn itself on, start cooking and its screen would be all lighted up (8888888888

. Pretty scary!!

We had to keep it unplugged when it was not in use.

I decided to repair it myself. Did you know that many microwave ovens include an envelope inside with some tips, plans and warnings on how to repair them?

Anyway I suspected the Quartz crystal to be at fault. What I did is simply redo the soldering for the crystal, and it fixed the problem!

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 100/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-25-07 06:49:22 AM, in TT64 Version 0.5.9b Released! Bug reports here.; last edit by VL-Tone on 09-25-07 06:49 AM

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by The Glitch
Just thought I'd report these two bugs, The last two textures in the texture editor can't be selected for some reason, and when I maximize TT64, and go to texture editor, the window resizes itself, but returns to normal when I go back.
I'm also having trouble getting modded textures to save, even though the thumbnail updates.

Hmm yeah, some few versions ago two textures were added to the list, and I forgot to change that hard-coded value that sets the maximum texture number you can select. It'll be easy to fix.

When you say "returns to normal when I go back" do you mean that it goes back to the same size it was before going to the texture editor? (in this case, maximized). Because if so this is how it should behave. But if your window was maximized before you did go to the texture editor, then when you go back it gets smaller than maximized, then it's a bug.

Originally posted by nevum
Hey guys sorry about not posting anything at all for the past million years and how late this comment is. (The reason for this is I've been really busy studying C++) Anyhow, I wanted to say that I had the same problem that Me-Me did. It crashed afer I selected a file.

Well it's late because Me-me's problem was fixed with version 0.5.9b, which was released before your post, right on this page.

Did you actually read my last post? You know, the part in bold letters?

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 101/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-28-07 04:37:06 AM, in ToadsTool Suggestions; last edit by VL-Tone on 09-28-07 04:37 AM

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Ok let's reply to these suggestions...

Originally posted by The Glitch
I got a few ideas.
1:Mario Proportains Modder - With this you could change Mario's height and width.
2:Mario Transparency Modder - Use this to change his transparency.
3.Mario Speed Modder - Use this to make him run faster or slower.
Those are my ideas, a post explaining if these can be done or not, with some technical details will be welcome.

1: I thought about it, maybe a Luigi preset will be included.
2: I don't know how/where to set this parameter in ROM, transparency seems to be controlled by ASM code (for warps, and the vanish cap).
3: Again, I don't know where this value is in ROM. Knowing about a GS code that does that doesn't necessarily means we can easily find the equivalent in ROM.

Originally posted by fiercelink
1 - jump hight editor

I have simply no idea where this value is in ROM. If someone can find it, I'll gladly implement it in TT64.

Originally posted by NintendoMasters
A level boundary* editor. Used in the same way as cropping an image if possible (Click and drag)
* The invisible walls at the ends of a level (for anyone who didnt get what i meant)

Originally posted by The Glitch
I noticed in the collision geography that the invisable walls may be generated by some kind of ground at the very bottom of the level, I at least noticed this in Whomp's Fortress that the ends of the "ground" at the bottom seemed to match the invisable walls.
So sorry, Polygon editor is needed for that.

I don't think the level boundaries are set by the collision ground found in some level. The fact that this type of ground only is present in some levels goes to prove that they're not responsible for that. I think this special ground has something to do with the "death by falling" routine. My theory is that the level boundaries are set by a command similar to the water areas commands.

Originally posted by wowfunhappy
There is probably some reason that makes my suggestion hard to implement, but an unlimited amount of text in the Text Wrangler would be fantastic. We could turn SM64 into an RPG!

Well, at least in my opinion it would be fantastic. One talent I pride myself in is writing stories, so if I could combine my writing skills with TT64... well it would be a lot of fun for me and would add a lot of depth to my hacks.

It wouldn't be "that" hard, I would just need to know where is the pointer for the beginning of the text data so I could move the text at the end of its MIO0 bank, at a place where expansion would be easier. I'll try to keep that suggestion in mind and eventually implement it.

Originally posted by bweeno
hi, i have a suggestion.

could it be possible for high resolution textures. i mean it doesnt have to be overly huge like todays standards, 1920 by 1080. maybe you could just add a 0 to the end of the current resolutions eg, insted of 32 by 32, you could have 320 by 320 etc. of coarse this would by an option, for those who wanna use "high" resolution textures, maybe some people find it easier for low, i dont know.

The N64 hardware has a very small texture cache, and this is the real limitation.

At best we could replace 32x32 textures by 64x64 versions. That would be relatively easy for textures that are contained in "texture-only" MIO0 data bank, but it would be much more complicated for textures that are contained along polygon data in the same MIO0 banks, since it would require moving the polygon commands around and change all the pointers and jump commands.

The high-resolution SM64 textures you've seen are possible only in an emulator using a specially crafted plug-in called "Rice video". This plug-in doesn't read the high-res textures from the ROM but rather from a folder. As far as I know it doesn't really increase the n64 texture cache, but rather intercepts the low-res texture before they're drawn on screen and replaces them with the high-res version.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 102/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 10-02-07 07:01:53 AM, in TT64 Version 0.5.9b Released! Bug reports here.

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by CellarDweller
Originally posted by VL-Tone
Is anyone here experienced enough in C or C++ command-line programming to help me write an all-in-one portable command-line version of the ROM Extender?

Did someone say C?

I actually started to work on an extender shortly after the original one was released, but I lost interest shortly after. There is one thing that is bothering me. A number of files in the ROM are relocated to odd numbered addresses. I suspect that this could cause problems if an extended ROM is run on a real N64.

I'm interested, and I can even include a GTK GUI. I have all of the information I need. If anyone wants it I'll get started.

I would really appreciate if you could do it. I'm sure many others are interested in seeing this happen. Heck, maybe it could inspire someone to create a linux/open-source SM64 level editor or some other editing tool?

Maybe it would be time to define a new extended ROM format, to add more space between uncompressed segments amongst other things, and to fix the odd numbered addresses problem.

The only catch would be for TT64 to make the transition to the new format... If I put backward compatibility with the old format in TT64, it would almost defeat the purpose of having a new format, because people that already started a mod or hack would continue to use the old format, and any new feature taking advantage of the new ROM format wouldn't work with these.

The best solution would be to have a program (maybe integrated into the new C based ROM Extender) that converts the old extended ROMs from the old to the new format, and make subsequent versions of TT64 only open the new format so it doesn't get held back by backward compatibility.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 103/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 10-02-07 07:46:55 AM, in ToadsTool Suggestions

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Vorton
There should be a function that allows you to save all edited textures at once. Sometimes it does get frustrating to save each texture one at a time.

It's a good suggestion Vorton, and welcome to the forum.

The main reason why I didn't do it is that my "saving to ROM" routine is relatively slow. Sure it can save a single texture in a fraction of a second, but saving all 850+ textures to ROM at once could take two or three minutes on slower systems. I guess it would be logical to only save changed textures, which would take less time. But still, when I'll implement the "Load all textures from folder" feature, you could still end up with a situation where all textures are changed.

I'll guess I'll have to implement these features anyway, hoping that users won't be often faced with a lengthy saving process.

BTW Vorton, I'm not sure your avatar image breaks any rules here, but personally I find it pretty disturbing. Also I don't think it fits well with the mood of this forum.

____________________

Register - Login
Views: 99798772	Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies	05-03-22 06:12:22 AM

Query execution time:	0.095539 seconds
Script execution time:	0.096224 seconds
Total render time:	0.191763 seconds