xdaniel

Might as well post it here, too, seeing how it can be found pretty easily via #zelda anyway: http://magicstone.de/dzd/random/3ds/N3DSCmbViewer_test9.rar - most recent build of the OoT3D viewer... and now Collada DAE exporter, with special thanks to Peardian on Jul/TCRF for basically walking me through the format. Source code coming soon-ish. Texture conversion is still problematic, lighting is as well, skeletons and animations aren't really understood yet, etc., etc. But it basically works and can basically export (static) models.

Mallos: There's a thread on Jul/TCRF about the demo, my posts about the model stuff begin halfway through this page. Posted the final binaries and sources of the programs I worked on, on page 19 or thereabouts. I'm not really doing anything with the game anymore myself, but other people there (ex. Hugo_Peters) are making more headway into the files.

The Dreamcast is already worth owning for its library of games alone, but developing for it is a fun plus Speaking of which, OMG?! "Fake error during main processing"!?! How could "Fake" fail, I don't get it!!

Message box seems stable, supports a few control codes for ex. text coloring. Substituted Droid Sans for the original DS firmware, and in turn European Etrian Odyssey, font... mainly for PVR memory reasons, as I keep running out of RAM on the PVR side... need to figure out why exactly that happens and what I can do about it.

Arcaith: I believe that's done using either PrimColor or EnvColor during color combining, not via vertex colors, which also wouldn't cause problems with different texture types. Granted, I haven't checked, but it would be the more sensible way. Airikita: Stalchildren, besitu, Teletubbie thing conversion, beginning of first display list each. Teletubbie is closer to Stalchildren than to besitu, yet works fine as besitu's room. While besitu does call display lists in other RAM segments for texture animation (scene configuration / "rr" value 0x31 in scene table entry, creates segment 0x08 for floor, 0x09 for walls), Teletubbie does not call anything in those RAM segments. I stand by the opinion that 1) gameplay_keep is hell to work with, making Navi replacements difficult, and 2) display lists created by this tool are equally compatible with actors and rooms, and factors outside of the data generated by the tool are responsible for crashes (i.e. actor code, hierarchy, plain improper data replacement, etc.). Not that this matters anymore, because the tool is still dead to me.

Two small things from a flea market: Xbox 360 controller (wired, white, complete w/ breakaway cable); dirty and yellowed but working fine, will try to clean it up a bit Commodore 64 DTV (probably version 2); one slightly oxidized battery contact, also needs cleaning The stall I got them at was originally selling off all their remaining items (DVDs, some PC games, much random junk) for 1€ each. Then while I was there, likely because of how much stuff they still had left, they decided on 1€ for two items. So I grabbed the controller and C64DTV, and got them for a total of a single Euro Edit, two days later and I have another purchase to report~ Electronics store chain Saturn had some special online sales on Sunday, including copies of Pokemon Black and White 2 for 10€ each. Ended up ordering Black 2, picked it up at one of their local branchs today. Which means, I'll be spending another two months or so playing pretty much just one single game...

So, once again and kind of expectedly, it was not my tool... And I mainly "blame" gameplay_keep for the Unicat problems.

I give up because I can't take your bloody attitude anymore. I can't test on hardware, I can only take stabs in the dark, which is exactly why I didn't even want to try and make another converter again. Go back a few pages for that if you want. Just imagine that I never did try to make another converter, just forget about this. Whatever. The converter's frozen as far as I'm concerned, anyone feel free to pick it up. Really don't feel like arguing or whatever.

I'm starting to feel like you're trying to argue with me out of spite or something? Yes, I know that certain actors need their model parts scaled the way you did it. I've seen inconsistent model sizes before when working on actor rendering in viewers, so I'm well aware of that. As for besitu, so what other ways for testing this would you suggest? Ones that do not involve hardware testing, because I have no way to do that. Do a Stalchildren replacement myself, i.e. do what you've set out to do but can't get to work reliably, like with Navi/Unicat before? Also, tt in scene table entries is always 0x00 anyway and it's unknown what it's there for in the first place. What graphical errors does that cause? How are maps thus "highly inconsistent"? Also, besitu aside and as I was saying, your patch crashes even under emulation, and before the display lists in question are ever executed, so it cannot be the output of my converter that's at fault. Would you mind addressing that one before ranting about me and besitu? If you can prove to me that your insertion technique is fine and my converter really is at fault here, then I will gladly look into this. Know what? Fuck this. Source here, do whatever you want, I'm going back to SceneNavi or something: http://magicstone.de/dzd/random/Model2F3DEX2.rar

The usual besitu replacement patch - http://magicstone.de/dzd/random/teletubbie-besitu.ppf - works fine under emulation, Project64 v1.6 + Glide 64 Final, same combo that crashes with your Stalchildren patch. Should work on hardware (was lazy with the mesh header and display list calls, tho other maps do the same thing I did), but of course it won't be animated or anything. Only change I had to make to the model is scaling it down in Milkshape, otherwise it wouldn't have been very visible in besitu, had to do the same thing with Unicat before, too. That aside and as far as I can tell, I'm rather sure my tool's not at fault here, ex. considering how your patch crashes for me before the display lists generated by the tool are ever called, like before the intro sequence with Adult Link... Your patch does work fine in Nemu64 v0.8 + Jabo's D3D6 v1.5.2 by the way, and the CRC's correct according to rn64crc.

The patch is not just crashing on hardware, it's also crashing the game before even the intro sequence under emulation for me. Skipping that by loading a save state, then going to Hyrule Field makes the game crash when it turns nighttime (as Child Link, that is). Again, I'm on the fence regarding if it's been inserted into the ROM correctly, but for now I'm looking into it regardless...

Water texture animation is based on the "scene configuration" byte in the scene's entry in the scene table, not exactly the scene index number: http://wiki.spinout182.com/w/Debug_ROM:_Scene_Table That byte also affects camera effects, multi-texturing, etc. For example, change Hyrule Field's 0x01 to 0x02 0x00 (the default for many house interiors, but not exclusively them) and the water animation stops. Edit, Jason was faster Edit 2, why'd I write 0x02...?