xdaniel

I should probably add an exit option somewhere on that tab, so that you don't have to change the raw data for that anymore...

YES, this appears to have fixed it! Now the collision data produced by SharpOcarina is identical to when being fixed by your tool, and of course the game doesn't crash anymore either! Committing code to SVN in a second, new build comes... well, at some later point, seeing how it's 1:30 AM an I've got some appointments today -.-

Timeflow is integrated into the Outdoor Scene option - so depending on whether it's outdoors or indoors, time either flows or not - but separating that might not be that bad of an idea.

Ugh, I can't seem to get the collision normals right, even with DeathBasket's code... Just changing the existing code the way you described didn't work, with the resulting normals being even worse than before, and I'm apparently too stupid to correctly port the Delphi code to C#, because that also resulted in literal collision failure. As for the current code - using Zeth's old testing map I mentioned -, it appears to be mostly off-by-one rounding errors but there's also a few instances where there's only zeros being written, while your collisionfix writes actual values. Hell if I knew how I'm doing it wrong... As for Kd commands in materials, I guess I'll see what I can do once the whole collision fiasco is sorted out... And finally, as for alpha translucency, you cannot have that and a texture with an alpha channel together, at least with the way combiner and render modes are created currently.

Black outlines should have been fixed, changed the render mode for textures with alpha channel. As for the other bug, you mean the per-group alpha for translucency? I don't have any problems with that, at least on the maps I tried (your castle one here, the demo dungeon). Is the alpha only ignored when importing, or is the preview already not showing the changes?

...same here actually -.- Found an old test map Zeth(?) made, tried importing that, and it crashes as soon as you get control of Link. Been messing with the code a bit, but no results so far...

Yeah, thanks for the fix. Just updated the code in SharpOcarina, although I don't have any test cases that produce broken collision handy. I'll release another build with that, plus some changes to the texture converter so that it uses CI-type and other more space saving texture types more often than before, as most textures originally ended up as RGBA 16-bit no matter what. Also will see about creating a new SVN for the project... SVN created, source is now available: http://code.google.com/p/sharpocarina/ New build coming after I rebooted, updated TortoiseSVN which now wants me to do just that... is here: http://code.google.com/p/sharpocarina/downloads/detail?name=SharpOcarina-v03.rar

Yep, you did... didn't notice that

Uhm, is this here the result of the upgrade?

That's exactly what spinout has done already, and on which I based my C# code for SharpOcarina...

Then it's either errors in the collision data, or as Zeth mentioned, maybe related to the modelling program the models are made with. Also, bugfix build: http://magicstone.de/dzd/random/SharpOcarina-v02-b.rar - mainly fixes the "model with one group doesn't show up in-game" bug

Just like that, it's MQ Debug ROM only, but one can try and insert the converted scene/room files into Majora's Mask manually. No guarantee that's gonna work, tho. Edit: What spinout said

1) SharpOcarina v0.2 released: http://magicstone.de/dzd/random/SharpOcarina-v02.rar (still binary only, as there's still too many bugs for my liking...) - Bugfixes in model and material parser, texture loader and a few other places - Backface culling can be disabled/enabled per group - Minor changes in Display List generation 2) SanguinettiMods, just for the record - because that threw me off before as well -, you did try to import your map into a fresh, unpatched Debug ROM and did not load a savestate ex. to get to the map select faster? I had weird collision issues with one of the problem maps Arcaith posted once, because I used a savestate from a different Debug ROM to access map select. The map worked, but it froze when I went to certain places, and some collision polygons were defined as exits which froze the game because there was no exit table defined.

Yep, that's it. Halved the height and it imports correctly. 64x64 works as long as the texture has 16 colors or less (4-bit CI), but this one has I think 111 unique colors. The FAQ has one or two more hints about this under "What texture sizes and formats are supported?" (like trying to make use of grayscale textures, they can be rather big) Edit, backface culling now selectable:

First, I suppose I fixed the crash, but I cannot say for sure where that texturing glitch comes from on the first screenshot: And second, I'll add an option to toggle backface culling per group later on, not much of a problem I guess.

Arcaith: Hrm, could you send your model over? I can see why it crashes - somehow going out of range while (most likely, because that's the only "unchecked" part in the DrawTriangle function) trying to select the vertices to render - and at least prevent the crash from the exception message alone, but I guess I need the model to properly debug and fix this.

Yeah, that's another bug in the material parser or rather texture loader. I fixed it - my test case has .obj and .mtl files in one folder, which has a subfolder named "Textures" where those are stored, which is similar to what you described -, but I will wait with another build until some more reports of bugs and the like come in. Hm? It does save environment changes. Also with regards to fog density, did you press enter after changing the fog value? I know it's annoying - and I'll look into changing the behaviour to also apply changes when those textboxes lose focus - but it's necessary for the time being. I have just tested both, saving environment setting changes to XML and increasing the fog density, and it works. The thing is - as mentioned in the Readme - the draw and fog distance values are kinda sensitive (in my opinion almost unpredictable), so you tend to have to experiment (ex. the lower the value, the closer the fog is, but don't set it too low, etc) Probably faulty collision, seeing how the code for collision normals isn't much different from spinout's (besides being rewritten in C#). Not much I can do at this point...

Did you press enter after changing the scene number, BGM, etc? If no, it says so in the Readme. Only thing I can imagine being the problem. As for the collision, I didn't have any problems with the maps I used for testing, but I guess it's still not producing perfect collision data then...

Emergency bugfix build thingy: http://magicstone.de/dzd/random/SharpOcarina-v01-b.rar The directory confusion should hopefully be fixed now; added some checks to the .obj parser (is path relative or absolute, etc.) No idea about the camera speed problems, tho. The injection offset bug has been fixed, bug in the respective control's setting (only allowed 4 digits, now does 8). The XML files are created by using the program, so once you've got a model for a map done, play around a bit. All other bugs - and it appears there'll be quite a few... - will have to wait until later, 2:18 isn't the time to fix them.

Current release: http://code.google.c...Ocarina-v06.rar Source code: http://code.google.c...se/#svn%2Ftrunk Requires .NET Framework 4.0, the Readme is there for a reason, program contains bugs.

1) Nice video! I guess SharpOcarina support for the hack won't be in the first release, so that I can get it out soon, but it's (hopefully) gonna be supported by the second and source release. 2) Said first release of SharpOcarina is probably a few hours or so away, as exit list support is done and working correctly (identical to the object list editor), so all that's left for now is documentation. That's already been started - as you can see a few posts above - but the bulk of it still needs to be written. Tomorrow afternoon at the very, very latest. Edit: 3) Things that won't be in the first release (for various reasons): waypoint support, editing of position/rotation in hexdecimal, the source code, probably one or two other things.

Now that's an interesting idea. If you can get something like this going, I'd gladly add support for it in the program. The bytecode interpreter could allow one to set up a RAM segment that reflects the current texture for the animation, ex. taken from a number of consecutive textures in the current scene file, plus the animation speed, and instead of pointing to a single texture inside room or scene, the surface's SETTIMG command would point to that RAM segment. I'm also wondering if this could allow ex. something like Jabu-Jabu's wobbly walls (unless we know how they work...?). (Meh, hope this made sense and wasn't redundant, I'm tired and about to go to bed ^^")

Arcaith: Alright, will add it to the package then, thanks! Zeth: Yeah, I had looked into that as well, and it seems that the RAM segment setup (for those 0xDE DList calls to ex. segment 0x08) is done via assembly, according to a table at 0xBA1544 (ROM) / 0x10D544 (code). Here's my notes of that, maybe someone with MIPS knowledge like spinout or DeathBasket can figure out more? spinout: Dunno if it would help, seeing how it's in C#, but would an "advance copy" of the source help you with writing a command line importer for my scene XMLs? As mentioned, I want to release the source anyway, but only after the first release and in turn implementing whatever (reasonable) ideas, requests and bugfixes people have. Also, more on-topic stuff, a preview of the incomplete documentation: Also also, I probably won't get to doing much work on this over the weekend, since I'll be visiting my family and won't be back until either Saturday or Sunday afternoon. Maybe I'll get this done by Sunday evening or so, although don't take this as a release date or any nonsense like that

SanguinettiMods: While, I believe, I do know how the area title display works, I have no idea about on-screen maps (or the start menu map stuff, while we're at it). Also, while surely needed in a complete mod, I don't think those are too important for this initial release - I guess I will look into those eventually, but for now, sorry. Also, before I (hopefully http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif) will go to bed for tonight... I think all that's left for now before release #1 is adding support for editing the scene's exit list and getting a bit of documentation written. That said, Arcaith, mind if I bundle your test dungeon with the program as some kinda "demonstation material", so that users can see how stuff is done by means of a working project?

Very rudimentary, as mentioned in the video description, but it works~