(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
 Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album 		05-04-24 03:26 PM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - General Super Mario 64 hacking / TT64 Progress thread New poll | | Thread closed
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71Add to favorites | Next newer thread | Next older thread
User Post
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 01-10-06 05:12 AM Link
In all my browsers, including lololol, I can do the same thing, but my problem was that I closed the window. When I tried to bring up the page with the History menu, my post was gone...

I know it was even more easy "in the days" to lose a post with some other browsers if it didn't get trough and you hit the back button. I guess you implied that IE still does that? One more reason not to use IE

But back to the topic:


As you can see, the Wet Dry world tunnel is part of both areas. It means that both never appear simultaneously. So you need a door or tunnel to hide the fact that part of the scenery disappears.


There is also the Tall tall mountain slide, which is divided amongst 3 areas. There even a music command for each of the 3 areas which all trigger the same slide music. The game seamlessly switches between 3 different track parts when you go trough tunnels. I'll try to pull the "walk on slides" trick using the 0x31 commands in those part, so I could walk back and see where and how the switch happens.

The game can also manage big levels in other ways. Inside the castle, there are three areas, staircases (and locked doors) are used to separate them. But it doesn't stop there: each area is subdivided in rooms. The geometry layout data for inside the castle, contains multiple sets of references to rooms in the polygon data found in RAM segment 07 (using command 0x15).

Some of these sets in that case contains individual rooms. Other sets contain two or more rooms reference. For example, one contains the main castle lobby room, and the level 1 room at the same time. This set is used when Mario transition from room to room the door.

This would have mean a seamless transition in theory, but there is a timing problem in the actual game, ie: when you exit the level 1 room, the cam is in the lobby, and you can see Mario walking out the other room. Unfortunately, you see the other room disappear before the door is completely closed, ruining the effect. I wonder if we could fix that...

There is only a few levels using the room sets method: Inside the Castle, Boo's haunted house and Hazy Maze Cave. I added a feature in my editor so I can instantly chose what sets of room is visible.

Command 0x02 is used inside the geometry layout data to read those room sets, its 8 bytes long, it uses a room number parameter, and a pointer to make the decoder jump to this address, then one or more 0x15 commands (8 bytes each) are read from starting at this position, until command 0x03 (4 bytes) is reached, then it jumps back to the command following the 0x02 command. I also recently found that commands 0x04 and 0x05 are used to group parts inside the level geometry, in some kind of hierarchy. Each one is 4 bytes long. They act in the same logical principle as parenthesis and you can find groups inside groups inside groups... Each 0x04 command has its associated 0x05 command somewhere after. Maybe it's some kind of BSP tree?

If you want to look at the geometry layout data for area 1 of Inside the castle, it's at 0x3D04D0 and ends where the following MIO0 data begins. You find this address with the 1F command for this level.

I'll have to update my doc since it doesn't contain the 0x02, 0x03, 0x04 and 0x05 commands

As for the mysterious "Luigi is real" 0x24 object, it doesn't behaves like a sign, it doesn't have a parameter number (signs have a parameter byte that sets the text it reads).


I tried to move it and it doesn't change anything. I tried changing the object type byte from zero to something else, and it has no effects, the object doesn't appear. There would be more to investigate though by looking at the behavior code.

The behavior pointer is 13003C90. Segment 13 is uncompressed data starting at 219E00. Add 0x3C90 and you get 21DA90 where you can find this:

00, 08, 00, 00,
0C, 00, 00, 00, 80, 2F, 09, 50
08, 00, 00, 00,
09, 00, 00, 00

I don't know much about this yet-another-sets of command, except that command 0x09 is used to mark the end of the behavior data. Obviously, it's not the actual code for the behavior like I first thought it would be, but rather pointers to it. Most other behavior data chunks contain other commands too, it seems that this particular object mainly contains the command 0C, which point to address 802F0950 in RAM...
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6285 days
Last view: 6285 days
Posted on 01-10-06 10:51 AM Link
That is interesting... sure it's not just the level 5 exit though?
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 01-13-06 01:40 AM Link
Originally posted by HyperHacker
That is interesting... sure it's not just the level 5 exit though?


Of course its not, do you really think I'm that dumb?



There are two level exits for Level 5 in the courtyard. They are at the same location, on the edge of the fountain, in front of the mysterious "Luigi is real" object, one is for successful level completion, and the other for when Mario dies.

The mysterious object has 0000 for parameters, so it couldn't be a warp exit, since those have "warp id's" defined in the second parameter byte. Warps never use 00 as an id. The successful exit warp in front of it uses "0A" as a warp id, while the "Mario lost a life" exit uses "0B". If you look at 0x26 commands defining how warp are connected in level 5, you'll see that the two possible exits lead to the courtyard, in warp 0A and 0B.

Anyway, just go in level 5, and exit it by dying or getting a star, and you'll see by yourself, Mario doesn't jump out of the Star statue.

Note: the screenshot is reduced, the editor now has a 800x600 window (a little larger than before). I moved the interface around and some things are out of place for now, like the stars.

I'm currently integrating a way to modify and save text descriptions for objects. Parameter labels like "Warp id" will be associated with behaviors, and those will also be editable. That means that even if I don't put description for all objects, behaviors and parameter labels, people will be able to add them, and send me the updated description file.

(edits: typos)

(edited by VL-Tone on 01-13-06 12:47 AM)
(edited by VL-Tone on 01-13-06 12:47 AM)
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6294 days
Last view: 6285 days
Posted on 01-13-06 02:33 AM Link
oops.

I made a mistake while looking for command 0x31 in the command table. I was off by one and the information I previously posted actually pertained to command 0x30.

Command 0x31 actually has a single 16 bit parameter that gets ORd with the existing setting in the area structure used by the game engine. (eg. "31 04 00 0f" followed by "31 04 00 f0" will result in the setting being 0x00ff, not 0x00f0) This suggests that the setting consists at least partly of bit flags. The setting also controls what mario does when idle. (eg. 0x0002 makes him rub his hands together for warmth)

I just hacked a primitive tracer into Mupen 64. I used the instruction formatting code and tables from the disassembler I wrote. The only way to control it is by editing the CPU core and recompiling Mupen 64. I have the function that handles the SW instruction check if it is executing the SW instruction in the level loading code that stores the pointer to the solidity data. The LW instruction function checks to see if it is reading from the saved solidity address and if it is, it starts a 512 instruction trace to stdout. Now I need to start looking at the output...

I have already found out that the file select menu sets off the trace, so it must have a level script and, oddly, some kind of solidity data.
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 01-13-06 05:22 AM Link
A tracer in Mupen64! neat!

Yes, the whole menu interface works using "level-like" scripts as their basis. The menu selection screen is a level with a negative number.

The entry point of the whole script structure seems to be at 0x108A10 where you can find this little script:
1B 04 00 00
03 04 00 02
34 04 00 00
13 04 00 00
00 10 00 14 00 26 9E A0 00 26 A3 A0 14 00 00 00
05 08 00 00 10 00 00 00
--

The important command here is:
[00] [10] [00 14] [00 26 9E A0] [00 26 A3 A0] [14 00 00 00]

[0]: Command number
[1]: Length Byte
[2,3]: Segment number
[4,5,6,7]: Start offset of data in ROM
[8,9,10,11]: End offset of data in ROM
[12,13,14,15]: Segment number and offset to jump too.

This command loads uncompressed data into a specified segment then jumps to the offset (0000 in this case) in a segment, which is always the same as the one data is loaded in (0x14 in this case).

I'm not sure yet what goes on in the 269EA0 segment, but it's the core of the level initialization process. At one point in this script, you find this command: [01] [10] [00 14] [00 2A 61 20] [00 2A 65 B0] [14 00 00 00]. Command 0x01 works much like 0x00. I think one or both of these commands might use a stack to store jump-back addresses. Command 0x02 found at the end of script subroutine would jump back to after when the last 0x00 or 0x01 command was called.

So at that point, the content of segment 0x14 is replaced by data from 2A6120 to 2A65B0 in the ROM and jumps to offset 0 there.

At one point in that script, you can find command 01 10 00 15 00 2A BC A0 00 2A C6 B0 15 00 00 00 Which loads the data starting at 2ABCA0 into segment 0x15 and jumps to offset 0.

I know a little more about the script starting at 2ABCA0.

As described in the old thread, this part loads the main segments shared by levels, including the Mario MIO0 file and another containing common polygonal objects. Then a sequence of 0x22 commands point to geometry data for each object and associate a number to them. These objects can be used in all levels.

After that at 2ABE78 the script jumps back into segment 14 (2A6120) at offset 0x118 which means 2A6250 in the ROM.

I'm not sure what happens at 2A6250, but it seems to come back at 2ABE78 when it's finished there (using the 0x02 command). At 2ABE78 it jumps to 0278 in the current segment 15 (2ABCA0), which can be found at 2ABF18 in ROM.

So this is the interesting part, after the 3C command, there is a series of 0C commands.

3C 04 01 03
[0C] [0C] [02 00] [00 00 00 04] [15 00 03 F4]-- 0x0C is a conditional branch. It branches if the current level id number matches parameters [4,5,6,7] in this case it's 00000004.
If this particular level is selected, the script jumps to 03F4 in the current segment which is at 2AC094 in ROM.

At 2AC094 you find :

00 10 00 0E 00 38 28 C0 00 38 39 50 0E 00 04 18 --Which jump to the actual level script of this course.

Other 0C commands after 2ABF18 can load any normal level.

At 2ABE8C, there is an interesting sequence of 0C commands that point to negative levels. These are for the title screen, menu select, debug menu and game over sequence...

So there you go, another lengthy confusing explanation leading to that little blurb of relevant information

Just look at 2ABE8C, you'll find the 0C commands that points to commands loading the main script of the file menu and other title related sequences.

(Note I'm pretty tired, I hope at least one person can make sense of this post )

(edited by VL-Tone on 01-13-06 04:25 AM)
(edited by VL-Tone on 01-13-06 04:26 AM)
(edited by VL-Tone on 01-13-06 04:28 AM)
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6294 days
Last view: 6285 days
Posted on 01-13-06 02:58 PM Link
Tracing turned up the following function, which I decompiled. arg2 points to the solidity data and arg4 points to to the command 0x39 objects. I seems to process 16 bit commands. 

0x803833b8(int arg1, short *arg2, int arg3, short *arg4)

{

    long lv2;  /* sp + 0x20 */

    short lv1; /* sp + 0x26 */

    short lv3; /* sp + 0x2a */



    *(0x80361184) = 0;

    *(0x8038be90) = 0;

    *(0x8036116c) = 0;

    *(0x80361170) = 0;

    0x803825d0(); /* this initalizes an array of 256 0x18(24)-byte structs at 0x8038be98 */

    for (;; ) {

        lv1 = *arg2;

        arg2 ++;

        

        if (lv1 < 0x40) {

            0x80383068(&arg2, lv2, lv1, &arg3);

        } else if (lv1 == 0x40) {

            lv2 = 0x803831d0(&arg2);

        } else if (lv1 == 0x43) {

            0x802e28ec(lv3, &arg2)

        } else if (lv1 == 0x44) {

            0x80383228(&arg2)

        } else if (lv1 == 0x41) {

            continue;

        } else if (lv1 == 0x42) {

            break;

        } else if (lv1 < 0x65) {

            0x80383068(&arg2, lv2, lv1, &arg3);

        }

    }

    

   

    if (arg4 && *arg4 != -1) {

        if (*arg4 >= 0 && *arg4 < 0x1e) {

            0x802e2690(arg1, arg4);

        } else {

            0x802e2414(arg1, arg4);

        }

    }

    *(0x80361174) = *(0x8036116c);

    *(0x80361178) = *(0x80361170);

}


EDIT: here is another: 
/* returns pointer to virts */

void * 0x803831d0(short **pwp)

{

    short *rv; /* sp + 0x00 */

    int n;     /* sp + 0x14 -- number or virts */



    n = (int)(*pwp); /* load nbr of virts */

    *pwp++;

    rv = *pwp;

    *pwp += n*3;

    return rv;

}


(edited by Cellar Dweller on 01-13-06 04:03 PM)
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 01-14-06 03:08 AM Link
That's a very useful code snippet you got there!

I guess it means that the 0x2E command for solidity, the 0x39 command and the other objects in between are all loaded from a single function?

From a preliminary look, I can see the 0x40, 0x41, 0x42 and 0x43 commands in the listing.

The basic structure of this data usually looks like this: 


*0040--Start of solidity data.

  *16-bit value for the number of vertex position in the list (multiply by 6 to find the byte length)

  *Vertex position list, each entry is 6 bytes

  *16-bit length value for vertex connection list (?)

   (I'm not sure about this one, it doesn't match the length in any obvious way)

  *Vertex connection pointer list, each entry is a 16-bit integer pointing to a vertex position in the previous list.

*0041

*0043

  *List of special objects, like trees

*0042

  *List of 10 bytes objects pointed by command 0x39. 

   The 9-bits type value points to what I call a "macro" object in a list at EC7E0 in the ROM. 

   Each entry in this list contains a type byte (the same as in 0x24 objects), 

   a behavior pointer and 2 parameter bytes. 

*0000001E


Command 0x1E is used to end the 0x39 listing. I guess it has something to do with that line? 

if (*arg4 >= 0 && *arg4 < 0x1e) {


I have to admit that I'm not too familiar with the c++ syntax. Mainly it's the symbols like && * etc. that confuses me, if only because I don't know all of them. I'll have to do some little research before I understand all of this code. But I don't think it'll be hard, I have hundreds of years of programming experience, though mostly with either high-level languages, or low level stuff like ASM and binary formats.

From what you found, do you think that the level is "drawn" as the level script is loaded, or that the level script only loads a bunch of pointers and data in memory, and only after that a "draw level" routine is executed, using pointers and data defined by the level script? By looking at that function you decompiled, I would say it's the latter.

As for the other little /* returns pointer to virts */ function:

By "virts", do you mean vertex positions or vertex connection pointers? The vertex position list is easy to load, as there is a "number of vertex" value after command 0x40. It's the vertex connection pointer list I have to find the length or number of entries value.

Anyhow, great work Cellar Dweller!
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6294 days
Last view: 6285 days
Posted on 01-20-06 12:23 AM Link
I added a thing to Mupen 64 to print the command and its location in memory when it encounters the load instruction of the "lv1 = *arg2" line. (ie. it prints the values for lv1 and arg2) A number of solidity commands are processed between the 0x40 command and the 0x41 command. 
Solidity command is:40 at 801098e8

   d60

Solidity command is:0 at 8010a648

   8e0

Solidity command is:5 at 8010af28

   10

Solidity command is:b at 8010af38

   14e

Solidity command is:13 at 8010b086

   22

Solidity command is:14 at 8010b0a8

   178

Solidity command is:15 at 8010b220

   3ee

Solidity command is:28 at 8010b60e

   4a8

Solidity command is:29 at 8010bab6

   352

Solidity command is:2a at 8010be08

   106

Solidity command is:65 at 8010bf0e

   22

Solidity command is:70 at 8010bf30

   1c

Solidity command is:41 at 8010bf4c

   2

Solidity command is:43 at 8010bf4e

   8c

Solidity command is:42 at 8010bfda


The above is output from the modification with some stuff removed and the differences between the addresses manualy added.

Most of the level loading commands setup pointers and stuff. I have even mapped out most of the per area data structure. An array of them exists in memory, and each one holds stuff like the music number, a head pointer to a linked list of objects in the area, a head pointer to a linked list of exits in the area, a pointer to the solidity data for the area, etc. It seems that the data in the per area structures are further processed by the game engine when entering an area.

EDIT: OOPS! I should have used a calculator for the first difference. It is 0xd60 not 0x12a0. Fixed.

(edited by Cellar Dweller on 01-20-06 12:48 AM)
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 01-20-06 03:30 AM Link
Is this from Level 1 solidity data? And while I'm here, what do you mean by "virts" again?
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6294 days
Last view: 6285 days
Posted on 01-20-06 03:59 AM Link
Yes.

"verts" should have been spelled "virts". The 0x803831d0 function advances the current processing location to the end of the virtices, and returns a pointer to start of the said virtices. The 0x803833b8 function saves the returned pointer and passes it to the 0x80383068 function, which process the commands containing triangles.

Solidity data VISUALIZED:


Here is what I know now. Command 0x0040 sets the vertex data as previously described. Commands 0x0000 - 0x003f and 0x0064 - ??? contain triangles. After the command number is the number of triangles. Each triangle is defined by a triple of point indices. After the triangles is the next command. Command 0x0041 is a noop. Command 0x0042 ends the list.
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 01-20-06 04:13 AM Link
Wow at last I found a use for this "surprised eyes" smily!

What's funny is that I figured that out a few seconds ago while trying to corroborate your findings, just before seeing your post... I should have figured this out before, it's so simple :/

For some reason, I thought that there was no commands between 040 and 041, since these are all commands with lists of vertex pointers (triangles). Now it's so obvious to me, even more with this picture you got Each of these commands in between 040 and 041 can produce a particular type of solidity, for different terrain types. Command 0x31 previously discussed seems to have something to do with these. I guess that these commands also include water solidity data?
Koitenshin +∞

Moblin


 





Since: 12-24-05
From: Misery

Last post: 6287 days
Last view: 6287 days
Posted on 01-20-06 04:15 AM Link
I wonder just how far off Super Mario 64 hacking is after taking a look at your progress so far.
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 01-20-06 05:15 AM Link
There you go, I've got it working too!




Thank you very much Cellar Dweller for this help, even though I should have figured this out before... The first polygon data I stumbled upon was the solidity data, but didn't manage to get conclusive results at the time so I focused my efforts on the textured polygon data.

Edit: I hope I'm not sounding like I want to keep the credit all for myself and minimizing your efforts Cellar. You are a better programmer than me and have a much cleaner/modular approach, and since the beginning you have been more than useful

Ok here is a second picture of solidity data, that one inside the castle (first floor).



Look at where paintings are... weird eh? There seem to be 3 separate areas defined both in front and behind, for a total of 6 different solidity values for each painting. I really wonder what they are used for... why 3 in front and 3 behind? If I remember correctly these are defined by commands Dx or Fx.

From what I found, command 79, 85, 1D and 21 are followed by lists with items that are 8 bytes long instead of 6, so they include an extra 16-bit parameter. The first 6 bytes are a triangle like other commands.

Command 0x88's items are 12 bytes long, and also contains a triangle. Command 0xA0 is only 4 bytes long.

I started decoding the other sets of objects that is found after 0x43 and before 0x42. Very interesting stuff in there, as predicted it includes Bowser, trees and other stuff like doors. In these objects I found the command that places the castle main tower on top (I had to do it manually before). The problem I have is that I cannot find the link between its object type value (0x65) and value 0x03, which is the value defined by the 0x22 command for the tower... It doesn't seem to use the same set of type/behavior/params macros that command 0x39 object use (found at EC7E0).





(edited by VL-Tone on 01-21-06 01:34 AM)
Lordlazer
Newcomer


 





Since: 11-18-05

Last post: 6662 days
Last view: 6662 days
Posted on 01-21-06 06:52 PM Link
I'm not a programming expert or anything, but this is an idea as to why they might have had those 3 separate areas defined both in front and behind. Maybe they used it so they could get the ripple effect they wanted when you enter and exit a painting? I haven't played the game in ages, but maybe if someone takes a long and see how far the ripple goes out [I'm simply guessing, but I'd guess it goes as far as the 3 area's in the front's width and height...and for the entering of the painting, I'd guess the back 3 areas would take that job]. The only problem that I find with this idea [without looking at code or anything for that matter] is that why would they need the back 3 areas so long if that was to represent the ripple for entering the painting? Anyways, food for thought.

P.S. If I'm saying something that you think is stupid or whatever please ignore this post. I normally wouldn't post in a thread like this, because I know I wouldn't be much of a contributor, but that came to mind and I couldn't keep it out. Anyways, good luck guys.
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 01-22-06 12:19 AM Link
I considered this possibility, but I thought it was a weird way to detect that, and from memory I was pretty sure that there was more than 3 different horizontal positions for the ripple effect. But after reading your post I decided to check... And it seems that you are right Lordlazer!

There seem to be only three possible horizontal positions for ripples in paintings, but the vertical position seems to be more precise. The 3 areas in front are for when Mario enters the painting, and the 3 areas at the back are for when Mario exits paintings.

But you shouldn't have to worry about posting in this thread. If you have questions about the Mario 64 editor, even basic things, don't hesitate to ask them in this thread, at least until I decide myself to post a more official thread...

From what I found, these areas define the terrain type in some instances and are there to detect if Mario is stepping on a specific floor part in the level, to trigger some specific event.
Lordlazer
Newcomer


 





Since: 11-18-05

Last post: 6662 days
Last view: 6662 days
Posted on 01-22-06 02:51 AM Link
Alright, thanks for the encouragement to post here. I'm glad I was able to help in some way. The thought came to me, because after seeing your layout of the map it reminded me of when I was making a map for Quake III and how 3d textures work and stuff. Though I never finished the map [mainly due to lack of interest and time rather used on other things], I thought it was a pretty cool idea, so if anyone wants to make a Quake III map [though this is off-topic, sorry] or want to see the ideas I had to use in a different FPS, I'd be glad to contribute.

Q: Is this editor going to work similar to GTKRadiant [editor for Quake III] or something of the sort? If so, editing will be somewhat of a breeze for me.

(edited by Lordlazer on 01-22-06 01:52 AM)
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 01-24-06 12:12 AM Link
Originally posted by Lordlazer
Q: Is this editor going to work similar to GTKRadiant [editor for Quake III] or something of the sort? If so, editing will be somewhat of a breeze for me.


I don't know much about the GTKRadiant editor so I couldn't tell. I guess you can create levels from scratch? The first release of my M64 editor won't enable you create new model geometry, I may add a way to edit the geometry shape by moving vertices, but I'm still not decided if I will include that in the first release.

As its basis, geometry editing (not importing) would be a simple feature to add, but to be useful, it should be more than being able to move individual vertices. Selecting and moving multiple vertices at the same time would be very useful, and scaling and rotating groups of vertices would be very practical. I'm thinking about implementing a way to match the geometry vertices to the solidity vertices so they would move in tandem.

Though it would be very cool to be able to create entirely new geometry and importing 3d data into Mario 64, I feel that this is too much of a task for me, and even with Cellar Dweller's approach, I'm betting that it will take years until we achieve that. There is much more things than vertex and triangles in the geometry format, there are pointers and other stuff that no 3d program deal's with. The format is actually a series of graphic processor commands, that have to follow specifications. An importer or geometry creator would need to keep track of many things to make sure the texture or triangle cache doesn't overflow for example. With the many limitations of the chip and engine, many things could go wrong.

We may have much more space for levels by extending the ROM, but memory will still be limited. Making sure a level doesn't make the game crash will require taking many variables into account. Sure, individual issues will be dealt with, but the sum of them may mean a lot of work ahead of us.

I may be a little pessimistic about this:

To build Mario 64, Nintendo used a 3d program called N-World by a company called Nichimen. There was a plug-in to export models to N64 graphic commands format, so it may not be so hard to replicate similar functionality.

Edit: By the way Nichimen is now called IZware http://www.izware.com/, N-World was renamed Mirai a few years ago, and IZware's products were used to animate Gollum's face in LOTR.

I'm currently looking for more information about N-World, here is one of the interesting pages I found on the internet archive: ress/n64-express.html>http://web.archive.org/web/19980712203000/nichimen.com/products/nworld/game-express/n64-express.html

(edited by VL-Tone on 01-23-06 11:19 PM)
(edited by VL-Tone on 01-23-06 11:35 PM)
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6294 days
Last view: 6285 days
Posted on 01-24-06 07:25 PM Link
VL-Tone: There is no need to worry about taking too much credit. you have done more than anyone else. Also, you do not apperar to be trying minimizing my effort, and even if you did I'd probably just shrug it off.

I have located the function table for the geometry layout commands and have started disassembling some functions. I have already learned more about the 0x02 command. 

02 01 00 00 0e 00 0b f0

|/ |/ |---/ |---------/

|  |  |     |

|  |  |     \-- Segmented address to decode from

|  |  |

|  |  \-- Ignored

|  |

|  \-- If is 01 save current location for return

|

\-- Command 02: Call/jump other layout data


I found some tutorials about Quake/Doom 3 editing, and I don't think that it will be similar. Wheras Quake levels are constructed with solid "brushes", SM64 editing is likely to revolve editing individual vertices and triangles, but there still could be tools that operate on groups of items(vertices, triangles, objects).

A while back I found some info about a N64 graphics export plugin for Alias. I also found a similar document about the same plugin, but with more info.
Lordlazer
Newcomer


 





Since: 11-18-05

Last post: 6662 days
Last view: 6662 days
Posted on 01-24-06 07:35 PM Link
About the Way the Editor works
I see... So no brushes. Oh, well, it'll still be cool and fun to work with. So, would it work like a mesh [assuming I have the correct termonolgy, if not, sorry]? I think a mesh [at least for the Q3 editing is when it is], I guess you could say, is 2-D. In other words, it would be like one side of a "brush" [the brush being 3-D object, whereas the mesh is 2-D [only front and back or top and bottom, if you will]. If it isn't like what I'm saying, I'll just have to see, because at the moment I can't picture any other way of editing.

(edited by Lordlazer on 01-24-06 06:36 PM)
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 01-25-06 05:07 AM Link
Lordlazer:

I'm not sure how mesh are used in the Quake editor, but meshes can be 3d, and the term mesh can apply to just about any 3d polygon group. So yes the Mario 64 levels can be described as 3d meshes. The editing would work by moving around vertices, thus changing the shape.

I guess the equivalent of brushes exist in Mario 64. Some levels, like Whomp's Fortress, or Wet Dry world (area 1) rely on level objects for platforms and many level elements. The Whomp's Fortress tower for example, is an object. You could move the tower, or put three of them if you want, by changing other object in the level into towers. The rotating platforms in this level are also individual objects you can move and tilt, and "duplicate" them at other positions.

For fun, I once made the tower use the rotating platform behavior so the whole tower would rotate! It worked, but for some reason the tower lost its solidity.

Here is how mesh editing could look, though a wireframe view could be an option. Vertex are represented as red spheres in this example. Each of these spheres could be moved, enabling you to change the shape of the Secret Slide for example.

Maybe a slide editor could be a start



Cellar Dweller thanks for reassuring me, I get a little paranoid sometimes.

Very cool that you found the geometry layout command's function table, this is one area I don't know that much about yet. I know just enough to decode levels and simple objects. Mario has an incredibly complicated geometry layout, and by understanding it more we'll be able to replace Mario with other characters. (But it obviously has more uses than that, as every object and level part has geometry layout data)

Like I explained earlier in this thread, command 0x02 is used in the level geometry layout to jump to different room sets in multi-room levels (Boo's House, Inside Castle and Hazy Maze Cave). In this case, each 0x15 commands point to a particular room GBI polygon commands. I don't know how the game identify room sets though, as no command seem to indicate room sets numbers as is.

I didn't know about the second byte use though, but in levels, it's always 0x01. Command 0x03 is used to jump back to the stored address.

Now, take a look at Yoshi's Geometry layout data, which is way simpler than Mario: 

1575340  [16, 00, 00, 01] [00, C8, 00, 64] 

1575344    [04, 00, 00, 00]  

1575352    [1D, 00, 00, 00] [00, 00, 40, 00] 

1575356      [04, 00, 00, 00]  

1575368      [13, 01, 00, 00] [00, 00, 00, 00] [00, 00, 00, 00]

1575372        [04, 00, 00, 00]  

1575384        [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 26, F0]

1575388          [04, 00, 00, 00]  

1575400          [13, 01, 00, 64] [00, 00, 00, 00] [05, 02, 24, F0]

1575404            [04, 00, 00, 00]  

1575416            [13, 01, 00, DE] [00, 00, 00, 00] [00, 00, 00, 00]

1575420              [04, 00, 00, 00]  

1575428              [0E, 00, 00, 02] [80, 29, DB, 48] 

1575432                [04, 00, 00, 00]  

1575440                [15, 01, 00, 00] [05, 01, DA, 58]  Head

1575448                [15, 01, 00, 00] [05, 01, DA, 80]  Head eyes closed

1575452              [05, 00, 00, 00]  

1575456            [05, 00, 00, 00]  

1575460              [04, 00, 00, 00]  

1575472              [13, 01, 00, 4C] [00, 31, 00, 00] [00, 00, 00, 00]

1575476                [04, 00, 00, 00]  

1575488                [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 13, 98] Lower jaw

1575492              [05, 00, 00, 00]  

1575496            [05, 00, 00, 00]  

1575508            [13, 01, 00, 33] [00, 37, 00, 61] [00, 00, 00, 00]

1575512              [04, 00, 00, 00]  

1575524              [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 17, 60] Leg?

1575528                [04, 00, 00, 00]  

1575540                [13, 01, 00, 4A] [00, 00, 00, 00] [05, 02, 16, C0]

1575544                  [04, 00, 00, 00]  

1575556                  [13, 01, 00, 45] [00, 00, 00, 00] [05, 02, 15, 78]

1575560                [05, 00, 00, 00]  

1575564              [05, 00, 00, 00]  

1575568            [05, 00, 00, 00]  

1575580            [13, 01, 00, 33] [00, 37, FF, 9F] [00, 00, 00, 00]

1575584              [04, 00, 00, 00]  

1575596              [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 19, E8]

1575600                [04, 00, 00, 00]  

1575612                [13, 01, 00, 4A] [00, 00, 00, 00] [05, 02, 19, 48]

1575616                  [04, 00, 00, 00]  

1575628                  [13, 01, 00, 45] [00, 00, 00, 00] [05, 02, 18, 00]

1575632                [05, 00, 00, 00]  

1575636              [05, 00, 00, 00]  

1575640            [05, 00, 00, 00]  

1575644          [05, 00, 00, 00]  

1575656          [13, 01, FF, FF] [00, 1B, 00, 5F] [00, 00, 00, 00]

1575660            [04, 00, 00, 00]  

1575672            [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 1D, C0]

1575676              [04, 00, 00, 00]  

1575688              [13, 01, 00, 64] [00, 00, 00, 00] [05, 02, 1C, 78]

1575692                [04, 00, 00, 00]  

1575704                [13, 01, 00, 5F] [00, 00, 00, 00] [05, 02, 1A, 88]

1575708              [05, 00, 00, 00]  

1575712            [05, 00, 00, 00]  

1575716          [05, 00, 00, 00]  

1575728          [13, 01, FF, A7] [FF, C2, 00, 00] [00, 00, 00, 00]

1575732            [04, 00, 00, 00]  

1575744            [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 1F, 20]

1575748          [05, 00, 00, 00]  

1575760          [13, 01, FF, FF] [00, 1B, FF, A1] [00, 00, 00, 00]

1575764            [04, 00, 00, 00]  

1575776            [13, 01, 00, 00] [00, 00, 00, 00] [05, 02, 23, 90]

1575780              [04, 00, 00, 00]  

1575792              [13, 01, 00, 64] [00, 00, 00, 00] [05, 02, 22, 48]

1575796                [04, 00, 00, 00]  

1575808                [13, 01, 00, 5F] [00, 00, 00, 00] [05, 02, 20, 58]

1575812              [05, 00, 00, 00]  

1575816            [05, 00, 00, 00]  

1575820          [05, 00, 00, 00]  

1575824        [05, 00, 00, 00]  

1575828      [05, 00, 00, 00]  

1575832    [05, 00, 00, 00]  

1575836  [05, 00, 00, 00]


I know that the 0x15 command points to polygon data, command 0x13 also point to polygons (but not always) and I don't know the use of the first 7 parameter bytes.

I added indentation for the 0x04 and 0x05 commands, which seem to act like parenthesis surrounding sub-groups, forming a hierarchy. This may well be something akin to bone hierarchy? Or maybe it's some sort of BSP tree? It's unclear how the game keeps track of each body part. Everything else I found in the game has somekind of ID attached to it, not in this case. Maybe they are referred as positions in groups and sub-groups?

Yoshi really has two heads , one with the eyes opened, and one with the eyes closed. Mario has 8 of them for its animated eyes. Ultimately, all heads refer to the same vertex and triangle sets, but with different textures. They are loaded sequentially one after the other using 0x15 commands, and with no ID attached to them.

One possible scenario is that these ID's (and their polygon data pointers) are created and stored as the geometry data is read, then referenced by bone animation routines.

By the way, this Alias document is full of very interesting stuff! What's funny is that it's not even from the internet archive, this site is still working even after all those years!

Edit: added screenshot that I struggled to upload at photobucket earlier.
Another Edit: Some phrase made no sense...yeah it's late...
and why is there a blank 3rd page on this thread now?

(edited by VL-Tone on 01-25-06 04:18 AM)
(edited by VL-Tone on 01-25-06 04:23 AM)
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - ROM Hacking - General Super Mario 64 hacking / TT64 Progress thread | Thread closed


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.026 seconds; used 499.59 kB (max 642.14 kB)