Newest Update to Sharp Ocarina (we *think* it is hardware compat now)

[haddockd]

xDan, please dont be jaded

[Arcaith]

I honestly think that a lot of trouble could be avoided by simply passing the job of creating the dlists to Model2F3DEX2, all you'd need to do is parse all the data from the preview window regarding culling, shading etc to the executable and the source obj/mtl file and you'd have a hardware functional output. It's known that the program works, why not just use SO as a frontend for now? That was going to be my original suggestion regarding a new tool set anyway; using a GUI program for creating the content and then passing it all to CLI programs for parsing. It keeps it modular, easier to update, and different CLIs can be switched out for OOT/MM if required.

[Airikita]

That's what I did with the HW-compatible converter, comparing its output to existing display lists from the game, yet a certain someone here kept insisting the converter was at fault when they didn't get the display list into the game properly. But whatever, bickering doesn't help anyone, especially not the Zelda 64 hacking "community" that's had a whole lot of that and worse over the years, so I'm out of this thread again for now...

I'm not pulling up old issues, because both of us didn't know what to change. I wasn't insisting, but it was poorly misinterpreted.

My post was asking for assistance, and perhaps find any flaws that were overlooked.

 

I'm referring, my statement, to the SO converter that was fixed.

 

I already stated that "I meant it in the sense of those who aren't making comparisons.We're all guilty of that at one point in our modding expeditions" and none of my posts were insisting everything. I was trying to co-op, but got dismissed because someone wasn't looking at how the ordering of the F3DEX2 commands from comparisons.

 

I was trying to figure it myself and help improve the converter, so I wanted to make as many tests and comparisons to ensure there wasn't any converting errors.

 

The mistake that I didn't realize was Nintendo using a different renderer for Stalchildren that didn't calculate Matrices. So, hence there were some unexpected issues from that.

 

Blaming each other is not the solution when there was never ill intent, just overworking ourselves when we were making progress. I did lose my patience because I was going through a lot and pushing myself, so let's just put that issue aside. I don't hold grudges.

 

Although... since we're on the topic, I forget if you have ever posted the source to the converter? Or am I just being dumb?

 

 

I honestly think that a lot of trouble could be avoided by simply passing the job of creating the dlists to Model2F3DEX2, all you'd need to do is parse all the data from the preview window regarding culling, shading etc to the executable and the source obj/mtl file and you'd have a hardware functional output. It's known that the program works, why not just use SO as a frontend for now? That was going to be my original suggestion regarding a new tool set anyway; using a GUI program for creating the content and then passing it all to CLI programs for parsing. It keeps it modular, easier to update, and different CLIs can be switched out for OOT/MM if required.

NO, you can't, both converters have to convert each mesh differently. Map mesh and zobj mesh are NOT synonymous at all.

[Jason777]

NO, you can't, both converters have to convert each mesh differently. Map mesh and zobj mesh are NOT synonymous at all.

 

Huh, that's news to me. I'm just curious and maybe a little misinformed; how are they different besides what RAM segments they typically use? Do you mean to say that the "proper" order of F3DEX2 instructions seen in models tend to differ for maps?

 

Also, the source for Model2F3DEX2 was released. Actually, fkualol used Model2F3DEX2 to convert a display list to be used in a hardware compatible map for MM so that makes me think that Arcaith may be right when he suggests using that instead.

[Arcaith]

I clearly haven't explained myself clearly. Here's the flow you'd have in place.

 

Open the GUI tool > Create definition file for either a map or an object > Load obj file(s) into editor > Add relevant data (culling types, texture tile mode, colouration/normals, matrices (for objects), collision data (for map/scenes) > Save definition file and any data appended to obj/mtl files > Pass definition file and obj/mtl files to CLI > CLI processes dlists > GUI checks for CLI output .bin files, assembles remaining data (collision definitions, matrices etc into final .zmap/.zscene or .zobj > Injects to relevant offsets if provided, otherwise leaves DEADBEEF at relevant locations.

 

You'd have different CLI programs depending on the options selected in the GUI, such as a different parser for a map compared to an object, and even different parsers for OOT/MM if required. I can't be bothered doing a proper flow, but that should give you a better idea of what I mean.

[Airikita]

Huh, that's news to me. I'm just curious and maybe a little misinformed; how are they different besides what RAM segments they typically use? Do you mean to say that the "proper" order of F3DEX2 instructions seen in models tend to differ for maps?

 

Also, the source for Model2F3DEX2 was released. Actually, fkualol used Model2F3DEX2 to convert a display list to be used in a hardware compatible map for MM so that makes me think that Arcaith may be right when he suggests using that instead.

Mainly that, but also the converter can't necessarily detect segments. There is also the facts that Actors use that flag that otherwise caused the map to cover up Link.

Logically, it works for an actor because of how an actor uses z-depth compared to a map.

 

Since the map was using the wrong flag before, it was treating it like an actor. So if the walls and ground were higher, below, and surrounding Link the map was using z-depth as if it was a convex shape and not acting like a flat surface. Therefore that was why it was likely covering Link for that reason.

 

For another reason, I believe tangent shading is different, but it's possible that actors can benefit from it too. I remember xdaniel mentioning a different type of lighting/combiner for maps.

I'm pretty sure that there are different set-ups for maps as opposed to actors because of the rendering differences. In fact, actors use different renders regarding matrices or not.

 

Of course it's possible that the same converter is used, although I do recall there being differences. Unicat worked with the old converter when placed into besitu because her model didn't go beyond Link's size, and I just never bothered to hardware test a normal map after that point for other reasons relating other modifications needed before doing so.

 

There is a reason why maps need a different set-up for the ordering of F3DEX2 commands, because of how the buffer works as part of it.

Try comparing a simple DList from a pot to a map, you'll see it will be missing a row of E6 and other commands before the texture rendering. We could try and see what happens without it, but my hunch is that maps use a different renderer than actors because of specific lighting effects.

 

So that is why xdaniel's model converter WILL NOT WORK and SHOULD NOT be made that way because of how it was designed to work with zobj files.

If you make it work that way for all models, you can end up with problems (possibly weird effects) on actor models.

[mzxrules]

bleh, I said I was going to work on this but I ended up having my laptop die on me, setting my stuff back by about a month minimum for some things if I can't get to my hard drive. Biggest thing relevant to this is that I was going through my xml doc revising things and documenting things I had previously overlooked.