SayakaGL - New Zelda OoT/MM level editor

[xdaniel]

SayakaGL v0.2, last version ever, binary and source: https://www.the-gcn.com/topic/186-sayakagl-new-zelda-ootmm-level-editor/?p=38810

 

April 19th, 2011, SayakaGL v0.1.1 Public: http://magicstone.de/dzd/random/sayaka/SayakaGL_v011.rar(Original post below)

---

http://i.imgur.com/eluCZ.pnghttp://i.imgur.com/x8gEx.png

Edited June 5, 2013 by xdaniel

[Gump]

Isn't that the Great Deku Tree? Or, are you referring to something else.

[xdaniel]

Well, I was referring to the program, but yeah, that's the Deku Tree in the first screenshot. The second one is a part of Hyrule Field, btw, just like this:

 

[Secant]

Reminds me of OZMAV2. I'm curious about this program's purpose and capabilities.

[xdaniel]

It's kinda OZMAV2's internal design, plus a GUI styled after and certain technical elements (data management, etc.) inspired by UoT, written in C#. I'm basically trying to make a more user-friendly OZMAV2, comparable in features to UoT, and it's going rather well so far. There's still a bunch of stuff to do, but it's already capable of loading and identifying ROMs, reading the DMA table and the scene table, loading, interpreting and rendering scenes and their rooms, proper camera movement and some more. All that said, here's another screenshot with (finally, mostly) proper textures - next up will be finishing up the rest of the Display List interpreter, mainly GeometryMode, OtherMode_L and _H, the combiner and a few other bits and pieces:

 

 

Showing the Dodongo's Cavern main hall, with one of its Display Lists highlighted - I really have to give credit to cool for quite a bit in terms of ideas and the like here

[Salvage66]

It's kinda OZMAV2's internal design, plus a GUI styled after and certain technical elements (data management, etc.) inspired by UoT, written in C#. I'm basically trying to make a more user-friendly OZMAV2, comparable in features to UoT, and it's going rather well so far. There's still a bunch of stuff to do, but it's already capable of loading and identifying ROMs, reading the DMA table and the scene table, loading, interpreting and rendering scenes and their rooms, proper camera movement and some more. All that said, here's another screenshot with (finally, mostly) proper textures - next up will be finishing up the rest of the Display List interpreter, mainly GeometryMode, OtherMode_L and _H, the combiner and a few other bits and pieces:

 

http://i.imgur.com/ma3Po.png

 

Showing the Dodongo's Cavern main hall, with one of its Display Lists highlighted - I really have to give credit to cool for quite a bit in terms of ideas and the like here

 

Dude whats cool been doing these days anyways and how do you keep finding him anyway?Skype?Because i could could use a few tips too.The dlist system and all.

[xdaniel]

Salvage66: I actually haven't been talking to him recently (that is, via YouTube messages or comments and such), I've just been looking at UoT's source to get an idea of how he did stuff, compared to how I did it in OZMAV2. He does seem to still use YouTube regularly, tho, so you might be able to get ahold of him that way.

[Secant]

I like the direction this is heading; it's about time we got a stable GUI tool similar to UoT. Keep us updated, xdan, this looks very promising.

[Satoshi Kura]

I wonder if you could get this to export to a .map file.... Then I could compile them for Jedi Academy. Course, I'd have to set up textures and everything, which would be a REAL pain.... But still, this is cool, keep up the good work!

[xdaniel]

 

The texture loader is done, the combiner is done, GeometryMode and OtherMode_L are in a presentable state, what's left for now in terms of the Display List interpreter is mainly RDPHalf and DList branches using that (used in, if I recall, Kakariko for the well, and Gerudo Valley for the river area). I also started working on the DList editing part of the program, it's so far capable of finding the selected command in the stored Display List; next will be the implementing of the actual editing part, writing the Display List back to the room file, and then saving the modified file to ROM.

 

A significant bug that I'm not yet able to track down is related to OpenGL's lighting - for some reason, the lighting setup I've been using for OZMAV2 doesn't work right here, which results in way too much darkness around the maps, as you can see on the right of the screenshot.

[Zeth Ryder]

I honestly really look forward seeing this finished, I really think this is going to be amazing! :>

I wanted to ask, are you going to finish work on the ZSaten viewer so that models display correctly?

[xdaniel]

Zeth: I'm probably going to work on it again, but I have no idea when. I've kept myself busy with other new projects, instead of fixing up old ones, which is quite typical of me... We'll see about it, I guess.

 

Now, as for this one:

 

 

Editing PrimColor and EnvColor is in and working correctly; just click the colored box in the lower right to pick a color, change the alpha value with the numerical selector if you want, and press the button. The changed colors should be visible in the level right away - well, at least if your geometry's color/alpha is determined by what you changed anyway, there's plenty of other ways after all Haven't coded up any saving routines yet, so it's still a temporary change for now.

[Secant]

I was wondering why some geometry was randomly tinted. That's really cool, xdan, looks like this will be far more functional than UoT. I'm really looking forward to this tool seeing a release.

[xdaniel]

The green tinting on the last two screenshot (and the red stuff before, I changed the color) is actually the currently selected Display List, color editing only came with that last status update

 

Anyway, next update:

 

 

First, a big speedup because I changed my rendering method around, now you can load up the whole Fire Temple at once and still move around it with relative speed. Overall, OZMAV2 is still faster, but it's not as severe of a difference anymore. Hope it stays that way.

 

And second, the combiner editor is pretty much done, allowing you to play around with each combiner setup. The labels in between each element are wrong, as I just noticed looking at the screenshot again, but they'll be fixed right away =P Saving still isn't coded in yet, tho - I will start working on actor placement next (with just cubes for now), then look into saving. Shouldn't be too big of a deal to implement.

 

EDIT:

 

Now with our old friends, the actor cubes!

 

 

...I soo need to get the texture of the Weighted Companion Cube XD

 

EDIT 2:

 

 

Actor editing and saving changes to ROM is in; but still needs some testing

 

EDIT 3:

 

Screenshot-less update this time, actor selection via mouse is now in as well; still need to implement moving them that way. And while not copy and pasted directly (doesn't work anyway, with VB vs C#), much of the code was based on UoT's

[xdaniel]

While waiting for feedback, I've been messing around with the Display List and combiner editors... not changing the editors, but actually using them. Got something a bit more impressive than yellow castle walls this time around:

 

 

Excluding the now enabled skybox, the coloring and transparency effects were all done using SayakaGL alone. I think this looks pretty nice, doesn't it?

[Salvage66]

While waiting for feedback, I've been messing around with the Display List and combiner editors... not changing the editors, but actually using them. Got something a bit more impressive than yellow castle walls this time around:

 

http://i.imgur.com/K7bDH.png

 

Excluding the now enabled skybox, the coloring and transparency effects were all done using SayakaGL alone. I think this looks pretty nice, doesn't it?

 

DUDE!!That sh** is sweet!I wish i had you around my project would be done in a week!!But dude seriosly Nice work!hey could you pm me your skype maybe?

[xdaniel]

Salvage66: Skype of all things I'm not giving out to / accept everyone on, sorry. Feel free to contact me ex. here via PM or so, tho

 

Also, started the OtherMode_L command editor - basically a list with checkboxes to enable and disable its settings -, for example, here I disabled Hyrule Field's water's Z_CMP option (that is, depth testing):

 

[Salvage66]

Salvage66: Skype of all things I'm not giving out to / accept everyone on, sorry. Feel free to contact me ex. here via PM or so, tho

 

Also, started the OtherMode_L command editor - basically a list with checkboxes to enable and disable its settings -, for example, here I disabled Hyrule Field's water's Z_CMP option (that is, depth testing):

 

http://i.imgur.com/4ss16l.jpg

 

Nice!

[xdaniel]

Alright, recent changes...

 

- Ucode interpreter slightly improved; mainly GeometryMode, OtherMode_L and texture coordinate generation

- Command editors for OtherMode_L, Vtx, Tri1 and Tri2 added, one for GeometryMode started but is still slightly broken

- New class for text printing, as used for the FPS display, because the old one (included with the texture library I'm using) basically wasn't really to my liking

- Some other changes under the hood

 

Also, would the testers please speak up? (Because if I progress much more, I need to send you a new build to test )

 

[Secant]

Already done so, xdan, I did a reply edit a few days ago. Check the PM conversation, it should have quite a bit of useful feedback.

[xdaniel]

...yes, you did. I didn't know you could edit PM replies o.O

 

Well, gotta go and read~

[xdaniel]

I'll just leave this here:

 

[Secant]

If I'm correctly detecting actor paths, then holy crap xdan, you're god.

 

And if everything we see here is planned to include edit features, then you're... I dunno, ultimate supreme executive master boss-chief emperor kaiser controller of the multiverse and beyond.

[xdaniel]

Well, then I'd like the title "Haruhi Suzumiya", because it's shorter than "ultimate supreme etc." and still basically implies god

 

Anyway, yeah, while I was looking for something completely unrelated, I stumbled across those. I do not yet know how the game knows which path to assign to which actor, tho. At least for the carpenters in Kakariko, it's the first byte of the actor's variable. Messaged spinout earlier with my findings, and maybe he's got an idea, or even knows more about those waypoints already. I'll look into adding editing of those for the next tester build.

 

Also, Majora's Mask is full of those - literally:

 

Edited February 15, 2011 by xdaniel

[spinout]

To quote a PM I sent to xdaniel:

Upon loading the map, the pointer in the header is converted from a bank-pointer to a RAM-pointer, and the pointer is stored at 0x80223E28 in RAM. After this, various actors read that pointer to get information. For example:

http://spinout182.com/mqd/En_Cs.S (Graveyard boy)

`func_809E1E90' has that pointer as a0.

 

Bitshift multiplication and pointer translation aside (0x02000D60 -> 80340DA80 or whatever), that function is simply:

typedef struct
{
    u8 count;
    u8 buff[3];
    coord_u16* location;
} origin_data_t;

typedef struct
{
    float x, y, z;
} coord_f32;

typedef struct
{
    signed short x, y, z;
} coord_u16;

int
set_actor_origin( origin_data_t *origin_data, coord_f32 *dest_xyz, int which_set, int which_coord )
{
    coord_u16 *location;
    
    location = origin_data[which_set].location + (which_coord * 6);
    
    dest_xyz->x = (float)location->x;
    dest_xyz->y = (float)location->y;
    dest_xyz->z = (float)location->z;
    
    return 0;
}

tl;dr/cant read C: The command is a way for actors to know locations in scenes without having them hard-coded in the actor.