Register - Login
Views: 99364259
 Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies		 04-23-22 02:26:50 PM
Jul - SM64 Hacking (Archive) - MariOZMAV - a Super Mario 64 level viewer New poll - New thread - New reply
Pages: 1 2 Next newer thread | Next older thread
xdaniel
980
Level: 64


Posts: 1/982
EXP: 2151467
For next: 62630

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 16 days
Last activity: 7 hours
Posted on 12-04-08 01:02:44 PM (last edited by xdaniel at 01-14-09 06:09 PM) Link | Quote
Hi there,

to give a short introduction, I'm xdaniel, a ROM hacker & translator from Germany, currently working mainly on a few N64-related things, all of them being level, or more generically model/geometry viewers. The one I'd like to post about here was the fourth started - first being one for Zelda OoT and MM maps, second for Starfox 64 models, third works on RAM dumps of Smash Bros. and Neon Genesis Evangelion -, but is already the second, or possibly even farthest along of the bunch.

Anyway, this is "MariOZMAV", a stupid pun on the base of them all, the Zelda viewer OZMAV (OpenGL Zelda Map Viewer).



It's coded in C, uses - as per the acronym - OpenGL for 3D rendering and reads all data from a Mario 64 ROM expanded by VL-Tone's ROM Extender. The RSP Display List interpreter is pretty complete - SETGEOMETRYMODE is giving me a hard time, tho, in regards to en-/disabling lighting and such, so that part is ignored in this build -, the Mario 64-specific stuff, mainly interpreting the Level Layout Script and loading and rendering objects, is, however, still rather incomplete.

Some problems are, for example: Rendering objects that don't have their Display Lists inside the level data itself (meaning those that aren't ex. the tilting bridge-thingy, or the gate in front of the Chain Chomp star, in Bob-Omb's Battlefield) doesn't work and they only show up as small, green and white cubes, the Bowser levels and Rainbow Ride barely show anything at all (they're almost(?) fully made from objects, aren't they?), other levels are missing their ground - ex. Lethal Lava Land's lava -, again others seem to be randomly missing parts of the geometry(??), etc., etc. Some of those are certainly sloppy coding on my part (^^"), with others I just don't understand and/or interpret enough of Mario 64's level layout data yet.

If you still want to give it a try, despite all the flaws I mentioned, the download is below. Just start the program and load up an expanded ROM, it will then render the level specified inside its INI file. Without an INI, it defaults to the first level in the level script pointer list, that being the Haunted House. Once you've run it once, you can change the level ID inside the INI to anything from 0 to 30 - 0 is the Haunted House, 1 is Cool-Cool Mountain, 2 is the castle interior, etc.

...or tl;dr: Mario 64 level viewer, working okay but has some bugs and is rather early overall.

Thus, enough of this wall of text, here we go: http://magicstone.de/dzd/random/ozmav-misc/MariOZMAV_v02.rar

Newer version + source: http://magicstone.de/dzd/random/MariOZMAV_v03_src.rar

Edit: ah, right, in case you're interested in the other viewers I mentioned: http://code.google.com/p/ozmav/ & http://zelda-coalition.net/index.php?topic=109.0
Stevoisiak
Member
Level: 38


Posts: 178/283
EXP: 345464
For next: 24983

Since: 11-22-07

From: New York, Long Island

Since last post: 12.3 years
Last activity: 5.6 years
Posted on 12-04-08 07:30:43 PM Link | Quote
WHOA! The amount of detail in that is amazing! The terrain almost looks like it's in game!
messiaen
Catgirl
Level: 68


Posts: 421/1085
EXP: 2593950
For next: 134850

Since: 11-20-07


Since last post: 8.1 years
Last activity: 7.2 years
Posted on 12-04-08 09:10:51 PM (last edited by messiaen at 12-04-08 06:20 PM) Link | Quote
Very cool stuff, is there a source available for this branch? Some part the levels such as water and lava are loaded by functions called from the main terrain geometry layout, so getting it in the viewer will be a bit more troublesome.

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


Posts: 3/982
EXP: 2151467
For next: 62630

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 16 days
Last activity: 7 hours
Posted on 12-05-08 10:52:43 AM (last edited by xdaniel at 12-05-08 07:53 AM) Link | Quote
Stevoisiak: It's at least very close to it. There's stuff missing, like I said before, the SETGEOMETRYMODE command I mentioned still isn't correctly implemented, but otherwise it's pretty good, I suppose.

messiaen: It's not yet available, but I'm planning to commit it to the Google Code SVN over the weekend. I'll try to get some more stuff in, fix some bugs and then make it available there


____________________
cu xdaniel
Stevoisiak
Member
Level: 38


Posts: 179/283
EXP: 345464
For next: 24983

Since: 11-22-07

From: New York, Long Island

Since last post: 12.3 years
Last activity: 5.6 years
Posted on 12-05-08 07:44:24 PM Link | Quote
Originally posted by xdaniel
Stevoisiak: It's at least very close to it. There's stuff missing, like I said before, the SETGEOMETRYMODE command I mentioned still isn't correctly implemented, but otherwise it's pretty good, I suppose.


I know the objects aren't there, but in VL-Tone's viewer, it looks a bit more... prerendered. If you combine this veiwer with VL-Tones, it would be perfect! Too bad its coded in a different language.
BigBrain
Member
Level: 22


Posts: 6/85
EXP: 55265
For next: 3085

Since: 09-10-08


Since last post: 8.8 years
Last activity: 6.7 years
Posted on 12-06-08 06:18:02 AM Link | Quote
Originally posted by Stevoisiak

I know the objects aren't there, but in VL-Tone's viewer, it looks a bit more... prerendered. If you combine this veiwer with VL-Tones, it would be perfect! Too bad its coded in a different language.


The programming language isn't that much of a barrier, it's just the loading routine or the renderer which is different after all.


Definitely a great program though, I'm really looking forward to seeing the source code ;D
(linux port, anyone? - Okay, just kidding)
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 362/621
EXP: 1135466
For next: 21653

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 1.2 years
Posted on 12-06-08 04:52:54 PM (last edited by VL-Tone at 12-06-08 01:54 PM) Link | Quote
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
At last some competition

I must admit, it does looks nice!

TT64's polygon decoding/rendering code is the oldest code in the program. The editor was rewritten from the ground up once, a long time ago before the first TT64 release, but I kept the polygon code from the first version. The code was written in part by trial and error, at a time where I was reverse engineering the GBI commands, with little or no input from documents or emulator source code (the only help I got was from Cellar Dweller, who explained a dew commands). The code is rather messy, and I'm now thinking about rewriting it.

The current release of TT64 doesn't implement normals, nor fog, and there's a pretty stupid bug I didn't fix where some polygons get some weird gouraud shading colors blended with the textures. And just like you, I've been struggling with the SETGEOMETRYMODE command, though I got better results than you in levels the Castle Grounds.

Now, after seeing that screenshot and trying the program, I've gone back to try to fix a few things in TT64. I implemented fog, fixed the color shading bug, and tried to implement normals (they don't seem to work quite correctly though).

Here's a screenshot of the latest improvements, showing the same scene:



The main differences are:

The grass is darker in your screenshot. It looks nicer, but the grass is really glowing green in the game, like in the TT64 screenshot.

The normals smooth shading doesn't seem to work well in the TT64.

The shadow under the bridge in your screenshot is darker, which is a good thing. Colorized polygons in TT64 were hard to implement, it's hard to colorize the polygons completely without reducing the overall brightness of the scene (A limitation of the Shockwave3d engine).

The alpha masked textures look better in TT64, yours have a black edge around them and are too dark overall.

The light source doesn't seem come from the same place. Do the shadows on objects all come from normals and/or do you have a directional light source in your scene?

All in all, it's really nice to see an open-source SM64 viewer released. Maybe someone will be inspired to make another SM64 editor! Be prepared though, it's not as easy as it looks. I spent much more time designing the interface functionality and other decoding stuff than on the 3d viewer.

As for the SETGEOMETRYMODE command, in this thread: SM64 RSP commands the last post from messiaen contains a description of the command and parameters. Maybe we could post in that thread and try to figure it out once and for all.




____________________
messiaen
Catgirl
Level: 68


Posts: 424/1085
EXP: 2593950
For next: 134850

Since: 11-20-07


Since last post: 8.1 years
Last activity: 7.2 years
Posted on 12-06-08 05:13:10 PM Link | Quote
That was from some old Cellar Dweller's post. I did some experimenting with the 0xB7 command when messing with polygon data, and it's really hard to conclude how exactly it works.

I don't know if this could help, but this function (copy and paste from Nagra's Mario resource) is called all the time to set some basic properties, including the SetGeometryMode.

/* 0x802471a4 */
myRspInit()
{
gSPClearGeometryMode(d_buf++, 0x001f3204); /* rescan */
gSPSetGeometryMode(d_buf++, G_LIGHTNING | G_CULL_BACK | G_SHADING_SMOOTH | G_SHADE);
gMoveWd(d_buf++, 2, 0, 0x80000040);
gSPTexture(d_buf++, 0, 0, 0, 0, 0);
}

I tried changing the parameters for the SetGeometryMode with some wicked effects, but it's interesting that it only affects some levels, so I think it's something related to how display lists are divided between layers.

If you want to experiment changing the SetGeometryMode Parameters (hey, some cool Gameshark codes can be done with this ), this is the specific part of the code:

80247204: LUI T6, 0x0002
80247208: ORI T6, T6, 0x2204 /* T6 = 00022204 (see the last post in the RSP thread)
8024720C: SW T6, 0x0004 (T7)

There is also a myRdp init function, also found in Nagra's Mario Resource.

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


Posts: 6/982
EXP: 2151467
For next: 62630

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 16 days
Last activity: 7 hours
Posted on 12-22-08 05:55:17 PM Link | Quote
Sorry for the (very) late reply, I've been quite busy with real life, and pretty much all the spare time I had for programming went into OZMAV itself (which now also loading from ROM, etc.)

VL-Tone: Thanks for your comments and suggestions! After reading your post a while ago, I did make some improvements to the rendering code, ex. regarding the textures with alpha blending (the dark edge around them). Lighting is actually pretty much the weakest point of the entire renderer, among the reasons for that being that I'm using a static light source - the data for that coming from the NeHe OpenGL tutorials that my earliest viewer experiments were heavily based on, and are still using some parts of. That's also why the alpha-blended fences in the Battlefield appear as dark as they do, flat out wrong lighting.

As for the source code to MariOZMAV, I still haven't put it up anywhere, sorry. I will do that after christmas ^^"


____________________
cu xdaniel
xdaniel
980
Level: 64


Posts: 7/982
EXP: 2151467
For next: 62630

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 16 days
Last activity: 7 hours
Posted on 01-13-09 06:42:51 PM Link | Quote
Hoping that this bump is acceptable...

http://magicstone.de/dzd/random/MariOZMAV_v03_src.rar - the most recent binary and source code to MariOZMAV. It's rather untested and all since I last worked on it, I guess, a week before Christmas, but I hope it'll be useful to someone nonetheless, even if it's just for the F3D interpreter or whatever...

GEOMETRYMODE emulation is enabled but en-/disabling of lighting and especially the vertex coloring in general is still very buggy... There's also a very simple kind of texture cache inplemented, which speeds rendering up by far in most cases, but for some reason also causes certain textures to disappear when enabled (sometimes only one texture in the level, sometimes most of them). The caching function can be enabled or disabled via the INI file. Speaking of which, level switching at runtime still isn't possible and you still have to change the level ID inside the INI.

Well, that's it so far, I guess. If anyone wants to improve upon this program, feel free to do so, since I'm not sure if I will devote much more time to MariOZMAV... While I really do like Mario 64, I just don't have as many fond memories of playing it as of Zelda OoT, for example, and those tend to play quite a big part in most projects and such that I'm working on.


____________________
cu xdaniel
Stevoisiak
Member
Level: 38


Posts: 202/283
EXP: 345464
For next: 24983

Since: 11-22-07

From: New York, Long Island

Since last post: 12.3 years
Last activity: 5.6 years
Posted on 01-14-09 07:36:49 PM (last edited by Stevoisiak at 01-14-09 04:37 PM) Link | Quote
Originally posted by xdaniel
Hoping that this bump is acceptable...

http://magicstone.de/dzd/random/MariOZMAV_v03_src.rar - the most recent binary and source code to MariOZMAV. It's rather untested and all since I last worked on it, I guess, a week before Christmas, but I hope it'll be useful to someone nonetheless, even if it's just for the F3D interpreter or whatever...

(insert text about new features and technical details here)

Well, that's it so far, I guess. If anyone wants to improve upon this program, feel free to do so, since I'm not sure if I will devote much more time to MariOZMAV... While I really do like Mario 64, I just don't have as many fond memories of playing it as of Zelda OoT, for example, and those tend to play quite a big part in most projects and such that I'm working on.

I think that is a good enough reason to bump the thread. Just be sure to update the first post with a link to the new version. Also, I hear someone is making a level editor for Legend of Zelda. It's called Utility of Time. Maybe you can help work on that.
xdaniel
980
Level: 64


Posts: 8/982
EXP: 2151467
For next: 62630

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 16 days
Last activity: 7 hours
Posted on 01-14-09 09:19:10 PM Link | Quote
Heh, cooliscool's Utility of Time actually already exists for quite some time now - I'm still having a really, really old version from March 2007 here, for example (still called ZAV, with no textures at all) -, and I guess our renderers are almost on par with each other, his having the edge over OZMAV However, even if I could theoretically contribute something to it - which I suppose I can't -, I couldn't contribute actual source code or anything because UoT is written in VB.NET and the last Visual Basic version I had anything to do with was 6.0.

Thinking about it, I'm actually wondering about the current state of UoT. It's been a while since I last heard anything about it or since he last released a build...


____________________
cu xdaniel
Lyskar
12210
-The Chaos within trumps the Chaos without-
Level: 192


Posts: 1921/12211
EXP: 99232248
For next: 641323

Since: 07-03-07

From: 52-2-88-7

Since last post: 7.4 years
Last activity: 7.3 years
Posted on 01-15-09 06:31:22 AM Link | Quote

Time/Date

01-15-09 12:31:22am

Posts

1921

Days Here

561

Level

63
Metal_Man88
Local Moderator
Originally posted by Stevoisiak
Originally posted by xdaniel
Hoping that this bump is acceptable...

http://magicstone.de/dzd/random/MariOZMAV_v03_src.rar - the most recent binary and source code to MariOZMAV. It's rather untested and all since I last worked on it, I guess, a week before Christmas, but I hope it'll be useful to someone nonetheless, even if it's just for the F3D interpreter or whatever...

(insert text about new features and technical details here)

Well, that's it so far, I guess. If anyone wants to improve upon this program, feel free to do so, since I'm not sure if I will devote much more time to MariOZMAV... While I really do like Mario 64, I just don't have as many fond memories of playing it as of Zelda OoT, for example, and those tend to play quite a big part in most projects and such that I'm working on.

I think that is a good enough reason to bump the thread. Just be sure to update the first post with a link to the new version. Also, I hear someone is making a level editor for Legend of Zelda. It's called Utility of Time. Maybe you can help work on that.


Hey you. You don't say when bumps are acceptable.

Next time I see you post things like you own the place, you'll own some deleted posts instead.

Anyway. Stevo is correct, especially since you are contributing something. But you don't have to update the first post. And I won't tell you what to do, unlike somebody else, who thinks he's a mod when he's not. :p

____________________
Original Layout © Tobias Kelmandia
Stevoisiak
Member
Level: 38


Posts: 204/283
EXP: 345464
For next: 24983

Since: 11-22-07

From: New York, Long Island

Since last post: 12.3 years
Last activity: 5.6 years
Posted on 01-15-09 09:16:38 PM Link | Quote
Originally posted by Metal_Man88


Hey you. You don't say when bumps are acceptable.

Next time I see you post things like you own the place, you'll own some deleted posts instead.

Anyway. Stevo is correct, especially since you are contributing something. But you don't have to update the first post. And I won't tell you what to do, unlike somebody else, who thinks he's a mod when he's not. :p

Sorry. It's a force off habbit. In a lot of other forums, it is ok because I am only stating my opinion. I'll try to stop though.
Lyskar
12210
-The Chaos within trumps the Chaos without-
Level: 192


Posts: 1923/12211
EXP: 99232248
For next: 641323

Since: 07-03-07

From: 52-2-88-7

Since last post: 7.4 years
Last activity: 7.3 years
Posted on 01-15-09 09:22:02 PM Link | Quote

Time/Date

01-15-09 03:22:02pm

Posts

1923

Days Here

562

Level

63
Metal_Man88
Local Moderator
Well, when your opinion exists to potentially contradict or confuse people with the official rules, it's a problem.

____________________
Original Layout © Tobias Kelmandia
xdaniel
980
Level: 64


Posts: 9/982
EXP: 2151467
For next: 62630

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 16 days
Last activity: 7 hours
Posted on 01-21-09 06:27:23 PM Link | Quote
So, actually I ended up working on this some more... I honestly didn't think I'd do, but here we go:

- GEOMETRYMODE problems seem fixed now - en-/disabling of lighting, normals and vertex colors seem to work properly. Well, the actual lighting, in regards to light position etc., is still bad compared to the real game, but it's better than nothing...
- the texture cache is still broken, possibly even more so than before...
- "Macro 3D Objects" are now being handled much better (or rather, for the first time ever, more or less correctly, they - like most other objects - only show up as little green cubes though
- ...maybe other things, but I'm not sure



No updated download or anything yet, as parts of the code got... well... really messed up. It works, but it's unstable, sometimes crashing without (seemingly) any reason, etc...


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


Posts: 375/621
EXP: 1135466
For next: 21653

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 1.2 years
Posted on 01-22-09 12:10:00 AM Link | Quote
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
xdaniel:

Great to see that you continued to work on MariOZMAV!

Could you explain what determines when normals are used instead of vertex coloring? You know, the three bytes that are in the vertex list that can be interpreted either as 3 vertex normals or a vertex color?

Messiaen gave me some great documentation about the GEOMETRYMODE command, but the normals/vertex color part is still not clear to me, and I'm a little tired of going by trial and error (as I said before, my polygon decoding routines are very old and a little messy).

____________________
xdaniel
980
Level: 64


Posts: 10/982
EXP: 2151467
For next: 62630

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 16 days
Last activity: 7 hours
Posted on 01-22-09 12:05:27 PM (last edited by xdaniel at 01-24-09 08:20 PM) Link | Quote
VL-Tone:

I'm not 100% sure if my method is correct (wrong light position, semi-broken texturing and all...), but it does look okay... Anyway: By default, I'm having OpenGL's lighting and normalization features enabled, glEnable(GL_LIGHTING) and glEnable(GL_NORMALIZE), and my program's vertex color flag disabled, Renderer_EnableVtxColors = false.

Then, when it comes to interpreting the Display List, I use the flags like this (example being SETGEOMETRYMODE, just think "glDisable" for CLEAR ):

0x00000001: glEnable(GL_DEPTH_TEST) - Z-buffering
0x00000004: Renderer_EnableVtxColors = false - vertex colors
0x00001000: glEnable(GL_CULL_FACE), glCullFace(GL_FRONT) - frontface culling
0x00002000: glEnable(GL_CULL_FACE), glCullFace(GL_BACK) - backface culling
0x00010000: glEnable(GL_FOG) - fog
0x00020000: glEnable(GL_LIGHTING), glEnable(GL_NORMALIZE) - lighting & normalization

As I said, I'm not fully certain that this is the correct way to do it, but it seems to be working so far. Also, I'm not resetting those flags to their initial status after each Display List or anything, I just let them handle the flags. Here's hoping that this helps you somehow

Finally, I've got a question myself. Here's part of MariOZMAV's log for Bob-Omb's Battlefield's level loading script:

(Command type, offset in script, first two bytes of command, description)

LVL: 0x00000264 - 0x1B04 - Start RAM loading sequence

LVL: 0x00000268 - 0x170C - Copy data from ROM to RAM
- Copying data to segment 0x07: start: 0x00EF0E37, end: 0x00F025F9, length: 0x000117C2

LVL: 0x00000274 - 0x1A0C - Decompress MIO0 data from ROM to RAM (textures)
- Texture start: 0x00CD4BD1, end: 0x00CE03D1, length: 0x0000B800

LVL: 0x00000280 - 0x170C - Copy data from ROM to RAM
- Copying data to segment 0x0A: start: 0x00B35715, end: 0x00B55855, length: 0x00020140

LVL: 0x0000028C - 0x170C - Copy data from ROM to RAM
- Copying data to segment 0x05: start: 0x0088C3BC, end: 0x0089D45C, length: 0x000110A0

LVL: 0x00000298 - 0x170C - Copy data from ROM to RAM
- Copying data to segment 0x0C: start: 0x0013B5D0, end: 0x0013B910, length: 0x00000340

LVL: 0x000002A4 - 0x170C - Copy data from ROM to RAM
- Copying data to segment 0x06: start: 0x00A09934, end: 0x00A2EABC, length: 0x00025188

LVL: 0x000002B0 - 0x170C - Copy data from ROM to RAM
- Copying data to segment 0x0D: start: 0x001D7C90, end: 0x001D8310, length: 0x00000680

LVL: 0x000002BC - 0x170C - Copy data from ROM to RAM
- Copying data to segment 0x08: start: 0x00A8181C, end: 0x00AAA40C, length: 0x00028BF0

LVL: 0x000002C8 - 0x170C - Copy data from ROM to RAM
- Copying data to segment 0x0F: start: 0x002008D0, end: 0x00201410, length: 0x00000B40

LVL: 0x000002D4 - 0x1D04 - End RAM loading sequence


Now, my problem is that I don't know for what many of those segments are used. As far as I understand them, segment 0x07 is geometry data, 0x09 is texture data (not mentioned as 0x09 since it's covered by the 0x1A command), 0x0E is right inside the level loading script as used by command 0x22 to execute geometry layout commands and... that's about it.

I'm not sure if I'm handling any other segments at the moment, but I don't think so. While not referenced above, segment 0x13 is behavior data (as far as I'm aware), and I do remember that one of the loading commands above points to the level's skybox textures, but neither is handled by MariOZMAV yet. I'm guessing that I might be able to access the Display Lists for all the objects that are right now being rendered as the lil' cubes once I understand more of those RAM segments, but... well, I dunno... it's kinda confusing ^^"

EDIT:



More objects are showing up (almost) correctly now, compared to the build of MariOZMAV v0.3 I posted above. Rotation for Macro Objects is non-existant at the moment, but that should be easy to implement...

EDIT 2:

Not really showing much more progress, but anyway: http://magicstone.de/dzd/random/ozmav-misc/v03x2_battlefield.png ~


____________________
cu xdaniel
messiaen
Catgirl
Level: 68


Posts: 465/1085
EXP: 2593950
For next: 134850

Since: 11-20-07


Since last post: 8.1 years
Last activity: 7.2 years
Posted on 01-25-09 04:15:51 PM Link | Quote
Originally posted by xdaniel
Finally, I've got a question myself. Here's part of MariOZMAV's log for Bob-Omb's Battlefield's level loading script:

[... log ... ]

Now, my problem is that I don't know for what many of those segments are used. As far as I understand them, segment 0x07 is geometry data, 0x09 is texture data (not mentioned as 0x09 since it's covered by the 0x1A command), 0x0E is right inside the level loading script as used by command 0x22 to execute geometry layout commands and... that's about it.

I'm not sure if I'm handling any other segments at the moment, but I don't think so. While not referenced above, segment 0x13 is behavior data (as far as I'm aware), and I do remember that one of the loading commands above points to the level's skybox textures, but neither is handled by MariOZMAV yet. I'm guessing that I might be able to access the Display Lists for all the objects that are right now being rendered as the lil' cubes once I understand more of those RAM segments, but... well, I dunno... it's kinda confusing ^^"


Segment 0x0A is used for the background textures. See this old Flatworld thread for some useful reference posted by rstewart.

Segments 0x05, 0x06, 0x0C, 0x0D are used by objects. Banks 0x05 and 0x06 cointains polygon data while banks 0x0C and 0x0D contains the geo layout data, pointed by the 0x22 command. AFAIR, segments 0x04 and 0x0B are also used by objects, but Bob-omb Battlefield doesn't use them.

Some segments (0x04, 0x03, 0x17, 0x16, 0x13) are shared (global), as they are loaded from the 'hub' script that launches the levels. Look at SM64MainLevelScripts.txt. Once you include that, I a lot of other objects can be displayed correctly (ie, coins, trees, signposts).

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


Posts: 11/982
EXP: 2151467
For next: 62630

Since: 12-04-08

Pronouns: he/they
From: Germany

Since last post: 16 days
Last activity: 7 hours
Posted on 01-26-09 06:55:30 PM (last edited by xdaniel at 01-26-09 04:01 PM) Link | Quote
Ah, thanks! Some modification to the level loading process later, and I'm now interpreting the important parts of the hub script as well, thus filling segments 0x03, 0x04, 0x13, 0x16 and 0x17 as well as executing the geometry layout data for each of the 0x22 commands in it - signs, among multiple other things are now starting to appear. That, however, brings me to the next problem:



What's wrong in that screenshot should be obvious, I guess:

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 0x0698 in segment 0x15, 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?

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

The sign in the screenshot above is way too big and another sign near the tilting bridge, right after the Chain Chomp is even floating in midair - again the question, how does the game know how to scale those objects properly, and why is said sign floating? (...actually, as I just noticed, it's also floating in Toad's Tool, so at least I'm not the only one who doesn't know, I guess )

Is the data that I'm missing - a Display List ID, additional model scaling and translation information - be coming from either the macro preset or the behavior data of an object? I looked at the macro presets for ex. the "!" boxes, but the parameters in there don't seem to influence ex. which Display List to use or at least I can't see them do it (since they're going from 0x00 to 0x09, for each box type increasing by one, and they're just 4 Display Lists). And behaviors... I don't really understand their data at all for now, gotta read up on that some.

(Goes to check out the thread on behavior scripts pretty much just next to this here...)

EDIT: *cough* geometry layout command 0x1D - "scale polygons command" ^^"


____________________
cu xdaniel
Pages: 1 2 Next newer thread | Next older thread
Jul - SM64 Hacking (Archive) - MariOZMAV - a Super Mario 64 level viewer New poll - New thread - New reply


Rusted Logic
Acmlmboard - commit 47be4dc [2021-08-23]
©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al.

32 database queries, 6 query cache hits.
Query execution time:  0.116328 seconds
Script execution time:  0.054711 seconds
Total render time:  0.171038 seconds


TidyHTML vomit below
line 1 column 1 - Warning: missing <!DOCTYPE> declaration
line 2 column 300 - Warning: unescaped & or unknown entity "&page"
line 119 column 11 - Warning: <form> isn't allowed in <table> elements
line 118 column 10 - Info: <table> previously mentioned
line 120 column 11 - Warning: missing <tr>
line 120 column 119 - Warning: missing </font> before </td>
line 124 column 16 - Warning: plain text isn't allowed in <tr> elements
line 120 column 11 - Info: <tr> previously mentioned
line 125 column 68 - Warning: missing </nobr> before </td>
line 141 column 68 - Warning: missing </nobr> before <tr>
line 147 column 35 - Warning: missing <tr>
line 147 column 50 - Warning: missing </font> before </td>
line 148 column 37 - Warning: unescaped & or unknown entity "&id"
line 147 column 212 - Warning: missing </font> before </table>
line 149 column 35 - Warning: missing <tr>
line 149 column 96 - Warning: unescaped & or unknown entity "&page"
line 149 column 50 - Warning: missing </font> before </td>
line 149 column 131 - Warning: missing </font> before </table>
line 156 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 158 column 9 - Warning: missing <tr>
line 176 column 13 - Warning: missing <tr>
line 177 column 99 - Warning: unescaped & or unknown entity "&postid"
line 202 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 204 column 9 - Warning: missing <tr>
line 222 column 13 - Warning: missing <tr>
line 223 column 99 - Warning: unescaped & or unknown entity "&postid"
line 228 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 230 column 9 - Warning: missing <tr>
line 248 column 13 - Warning: missing <tr>
line 249 column 99 - Warning: unescaped & or unknown entity "&postid"
line 254 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 256 column 9 - Warning: missing <tr>
line 274 column 13 - Warning: missing <tr>
line 275 column 99 - Warning: unescaped & or unknown entity "&postid"
line 284 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 286 column 9 - Warning: missing <tr>
line 304 column 13 - Warning: missing <tr>
line 305 column 99 - Warning: unescaped & or unknown entity "&postid"
line 313 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 315 column 9 - Warning: missing <tr>
line 333 column 13 - Warning: missing <tr>
line 334 column 99 - Warning: unescaped & or unknown entity "&postid"
line 347 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 349 column 9 - Warning: missing <tr>
line 367 column 13 - Warning: missing <tr>
line 368 column 99 - Warning: unescaped & or unknown entity "&postid"
line 370 column 73 - Warning: <style> isn't allowed in <td> elements
line 370 column 9 - Info: <td> previously mentioned
line 370 column 137 - Warning: missing </div>
line 404 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 406 column 9 - Warning: missing <tr>
line 424 column 13 - Warning: missing <tr>
line 425 column 99 - Warning: unescaped & or unknown entity "&postid"
line 451 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 453 column 9 - Warning: missing <tr>
line 471 column 13 - Warning: missing <tr>
line 472 column 99 - Warning: unescaped & or unknown entity "&postid"
line 483 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 485 column 9 - Warning: missing <tr>
line 503 column 13 - Warning: missing <tr>
line 504 column 99 - Warning: unescaped & or unknown entity "&postid"
line 517 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 519 column 9 - Warning: missing <tr>
line 537 column 13 - Warning: missing <tr>
line 538 column 99 - Warning: unescaped & or unknown entity "&postid"
line 551 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 553 column 9 - Warning: missing <tr>
line 571 column 13 - Warning: missing <tr>
line 572 column 99 - Warning: unescaped & or unknown entity "&postid"
line 581 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 583 column 9 - Warning: missing <tr>
line 601 column 13 - Warning: missing <tr>
line 602 column 99 - Warning: unescaped & or unknown entity "&postid"
line 604 column 73 - Warning: <style> isn't allowed in <td> elements
line 604 column 9 - Info: <td> previously mentioned
line 604 column 960 - Error: <z> is not recognized!
line 604 column 960 - Warning: discarding unexpected <z>
line 604 column 982 - Warning: discarding unexpected </z>
line 604 column 1008 - Error: <z> is not recognized!
line 604 column 1008 - Warning: discarding unexpected <z>
line 604 column 1015 - Warning: discarding unexpected </z>
line 604 column 1045 - Error: <z> is not recognized!
line 604 column 1045 - Warning: discarding unexpected <z>
line 604 column 1051 - Warning: discarding unexpected </z>
line 604 column 1077 - Error: <z> is not recognized!
line 604 column 1077 - Warning: discarding unexpected <z>
line 604 column 1082 - Warning: discarding unexpected </z>
line 621 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 623 column 9 - Warning: missing <tr>
line 641 column 13 - Warning: missing <tr>
line 642 column 99 - Warning: unescaped & or unknown entity "&postid"
line 654 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 656 column 9 - Warning: missing <tr>
line 674 column 13 - Warning: missing <tr>
line 675 column 99 - Warning: unescaped & or unknown entity "&postid"
line 677 column 73 - Warning: <style> isn't allowed in <td> elements
line 677 column 9 - Info: <td> previously mentioned
line 677 column 960 - Error: <z> is not recognized!
line 677 column 960 - Warning: discarding unexpected <z>
line 677 column 982 - Warning: discarding unexpected </z>
line 677 column 1008 - Error: <z> is not recognized!
Tidy found 545 warnings and 8 errors! Not all warnings/errors were shown.

The alt attribute should be used to give a short description
of an image; longer descriptions should be given with the
longdesc attribute which takes a URL linked to the description.
These measures are needed for people using non-graphical browsers.

For further advice on how to make your pages accessible
see http://www.w3.org/WAI/GL.
You are recommended to use CSS to specify the font and
properties such as its size and color. This will reduce
the size of HTML files and make them easier to maintain
compared with using <FONT> elements.

You are recommended to use CSS to control line wrapping.
Use "white-space: nowrap" to inhibit wrapping in place
of inserting <NOBR>...</NOBR> into the markup.

About HTML Tidy: https://github.com/htacg/tidy-html5
Bug reports and comments: https://github.com/htacg/tidy-html5/issues
Official mailing list: https://lists.w3.org/Archives/Public/public-htacg/
Latest HTML specification: http://dev.w3.org/html5/spec-author-view/
Validate your HTML documents: http://validator.w3.org/nu/
Lobby your company to join the W3C: http://www.w3.org/Consortium

Do you speak a language other than English, or a different variant of
English? Consider helping us to localize HTML Tidy. For details please see
https://github.com/htacg/tidy-html5/blob/master/README/LOCALIZE.md