SharpOcarina - Zelda OoT Scene Development System

[Strati]

http://magicstone.de/dzd/random/SO-v065-TEST2.rar

 

For those with window sizing problems because of ancient screen resolutions ...some issues <.<  Sure hope this works now.

 

Just a small report: disabled backface culling stopped to work on this new version.

[xdaniel]

SharpOcarina is technically dead. I do not know if I will make another release, I do not know when a potential bugfix release might come if I do.

 

1) The first spawn point does use variable 0x0FFF, while additional ones use 0x0000 on purpose, as room actors and spawn points use the same code to create new actors. I kinda expected people to realize "oh, this one has 0x0FFF, that must mean something..."

 

2) SO only adds a single entrance, spawn point 0, room 0. I guess I wanted to correct/improve/fix this back then, but up to this point no one has ever had such a problem with it, which is why I wasn't aware of it. Or no one ever told me about it, which wouldn't be the first time.

 

[Jason777]

As soon as I get some other things done, xdan, would you mind guiding me through the source code of SharpOcarina so that I might correct certain bugs? I imagine it would help relieve some of the weight of expectations people have for you.

 

EDIT: Well, this is all assuming that I'm knowledgable enough to fix said issues.

[xdaniel]

As soon as I get some other things done, xdan, would you mind guiding me through the source code of SharpOcarina so that I might correct certain bugs? I imagine it would help relieve some of the weight of expectations people have for you.EDIT: Well, this is all assuming that I'm knowledgable enough to fix said issues.

 

Like explaining what is done where in the code, where there might be bugs, etc.? Sure, that much I can do, I guess... Could probably just post a general overview or something here, too, and if you or anyone else is interested in working with it, I could try and specify things, answer questions you might have and such.

[DeathBasket]

I'd be interested in making a few fixes here and there, I'll see when I can get back on my other computer and get at the source code again. The only major thing I remember last time I was using the tool is that backface culling was broken though, everything else seemed to work well enough for me.

[xdaniel]

Basic SO overview time:

• MainForm.cs contains most of the GUI code, the defaults for a new scene (newSceneToolStripMenuItem_Click event, SetDefaultEnvironments), the OpenGL rendering code for the preview, as well as some code related to ex. per-group settings (ValidateGroupSettings) and certain kludges (SetPolyTypesInCollision).
• Helpers.cs contains a bunch of short helper functions, mainly for bitshifts and data appending/insertion/overwriting in byte lists
• The ActorEditControl is the collection of controls that are used for editing actors; number, position, etc.
• NiceLine, NumericTextBox, NumericUpDownEx are other controls used in the program
• The files prefixed "Z", ZActor, ZColPolyType, etc. contain their respective classes used to store ex. actor information, environment setups, etc., while ZScene.cs in particular also contains some conversion code, ex. scene/room header creation, collision creation and fixing, etc. as well as more kludges (like for forcing RGBA textures); near the end of ConvertScene is also the entrance list writing code, which right now just writes one entrance (room 0, spawn 0) as mentioned before
• ObjFile.cs is the Wavefront .obj model loader, containing the element classes (Triangle, Material, Group, etc), the actual parsers for .obj and .mtl file, some texture loading code and more OGL preview rendering code
• NTexture.cs is the "semi-intelligent" texture conversion code, which analyzes the given material, decides on the best N64 texture format and converts it; this shouldn't really need fixing, although maybe the RGBA forcing could be worked into it?
• NDisplayList.cs contains the heart of the program, the display list creation code, complete with C# replicas of several of the N64 SDK's macros (LoadTextureBlock, etc); the function InsertTextureLoad decides on the texture loading commands to insert, while the Convert function itself inserts the GeometryMode, SetCombine, OtherMode (SetRenderMode) commands, creates the vertex lists and inserts vertex load and triangle commands; this file might contain bugs, especially with the Geomode and similar commands
• GBI.cs contains many of the constants that NDisplayList / the SDK macros depend on
• The folder SayakaGL contains Sayaka's DL interpreter (UcodeSimulator.cs, NImage.cs) and some glue code (GameHandler.cs) for the semi-accurate N64 preview

Think that's about it for the file contents. Feel free to post any questions you might have about the code here and I'll try to answer them; it's been a while since I worked on this... I still need to commit the code from the latest build(s) I posted; the code on the SVN is a bit over a year old but I think already contains most of the "recent" changes (ex. Sayaka-based N64 preview).

[SoulofDeity]

XDAN.

 

Just had this idea. Suppose you had a combiner mode of

 

Color  0:    (TEXEL0 - 0) * 1 + 0

Alpha 0:   (0 - 0) * 0 + 1

 

Color 1:   (COMBINED - 0) * SHADE  + 0)

Alpha 1: (COMBINED - PRIMITIVE) * 1 + 0

 

Basically, the idea is to combine the texture normally for cycle 1, then subtract the primitive color for the alpha and apply shading for cycle 2. I haven't tested it yet, but if it works like I think it might, it'd allow for soft color keying with the primitive color as the index. Then you could have alpha with any texture format without requiring a mask.

 

This seems kinda redundant with the CENTER / SCALE combiner muxes, but I think I remember reading somewhere in the sdk manual that it was only a planned feature and never actually implemented.