SceneNavi - A simple Ocarina of Time level editor

[xdaniel]

OK, so PPF Studios wouldn't work for me because my LoZ rom was 17KB bigger than the original.

[...]

Now, I have tested a lot of maps with this rom, and I've always injected them in the default offset in SharpOcarina. The biggest map I've injected in to it had approximately 4927 triangles in its room and collision.(and let me tell you, I was surprised at what 8MB of RAM can do in LoZ)

Uhm, well, I think your ROM is quite messed up, which causes SceneNavi to crash while trying to parse everything. The first exception I get when loading the ROM occures while SceneNavi is trying to create the tree entry for market_alley_scene (ROM offset 0x02D07000), which was completely overwritten by something else. It expects a scene header, but none were found because the data at that offset isn't a scene file anymore, so it chokes there. If I make the program skip any scene that doesn't have valid scene headers, the ROM gets loaded correctly.

 

Next, hairal_niwa2_room_0 (ROM offset 0x03283000). It's mesh header points to a display list at address 0x03012708, so offset 0x012708 in the room file. There's no valid display list there; the data there looks like... I dunno, it's the end of some texture data or something. SceneNavi's renderer thus choked when it tried to interpret some of the data there as display list commands. To be exact, it interpreted something there as triangle drawing commands (Tri1/Tri2) and crashed when trying to use some insane numbers as indices into the vertex buffer, thus another index out-of-range exception.

 

I "fixed" those two problems in SceneNavi by adding more error checking, which isn't a bad idea anyway. The real problem, however, is that the ROM is just... pretty broken. On the plus side, your custom map in there appears to get loaded correctly by the program, so try reimporting that in a clean ROM.

[sairugoth]

Yah, I figured it was pretty f**ked up. Especially after seeing "hairal_niwa2_scene" that first time.

(A quot from "N64/Zelda hacking tools (DList conversation etc")

That said, I do kinda have the idea that, if I would spin this off into a custom map tool, I'd leave it command line-based as well, and it probably would not inject maps into ROMs, either (= just create separate scene and room files). That said, it would allow the user to specify how many ex. actors, transitions, waterboxes, etc. they want via some command line switches or something, it would insert some default values for those into the file(s), which could then be edited in ex. SceneNavi like any other map. Something like that.

Now, if you make this happen there wont be any more custom map scenes overlapping, right?

[mzxrules]

Since Dan hasn't responded to my comments, I will.

 

The biggest change would be to restructure the format a bit so that you have three "classes" of definitions (room actor, transition actor, spawn? actor).

Still want this.

 

Each class must have a "default" definition that serves as a template for other definitions within a class. Then instead of adding in Actor Number, Position, Rotation, Variable for every actor, they will be inherited from the default definition.

It is much easier to import automatically when defining things explicitly, so I don't want this anymore.

 

 

I also want to add a few possible Usage attribute values.

I've thought up one other one (a "Text" value), but it'd be a little ambitious. With some npcs (Navi Infospot) it's possible to display a certain text dialog. Rather than store all the dialog combos in English, we'd simply store the textbank id number then retrieve the value programmatically? Actually, it's more likely that you would be able to just store a single index and generate all possible options based on the mask value.

 

Two more things.

 

One, when the definitions are filled out more, I want the actor names to be put in the same xml file.

 

Two, the actor def editor is getting closer to being done. Need to create some sort of gui to easily add in the data that will fill the combobox options.

[xdaniel]

Gah, sorry mzxrules, I keep putting this off... not intentionally, it just happens. I'll be thinking this over during the weekend, re-read your posts and finally respond - definitely, even if I have to set an appointment in my phone's calender or whatever to remind me.

 

sairugoth: As I mentioned there, it would not inject into ROMs, so you'd have to manually do that with a hex editor OR someone would need to write a separate injector that takes scene and room files, puts them into the ROM somewhere and fixes anything that needs fixing (ex. scene table); not sure if something like that already exists.

[haddockd]

xDan,

 

I remember on our earlier bombed project that I put all the try/catches in there. They can be tedious though so I get it.

 

Besides I was just kidding 

[mzxrules]

My editor is "done". It's a little hacky, but it's good enough to build up the xml file. I'll be working on filling it up now, and updating with any issues I encounter.

 

The worst quirk so far is that I can't set the Usage attribute to my own values, or have an empty value set without SceneNavi throwing an exception. Seems odd considering the attribute is optional.

[xdaniel]

Still haven't looked into mzxrules' actor definition comments and improvements. At least this time I've got an excuse for that; don't have cold water in the bathroom since the weekend, water comes gushing out of the main valve for that when opened and drips out even when closed. Haven't slept very well since, haven't slept last night at all, fearing it might break completely (I mean, I sure as hell don't want water damage or something in here!). No toilet flushing, no washing machine, couldn't yet reach house management for them to send a plumber or something over.

 

Anyway, I have worked on SceneNavi a bit earlier, regarding alternative combiner emulation. I've more or less ditched the idea of doing it with glTexEnv (too limited and IMO not very intuitive), so I've started looking into GLSL, which is supposed to be supported on reasonably modern Intel hardware. I'm trying to target the lowest GLSL and OpenGL versions possible (1.10 and 2.0 respectively), too, so that there's a higher chance for this to work on lower-end chipsets.

 

It's still super-early work in progress - in fact, I'm not even parsing the actual combiner setups yet! - but even with some pretty simple "default" shaders, things look... reasonable already (check out the grass!):

 

 

For comparison purposes, here's the existing ARB_fragment_program combiner:

 

 

Still, no guarantees this'll work right on Intel GMAs, Intel HD Graphics, etc., I don't have (nor do I want) one of those to test things on.

[haddockd]

xDan, you seem to have the worst luck of all time. How do you stay so positive? I would have destroyed something by now.

[xdaniel]

On the subject of my leaky valve, plumber's coming tomorrow afternoon, hopefully they can fix or replace that thing quickly. And I have no idea how I manage to stay positive among some of the shit that's been going on in my life, from small to enormous... But there have been times where I wanted to smash something to pieces, although I guess common sense sets in before I actually do it - like "You'll have to replace that, stupid. You really wanna spend XX Euro for five seconds of gratification?" or something

 

On the subject of my GLSL...

 

...it's coming along nicely! Lighting is still a bit of a pain right now, tho (unlit/vertex-colored geometry looks awful; brightness levels in general not identical to other combiner modes), but it is certainly shaping up to be a good contender/alternative to the ARB combiner.

 

 

 

[haddockd]

I have powerful hardware. Is it wrong of me not to care about folks with crappy computers?

 

On a different note, I totally get the positive thing. I am going through a divorce now and I want to break things and hurt people constantly. I just work out alot more and it helps immensely. Plus drinking heavily always makes things better 

[HeavyZ]

Yeah, things like that are why I don't have a PS2 anymore lol. (Wouldn't read DVD I just paid for, and it was my only DVD player)

...Anyways keep it up xdan.

[xdaniel]

New valves are mine; cold and warm water main valves got replaced around noon today, because both were old as hell. I'll be sleeping well again tonight!

 

---

I have powerful hardware. Is it wrong of me not to care about folks with crappy computers?

 

On a different note, I totally get the positive thing. I am going through a divorce now and I want to break things and hurt people constantly. I just work out alot more and it helps immensely. Plus drinking heavily always makes things better 

 

Heh, it isn't, don't worry. I'm not sure if this GLSL stuff will even work right on Intel's junk, or with their junk drivers anyway, so yeah... It's my last try in accommodating Intel users regardless. And if nothing else, it's a good excuse to try and learn something new, at least.

 

And that's sad to hear about your divorce, hope everything's gonna work out for you somehow and you'll feel better soon.

 

---

As for SceneNavi and the GLSL combiner, I think I've got it working pretty well, for lit and unlit geometry alike. I'm missing some effects that were easily done in the old setup, like automatic texture-coordinate generation for reflections, because now I'll need to implement all of those in the vertex and/or fragment shaders by hand. Not sure if I'm gonna do that, or if that'll be ready by the next build.

[haddockd]

Yeah, every day gets easier. The good news is at 32 I am in the best shape of my life. Good thing the ladies love ripped men 

 

Do you think your talents would be better used implementing some of those additional features versus this new GLSL goodness?

[xdaniel]

I'm pretty much done with the GLSL combiner for now, just need to double-check my OpenGL extension (and Intel chipset) detection code, as well as look around the net to see if there's maybe a surefire way to detect GLSL support... just housekeeping things, basically.

 

Next up, looking into the additional features again, seeing what's feasible for Beta 9 etc., as well as hopefully finally having a go at improving the actor definition system as per mzxrules' comments and suggestions.

 

[Antidote]

It's been a long time since I really used C#. Your work with getting everything working with GLSL is pretty impressive, keep it up.

 

The only thing really holding this program back from working on Linux with Mono is that configuration. I think there is a 3rd party library out there that actually works better than Microsoft's solution.

 

Here is one example:

http://nini.sourceforge.net/

[xdaniel]

Hm, I guess that looks easy enough... Yeah, I'll see what I can do about replacing Properties.Settings with ex. Nini.

 

[john_smith_account]

I have all the faith in the world in you XDaniel.  Stay warm.

[mzxrules]

 

Another thing, I don't like how masking captures the value for editing either (note the switch flag on the bottom).

[Antidote]

What exactly is wrong with it?

Other than being a little confusing from a UI standpoint, I can only think of a possible data conversion issue.

[mzxrules]

In order to edit the value, you have to figure out the underlying mask, then left-shift your intended value.

 

For example, say there was an actor that displayed a number between 0 and 16, but the bit field to display this number was in an odd position like this one

 

0XXXX000

 

That would mask to 0x78. In order to display values 0-9 you'll have to input

 

0 = 0x00

1 = 0x08

2 = 0x10

3 = 0x18

4 = 0x20

5 = 0x28

6 = 0x30

7 = 0x38

8 = 0x40

9 = 0x48

 

If you drop the DisplayStyle attribute (which lets you edit the value as a decimal value), then values 0, 8, 16, ... , 72 would represent 0-9... not very intuitive.

 

Instead, what can be done is you can read in the value with the mask, then shift the value right based on the position of the least significant digit of the mask, then display for editing.

[Antidote]

So my hunch was correct, yes that is a bit of an issue, however it's not really an easy fix. One fix might satisfy some people, and tick off a bunch of others, while another has the opposite affect.

At this point it's really a matter of convention.

 

A good middle ground would be to add a way to calculate the mask and apply it, that way you can have the best of both worlds, however that leads to another issue: how to implement it seamlessly.

[mzxrules]

There is no "calculating the mask". Its set via the Mask attribute in the actor definition format.

 

I'm saying you can use the Mask attribute (rather than add yet another attribute to the format for this specific purpose) to figure out how to right-shift the value read off the rom/left-shift when writing back to it so that you're editing the actual bit field that the devs would have been editing.

 

I don't know why any sane person would want it any other way.

[Antidote]

The shift IS the calculation, and your solution isn't exactly a clean one. Sanity has nothing to do with it, it's a simple matter of how the data is displayed, you're nitpicking something that's not exactly an easy thing to have a good blanket solution for, how exactly do you expect him to handle something like that when it's determined by the actor definition?

 

mzxrules, instead of stating you don't like the current solution, you provide a WORKING example of a decent alternative? From what I can tell, there isn't a really clean way to do what you're asking for without adding another layer of complexity to the actor definition. What works for one actor may break another, I think xDan's current solution is the lesser of evils.

[xdaniel]

Very quick initial thoughts about the actor definitions and mzxrules' comments, more over the weekend.

• The Usage attribute is optional as in, it defaults to "Generic" if the attribute is not found in the definition. If it is defined, it has to be set to one of the values SceneNavi understands because the known Usages are an enum, otherwise it'll throw the exception as Enum.Parse fails. I should probably make that Enum.TryParse and have it disregard the attribute if its value is unknown/invalid, and have it fall back to "Generic" in that case. Known Usages are:
  
  public enum Usages
  {
  	Generic,
  	ActorNumber,
  	PositionX,
  	PositionY,
  	PositionZ,
  	RotationX,
  	RotationY,
  	RotationZ,
  	NextRoomFront,
  	NextRoomBack
  };

• Yes, the situation with masks and bitshifts is a bit of a problem... and I'd prefer to add another attribute, "MaskShift" or somesuch, that stores how many bits the mask is shifted instead of trying to calculate it on-the-fly. Feels less error-prone as long as the definition is correct. The attribute would just be an integer and would be optional; if it's missing, the shift count defaults to 0.

Anything else, as mentioned, I'll look over and try to comment on during the weekend.

[Airikita]

While we're on the topic of fixing SceneNavi, problem:

 

 

 

 

 

Because I moved the scene and map file for besitu, it doesn't detect the file. This could be because I didn't change the DMA data, but I changed where it reads the scene file... I didn't want to have to re-calculate the CRC/CIC to run a test... eh, not sure what you could do about it? I mean I'd have to re-calculate the CRC to run it again on mupen64 if I changed the address in the list (which the game doesn't really "use")...