Jul -- Posts by VL-Tone

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

Posts: 186/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 01-26-08 03:02:39 AM, in FlatWorld Battlefield, Take Two (New flat empty level template! TT64 v0.5.98b!) (last edited by VL-Tone at 01-26-08 12:03 AM)

Link

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

Note: I trashed the original thread about FlatWorld Battlefield because it was mainly about debugging the first versions. As far as I know, TT64 0.5.8b works correctly and can enable FlatWorld on your ROM.

This is the first step towards creating entire levels from scratch, including the importation of new geometry.

FlatWorld BattleField is a big flat square that replaces Bob-Omb Battlefield. In itself, it can be quite boring, as the level is empty.

Hopefully, despite the boring aspect of the level, some people will realize that it has a lot of potential, as it can be used as a template to create brand new levels. There are over 150 object slots available. They're all 0x24 objects, which is a good thing, as 0x42 and 0x43 objects are only limited versions of 0x24 objects. The only objects that are enabled by default are the Mario Start warp, and the original BBB warps. The other objects are invisible because their "acts" stars are all off. To activate an object, just chose which act it should appear in, and then select an object combo. I also added a few 0x26 commands slots so you can create more warps than in the original level.

The available object combos are from BBB, but eventually it will be possible to select object banks from other levels.

This new level was created through a lot of manual hex hacking, and with the help of my development version of TT64. So for now it can't be easily replicated using other levels as a basis. Still I now have a very good idea of what is needed to create a new plain level automatically.

The polygon and collision data combined only take 108 bytes, so it's a good basic template to envision more complicated polygon models, and importation of external models. Keep in mind that between creating a flat square level, and importing complex polygon models, there's a lot work involved.

I documented and commented the changes and the whole level and polygon data in these documents:

http://homepage.mac.com/qubedstudios/FlatWorldBattleFieldHexData.txt
http://homepage.mac.com/qubedstudios/FlatWorldBattleFieldHexUncommented.txt

The uncommented version can be used as a template for editing the data "by hand", much like I did when creating the level.

You might also want to read this, which has other important info:

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

Flatworld Battlefield is available as a .PPF patch: http://homepage.mac.com/qubedstudios/FlatWorldBattleFieldPatch.zip

Editing the patched ROM requires a new version of TT64, which I'm releasing now: version 0.5.98b (sorry it wasn't worthy of being called 0.6b).

Download the new "interim" version of TT64 at http://homepage.mac.com/qubedstudios/ToadsTool64.htm

Note that the .PPF patch is not really needed, since TT64 0.5.98b can patch the ROM by itself. Just go to Preferences... and click on "Enable FlatWorld".

Important: Version 0.5.98b fixes an important bug that prevented FlatWorld enabled ROMs from loading on Windows version.

My next step is to create an "height terrain map" level, which will be generated from a 33x33 greyscale image, and a 32x32 bitmap that determines the texture used by each triangle. I'm currently working on it, but at the same time I'm really busy because of my work.

____________________

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

Posts: 187/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 03-24-08 03:12:54 AM, in Adobe Director 11 released March 25th.

Link

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

Hi,

Just dropping by to say hello

I know, I've done it again, disappearing for a few weeks without warning. This time it's not about the pressure or annoying questions. I've been working very much since January, more than I ever did in my life. I work more than 50 hours a week and I get only a few hours a day for myself, so when I come home at night, tired, I only feel like doing passive things, like watching DVDs and TV shows.

Anyway, let's get back on topic.

Adobe Director 11 will be released in two days, March 25th. In case you didn't know, Director is what I used to create TT64. Version 11 is long overdue (the last version dates back from 2004, when it was still a Macromedia product). It doesn't have tons of new features, because Adobe had to clean up a lot of the legacy code for a product that was almost abandoned by Macromedia.

This rewrite of the code base was needed to allow porting to intel Macs and Windows Vista, and it will form a more solid basis for future versions.

Amongst the new features are full unicode support, and interactive live bitmap filters that can be applied in real time to textures on 3d objects. But really, the main features that will be interesting for TT64 is Vista and intel Mac support.

As you may know, on Vista, TT64 currently doesn't support 3d acceleration, and on intel Macs, it runs under Rosetta (the built-in PowerPC emulator). Director 11 will enable me to publish native versions of TT64 for these platforms.

While version 11 is supposed to be backward compatible, it's possible that I run into problems because of the use of Xtras (plug-ins) which deal with File I/O. That remains to be seen.

____________________

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

Posts: 188/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 03-24-08 03:27:20 AM, in FlatWorld Battlefield, Take Two (New flat empty level template! TT64 v0.5.98b!)

Link

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

ah, nice to see that at least one person decided to hack the polygons of flatworld!

messiaen:

You can indeed change the 0x17 command to allow more space for polygons. If you add polygons, remember that you also have to add collision polygon. That means that you'll have to change the related pointers so that they take that into account. That means the pointer to the polygon data , vertice data and the color data. These are pointers to bank 0x07, where the pointer is relative to the beginning of the bank in ROM. So, for example offset 0 in bank 0x07 is equal to 0x1203000 (the beginning of the bank), and offset 4D would be equal to 0x120304D.

To get the ROM address in Hex in TT64, just click the "Hex values" option in the main TT64 window.

The length byte is indeed the length of this particular command. The 0x17 command is 12 bytes long. The length of the bank loaded by this command is simply the difference between the start and end adresses.

I will investigate the problem you had where positions were not saved, it's possible that it only happens when using keys to move objects.

____________________

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

Posts: 189/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 03-24-08 03:36:14 AM, in Behaviour Scripts

Link

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

Very interesting stuff James, we're closer and closer to crack open the behavior system.

I knew that command 0x11 was used to load values into registers (and command 0x10 also), but I never investigated much into what was loaded. I thought that the 0x0C command was the only thing that determined the actual behavior, but it seems that the 0x11 command is also a key to this process.

I'd like to know more about that 0x0C offset/instruction thing, even though I'm not proficient in MIPS assembly code.

____________________

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

Posts: 190/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 03-24-08 04:04:56 AM, in ToadsTool Suggestions

Link

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

Originally posted by SubDrag
That's a shame. I think it'd be really simple to pop those suckers in GE. I'm not sure how you've coded Toad's Tool, maybe you parse displaylists, or do you bring them all into vertice/indice buffers? If you can manage to get things organized into vertice/indice buffers with textures, etc, it'd be great if you can export the models to .obj, .vrml, any format that can eventually be put into .obj format. The .obj format is remarkably simple.

Yes, I thought about using the .obj format.

Actually, if you take a look at my (unfinished) Starfox level editor, you'll see that it can export the game objects to .obj format, though they are uncolored and untextured.

Exporting fully textured objects from SM64 wouldn't be that hard, but would still require some work.

First, I would almost need to rewrite the polygon generating routine from scratch so that it produces a cleaner output. To get around some display problems in the Shockwave 3d engine, I have to split models into sub models each time there is a texture or drawing mode change in the display list. Exporting directly from this routine to .obj would produce a bloated file with a lot of overhead. Also, I would have to write a routine to export textures as .obj material files (.mtl if I remember correctly?).

For now, I have simpler plans for 3d export, which unfortunately may not help you that much in importing the objects in GE.

I'm thinking of enabling untextured, uncolored 3d export to the .obj format. The main goal of this feature would be to allow vertex editing. Models could be modified and imported back into TT64, as long as the number of vertices stays the same.

Yes it would limit what you could do, but the reason why it would be limited like that is that it wouldn't require changing the size of the polygon data, as that would make things much much more complicated, as moving things around requires changing dozens of pointers that are part of the polygon drawing script, and in external scripts that call those polygon drawing commands.

While this feature wouldn't be the export/import function that people are clamoring for, it would still be useful for things like creating a perfect Luigi or Wario representation.

____________________

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

Posts: 191/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 03-24-08 05:08:58 AM, in Why a Peach 64 hack is not impossible, but would require a lot of work!

Link

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

Since you guys seem to be interested in experimenting hacking Peach's animation, I'll tell you how and where to find Peach's animation data in ROM. (You can use this method to find the animation data for other objects)

First, read this thread: http://jul.rustedlogic.net/thread.php?id=954 it will tell you about the 0x27 command found in behavior scripts.

Then, open this document: http://homepage.mac.com/qubedstudios/SM64Behaviors.txt which contains annotated behavior scripts from the game. Try to look for Peach using the find command.

You'll find two occurrences of Peach. They both contain the same 0x27 command:

27 26 00 00 05 01 C5 04

05 01 C5 04 corresponds to the location of the animation data. 05 is the bank, and 01C504 is the offset of the data inside that bank. Where is the content of that bank in the ROM? Well banks can contain data from different ROM locations depending on the level. But animation data is often (always?) in the same bank as the polygons from the animated character. Where are Peach's polygons in the ROM?

Let's use this document to find out: http://homepage.mac.com/qubedstudios/SM64GeoLayoutPtrsAndPolys.txt (Oops I just realized that this doc wasn't linked properly in the "all SM64 hacking docs" thread)

This doc contains the location of every polygon model used by of every objects in the game.

Looking for Peach in this doc yields this result:

001040 Peach

--- Polygons --- LevelBank:05 ROMBank:064 ROM Address:9650180-9798148 

--- 023776

--- 023864

--- 023952

...

So indeed, Peach's polygons are loaded in bank 05, and in this case the ROM address of what's loaded in bank 05 is 9650180 (decimal).

So if we add 0x01C504 (dec. 115972) to 9650180 we get 9766152, and that's the location of Peach's animation data in ROM.

At this point to make things more easy, you should (using an hex editor) copy the content of this whole bank, that is from 9650180 to 9798148 in a new hex document. That way you can directly jump to offsets without having to add 9650180 each time. And for the animation data, it can be useful, since there's a lot of jumping around using offsets in the bank.

So once you've done that, you can directly go to 0x01C504 in this new document, to get to the entry point of the animation data.

The first thing you'll find there is 05 00 C7 20. In this case, 05 is the bank number (the bank you're currently in) and 0xC720 is an offset. So you can go directly at 0xC720 and take a look at the data there.

00 01 00 00 00 00 00 00 00 64 00 15 05 00 A2 10

There seem to be some animation data there, until it reaches another offset (05 00 A2 10). You can then jump to this new offset, and so on.

From that point, I can't help you much more than that, you'll have to be the one experimenting, changing the data in between offsets and seeing what happens. These pointers seems to organize the data in a tree-like structure, which probably matches Peach's body part hierarchy in some way, as well as the individual animation sequences.

____________________

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

Posts: 192/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 03-24-08 08:46:05 PM, in FlatWorld Battlefield, Take Two (New flat empty level template! TT64 v0.5.98b!) (last edited by VL-Tone at 03-24-08 05:49 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

00 00 00 02 <----- Loads 2 collision triangles

00 00 00 01 00 02 <----- Three 16-bit vertices numbers defining a triangle.
00 00 00 03 00 01

My question is, take for instance 00 00 00 01 00 02, the important data is just the 01 00 02 last three bytes, right? What does zero means, is it the first vertice of the collision data or just a blank value? Is this the command that sets the two big triangles you see at TT64 FlatWorld Wireframe collision data?

That makes me wonder how interesting would be a "update collision data from ROM" or a "change collision triangles vertexes" feature, if that is how it does works.

In collision data, all 6 bytes of a triangle are relevant. Indeed, 00 00 means the first collision vertex.

[00 00] [00 01] [00 02]

This triangle connects the first, second and third vertices.

Be careful with the vertices order. It must be clockwise when looking at the triangle from the top. If the order is anti-clockwise, Mario will fall thru the triangle, because the polygon will act as a "ceiling" instead of a floor. Note that I may have inverted the order when telling, maybe it's anti-clockwise when looking from the top. The same applies to textured polygons. If the order is inverted, the polygon will only be visible from under.

Originally posted by messiaen

Also, Could someone help me understanding the command below (especfically the last 3 bytes) ?

BF 00 00 00 00 00 0A 14 <------ Triangle command: last 3 bytes point to three vertices (base vertices address + vertex number * 10)
BF 00 00 00 00 00 1E 0A

Is this the command I would have to change to get what I want from my level vertices?

You forgot an important command, which is just before the BF commands and is relevant to your question.

04 30 00 00 07 00 00 00 <------ Loads vertices at 0x0000 in current bank (0x07)

The 0x04 command loads some vertex data in the vertex cache. Note that you can load a maximum of 16 vertices at a time. If you end up adding more than 16, you'll have to add another 0x04 command.

The last 3 bytes of the 0x04 command represents the offset of the vertex data in the bank. In this case, it's 00 00 00 since the vertex data is right at the beginning of bank 07. If you were to add another 0x04 command, it would have to point at the beginning of the additional vertex data. And to avoid repeating vertices, the 0x04 command may point to previously used vertices. For example, you may chose to include the last two vertices of the first bunch when using the second 0x04 command.

Another important thing, the second byte of the 0x04 command (in this case 0x30) represents the number of vertices to be loaded. To calculate this number do (number of vertices -1)*16.

The 0xBF command will use triangles available in the vertex cache.

BF 00 00 00 00 [00] [0A] [14]

In the case of polygon data, there's only one byte per triangle vertex, that means that only the last three bytes are relevant.

In decimal, the example upthere is 00,10,20. They represent vertex 1, 2 and 3. While the triangle vertex values work in increments of 10, each vertex in the data is 16 bytes long. So to find the position of a vertex, you have to divide by 10, then multiply by 16. That would mean 00,16,32. Note that you have to add the base address defined by the 0x04 command. In the case of the first one, it's easy since it's 000000. If you add another 0x04 command, the new offset will need to be added, instead of 000000.

If you want to do the reverse process, to find which values to use in the BF command, starting from the vertex data position: substract the base address of the vertex bunch you load with the 0x04 command, divide by 16 then multiply by 10.

____________________

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

Posts: 193/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 03-27-08 05:24:13 AM, in FlatWorld Battlefield, Take Two (New flat empty level template! TT64 v0.5.98b!)

Link

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

Nice to see your progress messiaen

I was about to suggest that you make a pyramid before you decided to do it

As for textures, well they can be a little more complicated. I think that HyperHacker gave you a nice example here. You should also try to investigate more about the 10.5 float-point number format.

You're right that for complex models, texture coordinates would need some complex calculation to do them right. But for a simple "height terrain" like that, you could do it "by hand" using your existing geometry coordinates directly.

Just take your X and Z coordinates, add some number to them so that they don't go under zero, then divide by some number to make them vary from 0.00 to 1.00. Then multiply by some number to get the texture repeated. The repeat setting on the terrain in Flatworld will simply repeat (wrap around) the texture when you get values higher than 1.0.

It's pretty simple, but if you get vertical walls, this technique won't give you good results.

Stevoisiak:

The spiral is made out of "pushable metal boxes" placed in the level using some equation, it's not a geometry hack. As for cutting a piece of the land to make it movable, it's certainly doable "by hand", and it still would require a lot of work, but creating a user-level feature to do that would be a lot more work. Essentially, with a built-in geometry editor in TT64, it would be possible, but it's far from being done yet.

____________________

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

Posts: 194/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 03-29-08 03:26:42 AM, in FlatWorld Battlefield, Take Two (New flat empty level template! TT64 v0.5.98b!) (last edited by VL-Tone at 03-29-08 12:30 AM)

Link

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

Again, nice progress messiaen

To have a platform that's truly modular, it would be best if the platform was a separate object that could be placed as a 0x24 object in a level. But doing so involves a lot of things.

Without going too much into details, here's what you'd have to do:

-Duplicate all the polygon drawing commands of the terrain, to serve as a basis for a new independent polygon model. Change the vertices and triangles to create your platform adding if necessary.

-Duplicate the geometry layout commands found in the level script part that starts at 0x1200008, copy it at the end of the level script data (that means extending the level script bank and changing the pointers at 0x2AC0F8 so that the new end is accounted.) Then in the new geometry layout commands, change the 0x15 command so that it points to the polygon drawing commands of your platform.

-Modify one of the 0x22 command in the level script so that it points to the geometry layout commands of your platform. You could actually skip the geometry layout step by changing it into a 0x21 command, which points to the polygon data directly instead of the geometry layout data, but I don't know the limitations of the 0x21 command. (using a geometry layout gives you more possibilities, such as using the 0x0D scale command).

The next steps are more complicated. Yo have solidity that moves with your platform, you need to create a new behavior script that includes a 0x2A command which points to the collision data of your platform. The problem is that the behavior script bank, always referred by the game as bank 0x13 and found from 0x219E00 to 0x21F4C0 in the ROM has no room for expansion, because it's not moved into the extended part of the ROM. You'd need to copy it somewhere in the extended part, then change all pointer references to it.

The command that loads bank 0x13 is

17 0C 00 13 00 21 9E 00 00 21 F4 C0

And it's found in a couple of places in the ROM. It would need to be changed at multiple places to reflect the new position of the behavior script data.

Ok so if you manage to move bank 0x13 somewhere else, here's what you'd need to do next.

-Find a behavior script that could be used as a basis for your platform. http://homepage.mac.com/qubedstudios/SM64Behaviors.txt This behavior script must include the 0x2A command (though you could add it yourself). If I had to chose one, it would be the "rotating platform" behavior script, which includes a 0x2A. You can then set the rotation speed to zero if you want a static platform.

-Copy and paste the chosen behavior script at the end of your new bank 0x13. Be sure to change the relevant 0x17 commands to extend the 0x13 bank.

-Delete the M64GeometryDataFlat.m64 file so that it's regenerated in TT64 with your new geometry.

-In TT64, create a new 0x24 object that uses the Object ID of the 0x22 command you modified, and manually set the behavior so that it points to the offset of the newly added behavior in bank 0x13. You could name your new behavior by alt-clicking on the label.

So that's about it, and I didn't go into all the details

Some answers to your other interrogations:

The 0xF3 command is also needed for textures, (as well as the 0xE6 command).

And yes the 0x1A command is used in this case to load the texture bank. Note that 0x1A loads MIO0 compressed data. I couldn't manage to replace 0x1A commands with 0x17 commands to load uncompressed data (the game would crash) like I did for 0x18 commands. The way I found to still get uncompressed data in the extended ROM is by creating a MIO0 wrapper with data that's not actually compressed. So in the case of this bank texture, the actual texture is not at the beninging of the data that's loaded with the 0x1A command, it's after the MIO0 header.

This particular texture bank is used by both Bob Omb' Battlefield and Shifting Sand Land.

____________________

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

Posts: 195/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 04-02-08 12:26:02 AM, in FlatWorld Battlefield, Take Two (New flat empty level template! TT64 v0.5.98b!)

Link

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

Ok, I'll address the details of it later, but for now:

I made a little mistake, you should use the "Rotating CCW" behavior as a basis instead of the "Rotating platform one" because the former has already a 0x2A command. The one you used may have its own way of setting its solidity through asm code, and adding a 0x2A command may break things.

I wouldn't recommend splitting your geometry into two banks. There is a limited number of banks that are supported by the SM64 engine. You can only have 15 different banks loaded at the same time. If there was a possibility of 256 banks, I would have split every banks into smaller banks that contain individual models, to get maximum flexibility when editing levels. Unfortunately, this limitation is hard coded.

As for TT64 not loading your ROM, it may has something to do with bank 0x13 being relocated. Did you change all the 0x17 commands pointers that were loading bank 0x13? If so, what if you change them back to their original values? Can you load the ROM in TT64 then?

Also, you forgot to change the behavior of your 0x24 platform object:

24 18 01 17 00 00 02 3D 00 00 00 00 00 00 00 00 00 00 00 00 13 00 2A A4

It shouldn't be set to 13 00 2A A4, it should be the hex offset of your new behavior in bank 0x13 (130056C0)

____________________

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

Posts: 196/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 04-04-08 12:46:59 AM, in Behaviour Scripts

Link

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

Wow, these are very interesting discoveries.

I actually knew about the 0x23 command, I just didn't document it. Mario's got a 0x23 command too! It doesn't affect it's actual collision with platforms and the terrain, but it affects the range of his interactions with enemies and such.

But what you found about the use of the 0x10 in combination with the 0x23 command is something I didn't know about. I wish I had time to experiment with it. Maybe this week-end if I'm not too tired from my work week.

I begin to suspect that the 0x10 (and 0x11) commands are used to write values to "RAM objects", you know, the objects that yoshiman knows a lot about. I guess that the second byte of the 0x10 command determines the offset of the write in the RAM object (it may be multiplied by two because they are 16-bits values). So depending of this offset you may modify different object properties. I think it's the case because RAM objects include properties such as the ones you seemed to modify in your experiments.

____________________

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

Posts: 197/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 04-04-08 12:50:42 AM, in FlatWorld Battlefield, Take Two (New flat empty level template! TT64 v0.5.98b!)

Link

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

I wish I could help you more, but I don't have much time (well I'm tired because of my job). Maybe this weekend I'll try to give you a hand.

In the mean time, keep on experimenting!

____________________

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

Posts: 198/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 04-05-08 03:54:50 PM, in FlatWorld Battlefield, Take Two (New flat empty level template! TT64 v0.5.98b!) (last edited by VL-Tone at 04-05-08 01:04 PM)

Link

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

My commands gets listed as 0x22 Number 075 , "Unknown". However, I still think there is something wrong with the listing, as there aren't 75 0x22 commands in the FlatWorld level.

The first forty-three 0x22 commands, up to "Cartoon Star" are part of Mario's geometry layout bank, which is loaded elsewhere, before the level script is read. If you look at the "ROM Address" field when you select one of these 0x22 command, you'll see that they're somewhere in the first 8 MB of the ROM, in the "unextended" part.

As for the objects not appearing in the game, maybe they're just invisible for some reason? Did you check if you can collide with them?

0x43 commands are essentially like "compressed" 0x24 commands. They use predefined model IDs and behaviors, and can only be rotated around the y axis. The only difference with 0x24 is that they are more limited. You couldn't use a custom behavior pointer with them unless you edit the predefined list which is at a place where modifications requires a checksum recalculation. You wouldn't gain anything in using 0x43 command except for a few bytes of space. They're often used for static platforms because these are all using the same behavior so they saved space by using only one byte to identify the model + behavior instead of 6.

The crashes you're experiencing might be related to the geometry layout that you're using. Maybe it wasn't such a good suggestion to use the level geometry layout as a basis, because it probably contains special commands that are specific to level terrain geometry. What you should do is take another simple geometry layout script as a basis. Take a simple platform geo layout script.

To find a geometry layout script, take a look at this list: http://homepage.mac.com/qubedstudios/SM64GeoLayoutPtrs.txt

Take the base address of the ROMbank containing the object you're looking for, and add the offset to find the location.

ROMBank:029 ROM Address:4300688-4302688 Level Script Bank

---------------------------------------------------------

Offset Description

001408 Wooden Platform

001432 Arrow Lift Platform

001472 Water Level Diamond

001512 Square Wooden Platform

001552 Wooden Platform Thing

001576 Main Level Geometry 1

001600 Hexagonal Platform

001624 Main Level Geometry 2

001828 Main Level Geometry 3

Let's say you want to find the geo layout script for that wooden platform. Just add 1408 to 4300688 and you get 4302096. Look at this location in the ROM and you'll find the script. Remember that geo layout scripts end with the "01 00 00 00" command.

Here's the script that you get at this address, which is essentially the simplest geo layout script possible, and that's what I should have told you to use in the first place:

20 00 02 26 

04 00 00 00 

     15 01 00 00 07 01 2B 90

05 00 00 00 

01 00 00 00

Now I'm not sure what the 0x20 command does. 0x226 in decimal is 550. When you get numbers like these (multiple of ten) it's usually a coordinate of some kind. I suspected that it may be the draw distance value, you can try to change it and see what happens. Don't forget to change the 0x15 command so that it points to your custom polygon data.

So, using this geo layout should fix a lot of problems, including the fact that the object doesn't appear in the game. I've seen someone experimenting with putting a copy of the main level terrain in the level, and while it did appear in TT64, it didn't in the game. Same symptoms, the level terrain geometry layout must be preventing additional copies from showing.

And with a short and simple geometry layout like that, it should encourage you to create more different platforms. I suggest that you already insert multiple copies of this short script so that you don't have to repoint everything each time you want to add one.

You know this experiment will be useful in the future development of TT64. I'm now thinking about how I could automatize the importation of polygon models that could be used as individual 0x24 objects. Note that if I do this, it would only work with this new level. Adding platforms and objects to existing levels would be much more complicated, as they use a lot of "goto" and "gosub" commands that would need to be repointed if things are inserted. I made the scripts in Flatworld a lot more linear. For example, normally in a level, 0x22 commands are often loaded from other banks. In Flatworld, all 0x22 commands are in the main level script (except those in the Mario bank). Also, polygon scripts are normally built with a lot of "gosub" commands, but in flatworld they're all one after the other.

BTW messiaen, you should learn to use the url tag to enclose your urls so that they become clickable.

Edit: Removed something about the draw distance that wasn't correct (There's no draw distance command in the behavior script, I misread it as being command 0x45, but instead this is the offset of the draw distance value in RAM objects structures, it may be well set by the 0x20 command after all)

____________________

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

Posts: 199/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 04-05-08 04:11:14 PM, in Behaviour Scripts

Link

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

Wow Cellar, thanks for this info... There's a lot of interesting stuff that may come out of this.

It means that we can now apply some of yoshiman's (yoshielectron) gameshark hacks in a permanent way in the ROM.

Maybe someday I'll make a behavior script editor that works a little like my StarFox level editor. Actually, I'm very proud of that StarFox script editor interface, even though it made the editor too hard to use because it was the only way to edit things. (I don't know of anybody that created a new level with it).

____________________

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

Posts: 200/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-11-08 03:40:44 AM, in Naming the Textures

Link

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

Just dropping by to tell you that I'm gonna integrate this list in an eventual release of TT64, and I'll credit you guys. (Before you ask, I'm gonna be less busy in June, so that should be when)

____________________

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

Posts: 201/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-11-08 03:46:36 AM, in Behaviour Scripts

Link

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

Hi,

Just wanted to tell you that you're doing an amazing work on understanding behavior scripts. I'll try to eventually integrate some behavior script editor in TT64 when I get more time (somewhere in June), though it'll be hard to make it easy to use for mere mortals.

____________________

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

Posts: 202/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-11-08 03:55:52 AM, in Experimental Platform Battlefield v0.4 RELEASED (Mac patch included)

Link

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

messiaen, I'm really happy to see all the things you've done and discovered. At last someone read and understood all of my M64 hacking docs

When I have the time, I'll try to add features that may help you creating custom levels like this. But you should understand that it's not necessarily easy to create tools that automatize all the steps needed to create levels like Mushroom Battlefield.

____________________

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

Posts: 203/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-11-08 04:12:55 AM, in Adobe Director 11 released March 25th.

Link

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

Ok, so I got Director 11, and after some modifications to get around a bug in the D11 version of the BuddyFile Xtra (it deals with reading and writing to files), I've managed to create a Vista and Mac intel native version of TT64...

But... there are two Xtras (plug-ins) that were not ported to D11, one was used to save Director list variables containing pre-decoded polygon data into the M64Geometry file, so currently the new version will have to decode polygon data each time a ROM is loaded, which can be a lengthy process on slower computers. I'm sure messiaen wouldn't mind, since it's useful when you're doing polygon editing, but I'd like to make it optional. The other missing Xtra is the one that's used to export textures as png files. These Xtras may never be updated for D11, and the alternatives are either Windows only, or cost money. Anyway, I'll find a solution.

So the problem is that I'm hesitant to add new features until I get around these problems, and I don't feel like working on two versions at the same time (one with D10 and the other with D11), because it would require tracking down all script changes, copying and pasting code between versions, etc.

Anyway like I said, I don't have much time for myself these days, and I'll be less busy in June. I may release a an alpha Vista and Mac intel native version before that using Director 11, but there won't be any new features (actually there will be less features, texture exporting will be disabled).

____________________

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

Posts: 204/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-28-08 02:37:52 AM, in Brainstorming ideas for Mushroom Battlefield (last edited by VL-Tone at 05-27-08 11:38 PM)

Link

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

Let me help you with that...

As far as I know, it's all in the collision data, it's a type of collision triangle that enables Mario to hang from under an object.

Here's some data that I may have forgot to publish somewhere and that may interest you messiaen:

collision triangle types



000E,002C, 0024, 0025, 0027, 002D are 8 bytes long per vertex.





0000: Normal (Slippery in Slide levels, when cmd 0x31=0006)

000E: Water currents (8 bytes per tri) the two last bytes of each triangle defines direction and force of current

002A: Un-climbable hill

0015: Climbable hills

0014: Slippery hill

0013: Very slippery hill

0012: Falling in void (Haunted House)

001B: Switches to area 1 (Used in Wet/Dry World)

001C: Switches to area 2 (Used in Wet/Dry World and Tall Tall slide to seemingly switch between areas)

001D: Switches to area 3 (Used in Tall Tall slide to seemingly switch between areas)

001E: Switches to area 4 (Used in Tall Tall slide to seemingly switch between areas)

0028: Wall/fence

0029: Grass/flat

002C: Lethal ice

0001: Lethal ice/ Lava

0005: Mario can hang from the ceiling

000A: Bottom of level (death)

0030: Flat

0036,0037: snowy ice stuff

002E: Icy

0033: Starting line in Princess Secret Slide

0034: Finish line in Princess Secret Slide

0079: Flat non-slippery floor in Princess Secret Slide

0065: Top of Bob Omb Battlefield mountain wide angle camera

0066: Walls Tiny Huge Island area 3

006F: Camera turn in Bowser Course 1

0070: Camera turns in BoB

0075: Camera stuff Cool Cool Mountain

007B: Vanishing walls. (non-solid when Mario wears the Vanish cap)

00D0: Limited camera movements in narrow hallways (part of Hazy Maze Cave)

00A6-00Cx: Painting warps areas (in front)

00D3-00F8: Painting warps areas (behind)

00FD: Pool Warp in Hazy Maze Cave

____________________

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

Query execution time:	0.767690 seconds
Script execution time:	0.093504 seconds
Total render time:	0.861194 seconds