xdaniel

I would call #202D3A dark, and while its visibility can be argued, I can also imagine the text being hard to read for some people. It's not exactly the easiest for me to read either. And I do have glasses.

Hah, here I wanna post something new, but I totally forgot to reply to SoD's post from over a month ago <.< Still, let's see... Meta tiles, as in tiles made up of multiple smaller tiles? Don't think there's enough repetition in the floor maps to allow for that, not really sure tho. As for triangle strips, IIRC the PVR uses triangle strips natively, but the models are likely not optimized for them. Kinda short reply, but it's been a while since I worked on that project, so... yeah... As for the new thing I mentioned, that's also related to Etrian Odyssey, but not to my DC semi-port project of it. I'm working on an editor for that game again, but am rewriting it from scratch, instead of picking up where I left off with the one shown in my channel update video thingy from some time ago. I also started this one from a different perspective: instead of focusing on dungeons and their 3D models, I'm first trying to make sense of as much of the other game data as possible, like items and such. So that, you know, there's actually something to edit soon-ish, and more to do in the program than just look at floor plans and somewhat pretty models. Quick explanation. Most if not all of that data is stored inside a common container format of sorts - MBB/TBB files contain tables of either strings (MBBs with MTBL tables) or binary data with entries of fixed size (TBBs w/ TBL1 tables), the latter's binary data format being arbitrary (i.e. not derivable from the binary). On the plus side, the developers were nice enough to give their files descriptive names, such as EncountData.tbb, EnemyData.tbb, Item.tbb, etc., so those can at least give you an idea of what the data inside the file's tables is used for. Item data, for example - or more specifically, equipment data -, was pretty easy to figure out a lot of, especially with the help of some FAQs to look up weapon and armor stats, then comparing those the respective item's entry in the table. And after that clumsy explanation, something prettier (*cough*) for you to look at: http://magicstone.de/dzd/random/eo1/eo1items.htm Hope that made sense, I'm rather tired by now, it being way past midnight and stuff... EDIT: Just for fun... my dumb notes in the code: EDIT 2: The program itself aside, I now (partially) understand item data, resource gathering data and item availability requirements (i.e. sell 3 Small Fangs to unlock Dagger in shop). Enough to, for example, make myself an insanely powerful Knife The editor side of things has seen some improvements too, by generally tidying it up, implementing some more helpers, etc. Nothing to really show yet in that regard, tho.

Ah, no, editing in SceneNavi will likely stay a ROM-only affair, with no emulator involvement. The whole rendering of RAM dumps (instead of just, say, room models from OoT) is mainly just to have a sizeable set of commands that need to be interpreted. With room models, for example, you can get away with just implementing the most basic geometry, texture/tile and rendering mode commands and still have it look good. On the other hand, with a RAM dump, you'll have to have cover matrix usage, more lower-level functions like setting viewports and RAM segment mapping, light positions and color, etc. for the frame to look the way it should, i.e. how it looked in the emulator you made the dump with, when you did it. The more commands to support, the more complete the renderer gets, the more universally usable the renderer will be, thus not just for Zelda.

It's been a while since the last actual progress, so here's what's happened over the last few days to a week. First and foremost, there's preliminary support for Majora's Mask: This is still pretty early work-in-progress, as I'm still in the process of "generalizing" things - I never intended for MM to be supported, so there's a bunch of OoT-specific logic, like the reading of scene table entries, as well as GUI code that need fixing. You can follow the progress in code form on GitHub. Something else I've been messing around with, which is related to SceneNavi, is a redux of DLViewer's RDRAM dump rendering capabilities. You provide the program with a full 4 or 8 MB N64 RAM dump, as well as the start address of the "master display list", from which the program renders the scene like an emulator would do. Or, well, DLViewer would if it ever came close to fully simulating the hardware: That's about what DLViewer spits out for a typical OoT RAM dump. Now, this new renderer/interpreter I've been working on is a lot closer to actual emulators at least - as opposed to the very abstract and simplified prior renderers of ex. OZMAV2, SayakaGL and SceneNavi -, and can simulate viewport changes and TMEM, uses the projection matrix, etc., etc. It is still far from being finished, tho. But once it's relatively free of bugs, and only in case it does fix certain rendering glitches that MM in particular exhibits in said prior renderers, it will replace SceneNavi's current "SimpleF3DEX2" rendering code. All that said, finally, here's how that new program renders the above scene from OoT: ...but again, it's still far from finished. OoT looks alright, but other games' RAM dumps show some glaring problems, like Super Smash Bros and Sin and Punishment...

Speaking of tools, you do know that Wind Viewer (partially) works with GCN TP? The only big problems I remember are texture conversion bugs, resulting in some pretty ugly rendering glitches, and that TP uses a different format for collision (KCL, I think) as opposed to Wind Waker, so it won't render a collision overlay. My last Wind Viewer build: http://magicstone.de/dzd/random/WWActorEdit_full.rar Continuation by pho & co.: https://github.com/pho/WindViewer Also, there's Lord Ned's and Sage of Mirrors' Wind Editor, a work-in-progress WW editor written from the ground up, which in turn should/could be compatible with TP: https://github.com/LordNed/WindEditor

They're probably in one of the _keep files, but accessed via segment 0x08, offset 0x0, set up at runtime, same stuff as for texture animation. See ex. here and various other threads about the animations part. Not sure if anyone's ever looked more closely into the corresponding code, aside from apparently DeathBasket in that thread.