Jul -- Posts by VL-Tone

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

Posts: 470/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 05-03-09 01:26:13 AM, in Super Mario 64: The Missing Stars RELEASED! (Download link on first post) (last edited by VL-Tone at 05-02-09 10:26 PM)

Link

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

messiaen:

I didn't have time to check the mod yet, but I just uploaded a new version of the ROM extender: 1.3b, which mainly addresses the problem with the different padding bytes between platforms.

The only important difference in 1.3b is in the Mac version, the padding is now done using 0x01 instead of 0xFF, to match the Windows version. Mod patches for Windows ROMs should now work on Mac ROM extended using 1.3b

In the Windows version, I added a dummy text file to the MIO0files folder to make sure that it gets unzipped (for some reason, some unzipping utilities on Windows don't extract empty folders)

If you are on Windows and your ROM extender already works, you don't need version 1.3b.

The M64 ROM Extender v1.3b can be downloaded on this page:

http://homepage.mac.com/qubedstudios/Mario64Tools.htm

Here's a direct link to the Mac version: http://homepage.mac.com/qubedstudios/M64ROMExtender1.3bMac.zip

____________________

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

Posts: 471/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 05-12-09 03:55:18 AM, 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 OniLink10
Not sure if this has been asked already(Don't want to read through 16 Pages of Questions), but can anyone teach me about the 1-6 Bit Floating Point S,T Coordinates used for storing the Texture Locations in ROM? What I mean is Bytes 9-12 of the Level Geo's Vertices. I've tried Googling and searching the documentation, yet can't find anything.

I had a pretty hard time finding anything about the texture coordinates format, since it was only described by the n64 devkit documentation as the "10.5 format" and I couldn't find anything about it.

What I eventually discovered is that the format is based on the IEEE-754-1985 "Binary Floating-Point Arithmetic" format, but using only 16-bits, with 10 bits used for the significand ( or mantissa) and 5 bits used for the exponent (plus one sign bit).

Here's the wikipedia entry for IEEE-754-1985: http://en.wikipedia.org/wiki/IEEE_754-1985

This format is also known as "s10e5" and is used by some recent graphic cards (nVIDIA) on a low-level.

Check out this document describing a s10e5 c++ class definition: http://www.mrob.com/pub/math/s10e5.h.txt

I had found a pretty nice document which help me a lot to write a decimal-to-s10e5 converter for use with the TT64 level importer, but I can't find it... It's been a few months since I've worked on it so I couldn't really teach you how it works from the top of my head.

____________________

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

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

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.

____________________

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

Posts: 473/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 05-13-09 03:14:03 AM, 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 OniLink10
Hrm, just tried loading my ROM(edited the Level by hand, may have missed something), and I get an error when it begins to render: Value out of Range. What do you think it could be? I have no idea what part of my code is causing this, so I'll just post it all:

----------

I also changed the Level Script to have the Polygon Pointer, Level Start/End, and Collision Pointer correct, so I don't know what could be wrong. Also, the Level is at ROM Address 0x1203000. If I need to give any more info, I will!

I can see two problem with your script:

The first one is minor, in the sense that it should cause any error in either TT64 or an emulator:

03 86 00 10 07 00 01 5C

03 88 00 10 07 00 01 60

Your pointers to the two shading colors are off. They should be pointing at 0x140 and 0x144, which is where you find FF FF FF FF and A0 A0 A0 FF respectively.

The second problem is a big one and will cause an error in both TT64 and an emulator. You didn't change the number of vertices to be loaded by the 0x04 command.

04 30 00 00 07 00 00 00

See that 0x30 value in the second byte? It should be 0x70 because you changed the number of vertices to 8 instead of 4.

Calculating this value is pretty simple: (number of vertices-1) X 16. Another equivalent way is simply set the low nibble (the left "digit" of the byte) to the number of vertices minus one. If you have 5 vertices, you'll get 0x40. If you have 11 vertices, you get 0xA0. The limit is 16 vertices per 0x04 command (0xF0) and is a limitation of the SM64 3d drawing lib.

So in case you didn't completely understand, you should change the line to this:

04 70 00 00 07 00 00 00

and it should work, unless there are other problems I didn't spot.

As for texture coordinates (S,T or U,V), they represent the corresponding positions of vertices on a 2d texture. If you scale the texture coordinates, you can change the relative texture size, but that's just a side effect of it, their main purpose is to map 2d textures into a 3d object. I suggest you do some research about texture mapping.

____________________

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

Posts: 476/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 05-15-09 03:04:48 PM, in Super Mario 64: The Missing Stars RELEASED! (Download link on first post)

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 wowfunhappy
Great job everyone who made this game. It's fun.

I'm purely curious: do you think it would work on actual N64 hardware?

It reaches the custom title screen, but levels don't work (not sure about the file select). I'm working on a separate patch that may work on a real N64, it's probably a (hopefully simple to fix) issue with the way the ROM is extended, since the normal extended ROM crashes at the same point.

Cellar Dweller mentioned while ago that the extended ROM wouldn't work on a real n64 because the repointed bank addresses are not multiple of 4, which doesn't matter in an emulator, but causes problems on a real n64. Unfortunately I didn't know that when I created the extender.

____________________

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

Posts: 477/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 05-18-09 05:31:08 PM, in Super Mario 64: The Missing Stars RELEASED! (Download link on first post)

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 VL-Tone
Cellar Dweller mentioned while ago that the extended ROM wouldn't work on a real n64 because the repointed bank addresses are not multiple of 4, which doesn't matter in an emulator, but causes problems on a real n64. Unfortunately I didn't know that when I created the extender.

hcs (the guy behind the USF format) did a quick test using Cellar Dweller's extender to round the address so that they are aligned (using an 16-byte alignment, all addresses ending in 0, as for some reason I don't understand just being word-aligned isn't enough) and the extended ROM worked, when I fnish the updated patch we'll see if the hardware can handle the expansion pak memory correctly.

Edit: I finished the aligned patch. That was the reason why the extended ROM wouldn't t run on Nemu, it's the only emulator that accurately emulates the alignment isssues:

The next version of Toad's Tool 64 could be a good opportunity to correct this problem, since Nemu's debugger is still unmatched and Project 1.4 is a pain to work with.

Oh I forgot, it's indeed a 16 bytes alignment issue, not 4 bytes.

You're right, TT64 0.6 would be the best opportunity to make drastic changes to the extended ROM format. I was already doing some changes to the ROM inside TT64, such as extending it to 32MB, and patching for extended RAM support, but I think it would make more sense to do all of this into an updated ROM extender that would move the MIO0 banks to 16 bytes aligned addresses.

I'm not sure I could/want to maintain backward compatibility with the old extended ROM format though. It wouldn't be that bad since many SM64 modders will probably scrap their old projects anyway and start creating entirely new levels when 0.6b is released. I'll keep version 0.5.9xx available for download for editing older projects. Maybe I should change the .ext extension to something else to make it easier to differentiate between extended ROM versions.

BTW I recently upgraded to Director 11.5, which includes (at last) a new byte array container type, and ways to use the built-in FileIO commands to load and save binary data into those containers (instead of using external plug-ins and managing bytes into general purpose value lists). This may mean much faster loading/saving/decoding routines, though implementing the new commands would require a partial rewrite.

____________________

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

Posts: 478/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 05-18-09 05:47:37 PM, in Toad's Tool 64 v0.5.994b bugfix release! Bug reports go here!

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 OniLink10
I've had some troubles with the little "Act Bar". Every time I click a certain star, a random star other than that one lights up/dims down. Why is this?

I get this error sometimes too. Also, there's maybe a problem in the way TT64 handles the act bits of the 0x24 level command. Since there are only 6 acts, there should be no value higher than 0x3F (all 6 bits set), but in some circunstances TT64 will save values higher than that in the ROM.

Was there more than one object selected? Anyway I'll check to see what I can do about it.

____________________

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

Posts: 479/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 05-19-09 12:38:49 AM, in Super Mario 64: The Missing Stars RELEASED! (Download link on first post)

Link

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

Originally posted by messiaen
I'm sure people won't mind incompatibility issues, as there's always the option of using old versions of Toad's Tool 64 for smaller hacks.

By the way, did the extended memory patch worked ok? I can work on a few more patches for the new ROM, one of them - which I'm already working on - being a small adition to one of the water functions so that it can read additional pointers from a table into extended memory. This way we can have many new water boxes without messing with the original pointers.

Yes extended RAM support works very well, it's now fully implemented in the level importer. I'll give you guys an more detailed update about the progress soon.

If you can get the water function patch to work, I'll add a water box creation/editing feature in the importer.

____________________

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

Posts: 480/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 05-19-09 08:38:10 PM, in Beta Stuff Thread: Beta Trampoline and other stuff

Link

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

Not so long ago I made a thread about my quest to find an hex editor which could be used to visually color code known data inside the ROM to make it easier to find things we don't know about. Since I didn't find one, a suggestion by messiaen was to blank out known parts with zeros, so that only the "unknown" stuff would be left. I modified TT64 so that everything read while opening the ROM would be blanked out with zeros in another ROM.

My initial goal was to try to find the level-specific camera controls, and that would be very useful for version 0.6b, but I stumbled on some beta stuff along the way. (In other words, I wasn't intending on "wasting" time on doing something else than actually working on TT64...)

Some of you may already have found the yellow question mark texture with a red background. I had found it in the early days, but wasn't sure if it was in the game or not. With the blanked out ROM, it stood up as one of the unused texture in the game. And by looking for the texture pointer in the ROM, I found the polygon data, then the geo layout data.

Its found in the same banks (poly and geo) than the Cap switch, which was incidentally the only object used by the game in that bank.

The Geo Layout bank is at: 166BD0-166C60 and must be loaded in bank 0x0C using this command: 17 0C 00 0C 00 16 6B D0 00 16 6C 60

The polygon and textures are found at: 9109C4-913E8C in an extended ROM, and must be loaded in bank 0x05 using this command: 17 0C 00 05 00 91 09 C4 00 91 3E 8C

The object is split in 3 parts: One part is found at offset 0x00 in the geo layout, the other at 0x18 and the third at 0x30.

So I manually created 3 0x22 command and assigned them model IDs 54,55 and 56 which are in the range of model IDs for objects in bank 0x0C (ID 55 is taken by the cap switch).

22 08 00 56 0C 00 00 00
22 08 00 57 0C 00 00 18
22 08 00 54 0C 00 00 30

The geo layout scripts are:



0x00:

20 00 01 F4 

    04 00 00 00 

        15 01 00 00 05 00 16 B8

    05 00 00 00 

01 00 00 00 



0x18:

20 00 01 F4 

    04 00 00 00

        15 01 00 00 05 00 18 00 

    05 00 00 00 

01 00 00 00



0x30:

20 00 01 F4 

    04 00 00 00 

        15 01 00 00 05 00 19 00

    05 00 00 00 

01 00 00 00

This gives you the pointers of the polygon data inside bank 0x05.

The key missing thing here is the behavior script...

This thing looks like some air switch which would work much like the red ground pound switch in Super Mario Galaxy. Or maybe it's a trampoline. The line pattern on the red/yellow question mark texture indicates that this part would be compressed between the two checkerboard platforms when Mario jumps/pound on it.

There are two corresponding unused chunk of collision data in the polygon bank. One is at offset 0x1A28, and the other at offset 0x1AF4.

I've search through the behavior scripts, and found one "unused behavior" that points to collision data at offset 0x1A28:

ROM Addr: 0021B408 Hex Behav: 13001608

>>>>>>>>>>Unused Behavior?

21B408/001608  00 09 00 00

21B40C/00160C  11 01 00 01

21B410/001610  2A 00 00 00 05 00 1A 28

21B418/001618  2D 00 00 00

21B41C/00161C  08 00 00 00

21B420/001620  0C 00 00 00 80 2B 25 AC

21B428/001628  0C 00 00 00 80 38 39 CC

21B430/001630  09 00 00 00

But that may be just a coincidence and it may not be the right behavior script (bank 0x05 can contain other things depending on the level).

Using it with the object does work for creating solidity, but it renders the objects invisible... Maybe that's because the behavior code spawns the model themselves and that I didn't use the right model IDs. Someone could take a look at the two 0x0C routines and find which model ID they're supposed to spawn.

I didn't find any references to the collision map at 0x1AF4 in the behavior scripts, but again, that collision map may be spawned by the behavior ASM code (or maybe it was deemed useless, as it's for the inner question mark ring which is sandwiched between the platform).

One last note, there's a lot of other polygon data left in the "blanked" ROM, which may or may not be unused stuff in the game, but some of it are parts of models that TT64 just doesn't read because of some bugs.

____________________

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

Posts: 481/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 05-19-09 11:26:51 PM, in Beta Stuff Thread: Beta Trampoline and other stuff (last edited by VL-Tone at 05-19-09 08:27 PM)

Link

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

Originally posted by messiaen
Later on I may look more closely at the code, but one of the thing it does is to spawn two objects:

Behavior 0x1634 with model ID 0xB6
Behavior 0x2A48 (non-solid object) with model ID 0xB7

Behavior 0x1634 is probably the trampoline itself, because it stretches the object along the Y-axis. So, try to assign the red texture with question marks an ID of 0xB6 and the upper part (which is probably redrawn to conform to the new Y position as the trampoline is strechted)a model ID of 0xB7.

To make the trampoline itself show, try NOPing the instruction at 0x6D5B4.

Ok, I've made one of the platform 0xB5 (a guess), the other as 0xB7 and the question mark thing as 0xB6. I didn't NOP anything.

22 08 00 B5 0C 00 00 00
22 08 00 B6 0C 00 00 18
22 08 00 B7 0C 00 00 30

I've created a 0x24 object that uses the 0xB5 model, with behavior 0x1608.

24 18 01 B5 F1 04 E6 0D 04 AF 00 00 00 00 00 00 00 00 00 00 13 00 16 08

It does work as it spawns the rest of the trampoline at the right position with the correct collision, so it seems that it's indeed the right behavior for this object.

But while Mario can stand on it, jumping or pounding the platform doesn't do anything... Are we missing something or was this intended to be a static platform?

____________________

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

Posts: 482/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 05-20-09 01:23:45 AM, in Beta Stuff Thread: Beta Trampoline and other stuff (last edited by VL-Tone at 05-19-09 10:33 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
I'd say the Inner part between the two checkerboards looks slightly wooden, so maybe decoration? Or maybe it was intended to be a Trampoline, but then they made it static after realizing it looked too wooden and didn't want to have to go back and redo the Texture? If that were true, it would either be laziness on Nintendo's Part, or they were pressed for time, considering this was a release game.

Edit: I posted this seconds after messiaen post... I'll take the time to read it and try his suggestion.

Well the pattern reminds me more of an accordion type structure.

Incidentally, there are hexagonal-shaped accordion called concertinas.

I doubt very much that they changed the behavior from a trampoline to static just because they didn't want to have to change the texture, it simply doesn't make sense.

The most valid argument to show that is was intended to be animated is that it's made out of three distinct polygon models that each have their own geo layout script and are spawned and positioned by ASM behavior code.

They could've simply make a single polygon object, or combine them in a single geo layout script. There was no need to get into the trouble of programming ASM code to assemble the three pieces if it they were intended to be static.

It's possible that it can only work in certain circumstances, or maybe I made some mistake somewhere. It may also not react to Mario, but to another trigger, that would make the platform extend and stretch to reach a higher place.

____________________

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

Posts: 483/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 05-20-09 01:32:42 AM, in Beta Stuff Thread: Beta Trampoline and other stuff (last edited by VL-Tone at 05-19-09 10:35 PM)

Link

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

Originally posted by messiaen

Edit: VL-Tone, try inserting this object:

24 18 1F B6 F1 04 E6 0D 04 AF 00 00 00 00 00 00 00 00 00 00 13 00 16 34

Collision won't happen since its designed to be a child of the main trampoline, but when Mario is very near at least some animation (stretching along the Y-axis) should happen.

Nothing appears, the question mark ring is invisible, so I can't see what could be happening, and there's no sound either. I tried with or without the full trampoline in the same scene.

Edit: A little note, I chose 0xB5 as a guess for the "root" model, maybe I got lucky?

____________________

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

Posts: 484/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 05-20-09 03:01:52 AM, in Beta Stuff Thread: Beta Trampoline and other stuff

Link

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

I'm gonna try with the yoshielectron spawn code. Anyway it means that we have proof that it is supposed to be an animated object. Maybe the code is buggy and it's why it was not included in the final game?

____________________

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

Posts: 485/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 05-20-09 03:51:22 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

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.

____________________

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

Posts: 486/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 05-21-09 03:18:58 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (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.

____________________

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

Posts: 487/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 05-22-09 12:33:30 PM, in Beta Stuff Thread: Beta Trampoline and other stuff

Link

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

Originally posted by messiaen

The 0x1634 object is set to stretch along the Y-axis according to the Y position of its parent (the trampoline platform), however the ratio seems a bit off. With this corrected plus some increment in Mario Y's position to simulate an upward impulse (and maybe setting his action to that of exiting a cannon) a proper effect can probably be obtained.

Maybe you could set it to the action to the one he makes when bouncing of a fly guy? (when he says "boing!" and spins around).

Originally posted by Hectamatatortron
That looks more like an elevator than a trampoline, at the moment.

The texture does suggest trampoline, and Mario games have had trampolines since Super Mario Bros.

Looks like you've got more work to do if you want it to work right. I doubt it was supposed to be an elevator.

Well it could be some kind of elevating platform thing that's triggered by some action (such as activating a cap switch).

Originally posted by RomanianGirl
That's pretty awesome. Looks like Nintendo left a lot of objects for dead in the game.

Is it possible for you to create a .ppf of this ROM, for a chance to look around as well?

It's a good idea, I have to go to work now, but tonight I'll post a .ppf patch for the "blanked" ROM.

____________________

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

Posts: 488/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 05-22-09 12:53:55 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (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: 99798783	Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies	05-03-22 06:12:33 AM

Query execution time:	0.103796 seconds
Script execution time:	0.084302 seconds
Total render time:	0.188098 seconds