Jul -- SM64 Hacking (Archive): MariOZMAV - a Super Mario 64 level viewer

messiaen
Catgirl
Level: 68

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

Since: 11-20-07

Since last post: 8.1 years
Last activity: 7.2 years

Posted on 01-26-09 08:05:00 PM

Link | Quote

Originally posted by xdaniel
1) All "!" boxes are rendered at once, in the same place, every time one of the boxes appears in a level.

For example, the "!" boxes are object ID 0x89, the 0x22 command loading the geometry - 22 08 00 89 0F 00 06 94 - being at 0x0694 in segment 0x0F [corrected typos], which in turn executes 4 Display Lists in segment 0x08... So, how does the game know which one of the 4 Display Lists to use for a given box?

I'm not sure if I understood what is happening, but each display list is a part of the object (they are usually divided by textures, I guess for optimization), like the main terrain. Try rendering all the display lists between the beggining and end of a Geo Layout script. If they all show in the same place, are you sure you are offsetting them by the X, Y, Z positions specified by the 0x24 command that creates the individualized objects ?

Originally posted by xdaniel
2) Certain objects ~~aren't scaled down to their in-game size~~, among other things.

Some objects have hardcoded scaling settings in the behavior scripts (0x32 command, which is just a a simple scaling factor), others in the geometry data (0x1d command, not sure how to read it) and many others have it hardcoded in their specific code. Also, behaviors can sometimes offset x,y,z positions or add a "gravity effect" (behavior command 0x1e), though this will depend a lot on the specific object. I guess dealing with all cases would be pretty much impossible.

____________________
Mario 64 notes @ http://sites.google.com/site/messiaen64/

xdaniel
980

Level: 64

Posts: 12/982
EXP: 2153585
For next: 60512

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 25 days
Last activity: 1 hour

Posted on 01-26-09 08:41:33 PM

Link | Quote

Okay, first about the scaling: I've got the 0x1D geometry command in, approximating how to read its parameter bytes based on the signposts - they now show up pretty much like they do in the game, I think. As for the other ways how scaling and positioning might be set or offset... I'll leave those out since it really seems like too much work and all to try and implement them...

Now for the "!" boxes, which I guess I haven't written about clearly enough (ugh, typing and coding while being tired isn't that great of an idea ^^"):

Anyway, what I'm doing right now actually is already rendering all the Display Lists inside one geometry layout script, and using the X, Y and Z position specified by the 0x24 command to render them. This one has 4 almost identical Display Lists - same order and amount of commands, just different texture and vertex offsets - which, I suppose, means that there's one for the red Wing Cap box, one for the green Metal Cap box, one for the blue Vanish Cap box and one for the regular orange box.

So when rendering a 0x89 "!" box object, I end up with all 4 of those Display Lists being rendered instead of just the one of the box type that's actually supposed to be at that place in the level - so when there's a Wing Cap box in Bob-Omb's Battlefield somewhere, the viewer places it at the correct position but renders all four "!" box models instead of just the red one, or if there's a regular orange box with coins or a star inside, it again renders all four models instead of the orange one alone.

I hope this came out a bit clearer ^^"

____________________
cu xdaniel

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

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

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 01-27-09 01:01:01 AM (last edited by VL-Tone at 01-26-09 10:01 PM)

Link | Quote

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

The correct display list for the "!" boxes is chosen by the behavior asm function, depending on the behavior param found in or referred by the 0x24, 0x42 or 0x43 command displaying the "!" box. I had to add a special case in TT64 that traps the "!" box objects and choose the corresponding display list according to the behav param.

Now, let's take a look at the geometry layout script for the "!" box:

00200F64 / 0F000694 [ 20 00 01 2C ]

00200F68 / 0F000698 [ 04 00 00 00 ]

00200F6C / 0F00069C    [ 16 00 00 0A 00 B4 00 46 ]

00200F74 / 0F0006A4    [ 04 00 00 00 ]

00200F78 / 0F0006A8       [ 0E 00 00 04 80 29 DB 48 ]

00200F80 / 0F0006B0       [ 04 00 00 00 ]

00200F84 / 0F0006B4          [ 15 01 00 00 08 01 93 18 ]

00200F8C / 0F0006BC          [ 15 01 00 00 08 01 93 78 ]

00200F94 / 0F0006C4          [ 15 01 00 00 08 01 93 D8 ]

00200F9C / 0F0006CC          [ 15 01 00 00 08 01 94 38 ]

00200FA4 / 0F0006D4       [ 05 00 00 00 ]

00200FA8 / 0F0006D8    [ 05 00 00 00 ]

00200FAC / 0F0006DC [ 05 00 00 00 ]

00200FB0 / 0F0006E0 [ 01 00 00 00 ]

See that 0x0E command? It's used for doing animation using multiple display lists (I'm not talking about things that move or rotate, but rather animation done by switching models/display lists). The fourth byte (in this case 0x04) is the number of frames in the animation. The 0x0E command applies to items inside the following "node" in the geo layout hierarchy, which in this case contains four 0x15 commands pointing to 4 different display lists, and only one at a time is displayed by the game engine.

The last four bytes of the 0x0E are a RAM pointer referring to some ASM function that determines what kind of animation will be used. For things like flames and other similar animated models, the game simply cycles trough all frames with a predetermined frame-rate. In other cases, the current frame number is dynamic and is set by behavior ASM functions, for example, Mario's eyes animation are done by switching the whole head display lists found inside a similar node (and like the "!" boxes, these share the same vertices).

While the 0x0E is mainly used for animation, it's also used for the "!" box, as the behavior ASM function for these will set the "frame" to the box with the corresponding color depending on the provided parameter. A similar trick is used to put star numbers on doors.

Now, I didn't look inside the behavior ASM code to be able to render the "!" boxes correctly depending on their content. Unless you integrate an N64 emulator into your program, you'll never be able to render every single animated object correctly, even in a static form, using only the data in ROM. Not to say that you couldn't animate simple stuff like flames, but there are a few things that absolutely depend on ASM to be rendered correctly. The most you could do without integrating an N64 emulator is to reverse-engineer and port all these behavior functions to your program, and that wouldn't be a piece of cake (this is essentially what I did for the "!" box case, but there are many others cases, each behaving differently.)

____________________

xdaniel
980

Level: 64

Posts: 13/982
EXP: 2153585
For next: 60512

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 25 days
Last activity: 1 hour

Posted on 01-29-09 07:26:37 PM

Link | Quote

Thanks for the help and advice, but I haven't managed to get the program to render those objects properly... It's not that I don't understand how I should be doing it, but rather that I can't seem to implement that into my existing code without breaking everything - objects not showing up at all, objects still rendering all Display Lists instead of just one, objects only rendering one Display List when they should render multiple, etc. The last one was my third freaking try... Well, gotta rewrite some of that object rendering code, I suppose -.-

____________________
cu xdaniel

xdaniel
980

Level: 64

Posts: 14/982
EXP: 2153585
For next: 60512

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 25 days
Last activity: 1 hour

Posted on 04-06-09 04:23:56 PM

Link | Quote

It's been a while since I last posted here, and also since I last worked on MariOZMAV... So, in case someone might be interested in it, here's the (slightly broken) latest source code of the program - I last worked on it late January, the included executable having been built on January 31st, I think the texture cache is still broken, object rendering is still buggy as well, but it's better than nothing...

...anyway, download here: http://magicstone.de/dzd/random/ozmav-misc/mariozmav_latest.rar

Even though I've ceased working on it - actually, no branch of OZMAV is still in the works at the moment -, I still won't mind comments or whatever

____________________
cu xdaniel

Stevoisiak
Member
Level: 38

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

Since: 11-22-07

From: New York, Long Island

Since last post: 12.4 years
Last activity: 5.6 years

Posted on 04-07-09 09:46:12 PM

Link | Quote

One thing I always love about MariOZMAV is that the levels look a bit more... natural, as opposed to prerendered

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

dragon123
i told you man i TOLD you about posts
Level: 6

Posts: 5/5
EXP: 747
For next: 160

Since: 02-10-10

Since last post: 12.2 years
Last activity: 12.2 years

Posted on 02-16-10 12:53:19 PM

Link | Quote

doesnt worked for me

____________________
if you want to have fun make hacks!

hacks is the best!

hack made the word better.

HOLY CRAP THAT AVATAR WAS HUGE don't put it that big thanks -administration

xdaniel
980

Level: 64

Posts: 24/982
EXP: 2153585
For next: 60512

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 25 days
Last activity: 1 hour

Posted on 02-16-10 03:09:30 PM

Link | Quote

Originally posted by dragon123
doesnt worked for me

Even though the project is very much frozen right now, I'm still interested in why the program doesn't work for someone. However, "doesnt worked for me" isn't much help.

So, what exactly is happening when you try to start it? Does it crash, does it not load the ROM or levels?

____________________
cu xdaniel

Lyskar
12210

-The Chaos within trumps the Chaos without-
Level: 192

Posts: 4336/12211
EXP: 99320561
For next: 553010

Since: 07-03-07

From: 52-2-88-7

Since last post: 7.4 years
Last activity: 7.3 years

Posted on 02-16-10 06:44:27 PM

Link | Quote

Time/Date

02-16-10 12:44:27 PM

Posts

4336

Days Here

959

Level

96

	Metal_Man88
	Local Moderator

Don't bother, he can't operate the new reply button properly, let alone OZMAV.

____________________

MarIO0
Member
Level: 16

Posts: 23/43
EXP: 19175
For next: 1081

Since: 09-03-09

Since last post: 9.3 years
Last activity: 8.6 years

Posted on 05-28-11 12:15:38 PM

Link | Quote

There's a bug that crashes the program (at least with the latest version of Code::Blocks+MinGW).

On helpers.c, HelperFunc_ScriptLogCommand, the line that reads:

char * CmdTypeText;

Should be:

char CmdTypeText[4];

I'm surprised that some compiler actually manages not to crash the program with this bug.

xdaniel
980

Level: 64

Posts: 262/982
EXP: 2153585
For next: 60512

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 25 days
Last activity: 1 hour

Posted on 05-30-11 07:51:52 PM

Link | Quote

>>ESTABLISHING LINK...DONE.    >>FETCHING POST DATA...DONE.    >>EXECUTING POSTDISP.BIN...

On one hand, it's great that someone actually looked at the thing, on the other, it's embarrassing for me to see this POS code again.

That is quite a bug, and I don't even know why I did this, or yeah, why it even worked for me...

____________________
cu xdaniel - Follower of the Church of Madoka

"What color is your BLOOD?!?"

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

Query execution time:	0.090821 seconds
Script execution time:	0.028424 seconds
Total render time:	0.119245 seconds