xdaniel

I addressed that a few posts ago, actually, and it's more likely to be January: ...might be a bit conservative even, early January is very possible.

http://magicstone.de/dzd/random/besitu-hacked-9.ppf - Nailed it! (maybe) Apparently, mesh type 0 isn't just one address per entry, it's two - first address is the opaque display list, second is the transparent one. So, for example, besitu's modified mesh header in the above patch: ROM 0x03545030: 00 01 0000 0300003C 03000044 ROM 0x0354503C: 030012E8 030003F0 00 is the mesh type, 01 is the number of entries, 0300003C 03000044 seem to be (2nd one might actually be a pointer to something else; maps have a 01 byte at that address?) the start and end address of the display list pointer table. Next, 030012E8 is the display list with all opaque geometry, while 030003F0 is the one with transparent geometry. ...at the very least, that seems to be the case with other maps like turibori_room_0 (fishing pond) or bdan_room_0 (Jabu-Jabu's first room) - they have the number of entries set to 01, but have two addresses, the second of which is the water of each room, and in the fishing pond's case some bits of decoration on the walls. Anyway, if that patch works fine on hardware and looks the way it's supposed to, I think we might've solved ourselves a big problem with custom maps.

Saori Hayami, Nao Touyama - Hello Alone (Yahari Ore no Seishun Love Come wa Machigatteiru / Oregairu ED)

No exact plans as such. Obviously this thing could be extended into, or used as the base for a map importer, but that's something to think about after getting it polished up and released... That said, I do kinda have the idea that, if I would spin this off into a custom map tool, I'd leave it command line-based as well, and it probably would not inject maps into ROMs, either (= just create separate scene and room files). That said, it would allow the user to specify how many ex. actors, transitions, waterboxes, etc. they want via some command line switches or something, it would insert some default values for those into the file(s), which could then be edited in ex. SceneNavi like any other map. Something like that. Again, if that happens, it's still quite some time away. First things first, that being the simple model converter it's planned as right now.

Oh, don't worry. At this point pics would be most important when something glitches on hardware, so seeing how patch 8 did work fine, I don't think pics are needed right now Alright, doing more cleanup work, etc. tomorrow. Not sure if I'll be able to get a release of the converter out before or during Christmas - will be with my family over the holidays, and while I will bring my laptop, I don't think I'll be using it much -, early to mid January should be realistic, tho.

Yeah, this not having proper collision is normal; the converter's just a simple model converter for now, not a map creation tool like SharpOcarina, so it doesn't create collision, etc. at all. So, it sounds like patch 8 looks like it's supposed to on hardware? Like the screenshot I posted with patch 7? (Model itself was identical between the two, just the way it was converted differs, mainly regarding rendering modes and combiner stuff)

Tsk, the moment I post, Zeth posts and pushes my post off to the previous page! EDIT: Another patch! http://magicstone.de/dzd/random/besitu-hacked-8.ppf Also updated the DL comparison table a bit, including the above patch 8: http://magicstone.de/dzd/random/DLCompare.htm

Another patch for HW testing: http://magicstone.de/dzd/random/besitu-hacked-7.ppf - Been working on cleaning up the conversion code, proper mode settings, combiner setups, etc.; hope this didn't break anything! (Note that Link will appear in front of the translucent cube regardless of position, a limitation of how I hacked the display list into the game...) Speaking of the combiner, I really need to port more macros from the SDK to C#... SetCombineLERP makes generating combiner setups easy as pie (if you know what you're doing): GBI.SetCombineLERP("TEXEL0", "0", "SHADE", "0", "0", "0", "0", "TEXEL0", "COMBINED", "0", "PRIMITIVE", "0", "COMBINED", "0", "PRIMITIVE", "0"); - I believe there's more where that came from, ex. for SetRenderMode.

Not my type of game, Zelda or not. I mean, it might very well end up a decent game... it's just not really what I want to play, regardless of franchise.

It does, but they're described as "stages" like the Map Select does it - expand a scene's entry in the treeview, then select the stage you want. The order in the list IIRC should map one-to-one to the object set numbers, but might not map exactly to the Map Select, and there's only a few scenes with proper descriptions for each stage so far. For example:

Part of the .obj format. That's why I said ".obj format's groups", ".obj groups", "features already available in the .obj format" and the like

Not exactly a pick-up, but close: made me a new AV cable for that Asian Mega Drive, now with actual A(udio). A tiny bit short, not very pretty (messed up the MD-side plug's casing a bit), it's just mono audio, it's still just composite... in short, it's not a nice RGB SCART cable with separate headphone jack to plug into the front of the MD for stereo sound... but hell, it works and I made it myself

Haven't actually worked on the converter's code again yet, but have thought about user interaction, like how to specify what parts of a model should ex. have backface culling, where lighting should be enabled, etc. I was thinking, what about using the .obj format's groups for that purpose? More specifically: their names. As with SO and Model2N64 previously, display lists are created by the converter on a per-group basis, so everything that's part of one group in the .obj file ends up in the same display list. Unlike SO and Model2N64 tho, this is a command line application, so user interaction is limited. Thus, to 1) avoid ridiculously long command lines (say, converter.exe test.obj -g "group name here" "nocull" -g "another group name here" "nocull lighting") and 2) use features already available in the .obj format and thus supported by modelling programs, I think specifying settings such as culling via the names of .obj groups is a good idea. The way I'm currently planning for this to work is as follows, using SketchUp as the example: You group your model the way you need, then set the name of each group to the properties you want to set, delimited by underscores or spaces, like ex. "nocull lighting" (no quotation marks). Now, you export the model to .obj. SketchUp adds some stuff to the names you gave the groups, so they'll look like "Mesh1 nocull_lighting Model" - note that SketchUp appears to turn most non-alphanumeric characters into underscores, so you could technically say "nocull?lighting" and it'll work. Do use underscores or spaces, tho, also for compatibility with other modelling programs. When the converter now begins to create a display list from a group, it looks at the group name, splits it at underscores and spaces (so the above example becomes a list of "Mesh1", "nocull", "lighting", "Model"), checks if the resulting strings are known properties (so the list is now "nocull", "lighting"), and then acts on each property by ex. noting that this display list shouldn't have culling enabled. This might sound complicated, but I think it's pretty intuitive: Note that this isn't fully implemented yet as it's still in the planning stages. The actual conversion process doesn't yet do anything with the information gathered; that's part of the de-suckification the currently rather hacky code will receive soon. Underlying, preliminary, experimental code for parameter detection as of now for those who're curious: Hope that makes sense so far!

Been rewatching Yuyushiki the last few days, one of the few shows I actually want to rewatch from time to time. It's just great to relax with. Spent the last hour or so in front of my desk, with some snacks and my head just sorta proped up on my pillow, watching Yuyushiki episodes 6 and 7. It's a comedy but for some reason pretty calming to me; I had some nice laughs during the hour, hummed along the OP and ED themes... yeah. Dunno, as mentioned on the shoutbox, I've not been sleeping very well the last few days, was kinda restless I guess... but now I'm just feeling good. Tired but relaxed, a smile on my face, like that. ...yeah, I gotta go to bed, I'm starting to write nonsense here, aren't I? ^^ Episode 1 at Random Curiosity; just introduction, no full series posts: http://randomc.net/2013/04/10/yuyushiki-01/ Entry on MAL: http://myanimelist.net/anime/15911/Yuyushiki

I'll be cleaning up the display list generation in a bit (ex. make the order of commands more akin to ex. object_timeblock and Bmori1_room_0), so there is a chance for breakage...

Hylian Toolbox's conversions likely won't work because it uses a command line variant of my own Model2N64, which has the same incompatibility problems SO has. IIRC Flotonic was at some point going to write his own model converter for use in HT, but I'm not sure if he's still at that...

SketchUp 8 file, http://magicstone.de/dzd/random/test.skp, and goodnight!

I'd actually be willing to bet that spinout's converter worked perfectly fine all along, and all this is just my fault, having fucked up my code that was based on his working code. Oh what the hell, here we go, my code's working fine now, too; now it's time for cleaning it up and improving conversion (everything's super-hacky right now), then making sure nothing will trip up the converter (ex. materials without texture maps), then adding features like user-changeable parameters for ex. backface culling, etc...

You know what, Heavy? You just made my day - and it's only 1:32 am! Oh god, this is so awesome to see!

OMGWTF? Pics or it didn't happen! XD!

One: http://magicstone.de/dzd/random/besitu-hacked-6.ppf - Compared my code to what spinout's converter's code does (which my code was originally based on), noticed a discrepancy, hopefully fixed that. I might've accidentally created vertex buffer overflows... Two: http://magicstone.de/dzd/random/DLCompare.htm - My Excel table in HTML format, now with (parts of) spot00_room_0, Bmori1_room_0, besitu_room_0, syotes2_room_0, object_gi_letter and object_timeblock, and my patches 3 and 5. Three: Going to bed soon, hoping Heavy is still online so that I can witness one more test - or the posting of the result of it, anyway...