Jul -- Posts by VL-Tone

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

Posts: 530/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-11-09 02:24:25 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

I made a new video to demonstrate an imported level. (Thanks Gecko for your nice level!)

<object width="425" height="344"><embed src="http://www.youtube.com/v/QFK6xvrXRTI&hl=en&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>

____________________

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

Posts: 531/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-12-09 01:07:44 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by GhostMaster3000
I tried using your importer and when it said "parsing" and "not using mtl " it crashed and did not import the level, what did i do wrong???

For one thing GhostMaster3000, you did post in the wrong topic

I managed to import the Spiral Mountain with textures. I did struggle a lot to find the right texture scaling value, and its still not right. I'm pretty sure there's something wrong with my texture scaling value conversion function.

There's no simple way we'll ever get this level in SM64 to look like it did in Banjo Kazooie. Rare did create a completely new graphic engine to support higher res textures and other stuff. It uses 64x64 pixels textures that the SM64 engine doesn't support (it supports up to 32x64). The BK engine can combine multiple layers of textures, fading them into one another. Polygons are also colorized smoothly in a way I never seen in SM64.

Another thing, I found a lot of places where Mario would simply fall into the ground while walking and die. SM64's collision engine is very flaky, it was probably much more polished in BK.

____________________

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

Posts: 532/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-12-09 01:48:34 AM, in Mario 64 Level Importer

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by Stevoisiak
Originally posted by VL-Tone
As for Banjo Kazooie levels, I think we may run into problems with texturizing the model. Rare did write an entirely new engine to make use of higher resolution textures.

Can't the textures just be scaled down? Sure, they won't look as nice, but they'd work at a smaller resolution, right?

Yes they can be scaled down

But like I explained in the other thread, there's a lot of other stuff that the BK engine can do that the SM64 engine can't. For example the BK engine can combine 2 layers of textures, fading from one to the other, and can smoothly colorize textures.

Originally posted by messiaen
The scaling value will differ widely depending on how your .obj is laid out. The Mario 64 engine supports vertex values between -8192 and 8192. If your scaling is too big, the program will warn you and you should try using a smaller value. Floats are supported: for instance, if you want to scale down your object to 70%, use a value of 0.7.

SM64 supports vertex values from -16384 to 16384, but the collision engine will only work within the horizontal -8192 to 8192 boundaries, that is, Mario won't be able to reach anything outside of this, there will be an invisible wall at 8192. It could still be usefull to allow for values between 8192 and 16384, as you might want to include unreachable areas around you level (If you look at the Spiral Mountain level, there's a lot of space on the side that's unreachable and could be out of boundaries).

BTW, how do you handle texture coordinates conversion? I'm stuggling to find the exact right way. I got a 10.5 float conversion function, but I'm not even sure if it works correctly. I did manage to get some good scaling values, but if I change the value by even one decimal some of the textures get screwed up for some reason.

____________________

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

Posts: 533/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-12-09 10:39:54 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by wwwarea
Wow, that looks nice. Cant wait for this tool. Wow, Banjo Kazooie - Spiral mountain.

I have a question though, will Toads tool 0.6.0 import obj's into more then one level? I'm not sure if it will. I saw level slots and replacing Bomb omb battle field in the old screen shots.

Version 0.6b has 20 custom level slots, you can decide which level each slot will replace.

Originally posted by Breegullbeak

WOW! Just seeing that made me dislocate my jaw so it could reach the floor. I want this update more than ever now.

There were a few texture problems in those screenshots, namely they were flipped upside down. I fixed that and made a Youtube video which is currently processing.

____________________

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

Posts: 534/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-12-09 10:55:41 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 10-12-09 08:14 PM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

I think this model has like 4000+ polygons and uses 512k of RAM (half of what a level slot can contain). I forgot to tell you guys, there's a big problem in the current version of TT64, it will only read the first 2000 polygon commands, so levels like this won't show up completely. This was an artificial limitation I put back in the days to prevent it from reading data until the end of the ROM if something did go wrong. I removed the limitation in v0.6b.

Here's the Spiral Mountain video:

<object width="425" height="344"><embed src="http://www.youtube.com/v/t-PtJIFz2tI&hl=en&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>

Edit: Hmmm weird, this video appears in High Quality when emmbeded, but in crappy quality when viewed directly on Youtube (with no HQ button). And the two other videos I posted yesterday are now in crappy quality while they were in HQ yesterday.

____________________

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

Posts: 535/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-13-09 05:49:38 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by VideoGuy
Wow, that was amazing. I can see SM64 hacking becoming a lot more mainstream with this tool. It's good to see the SM64 engine can support a model like that without lagging, it gives me more confidence in the stuff I'm making with Blender.

I'm guessing from that video that TT64 doesn't use alpha when importing textures? Or was that the fault of the texture?

It's planned that TT64 v0.6b will be able to use the alpha channel for textures, but it doesn't currently. I didn't check, but I'm not sure that the texture provided for the BK level had their alpha channel (which by the way in SM64, is only 1-bit for color textures)

Originally posted by unintelligentgenius
Hey VL (I'm new here), I was wondering, what's a good face count on a new obj. imported into Toad's Tool?
Also, you can delete and replace mesh terrain, right?

Edit: Also, how do you make invisible walls? I assumed using a mesh with just an completely alpha'd texture.
Is that right?

Hi unintelligentgenius, welcome to the forum. I would say that you should be safe with around 3000 faces, but I haven't done extensive tests yet. This level is more than 4000+, but I didn't put any enemies.

Originally posted by messiaen
I was going to ask you about this , I noticed that only half of the level shows up in TT64. The Spiral Mountain looked very nice, I haven't played Banjo so I don't know how different it looks in that game. When importing the .obj file, I actually scaled down the vertex to 70% of the original size to avoid the invisible boundaries problem. I also noticed that at some points you just fall through the floor, but I thought it was a problem with my importer.

You may want to take a look at this to see how the level is supposed to look: http://img26.imageshack.us/img26/5456/clipboard01jcg.jpg

First there's the vertex coloring that's missing (it's not in the .obj file and I'm not sure the .obj specs support vertex coloring). SM64 can do vertex coloring, but I'm not sure it can do the same kind of coloring. Then there are the higher resolution textures, but what's really impossible to do in SM64 can be seen on the bottom left and middle right. The BK engine can gradually fade between two layers of textures. The leave pattern on the left is actually on top of a brown ground pattern and it fades between the two layers at places.

I checked the collision map my importer generated and it looks normal, there's no missing triangles. The SM64 collision engine is definitally flaky. I can't imagine how many hours they had to test every single levels to find holes in the collision maps. I would venture to say that the levels that were cut from the final game were cut not only because of space, but also because they were the ones that probably still had collision problems.

____________________

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

Posts: 536/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-13-09 06:10:35 AM, in Mario 64 Level Importer

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by messiaen
The 10.5 converion is easy, a long time ago I asked about it and Cellar Dweller said the texture coordinates are actually 10.5 fixed point, not floating point. The first 10 bits are the integer value and the remaining the fraction, so all you have to do is shift left 5 bits, that is, multiply by 32.

Now that you asked, I noticed that I handle the texture coordinates based on a misreading from one of your posts : I divide them by the biggest vt value and them multiply by scaling, which is probably not a very good method.

Damn I spent hours trying to get a a 10.5 floating point function working... That must explain why I had mixed results with it. It also explains why I could decode the coordinates for display in TT64 without some fancy math.

Anyway, even before reading your post I decided to scrap the 10.5 floating point function while working on the BK level. I observed the texture coordinates for simple objects in SM64 (cubes) and found that they were often 0x0 and 0x3DE. So what I did is multiply the texture coordinates from the .obj file by 990, transform this into a 16-bit signed integer and it seemed to work. I did have to offset the numbers a little to get a better result. So the equation I used is (S*990-30,T*990-40) and it was close enough to me.

I first thought I would have to "normalize" the texture coords like I did for the vertices, but I realized that texture coordinates had to be more standardized than vertices, the latter can vary greatly depending on the 3d program (some will ouput vertice values from 0.0 to 1.0 while other will output integers of varying ranges 0 to 1000+ for example). Texture coordinates on the other hand, have to be standardized so that 1.0 in all .obj files should mean the edge of the texture, and 2.0 would mean that the texture gets repeated 2 times, that's why they shouldn't be normalized.

____________________

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

Posts: 537/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-18-09 04:41:30 AM, in Post your SM64 mods, patches and screenshots here! (NO ROM LINKS!)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Nice work unintelligentgenius! I can't wait to see this textured.

BTW just a question, what is the face and/or triangle count on the original SMG model?

____________________

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

Posts: 538/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-18-09 05:30:04 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Welcome back xdaniel!

The thing is, despite having done a SM64 geometry decoder and an importer in TT64, I don't have a very deep knowledge of the actual GBI commands. Most of the reverse-engineering I did was through deductions and experimentation. So I'm not sure I understand how this SetCombine command works and how did you use it in your example. One thing I know is that what the Banjo Kazooie engine seems able to do is use two textured polygon layers and fade between them at the polygon level (not the texture level). It's kind of like they used vertex coloring but with an alpha channel.

Originally posted by Gecko
I just had another idea while viewing your latest videos. Maybe it could be useful being able to create prefabs which means putting two or more items together in a speacial manner saving them onto a "prefab slot". The next step would be selecting a prefab slot and create a copy of the very same object combination, e.g. a tree with a red coin on its top which could save everyone some time. Prefabs could be sharable so everyone could import prefabs created by other users, analogous/similar to your TT64 level file standard.

That's a good idea which I will probably implement in a future version. That makes me think: one of the interesting side benefit of the level file feature in the importer (which can contain objects from a level too, aside from the import parameters, the .obj file and textures.) is that clever people with some programming experience could feed mathematically calculated object positions in TT64.

Remember that first "flatworld" youtube demo I posted with the boxes making a spiral path? http://www.youtube.com/watch?v=SU6cIPdGllU. Some people were wondering how I did place the boxes in such a perfect spiral. It was easy for me since I have access to an "open version" of TT64, and I simply made a simple routine that uses SIN and COS to place the boxes at the right position in space.

With the "open" nature of the custom level file format in TT64 0.6 (which is a text file) some clever programmer could generate a level file that places objects in a level in a circle or whatever shape they want without having to move them manually in TT64. Here's an idea: someone could make a program that writes any text message you want in a level using coins (that reminds me of a program I did that would write messages in Starfox using asteroids).

____________________

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

Posts: 539/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-18-09 05:32:11 AM, in Mario 64 Level Importer

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by messiaen
Originally posted by sdtyson
i can do this perfectly now, i just need to know how to do the textures, without a texture you can barely see the shape of the level because its all plain green/ how do you change it???

Seems like your .obj file doesn't have texture coordinates, make sure your 3d modeller is exporting the texture mapping.

What does your importer do when there's no texture coordinates? Does it write zeros as the texture coordinate values?

____________________

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

Posts: 540/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-19-09 06:36:26 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by xdaniel
With the fading in BK you describe, do you mean ex. the fade-out at the level edge that can be seen in the Bottles' Glasses screenshot you've posted above, http://img26.imageshack.us/img26/5456/clipboard01jcg.jpg ? If it's that, I'm pretty sure that this actually isn't created by the combiner, because Bottles' Glasses doesn't even emulate it (as far as I can see from the program's source that cooliscool released some time ago).

Also, something I've been working on for a few days now: http://z64.spinout182.com/index.php?topic=391.0 - it's a tool that allows experimenting with and previewing combiner setups. Might be useful if anyone wants to mess with the combiner or so

btw, another multi-texturing experiment, this time using Flatworld as the base (which is way easier to work with instead of an imported Wavefront model in this case): http://magicstone.de/dzd/random/sm64_newcomb.png

I was talking more specifically about these parts:

Looking at the level in TT64, I can see (because of the flickering in those areas) that there are two polygon layers precisely on top of each other, with different textures. What you can see in the game and in these screenshots is that the ground fades smoothly between these textures in a similar way to vertex coloring. The version imported in SM64 only shows the top polygon layer.

Your program looks very interesting, it might help me understand this SETCOMBINE command better. I still don't have a suitable "transparent texture" header to be used in the importer, and I'm sure this command is involved in making the engine use the alpha channel from textures.

I might not include the transparency option in 0.6b, because I expect some big problems with mixing non-transparent and transparent textures. In SM64, parts of the level that are using alpha textures are drawn separately using their own 0x15 commands, which include a value that specifies the "drawing layer". Tree shadows, fences, windows on the castle, the rest of the levels are drawn on 4 separate layers. I presume that without this separation into layers, the engine will run into serious z-ordering issues. Shockwave 3d (the 3d engine used in TT64) has similar issues with transparent textures, but unfortunately no way to control the z-ordering at the polygon level (I mostly avoid these issues in TT64 by splitting the level into polygon chunks, but if you take a look at the Tick-Tock Clock level in TT64, you'll see that there are sill issues).

So to avoid these problems I would have to do a major rewrite of my importing code, as well as figuring out how to use this drawing layer value.

Now here's some progress update:

This is the latest version of the importer interface.

When you click "Save level to ROM" you'll be presented with this dialog box:

Before saving you'll have to choose in which level slot you want to save it, and which level in the game it will replace.

The "Manage Level Slots" button will present you with a similar interface, but will be used to change the replacing levels for levels already saved in slots.

The "Empty Objects Only" option will save your level with empty 0x24 objects. The number of objects can be set.

The "Keep existing objects" will keep the objects found in the slot you're saving to.

And lastly, the "Use Objects From File" will use the objects found in the current level file (the number of objects found in the file is in parenthesis).

By default, objects won't be saved in the level file. Automatic saving of the objects in the file had too many potential problems. While it's obvious that when you just saved a level in slot 2, that you want objects from slot 2 to be copied in the level file, if you open another ROM where there's another level in slot 2, TT64 would save the wrong objects. That's why you can only save objects in the level file when you check the option ("When Saving Level File Also Copy Objects") which btw has the checkbox missing in the screenshot. And when you do use this option, you'll be presented with a dialog where you choose/confirm which slots you want to copy the objects from.

It sounds a little complicated, but keep in mind that the only time you'll want the objects copied in the level file is when you want to move a custom level from one ROM to another (or from one slot to another), with its objects intact. You don't need a constantly updated copy of the objects in the level file for this purpose, and you can always go back to copy the objects even if you forget to check the option, because those are saved in the ROM when you edit them in the main level editor module.

Normally, what you'll want to use is the "Keep Existing Objects" option, so if you change your .obj file and reimport the level, the objects that were already in the level slot will remain.

Note: I just realized that the "Polys:" count in the screenshot is wrong, it should read 3136 polys (triangles) for this level.

____________________

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

Posts: 541/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-19-09 10:53:34 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 10-19-09 07:54 PM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by cooliscool

Yeah, OBJ doesn't support per vertex coloring. I could potentially "emulate" it using a color map but that would make the resulting file huge. I could add the RGBA values (8-bits each) to the file as comments which you could read in; and I eventually want to switch to VRML which supports them natively. I can also have it export combiner MUXs as comments for use in your importer. As Xdaniel said, the color combiner commands are globals, all ucodes can use them to the same extent.

The .png textures that BG makes do have their alpha channels (thus why they're PNG).

Edit: Here's a new obj file with vertex RGBAs and precompiled SETCOMBINE commands.

How to interpret them (they're formatted like any other .obj command, space delimited):
vc r g b a - vertex colors, as floats. Multiply by 255 to get 8-bit integer values. They share indices with vertices and texture coords.

cmb command - compiled color combiner (0xFC) command for the current group; stays the same for subsequent groups until the next instance. 

BK doesn't use SETPRIMCOLOR, SETENVCOLOR, or SETBLENDCOLOR, combiner generation relies solely on vertex shading, texel0 and texel1.

Welcome to jul cooliscool

Thank you very much for providing this modified .obj file, I'm currently working on making TT64 use it, but I noticed some little problems with the values for the "vc" command. It seems that the second parameter is repeated twice without any spacing...

vc 1 11 1

vc 0.345098 0.3450980.345098 1

vc 0.345098 0.3450980.345098 1

vc 1 11 1

vc 0.5490196 0.54901960.5490196 1

vc 0.4705882 0.47058820.4705882 1

____________________

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

Posts: 542/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-20-09 12:49:35 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 10-19-09 09:51 PM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Ok, here's what works well:

The only thing is that the level seems a little darker than it should be. I got this rainbow effect on Mario again, because I used the same buggy header I was using for transparency, which causes Mario to have vertex coloring instead of normals. I still have no idea how to fix this.

Now here's what doesn't seem to work:

While Gruntilda is improved because of the eyes, her whole face and hat is supposed to be colored green.

While the setcombine commands seems to make a difference in these two cases (before only the top texture would appear), the textures don't fade into each other like they should. Note that the textures now use their alpha channel.

Now I don't know who could help me here, but here's the "header" i'm using for each triangle group:

E7 00 00 00 00 00 00 00 

BA 00 14 02 00 10 00 00

B9 00 03 1D C8 11 30 78 

B9 00 02 01 00 00 00 00

F8 00 00 00 00 00 00 FF 

BC 00 00 08 0E 49 F2 B7

B7 00 00 00 00 01 00 00 

FC 12 98 04 3F 15 FF FF

B6 00 00 00 00 02 20 00 

BB 00 00 01 FF FF FF FF

F5 10 10 00 00 01 40 50 

F2 00 00 00 00 00 C0 7C

FD 10 00 00 09 00 58 00 

E6 00 00 00 00 00 00 00

F3 00 00 00 07 3F F1 00 

E8 00 00 00 00 00 00 00

FD 10 00 00 07 00 00 00 

E6 00 00 00 00 00 00 00

F3 00 00 00 07 3F F1 00 

03 86 00 10 07 02 68 00

03 88 00 10 07 02 68 04 

04 D0 00 00 07 02 68 08

BF 00 00 00 00 00 0A 14 

BF 00 00 00 00 1E 28 00

BF 00 00 00 00 32 3C 46 

....

Can anyone tell me what I'm doing wrong or maybe give me a better header to use?

____________________

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

Posts: 543/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-20-09 01:53:37 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by mortalkenshi2
I'm pretty sure VL-Tone made a thread awhile back about water hexing. (It was named super geeky hex hacking stuff + Geo or something.)

I'm still hesitant about adding water support in v0.6.0, I'll keep it as one of the last things I'll add, so if I don't have time before the end of the year, I'll release v0.6.0b, and water in 0.6.1 or 0.6.2.

Originally posted by mortalkenshi2
I remember reading about extra level slots in SM64. In Rstewarts collision editor that was in like Super Alpha Stage he had some extra levels listed there as well. Are those levels usable in game, and are we able to extend the number of stars that you can put in the game in total? (like SM64 DS) I think one cool thing would be to take DK64 levels and put them in here. DiD you recreate that level or did you get the model of it? (Probably got the model but worth asking)

The level slots in the level importer have nothing to do with the game's level slots. There are indeed a few unused level IDs in the game, but we can't use them yet because we still don't know where are some the basic level parameters. TT64's importer level slots are associated with existing level IDs (that's why you can only replace existing levels).

Originally posted by mortalkenshi2
Messiaen, your hack had the ability to switch between Mario & Luigi During the game select screen. Is it possible to like hit a cap and have the models switch or something mid game? Or maybe Your certain characters in certain levels and not others.

I'm pretty sure messiaen mentioned that switching from Mario to Luigi in game would cause problems.

Originally posted by mortalkenshi2
VL, Is that first screenshot where you said this is how its supposed to look from TT64? Or a different source?

Are you talking about this screenshot http://img26.imageshack.us/img26/5456/clipboard01jcg.jpg? This is from Bottle's Glasses, a nice tool by cooliscool that enables viewing and exporting BK levels to the .obj format, amongst other things.

____________________

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

Posts: 544/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-25-09 07:57:58 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 10-25-09 08:02 PM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Sorry guys for the time it took to reply, but like you may know, I work a lot during the week so I mainly post during the weekend (my days off are sunday and monday).

Originally posted by cooliscool

It looks like you're setting the geometry mode, then clearing it (0xB7 and 0xB6 respectively). Not sure of the point in that, you should probably clear then set. You shouldn't need the second SETOTHERMODE_L call (MDSFT = 0x02 (ZSRCSEL), not sure how it works), either. MDSFT = 0x03 (RENDERMODE) sets the current render mode. Try this:

...

That will disable lighting (so vertex colors are sent as colors), and enable back face culling. The new SETOTHERMODE_L command will force blending (FORCE_BL = 0x00004000) and disable alpha testing (CVG_X_ALPHA = 0x00001000). These are not fixes, you'll need to compute them dynamically for any sort of universality, as you surely well know. An interesting sidenote, both BK and Mario use F3DEX, and from what I can tell pretty much identically.

Edit: What is the purpose of drawing 3 triangles (the last 0xBF commands), for every group? Also, do you insert an ENDDL (0xB8 00 00 00 00 00 00 00) at the end of each list? I find it strange that paramaters set when drawing the level would carry over to Mario.

When I started reverse-engineering SM64, I didn't know that the display lists commands were already documented (I didn't know that emulators were using them for emulation), so I did a lot of this reverse-engineering by hand, trial-and-error and observation of the data structure. I did eventually got some hints from some more knowledgeable people to help me fix some issues, but since it worked in a "good enough" way, I never studied Fast3D commands thoroughly.

If there are some things that are illogical in my header, you can blame Nintendo as it was ripped from some object in the game (It's possible though that I made a mistake while ripping or that I did some modifications without knowing what I was doing). I never completely understood all steps necessary to "initialize" a display list sequence. Despite having built TT64, you three guys (cooliscool, xdaniel and messiaen) seem to know a lot more than me about RDP commands.

As for having only 3 triangles at the end, it's only because I didn't paste the whole thing (hence the "..." at the end) there are more triangles than that in the real thing.

I tried your header and while it did fix the "level too dark" problem, it broke Gruntilda's eyes texture transparency effect so it ends up looking like in the video.

Edit:

Now I get it... obviously as you explained, the SETOTHERMODE_L (0xB9) command you provided disables alpha testing so it was normal that Gruntilda's eyes didn't use the alpha channel as expected.

The thing is, the blending still doesn't occur, even worse the top texture completely takes over.

Here's with my header (fixed the rainbow Mario and the darkness problem):

Here's with yours.

In my header, the transition between the two textures is sudden, but at least some transition is happening.

Another thing I noticed using my header, when you pause the game, you can see where all the areas where blending is supposed to be happening, some gradual redrawing of one texture over the other, until the cut-off point (it happens in 1/3 of a second).

As for Guntilda's face not being colored green, it seems that it's an emulator problem with SixtyForce (Mac emulator) where it doesn't seem to apply vertex coloring everywhere for some reason. Mupen64 for Mac (which is an old port) has the same problem as both use the same gIN64 plug-in.

In PJ64, it does work correctly as you can see here.

Note that in PJ64 the blending doesn't occur either (though if I activate the "Force alpha blending" option, I do get the expected blending effect on the ground, but the rest of the level ends up being all translucent).

One last thing, I fixed the rainbow Mario problem by inserting the following commands before the 0xB8 command:

BB 00 00 00 FF FF FF FF 

E7 00 00 00 00 00 00 00 

BA 00 14 02 00 00 00 00 

B9 00 03 1D 00 44 30 78 

B6 00 00 00 00 01 00 00 

FC FF FF FF FF FE 79 3C 

B7 00 00 00 00 02 20 00

These are ripped from an existing model in SM64 (Red Mesh Wall).

Originally posted by messiaen

VL-Tone, nice progress with TT64! Do you still have plans to integrate the Text Wrangler into the interface? I ask because one thing I want to try soon is to move the text/level name/acts table to extended memory so it can be expanded freely.

The Text Wrangler code and interface has already been moved into TT64, but the actual integration with the rest of the interface will probably be done in version 0.6.5 or something.

____________________

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

Posts: 546/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-26-09 12:39:04 AM, in ToadsTool Suggestions

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by Breegullbeak
I know it'd be an incredible amount of work and may not even possible for another 10-15 years or so of constant hacking, but would it ever be possible to swap Mario's model out with other models? I've seen in another post that Mario has a skeletal structure made of poles inside of him. If you could insert his skeleton into another model, could it be done? I know this wouldn't come along for an incredibly long time, and it'd probably start with something relatively simple like a Goomba which messiaen has already hacked into, but could it happen from your current knowledge of the game(by this I mean from what is currently known, it's still hasn't been ruled out.)?

Well, using what we currently know, what could be eventually possible is replace each Mario body part with individually imported models. That means, any character replacing Mario would have to keep the same number of body parts and the same parts hierarchy.

____________________

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

Posts: 547/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-26-09 12:50:39 AM, in Help/Questions about Toad's Tool 64 and SM64 hacking

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by KingBoo10
Hello. I was wondering, how exactly do you change Mario's model to another character/enemy? I've been trying to figure exactly what object is Mario in the game and how to create it as a new object, and I'm having a bit of trouble in doing so...

The key word here is animation.

Sure it can be relatively easy to replace Mario with a rock or a tree, but to replace him with a character that can run, swim, hold things, do somersaults like Mario can, it's a completely different thing.

As I just posted in the other thread, we'll be eventually be capable of changing Mario into another animated character, but that will require a character that has the same body part hierarchy (ie. not a three-legged dog with two heads). Anything else would require hacking Mario's animation engine, and very little is known about it, and even when we'll know everything we can about it, hacking it will require a lot of work even if you have some motion-capture thingy in your house since Mario has a lot of different animations.

____________________

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

Posts: 548/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-26-09 01:35:41 AM, in Help/Questions about Toad's Tool 64 and SM64 hacking (last edited by VL-Tone at 10-25-09 10:36 PM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by KingBoo10

Well, can you still tell me how exactly is it done (I'm not sure how I did it)? Because I'm just experimenting at the moment, and I'm interested in working in that area, even if it's just as a rock or tree for now. Thanks in regards.

First, you have to choose the "Expert" commands mode (upper left of the interface). Then, in the command menu, scroll down a little and choose "0x22 Geometry Layout Pointer". Then, choose the first item in the list below ("001 Mario"). From the yellow list ("Set Geo Layout Combo") you can then choose the object to replace Mario. Then save the changes.

One important thing is that this object must be available in the level you want to play in. For example, if you replace Mario with Yoshi, it will only work in Castle Grounds. Note that animated objects like Yoshi will have messed up animations. There are Gameshark codes that can replace Mario with animated things without messing their animation too much.

____________________

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

Query execution time:	0.100128 seconds
Script execution time:	0.090157 seconds
Total render time:	0.190285 seconds