Jul -- SM64 Hacking (Archive): Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

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

Posts: 472/621
EXP: 1136647
For next: 20472

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 8 days

Posted on 05-13-09 02:43:05 AM

Link

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

Originally posted by VideoGuy
I have been reading this thread for quite a while and am very excited for the importer.

I have two questions, that I believe have not been asked before, although I could be mistaken.

1) In addition to the imported ground, will our levels have the 200-something empty objects that were available in the original Flatworld?

2) You mentioned being able to import textures for the created levels. Do these have to be set externally or is there an option to use textures that are already in Super Mario 64? For example if I want a grass area on my level, could I use the grass texture that is in such levels as Bob-omb Battlefield?

1) You'll be able to set the number of empty objects you want, though there are some limits to the SM64 engine. You can't have more than 240 objects in a level at a given time. Keep in mind that some objects will spawn other objects (such as coins, leaves, explosions) so you'll have to put less than 240. There could be a need to have more than 240 object slots though, since you could make some objects appear only in some acts to avoid busting the limit.

2) I'm seriously thinking of not including the custom import feature from the importer, at least in the first release. As I explained it gets complicated to manage custom textures when reimporting a modified .obj file.

But it won't really limit users, you'll still be able to use any texture you want, but you'll have to choose and set them in your 3d program, which is the most logical thing to do anyway, since you'll have to build your UV map there.

As for using textures from the game, TT64 already includes a feature to export all textures from the game in a folder. Just use them in your 3d program, and they'll be reimported with the .obj model.

____________________

messiaen
Catgirl
Level: 68

Posts: 595/1085
EXP: 2596707
For next: 132093

Since: 11-20-07

Since last post: 8.1 years
Last activity: 7.2 years

Posted on 05-19-09 07:51:19 PM (last edited by messiaen at 05-19-09 04:55 PM)

Link

Here is the hack for the water pointers: Binary and source. It's an exact replica of one of the functions that contains the water box pointers, however with an addition that allows new pointers to be read from a table.

This is the function called from the geometry layout that places the water box polygons:
1800 1601 802D 104C [ 1601 = argument]

In the hack, any value >= 0x8000 will result the pointer being read from a table that starts at 0x80405000 in RAM (0x1205000 in ROM). It's up to you to decide how many entries the table shall contain, the function itself will accept any value higher or equal to 0x8000.

This function can also be used for the toxic stuff at hazy maze once we figured the format of it. Lava and the Waterfall in Castle Grounds use another functions.

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

Posts: 485/621
EXP: 1136647
For next: 20472

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 8 days

Posted on 05-20-09 03:51:22 AM

Link

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

Originally posted by messiaen
Here is the hack for the water pointers: Binary and source. It's an exact replica of one of the functions that contains the water box pointers, however with an addition that allows new pointers to be read from a table.

This is the function called from the geometry layout that places the water box polygons:
1800 1601 802D 104C [ 1601 = argument]

In the hack, any value >= 0x8000 will result the pointer being read from a table that starts at 0x80405000 in RAM (0x1205000 in ROM). It's up to you to decide how many entries the table shall contain, the function itself will accept any value higher or equal to 0x8000.

This function can also be used for the toxic stuff at hazy maze once we figured the format of it. Lava and the Waterfall in Castle Grounds use another functions.

I'll take a closer look at it and try to integrate it in v0.6b.

But for now, a little update on TT64 v0.6 progress.

Here's where the interface is at now.

On the right, there's the interface for managing textures (or "materials"). You can set the scaling for textures individually (or set it globally if you want), and the collision type for this specific material. You can't import textures aside from those that comes with your .OBJ file. If you want to change them, you can edit the texture files themselves and reimport the .OBJ file. You can have whatever texture that you want, but managing them is done outside of TT64 (it can be done inside your 3d program for example).

You can see that thanks to extended RAM support, there's a lot of space for the level geometry and textures. Even with the biggest banks selected (Peach/Yoshi and Bowser banks), there's about 2000K left for the level data.

Before you can reach 2MB of level data though, you'll encounter another limit, 1MB which is the maximum level slot size in ROM. (Because of this, the RAM gauge is essentially useless...).

1MB is still plenty of space, considering that Gecko's level shown here only takes 113k, including textures. Even with a lot of textures (which only take 4k each) you guys should be able to make complex levels, then engine would probably start to slow down before you can reach 1MB. That being said, that limit is not set in stone, I could decide to raise it before releasing the new version, but that would limit the number of slots.

By extending the ROM to 32MB, you can have twelve 1MB level slots.

If you click the "Level Slot" text or on the little arrow at its left, you get a menu to choose which slot to save your level, and choosing which level it will replace.

As you can see there's currently 12 slots available, but this is likely to change. I'm seriously thinking of extending the ROM to 48MB instead of 32MB, so you could get up to 28 slots. That may be less than that if I decide to raise the size of the slots. (One thing I kinda forgot is that it would be nice to be able to have custom sky backgrounds for each slot, and sky bg take 256k each). Do you think that 18x1.5 MB would be a good compromise?

So, everything you see in the screenshot works pretty well, with a few bugs here and there to be fixed.

What's left to be done:

-The 3d preview doesn't take into account the individual texture scaling values for now.
-Adding a Mario proxy box/sphere to get an idea of Mario's size relative to the level.
-The Level File format has to be updated to include the new multi-texture parameters.
-Allowing the saving/loading of level script objects (0x24 etc) in the level file.
-Dealing with what will happen if you re-import an .OBJ file which has more/less materials, or where the material names have changed.
-Adding custom backgrounds skies to levels.
-Finalizing/fixing the sky bg swapper/importer/exporter.
-Getting a working "transparency" GBI command header (without the rainbow Mario glitch).
-Fixing the new Align/Copy/Paste menu options.
-Allowing the editing of level/act names, as well as dialogs in a more integrated way (like I announced, the TextWrangler will be integrated in TT64).
-Water box creation/editing.
-Revamping part of the TT64 interface to switch between modules (Level editor/Importer/Texture editor/Sky Swapper etc.)
-ROM extender format update to have it 16 bytes aligned.
-A lot of error checking routines to be added to prevent the user from crashing TT64 by doing dumb things.
-Updated documentation.

____________________

OniLink10
User
Level: 12

Posts: 16/21
EXP: 6628
For next: 1293

Since: 05-09-09

Since last post: 12.9 years
Last activity: 12.3 years

Posted on 05-20-09 07:19:56 AM (last edited by OniLink10 at 05-20-09 04:25 AM)

Link

Personally, I find 24x1MB more than enough. That would be a Total size of 44MB. Maybe 28 Slots instead. You did say that the engine would slow down before 1MB, so I'd advise not going over that. I'm lovin' the new GUI! I wonder what Nintendo would say if they saw this.

Also, for the reimporting .OBJ files, would it overwrite the current level? If so, I'd just have it clear the level and import the new one as if there wasn't a level there before. Or am I misunderstanding?

Gecko
Member
Level: 25

Posts: 40/113
EXP: 83102
For next: 6518

Since: 03-27-09

Since last post: 9.1 years
Last activity: 7.7 years

Posted on 05-20-09 11:07:01 AM

Link

First of all, you did a great job on that GUI building it, from my perspective, as user friendly as possible. It's definitely worth the noble price.

Good to see that you've already included terrain types.

Regarding the ROM extension, would it be possible to have different sizes?
I'd prefer 32MB, because it's a size found in many other games like Zelda. It would leave the possibility open to play the game on real hardware, either through a Z64 or maybe an altered cartridge.
Other than that, bigger is better. 48MB with 18 * 1,5MB slots allowing for custom backgrounds sounds good!

Stevoisiak
Member
Level: 38

Posts: 265/283
EXP: 345831
For next: 24616

Since: 11-22-07

From: New York, Long Island

Since last post: 12.4 years
Last activity: 5.6 years

Posted on 05-20-09 10:40:50 PM

Link

Lookin sweet so far! Actually, I have an idea to help wade some dying fans over. (Don't kill me again if you don't like it. I couldn't bear the guilt) Since you have a few levels already imported, (Tubular Slide, Geko's Level, SMG level tests, ect), and a few other models premade by fans, why not release one of the levels every 3 weeks or so?

____________________
The guy who acts like he actually knows what he's talking about

Gecko
Member
Level: 25

Posts: 42/113
EXP: 83102
For next: 6518

Since: 03-27-09

Since last post: 9.1 years
Last activity: 7.7 years

Posted on 05-21-09 09:25:57 AM

Link

Importing models is just one part of the editing procedure, one also has to include level goals, objects and enemies. There are more important goals to work on right now than releasing unfinished test maps.

luigiman1928
Member
Level: 17

Posts: 21/46
EXP: 21655
For next: 3088

Since: 02-23-09

From: Gscentral

Since last post: 12.1 years
Last activity: 11.3 years

Posted on 05-21-09 12:46:45 PM (last edited by luigiman1928 at 05-26-09 09:47 PM)

Link

Those pictures make me wanna *meow* there so awesome! Good job man! EDITORP:Awesomeness is Awesomeness....

____________________
Gscentral forever!!

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

Posts: 486/621
EXP: 1136647
For next: 20472

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 8 days

Posted on 05-21-09 03:18:58 PM (last edited by VL-Tone at 05-21-09 12: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 OniLink10
Personally, I find 24x1MB more than enough. That would be a Total size of 44MB. Maybe 28 Slots instead. You did say that the engine would slow down before 1MB, so I'd advise not going over that. I'm lovin' the new GUI! I wonder what Nintendo would say if they saw this.

Also, for the reimporting .OBJ files, would it overwrite the current level? If so, I'd just have it clear the level and import the new one as if there wasn't a level there before. Or am I misunderstanding?

If I also include sky backgrounds for each custom levels, it will take away 256k from each slot. So maybe 1,2MB would be a good compromise.

It will overwrite the existing object, but: there is an option to save all importing parameters as a .T64 "Level file", and you'll have the option of keeping existing objects. So essentially, you can optionally reimport and keep everything as it was.

Originally posted by Gecko
First of all, you did a great job on that GUI building it, from my perspective, as user friendly as possible. It's definitely worth the noble price. Good to see that you've already included terrain types.

Regarding the ROM extension, would it be possible to have different sizes?
I'd prefer 32MB, because it's a size found in many other games like Zelda. It would leave the possibility open to play the game on real hardware, either through a Z64 or maybe an altered cartridge.
Other than that, bigger is better. 48MB with 18 * 1,5MB slots allowing for custom backgrounds sounds good!

Well thanks, I try to make everything as user friendly as possible, even though the SM64 level format sometimes makes it difficult.

Are you sure that you can't use 48MB ROMs with a Z64? And can't you put a 48MB ROM in a Zelda 64 cart?

Anyway, you could always use only the first 8 x 1,5MB slots or so and then chop the ROM to 32MB afterward if you're so inclined to make a 32MB ROM. (People that would do that will have the knowledge to do such a simple thing anyway)

Originally posted by Stevoisiak
Lookin sweet so far! Actually, I have an idea to help wade some dying fans over. (Don't kill me again if you don't like it. I couldn't bear the guilt) Since you have a few levels already imported, (Tubular Slide, Geko's Level, SMG level tests, ect), and a few other models premade by fans, why not release one of the levels every 3 weeks or so?

It's a very good idea, but as Gecko said, there are other priorities.

Originally posted by luigiman1928
Those pictures make me wanna Pee me self there so awesome! Good job man!

Eewww, I don't think that we want to read about your bladder problems luigiman1928. This is a formal warning, don't post similarly disturbing things again.

____________________

RDX

Level: 32

Posts: 79/198
EXP: 193577
For next: 12865

Since: 02-14-09

Since last post: 10.8 years
Last activity: 10.5 years

Posted on 05-21-09 10:17:35 PM

Link

Just as a suggestion to whoever can do it.

Can someone find Mario's exact size in-game so that we can import it into Blender and then make our levels from there? Because while it would work in-toadstool, it would be loads more helpful in Blender itself so that way we wouldn't have to redo our levels if they turn out to be too big/small.

____________________

RomanianGirl

Level: 16

Posts: 34/42
EXP: 19641
For next: 615

Since: 01-31-08

From: Canada

Since last post: 12.9 years
Last activity: 12.9 years

Posted on 05-22-09 12:01:53 AM (last edited by RomanianGirl at 05-23-09 02:13 AM)

Link

EDIT: Removed due to mistakes. (I must have re-scaled it when I was rebuiling Mario's skeleton. I deeply apologize.)

RDX

Level: 32

Posts: 80/198
EXP: 193577
For next: 12865

Since: 02-14-09

Since last post: 10.8 years
Last activity: 10.5 years

Posted on 05-22-09 12:31:45 AM

Link

Wow. Is he really that big in-game?

Because that's pretty huge D:

____________________

RomanianGirl

Level: 16

Posts: 36/42
EXP: 19641
For next: 615

Since: 01-31-08

From: Canada

Since last post: 12.9 years
Last activity: 12.9 years

Posted on 05-22-09 01:04:37 AM

Link

Originally posted by RDX
Wow. Is he really that big in-game?

Because that's pretty huge D:

I suppose so. He was exported with the level itself and I was like, "Where's Mario?"
I had to zoom in then I found him and cut him out.

gamekrazzy
Member
Level: 32

Posts: 106/199
EXP: 194645
For next: 11797

Since: 03-06-09

Since last post: 10.4 years
Last activity: 8.6 years

Posted on 05-22-09 02:05:25 AM

Link

umm, if you read back a page or maybe just a few posts.
I beleive there is something on how the level gets scaled to fit or something. So size wise I don't think you have much to worry about. Umm, Mario truly is pretty big. It's the only way they could give him such complex animations.

____________________
Gamekrazzy*

RDX

Level: 32

Posts: 81/198
EXP: 193577
For next: 12865

Since: 02-14-09

Since last post: 10.8 years
Last activity: 10.5 years

Posted on 05-22-09 03:32:54 AM

Link

His animation isn't really all that complex. It probably was back then, but that was over a decade ago.

Also scaling will probably skew a lot of levels.

____________________

gamekrazzy
Member
Level: 32

Posts: 107/199
EXP: 194645
For next: 11797

Since: 03-06-09

Since last post: 10.4 years
Last activity: 8.6 years

Posted on 05-22-09 04:03:03 AM

Link

Exactly. What did I just say. "In order for them to make such complex animations, it had to be big."
It was complex then. Have you ever tried to draw a picture from a far distance? When you are done, what do you notice when you zoom in?
The pic is raggody and not done very well, which is exactly why they had to make Mario Big. They needed to be as accurate as possible so that Mario does not look like a peice of C**p.

____________________
Gamekrazzy*

RDX

Level: 32

Posts: 82/198
EXP: 193577
For next: 12865

Since: 02-14-09

Since last post: 10.8 years
Last activity: 10.5 years

Posted on 05-22-09 04:06:15 AM

Link

I'm assuming they scaled the in-game model down by a bunch.

When I model small things I start off big and when I'm done I scale it down to the proper size.

____________________

gamekrazzy
Member
Level: 32

Posts: 108/199
EXP: 194645
For next: 11797

Since: 03-06-09

Since last post: 10.4 years
Last activity: 8.6 years

Posted on 05-22-09 04:11:50 AM

Link

Originally posted by RDX
I'm assuming they scaled the in-game model down by a bunch.

When I model small things I start off big and when I'm done I scale it down to the proper size.

It probably is. But lets not talk about this now, because we don't want to fill up this thread with c**p that does not belong here. And I agree with you on the scaling. I do that for my custom avatars.

____________________
Gamekrazzy*

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

Posts: 488/621
EXP: 1136647
For next: 20472

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 8 days

Posted on 05-22-09 12:53:55 PM (last edited by VL-Tone at 05-22-09 09:55 AM)

Link

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

I really don't get this discussion about how Mario looks "big".

Everything is relative, especially in a 3d vector/polygon world. Mario is simply as small/big as he is, compared to the in game levels.

RomanianGirl simply posted a picture where Mario is zoomed in by some arbitrary amount, it says nothing about its relative size. I don't know how you guys can infer that he's big by looking at that picture.

Maybe that's because Mario has a relatively high polygon count compared to the levels?

What we need is Mario's size in SM64 world coordinates units (not blenders units, unless we can find a conversion ratio between the two).

Originally posted by gamekrazzy
umm, if you read back a page or maybe just a few posts.
I beleive there is something on how the level gets scaled to fit or something. So size wise I don't think you have much to worry about. Umm, Mario truly is pretty big. It's the only way they could give him such complex animations.

On the contrary, the level scaling feature is one of the main reason why it will be useful to be able to see Mario's relative size in TT64. Even if you auto-scale the level, it won't magically make you platforms low enough for Mario to jump on, or the distance between platforms short enough for Mario to jump/long jump to them.

Again, Mario is not "pretty big", you guys are simply deceived by the fact that he has a lot of polygons compared to levels.

Mario's 3d designers didn't have to make him big to make him as detailed, there's a wonderful feature in 3d program called "zoom" that enable you to see more details without actually scaling the actual model...

It is possible that he was made on a bigger scale and then scaled down "live" in the game engine, but the opposite could be true, he could've been made on a small scale, then made bigger by the game engine.

____________________

Register - Login
Views: 99872118	Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies	05-04-22 07:20:41 PM

Query execution time:	0.141759 seconds
Script execution time:	0.038696 seconds
Total render time:	0.180455 seconds