xdaniel

Hrmm, herp-derp, I might've found a flaw in - guess what - my code for vertex and triangle commands... I'll try and fix this right now, despite it being almost 1 am. Will edit the post in a bit...

SetCombine tends to be located a few commands before the first VTX and TRIx commands, like it is in Bmori1_room_0 and object_timeblock; object_gi_letter looks like it's a bit of an anomaly there. At least this, and that table in general, shows that the order of commands isn't as rigid as we thought it might be, but there are some rules to follow, it seems (ex. SetTextureLUT and Texture before other texture-related commands). As for culling, here's the function reference on 0x03/CULLDL: http://n64devkit.square7.ch/n64man/gsp/gSPCullDisplayList.htm - Apparently, that VTX command loads the vertices that define a bounding volume for culling, then CULLDL checks if that volume is outside of the viewing volume (so like, the visible part of the world, the "camera" or "screen" I guess?) and breaks out of the display list if it is, so that it doesn't get rendered. So it's not like face culling, toggled via GeometryMode, but something on a much larger scale that can "disable rendering" of whole rooms if they aren't visible on screen.

Thanks, but that's pretty much just the basics I'm already aware of, so not much of a help. It's got a few mistakes too, but those mainly seem to concern terminology (ex. RDP means Reality Display Processor, not Drawing Pipeline), thus shouldn't be a big deal. I'd be kinda curious about what he's got to say about the combiner, and geometry and render modes (i.e. parts 4 and 5), tho, but he's never finished that series, right? Anyway, another patch for Heavy and/or Arcaith: http://magicstone.de/dzd/random/besitu-hacked-5.ppf - The result of display list comparisons and fixing one command mixup I've had in there: Now everything before the vertex and triangle commands is nearly identical to object_gi_letter. If this patch doesn't work, I'll need to check and double-check the code that generates said commands. And if that doesn't bring to light any mistakes, then I might need to replace an actor model or something, because then I'd believe that rooms need special treatment compared to ex. GI object models (like the DL culling part?)...

Honestly pretty much this, at least right now. A week or so ago I mentioned how the latest release isn't yet "v1.0 Final", but that I'm getting there and that additional features will come after getting that "initial final build" out. Model exporting is something I'll probably look into for v1.1 or v1.2 or somesuch, just like how I might look into ex. display list command editing and actor rendering (like in ZSaten or never-finished SorataVSE, not in-level). There's some things I consider more important that are still to-do for v1.0 Final, like more scene metadata options, more collision polygon type options, things like that. Edit: Oh yeah, about the source. I haven't 100% decided when I'll make the program open source, but I will eventually. Maybe put it on Google Code or GitHub with v1.0 Final, then keep going from there.

Don't think it's any of the headers as all I did was convert textures and make a display list - it's still besitu's original scene file and room header; the program doesn't make scenes or rooms at this stage. I just overwrote the original textures and display list with my data (shorter than the original, so the DMA table shouldn't be a problem, either?), then changed the mesh header to point to my new display list. Anyway, gotta go for now. Great to see that crappy model on real hardware, even if only for a split second and in an already crashed game state.

All those edits I did to my previous post... gah, I shouldn't be working on this at 1 am on a... what'll become a Monday morning in a few hours. Will still wait for the result of patch 4, tho! Edit, seen the result above, so that at least makes me sure it's not the texture loading...

First of all, http://magicstone.de/dzd/random/besitu-hacked-4.ppf - now with a RGBA16 texture instead of CI, because I've noticed a discrepancy between format specifiers with CI textures in official maps that (I think!) shouldn't appear if they used the SDK's macros in GBI.h verbatim... more stuff to look into, huh! Speaking of which, Airikita: 0x10 does mean RGBA16 and 0x48 and 0x40/0x50 (<- the discrepancy I mentioned) do mean CI4 and CI8. However, a CI-type requires a palette to be loaded as well, which in turn is in RGBA16 format. Look at 0x1D20 in Bmori1_room_0, the Forest Temple's entrance, the 0xFD50[...] there is 1) the start of the LoadTextureBlock macro from GBI.h and 2) means it's a CI-type texture. Next, look at 0x1D58, the 0xFD10[...] there is 1) the start of the LoadTLUT macro and 2) means that the palette to be loaded is in RGBA16 format. So, if the first 0xFD/SETTIMG specifies the CI format (= a CI-type texture), there should be another 0xFD command following some 50 bytes later, which'll specify RGBA16 format (= a RGBA16-format palette). SETTIMG can not only specify textures, but also palettes. (Edit: That said, SETTILE commands also contain a format specifier, and there's the discrepancy: at 0x1D28 is a SETTILE with format 0x50, like the SETTIMG preceeding it, but at 0x1D48 is a SETTILE with format 0x48, which... is what's still confusing me. If you look at gDPLoadTextureBlock in GBI.h, both instances of SETTIMG SETTILE are fed the same format parameter there, which makes me think that OoT's devs didn't use this macro verbatim...) (Edit 2: Correction to the first edit, and the two SETTILE's aren't fed the same format (or rather size, which together form the 0x10 and 0x48 we see in display lists) parameter, but my C# code should be doing this properly... yeah, more research needed, but not right now as it's almost 1 am here and I gotta get up at ca. 7 am )

Yeah, figured it wouldn't work first try, tho I'm a bit confused because the command order, up to the VTX and TRIx commands, is almost identical to object_gi_letter's... Maybe it's the order in which the data of CI-type textures is loaded; I just compared my conversion and Hyrule Field, and I've got that part backwards - I load the palette first, then the texture, while the field loads the texture first, then the palette...? *goes to make new patch* Second try: http://magicstone.de/dzd/random/besitu-hacked-2.ppf - Changed order of palette/texture loading, also cleaned up the aforementioned remnants from previous conversion tests. No wait, another thing... brb. Third try: http://magicstone.de/dzd/random/besitu-hacked-3.ppf - Changed the location of one more command (0xE3/SETOTHERMODE_H that does SetTextureLUT; GBI.SetTextureLUT(GBI.G_TT_RGBA16) / GBI.SetTextureLUT(GBI.G_TT_NONE) in my code), not sure if that one makes a difference... Feel free to try out both patches.

Got some basic display list generation working, so here's some extremely preliminary testing of extremely preliminary code under emulation: Patch for MQ Debug, replaces Besitu (Map Select 116)'s room model: http://magicstone.de/dzd/random/besitu-hacked.ppf - I don't necessarily expect it to work on hardware yet, tho. While the setup commands etc. are based on (IIRC) object_gi_letter, there's some slight differences to it, mainly because the converted model uses a CI-type texture, thus there's a LoadTLUT macro at work. Would still be great if ex. Heavy could test this on hardware and report back on the results. And hell, if it would work first try against all odds, a photo would be cool! XD Oh yeah, for Airikita and anyone else interested, the display list itself starts at 0x035460F0 in the ROM if you want to take a look. Also, ignore the commands from 0x035463D8 to 0x03546588, they're never executed - there's an ENDDL right before them - and are remnants from previous injections/conversions that I only noticed after I had already made the patch.

Quick progress report before I go to bed (4:56 am), even though there's not much else to report: texture conversion is working, with the converter having two "modes", basically. By default, it automatically determines what type of texture will be the most effective, data size-wise, once converted - ex. it checks if an image is all grayscale, thus it'll create either an I- or IA-type texture from it; or for colored textures, it'll generate a RGBA16-type texture for reference, then generate a CI4- or CI8-type texture depending on the number of unique colors, then compare the size in bytes of that and its palette to the RGBA reference and use whichever one is smaller. That last bit with the RGBA reference texture is new; SO and Model2N64 always created a CI-type texture if they could from a colored texture, which might actually result in a texture that's overall bigger in raw data size than RGBA16, with very low-resolution textures (ex. below 32*32) in particular. And while the auto-detection will result in space saved (ex. SO demo scene, first room: 0x2600 bytes saved vs. w/ all textures as RGBA16), if you do want everything converted to RGBA16, you can force the converter to do just that. Anyway, it's 5:11 am by now, so I'm pretty much off to bed. Good thing it's Saturday... Night!

"Loading zones" as in, say, dungeon entrances/exits? I'm gonna go ahead and guess that's some exit-enabled collision polygons, the same way the N64 Zelda's work. I hadn't looked very deeply into collision in WW, but if it's similar to OoT/MM, then you've got a collision polygon type that's set to trigger one of the exits defined elsewhere (in this case presumably in the SCLS chunk), as well as any number of polygons that are set to be of that type. If you step onto one of those polygons in-game, it triggers the transition to whatever map is defined by that exit. Hope that helps any, even if it's just a theoretical idea.

I'm gonna check out a few somewhat more complicated models, like ex. the test map or Besitu, and see what they do for setting up, and where their texture loads and combiner-related commands are. If you want to, you could make a few more lists of commands like those in your previous posts for some other non-map objects like pots, gravestones, GI objects or similar. My experience comes mostly from maps, so I'm not sure if/what differences there might be. But without the snide remarks, please I've also - and I'm starting to wonder if I'm a masochist in this regard - started writing a new, command line-based converter. I ended up recycling an .obj loader and a few related classes from a previous aborted project (haddockd probably knows which one), and should soon be ready to start the actual conversion code. I'll be recycling from Model2N64 here, too, at least the stuff I know works correctly, like the texture conversion code and the C# ports of the SDK macros. Once I've got the thing going, would you and Heavy like to do some testing with it?

This last post of yours might contain the reason why I subconsciously didn't take you seriously in a while: the likes of "What happened HERE??? No-no." or "Facepalming..." are not constructive criticism. Yes, there's an extremely high chance that there's commands in the wrong order which breaks hardware compatibility, but that's not the right way of telling anyone that's the case, and IIRC this isn't the first time you're doing this either. I do appreciate that you're looking into this and trying to help me fix my program, but if that's the way you will keep informing me of your findings or theories, I'm honestly more likely to ignore you outright from this point on. Also, the sequences of "G_SETTIMG, G_RDPTILESYNC, G_SETTILE, G_RDPLOADSYNC, G_LOADTLUT, G_RDPPIPESYNC" and "G_SETTIMG, G_SETTILE, G_RDPLOADSYNC, G_LOADBLOCK, G_RDPPIPESYNC, G_SETTILE, G_SETTILESIZE" are correct no matter what, because they're macros from the SDK and also used in OoT proper. See GBI.h in the SDK, LoadTextureBlock, LoadTLUT_pal16 and LoadTLUT_pal256. The surrounding commands might very well be wrong, but there's no doubt about those sequences, otherwise the SDK and OoT itself would be wrong. See also my C# ports of those and other macros in SharpOcarina. Anything else I'll look over when I'm not tired as hell and don't have a headache like right now... EDIT: Alright, looking over your posts now... first of all, "pipe" in this case is nothing like a "pipe" in networking. It's one single pipe, and it's the "attribute interpolation pipe" (can't find a copy of the Function Reference online right now, but it's said so on the pages for every sync command...) Also, to quote the manual: EDIT 2: No, format 0x10 does not mean a CI-type texture, but it's the format of the palette (RGBA16) a CI-type texture uses, and the SETTIMG command preceding a LOADTLUT specifies the format and location of the palette. Again, have a look at the aforementioned macros... EDIT 2.5: Convert your model once more in Model2N64's normal GUI version, then check and preferably also post the statistics it prints out here. I'd be willing to bet your texture is converted to a CI-type. Like so: EDIT 3: Yeah, I am not an expert at this, as obvious from the fact that my tool doesn't produce hardware-compatible display lists, but you're even further off base than I am at this in some instances...

Maybe I unintentionally skipped some of what you've posted before, but all that's ever stuck with me regarding what you said about this problem was stuff like "I swapped some commands, it still doesn't work" or "Here's a screenshot of the display list", that kinda stuff, nothing detailed. AFAIK you never really specified ex. what the proper, or at least a "more proper" order of commands would be, in particular regarding the sync ones. But, again, I might've skipped something you posted... About the F3DEX2 article on the wiki, I'm pretty sure I actually started that article years ago (back in the late ZSO/ZC days?), on a previous incarnation of the wiki or something. The crappy intro, the command list and triangle example(?) in particular, I think. A better recommendation would be the glN64 source code, even though it's more difficult to understand - probably no surprise, seeing how it's a complete graphics plugin. The wiki article isn't really accurate, either, see ex. the descriptions for DL and RDPHALF_1. I'm gonna pack up Model2N64's source and that of the conversion library it uses over the weekend, then post it here. Everyone feel free to look over it, look for problems, etc., etc. - that said, SO's conversion code is functionally pretty close to Model2N64's, so feel free to look at that in the meantime, too! Which I don't think anyone has ever done either, besides marshallh for use with his racing game stuff.

If there were issues with texture conversion, I'd surely look at tools that do it correctly and fix mine, but at least RGBA16 conversion - the specific texture format you had problems with - worked perfectly fine for me, with the same code that's used in Model2N64. Same size as SoD's converter's output, same data. Would be nice if you could prove that the conversion went wrong instead of just throwing around two data sizes, and without providing ex. the actual output generated by my tool, or, if it's the bog-standard Model2N64 GUI version, the statistics it spits out after converting something (which show exactly what format a given material was converted to, even!). Then I'd also be more willing to look into the matter more closely, instead of when I just hear accusations like that. It's not like I've done every program I've ever done in a vacuum, of course I've looked at and used other tools for reference - depending on the program in question, I've looked at UoT itself, the glN64 graphics plugin's source code, spinout's converter(s?) and surely a bunch more. What I have not done and will not do is bundle and have the program itself or the user use separate programs (like ex. UoT with collision_fixer, rn64crc and zdec), because that's ugly. Flotonic, too, has done a great job with Hylian Toolbox, but that also is a tangle of 5 or so different programs and their DLLs. If I can do something in C#, and to the same standard that other tools can, I will do it in C# and incorporate it into the program in question. See, and I'm getting fucking pissed about YOUR ATTITUDE towards ME and MY TOOL. Screenshots of display lists, wild speculation and "re-arranging" things in them, no .obj/mtl model files I could test myself, not the complete converted data I could look at closer, you saying things like vertex data "inside" a display list looking odd, and so on, and so forth. Why the fuck should I react any differently than I do right now? And feel free to give me either 120€+ for a flash cartridge or the cartridge itself! I CANNOT AFFORD stuff like that! I'm currently living off of 700€ welfare per month (while also participating in a job reintegration thingy, and hopefully soon professional retraining, all of which doesn't give me a single cent extra and for the next three or whatever years!), from which I have to pay rent, electricity, internet and phone, and everything else. A few cheap games here and there I can afford, but not spending that much money on a single thing like that. As for having someone else test stuff on hardware for me, judging from 1) how many times I'd potentially need to re-convert and re-test a model after changing something in the converter and 2) how many of us are living in different time zones - 7:45 am over here, and what great stuff in here to wake up to! -, it's neither very economical nor particularly fast to test every little thing this way. I'd need to take a stab in the dark as to what might be causing issues, then prepare a build for someone (ex. HeavyZ) to test, then wait half a day, a day for him to get back to me with the result, by then it's probably late in the evening or night here, so I'll have to get back to coding the next day. Rinse and repeat. And of course I'd want hardware compatibility! Hell, I'm the idiot who keeps burning CDs to test the Dreamcast stuff he's working on, on and off, on real hardware! DC emulators might be even worse than N64 emulators, with nonsensical slowdowns where HW reaches 60 FPS permanently, dynarecs that just crash on you after a few minutes while HW runs fine for half an hour plus, etc., etc. However, I CAN test my stuff on a real DC (even if it's not very fast), but I CAN'T test my stuff on a real N64 at all outside of asking someone else (which'll take way longer than the 5 or so minutes to burn a CD), which obviously goes back to the last two paragraphs - and no Heavy, I didn't get offended by your thread or anything, don't worry.

Judging from just the ROM infomation, it appears to be very much the same ROM I used excluding the game ID (CZLE vs NZLE), which isn't a problem in this case... Does simply re-importing the original title card work? Meaning, you take an unmodified ROM, export the Fire Temple's title card, then import the image file you just exported again, then save. Also, progress-wise, I added some more additional features that are totally not useful! Got some antialiasing and mipmapping going, to smooth the rendering a bit. Can be enabled and disabled from the menu, hope this works well enough on lower-end hardware (i.e. that the checks in my code catch if the hardware doesn't support one of them, that the program doesn't crash, etc...)

EDIT: Disclaimer: mostly a whiny rant. About RGBA16 textures: I just had my code as used in Model2N64 convert a 64x32 PNG (because C# doesn't support TGAs) and the resulting file is identical - including the size of 0x1000 bytes - to what SoD's tga2rgba16 produced from a TGA version of the same image. I have no idea what's going on, but at least this here is not a fault of my code. Do note that Model2N64 automatically chooses the N64-side format into which it converts a texture, depending on number of colors used, etc. Maybe that's the problem, you assumed it output a 16-bit RGBA texture while in reality, it converted it into ex. 8-bit CI or something? And no, it also does correctly set the format and size parameters in SetTImg/0xFD. About accuracy, display lists, hardware compatibility... no, actually, about conversion in general - and this might be kinda passive-aggressive, if I'm honest: Honestly, if SoD's tools are so highly accurate, have him make a model converter, or seeing how you apparently know so much about the RDP, etc., you could try coding one. Or improve mine, I can post my code, I wanted to do that at some point anyway. I really can only do so much - I cannot test on hardware because I don't have a flash cartridge, I have way too many projects going on and I can't even really focus on one or two, Model2N64's code is pretty crap and likely would need a full rewrite (so its code is probably useless anyway... it was made in a period where I wanted to make my code as modular as possible but just made it messy instead), etc. Apologies if I'm rubbing you the wrong way with this, but I really am just one person, not a professional programmer, not a master of the N64's hardware, but at the same time apparently the only one who even dares to write programs bigger than simple texture converters. There's things I cannot do, and I'm close to never wanting to do another converter again. Sorry if this isn't helpful, sorry if this is whiny, confrontational even, what the hell ever.

Just when I actually want to make an effort to create videos, as uninteresting as they might be... YouTube's just been going downhill since Google. The continuous dumbing down of channels and designs, Google+ crept up slowly but surely, etc... yeah, I wish there was a real alternative to YT as well. There was one thing I actually liked that was introduced during Google's tenure, but I can't for the life of me remember what that even was.

Sorry for the late reply, but I can't seem to reproduce the problems you're having... I took an unmodified MQ Debug ROM, downloaded the image you posted, imported that into the game via SceneNavi, and everything works fine in PJ64 v1.6 and Nemu v0.8. The image loses its color and darkens somewhat, but that's normal because the texture is in a grayscale format in the game and has to be converted to that: Mind posting what the ROM information dialog (menu "File" -> "ROM Information") shows for your original base ROM? Like ex. so: