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

Gecko
Member
Level: 25

Posts: 8/113
EXP: 83089
For next: 6531

Since: 03-27-09

Since last post: 9.1 years
Last activity: 7.7 years

Posted on 04-20-09 05:28:09 PM (last edited by Gecko at 04-20-09 02:28 PM)

Link

Originally posted by messiaen
I just checked out and there's plenty of debug information going on the title screen, including a vertex counter. This debug information isn't printed on screen, but probably redirected to a console (ie, the SGI hardware the programmers used to develop the game). Disassembly of these functions are on "Nagra's Mario Resource" (from dextrose.com). Recently something similar was discovered in the debug Zelda ROM and using a hacked version of Mupen it was possible to recreate a console debugger.

Getting back to Mario, I did a quick check and the title screen (with Mario's face) use 2019 vertices of a possible total of 3989 (this is from one of the functions that checks overflow). Unfortunately, the debug only runs on the title screen, but I guess 4this information could be useful. There's also indicators of "Mtx/Light/Gfx" which I have to check out.

Your findings could be really useful, I'll bet you are able to include such a debugger into the game by default.

No one should underestime the value of such a tool for level editing as it's something you can simply rely on when you're creating a level.

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

Posts: 443/621
EXP: 1136481
For next: 20638

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-21-09 01:57:01 AM (last edited by VL-Tone at 04-20-09 11:37 PM)

Link

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

Originally posted by Gecko

Thank you for taking the time to answer my questions!

I understand what you mean and those baked shadows always looked darker than everything else in the game.

Do you know if the fog changes anything enginewise, e.g. allowing more geometry to be used because it adds vis-blocking? Visibility blocking refers to the engine not drawing level geometry behind a certain distance such as the object vis-blocking (objects will pop up when you reach a certain distance).
Is there vis-blocking when creating two rooms which are completely seperated from each other or is the level geometry always fully drawn?

You told us that your spiral level almost reached the engine limitations. I've been creating maps for the half-life engine which has a lot of limitations and there you have to possibility to lower the number of leaves by upscaling the texture.

On this picture every square resembles a leaf.
If you scale the texture up or down, the leaf also becomes bigger or smaller. The more leaves there are, the more often a texture gets repeated and the more hardware ressources are used resulting in reaching engine limitations when a texture often gets repeated/when there are many textures and texture recurrences drawn.

This would usually mean that you aren't able to create huge levels, but look at Banjo-Tooie for example. Rare created huge levels by scaling textures up, maybe it's also possible with Mario 64.
There are some maybe unwanted texture recurrences in your spiral map. If you look at 1:58 in the video, you'll see that the texture is scaled down. If you're able to scale it up again, you will maybe be able to set some more polygons free. Additionally, you could scale the texture in the whole map up in order to free up polygons if this experiment worked.

Does Mario 64 have a debug menu? Maybe there would be a subitem showing you how many polygons are drawn helping you with the engine limitations.

The spiral level reached a RAM limitation, not an engine limitation. But since then, thanks to messiaen, I added support of Extended RAM in v0.6b and the limitation will become more about the polygon draw speed than anything else. I haven't tested what would be the limit without having that RAM limitation (because the importer is not fully functional at this point), but it should be higher than what the un-extended RAM allowed.

The texture system you describe is simply not practical using the standard polygon drawing micro-code in Mario 64. The main problem with the N64 is the very small texture cache, which is only 4k (only enough to store a single 32x64 texture at a time).

For Banjo-Kazooie and Banjo-Tooie, Rare completely bypassed the standard N64 drawing libraries with custom micro-code and found some work-around for the small texture cache, and doing the same with Mario 64 is not realistically feasible.

As for polygon count in existing levels, it should be trivial for me to count them using TT64...

Edit:

Here's the polygon count for almost every level according to TT64. It includes polygons from objects found in the level and not only the level geometry.

 Haunted House        : 21831*

 Cool Cool Mountain   : 3828 

 Inside Castle        : 18658*

 Hazy Maze Cave       : 22521*

 Shifting Sand Land   : 5022 

 Bob-Omb Battlefield  : 8246 

 Snow Man's land      : 2984 

 Wet Dry World        : 3352 

 Jolly Roger Bay      : 5310 

 Tiny Huge Island     : 9154 

 Tick Tock Clock      : 4141 

 Rainbow Ride         : 6700 

 Castle Grounds       : 4028 

 Bowser 1 Course      : 5081 

 Vanish Cap           : 1092 

 Bowser's Fire Sea    : 3100 

 Secret Aquarium      : 424 

 Bowser 3 Course      : 5317 

 Lethal Lava Land     : 2356 

 Dire Dire Docks      : 1464 

 Whomp's Fortress     : 3832 

 Castle Courtyard     : 1826 

 Peach's Secret Slide : 2152 

 Metal Cap            : 1963 

 Wing Cap             : 954 

 Bowser 1 Battle      : 6394 

 Rainbow Clouds Bonus : 4196 

 Bowser 2 Battle      : 6466 

 Bowser 3 Battle      : 6664 

 Tall Tall Mountain   : 6141

*The Haunted House, Inside Castle and Hazy Maze Cave have much more polygons because they're using a "room" system, which only display the room Mario is in (and sometimes, other connected rooms) instead of the whole level at the same time. Doors are used to trigger the room set changes.

Here's an early animation I made of the Haunted House rooms:

Note also that these poly counts don't include sub-areas.

____________________

Nikodude
User
Level: 9

Posts: 10/10
EXP: 2193
For next: 969

Since: 03-01-09

From: Denmark

Since last post: 13.0 years
Last activity: 12.4 years

Posted on 04-21-09 06:45:21 AM

Link

I have a little question about 0,7b.
Will i be able to import a Luigi object and place it in a level and give it Mario behavior?

____________________
Layout removed. Completely unreadable. --Xkeeper

BigBrain
Member
Level: 22

Posts: 21/85
EXP: 55318
For next: 3032

Since: 09-10-08

Since last post: 8.9 years
Last activity: 6.8 years

Posted on 04-21-09 09:16:23 AM

Link

Originally posted by "VL-Tone"

*The Haunted House, Inside Castle and Hazy Maze Cave have much more polygons because they're using a "room" system, which only display the room Mario is in (and sometimes, other connected rooms) instead of the whole level at the same time. Doors are used to trigger the room set changes.

Would this room system be non-trivial to add support for in TT64 once you've added the possibility to load more than one model into a level? Sounds just like some command which is called by the behavior scripts of the doors to me, so it seems to be pretty simple, but on the other hand I know nothing about ROM hacking

Stevoisiak
Member
Level: 38

Posts: 245/283
EXP: 345780
For next: 24667

Since: 11-22-07

From: New York, Long Island

Since last post: 12.4 years
Last activity: 5.6 years

Posted on 04-22-09 08:03:39 PM

Link

Originally posted by Nikodude
I have a little question about 0,7b.
Will i be able to import a Luigi object and place it in a level and give it Mario behavior?

You will only be able to replace the main level geometry. Objects and Mario have animations that wouldn't work with model importation so easilly, especially mario with his complex animations. There is a built in Luigi Model though.

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

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

Posts: 444/621
EXP: 1136481
For next: 20638

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-23-09 02:37:48 AM (last edited by VL-Tone at 04-22-09 11:39 PM)

Link

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

Originally posted by BigBrain
Originally posted by "VL-Tone"

*The Haunted House, Inside Castle and Hazy Maze Cave have much more polygons because they're using a "room" system, which only display the room Mario is in (and sometimes, other connected rooms) instead of the whole level at the same time. Doors are used to trigger the room set changes.

Would this room system be non-trivial to add support for in TT64 once you've added the possibility to load more than one model into a level? Sounds just like some command which is called by the behavior scripts of the doors to me, so it seems to be pretty simple, but on the other hand I know nothing about ROM hacking

Well I'm still not sure how it works. I once understood how the hierarchy of room sets was working (actually, a very early unreleased version of TT64 had some widget to choose which room set to display), but I never found how the game switched between them. I thought it was doors, but its not.

You can make this simple experiment in the castle: remove all doors (except the front doors) by moving them out of the way. When inside the castle, you'll see that other rooms appear black until Mario gets close to the door.

The thing is, there's no special collision floor there to detect when Mario is in front of the door. And it's not simply a matter of Mario being close to the other room, because you'll see that you can make the other room appear when being in front of the wall, but only when you are close (left or right) to the door. So there's something that triggers the room change according to proximity, but not to the whole room, but rather a single point in space.

Another thing that's triggered by something unknown, is the camera modes inside rooms when you crosse the door frame. For example, in the castle lobby, the camera is fixed, but as soon as you crosses the door frame, it changes to a non-fixed camera.

Now that I think of it, the room change triggers coordinates are probably at the same place as the camera mode change triggers, and it would be very very useful if we could at last find where they are, as they will cause problems in certain levels being replaced by custom geometry. I tested flatworld replacing other levels, and there was some crazy unexpected camera mode changes happening when using levels like inside the castle and haunted house.

____________________

Gecko
Member
Level: 25

Posts: 12/113
EXP: 83089
For next: 6531

Since: 03-27-09

Since last post: 9.1 years
Last activity: 7.7 years

Posted on 04-23-09 01:48:28 PM

Link

It could be a z-coordinate, because the room behind the portal also is shown when Mario levitates above the portal and it makes perfect sense that the portal triggers camera movement, like you said. Therefore it could be the same system used for camera changes inside the levels.

Bob-omb8194
Still Explodin'
Level: 80

Posts: 154/1654
EXP: 4670274
For next: 112695

Since: 02-19-09

From: NC, US

Since last post: 10.8 years
Last activity: 10.8 years

Posted on 04-23-09 09:26:55 PM (last edited by Bob-omb8194 at 04-24-09 03:39 PM)

Link

Will there be a option to export the origional models from their levels, so we can edit them how we want?

BigBrain
Member
Level: 22

Posts: 23/85
EXP: 55318
For next: 3032

Since: 09-10-08

Since last post: 8.9 years
Last activity: 6.8 years

Posted on 04-24-09 09:09:00 AM

Link

Originally posted by Bob-omb8194
Will there be a option to export the origional models from their levels, o we can edit them how we want?

It's not a very comfortable way, but you can do this already with a program called OGLE (OpenGL Extractor).
If you run SM64 in an emulator using OpenGL, OGLE catches all OpenGL calls (i.e. also the model drawing functions) and can export the rendered objects to a .obj file. So, if you see the model you want to export in the game, you just press some button (see OGLE readmes...), open the .obj file in , remove all "unimportant" vertices (it can't export a specific object but only the whole scene unfortunately) and save it.

Sounds quite complicated, but honestly: If you got the grip it's actually fairly easy

The only drawback would be that you can't export animations that way, but on the other hand I don't know if SM64 even uses any special animation system for enemies.

I think that writing a model exporter shoudn't be too hard though. You need to know where the model data is located and how it is structured. If one has only a bit programming experience, everything else is simple... Assuming, it's the same for 90% of the game's models, of course.

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

Posts: 445/621
EXP: 1136481
For next: 20638

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-25-09 03:35:22 AM

Link

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

Seeing all the nice level models people built, and how some of them would need multiple-textures, I began to think about how I could easily add multi-texture support in 0.6b...

What I realized is that it wouldn't be that hard. I had big plans for 0.7b so you'd be able to manually set textures to groups of objects and even to the polygon level, right in TT64. The idea was that I wanted to avoid using the .mtl file and external texture files that come with them, simply because there's too much variation on how these are generated by different 3d programs (some use relative file paths for textures, some don't, and they use different types of bitmap textures which TT64 can't all import, and some programs have broken/insufficient support for .MTL files).

But in my planning to avoid using .MTL files, I overlooked a simple solution that doesn't require a complex interface to manually assign textures to groups and polygons inside TT64...

OBJ files use a command called "usemtl texturename" to specify which texture to use for the following faces found in the file. The texture name in the usemtl command is pointing to a set of material parameters in the external .MTL file which also includes the texture file path. What I could do is simply ignore the .MTL file, but still use the usemtl commands found in the .OBJ command.

TT64 would list the texture names found in the .OBJ file, and offer to associate each of them with a 32x32 texture which would be importer right in TT64. When building the N64 polygon draw list code, it's simply a matter of inserting a "texture change" sequence of commands to switch the texture for the following triangles.

Overall, it wouldn't be that hard to implement. The hardest part would be to conceive the interface for the texture list. And to avoid having to create some pop-up menu interface, I would ideally need to extend the width of the importer's interface to 1024 to add the texture list on the right side.

When I first released TT64, a few (very few) people still had 800x600 monitors (laptops) so I always tried to make the interface in these, but hey we're in 2009... If you don't have at least a 1024x768 monitor, well just too bad.

Now the texture list interface in itself is not that complicated to do. The texture associations would be saved in the .T64 level file along with the other parameters. To keep things simple, there would be a fixed maximum number of textures (maybe 12 or 15, what do you guys think?) per level. The complex stuff would be dealing with situations where the texture names, order or amount changed since the last .OBJ importation in a given level file.

Ok, now that I've over-explained myself again. Here's the deal: I found a way to easily add multi-texture support for the importer in 0.6b, but that would mean a few more days of work. But... since my "real-life" job is keeping me busy and I only have 2 days off per week where I can really have time to work on it, this means a few more weeks of waiting.

The poll still indicates that the majority is ready to wait more if it means that the importer will be more "full featured". But seeing you guys starting to get excited about creating polygon models in Blender, it's a little disconcerting not to be able to release it earlier. Still as you guys create more and more level concepts, it becomes clearer and clearer that the real fun would be to have multi-texture import...

____________________

Hectamatatortron
Member
Level: 35

Posts: 148/232
EXP: 258215
For next: 21721

Since: 09-19-07

Since last post: 7.2 years
Last activity: 5.3 years

Posted on 04-25-09 04:48:37 AM

Link

About the room loading and camera mode changing:

Surely you can set a breakpoint on reads of Mario's coordinates and find the assembly related to the process?

I wonder if the coordinates are used to specify a sphere (probably with fixed radius) rather than a point.

____________________

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

Posts: 447/621
EXP: 1136481
For next: 20638

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-25-09 05:21:59 AM (last edited by VL-Tone at 04-25-09 02:23 AM)

Link

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

Originally posted by Gecko
It could be a z-coordinate, because the room behind the portal also is shown when Mario levitates above the portal and it makes perfect sense that the portal triggers camera movement, like you said. Therefore it could be the same system used for camera changes inside the levels.

I forgot to reply to this post...

I think that you mean a 2d coordinate on the horizontal plane? That would make sense, since the camera modes were switching in flat-world even though the floor is probably not at the same height as the floors found in the original levels.

That would explain why the castle is actually separated in 3 levels, so that the triggers don't overlap between the first, second floor and the basement.

Originally posted by Hectamatatortron
About the room loading and camera mode changing:

Surely you can set a breakpoint on reads of Mario's coordinates and find the assembly related to the process?

I wonder if the coordinates are used to specify a sphere (probably with fixed radius) rather than a point.

From what Gecko said and my own experiments, it could be more like a circle on the floor.

As for setting up a breakpoint and trying to find the code/coordinates by observing RAM, messiaen or yoshiman (yoshielectron) would be more qualified than me to do that.

____________________

Gecko
Member
Level: 25

Posts: 19/113
EXP: 83089
For next: 6531

Since: 03-27-09

Since last post: 9.1 years
Last activity: 7.7 years

Posted on 04-25-09 07:14:45 AM (last edited by Gecko at 04-25-09 04:16 AM)

Link

Originally posted by VL-Tone
Seeing all the nice level models people built, and how some of them would need multiple-textures, I began to think about how I could easily add multi-texture support in 0.6b...

What I realized is that it wouldn't be that hard. I had big plans for 0.7b so you'd be able to manually set textures to groups of objects and even to the polygon level, right in TT64. The idea was that I wanted to avoid using the .mtl file and external texture files that come with them, simply because there's too much variation on how these are generated by different 3d programs (some use relative file paths for textures, some don't, and they use different types of bitmap textures which TT64 can't all import, and some programs have broken/insufficient support for .MTL files).

But in my planning to avoid using .MTL files, I overlooked a simple solution that doesn't require a complex interface to manually assign textures to groups and polygons inside TT64...

OBJ files use a command called "usemtl texturename" to specify which texture to use for the following faces found in the file. The texture name in the usemtl command is pointing to a set of material parameters in the external .MTL file which also includes the texture file path. What I could do is simply ignore the .MTL file, but still use the usemtl commands found in the .OBJ command.

TT64 would list the texture names found in the .OBJ file, and offer to associate each of them with a 32x32 texture which would be importer right in TT64. When building the N64 polygon draw list code, it's simply a matter of inserting a "texture change" sequence of commands to switch the texture for the following triangles.

Overall, it wouldn't be that hard to implement. The hardest part would be to conceive the interface for the texture list. And to avoid having to create some pop-up menu interface, I would ideally need to extend the width of the importer's interface to 1024 to add the texture list on the right side.

When I first released TT64, a few (very few) people still had 800x600 monitors (laptops) so I always tried to make the interface in these, but hey we're in 2009... If you don't have at least a 1024x768 monitor, well just too bad.

Now the texture list interface in itself is not that complicated to do. The texture associations would be saved in the .T64 level file along with the other parameters. To keep things simple, there would be a fixed maximum number of textures (maybe 12 or 15, what do you guys think?) per level. The complex stuff would be dealing with situations where the texture names, order or amount changed since the last .OBJ importation in a given level file.

Ok, now that I've over-explained myself again. Here's the deal: I found a way to easily add multi-texture support for the importer in 0.6b, but that would mean a few more days of work. But... since my "real-life" job is keeping me busy and I only have 2 days off per week where I can really have time to work on it, this means a few more weeks of waiting.

The poll still indicates that the majority is ready to wait more if it means that the importer will be more "full featured". But seeing you guys starting to get excited about creating polygon models in Blender, it's a little disconcerting not to be able to release it earlier. Still as you guys create more and more level concepts, it becomes clearer and clearer that the real fun would be to have multi-texture import...

That's great news! Your solution to the texture loading issue seems reasonable and it raised a smile when I read about finding the solution to be the hardest part of the problem.

From my point of view, 12-15 textures should be enough, at least for now. I think it's pretty much dependent on how detailed a map can be. If I left my map in its current state, I should get along with maybe 8 textures. As soon as I'd to like to add e.g. rails on top of the building, I'd need a little more. If there's no limitative factor, which could be bugs resulting from the implementation of the RAM extension, I'd suggest a texture number somewhat higher than originally used in every Mario 64 level - (Bob Omb outputs at least 15 level textures excluding object textures).

For the resolution issue, I'd say that 1024x768 was a standard some years ago, it's higher now, but it should be ok as it would leave editing on older machines possible. Speaking off topic, Steampowered has been collecting user machine information for years, you can see the results on the following page: Hardware survey.

Originally posted by VL-Tone

I think that you mean a 2d coordinate on the horizontal plane? That would make sense, since the camera modes were switching in flat-world even though the floor is probably not at the same height as the floors found in the original levels.

That would explain why the castle is actually separated in 3 levels, so that the triggers don't overlap between the first, second floor and the basement.

That's exactly what I thought!

Also, thank you for your comment on my map.

messiaen
Catgirl
Level: 68

Posts: 548/1085
EXP: 2596320
For next: 132480

Since: 11-20-07

Since last post: 8.1 years
Last activity: 7.2 years

Posted on 04-25-09 08:00:52 PM

Link

Since you are taking your time to get the importer to a more usable state (which I think its great), there are a few other modifications that could be done right now.

I think it would be very important to move the behavior bank to an extended area of the ROM so it can be expanded. While new behavior scripts could be placed into another banks, it will be much easier for TT64 to manage having them in only one bank, plus with the collision tables instead of hardcoded offsets its nice to have them acessible from all levels.

I have been using the range from 0x11B0000 to 0x11C0000 for this purpose, which is a bit after the last of the original extended banks, but that's only a suggestion.

What I'm thinking of is that, once the behavior bank is expanded and loaded into extended memory, it will be possible to have some sort of tool that injects new game and creates appropriate behavior for them, so we can have easily insertable "ASM" hacks.

Hectamatatortron
Member
Level: 35

Posts: 150/232
EXP: 258215
For next: 21721

Since: 09-19-07

Since last post: 7.2 years
Last activity: 5.3 years

Posted on 04-25-09 08:08:30 PM

Link

Originally posted by VL-Tone
As for setting up a breakpoint and trying to find the code/coordinates by observing RAM, messiaen or yoshiman (yoshielectron) would be more qualified than me to do that.

Eh, I could probably do it too.

Whether I will is a mystery...

____________________

messiaen
Catgirl
Level: 68

Posts: 549/1085
EXP: 2596320
For next: 132480

Since: 11-20-07

Since last post: 8.1 years
Last activity: 7.2 years

Posted on 04-25-09 10:28:14 PM (last edited by messiaen at 04-25-09 07:28 PM)

Link

Originally posted by Hectamatatortron
Originally posted by VL-Tone
As for setting up a breakpoint and trying to find the code/coordinates by observing RAM, messiaen or yoshiman (yoshielectron) would be more qualified than me to do that.

Eh, I could probably do it too.

Whether I will is a mystery...

We really could use some help from an experienced hacker

, I have tried a few times to find for instance how hardcoded camera positions work (especially level-specific, which depends on the current "level id" at 0x8032ddf8) without success.

VL-Tone, do you have any notes about how the "room" system works?

Hectamatatortron
Member
Level: 35

Posts: 151/232
EXP: 258215
For next: 21721

Since: 09-19-07

Since last post: 7.2 years
Last activity: 5.3 years

Posted on 04-25-09 11:40:30 PM

Link

You might be getting more help from me than you'd expect if Blender causes our goals to coincide still more.

I've been wanting to get a hold of those C files and tweak them to be more visually appealing to me as well, so that I'll feel more comfortable using and adding to them.

____________________

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

Posts: 451/621
EXP: 1136481
For next: 20638

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-26-09 04:14:03 AM (last edited by VL-Tone at 04-26-09 01:14 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
Originally posted by Hectamatatortron
Originally posted by VL-Tone
As for setting up a breakpoint and trying to find the code/coordinates by observing RAM, messiaen or yoshiman (yoshielectron) would be more qualified than me to do that.

Eh, I could probably do it too.

Whether I will is a mystery...

We really could use some help from an experienced hacker , I have tried a few times to find for instance how hardcoded camera positions work (especially level-specific, which depends on the current "level id" at 0x8032ddf8) without success.

VL-Tone, do you have any notes about how the "room" system works?

To avoid going out of topic, I've created this thread: http://jul.rustedlogic.net/thread.php?id=4825 where we can discuss multi-room levels.

____________________

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

Query execution time:	0.157678 seconds
Script execution time:	0.044852 seconds
Total render time:	0.202530 seconds