N64/Zelda hacking tools (DList conversion etc)

[Airikita]

I have a new problem. HeavyZ has been testing Unicat on console, and Unicat is crashing the console. She works fine in emulators, but fails on hardware.

 

Here's her display list:

I already spotted some oddities in this display list, mainly the 00 00 FC 01 FF FF FF FF... I'd like to know if this display list is proper, because it does not agree with the N64...

[xdaniel]

If you mean ex. the 0000FC06 FFFFFFFF at 0x03FFFEF8 in your screenshot, why would that be odd? That's part of the vertex data, the texture coordinates and colors for one vertex, to be exact; the display list proper begins at 0x03FFFF10.

 

If you'd use the start address of the vertex data as your display list address - meaning that the system would try and interpret vertex data as commands -, that would very likely cause crashes or other problems on hardware and might be ignored by emulators (ex. via sanity checks like "if pointer is invalid, ignore command"). If you're certain that the start address you're using is correct, I'll have a closer look at the display list in the screenshot later.

[Airikita]

If you mean ex. the 0000FC06 FFFFFFFF at 0x03FFFEF8 in your screenshot, why would that be odd? That's part of the vertex data, the texture coordinates and colors for one vertex, to be exact; the display list proper begins at 0x03FFFF10.

 

If you'd use the start address of the vertex data as your display list address - meaning that the system would try and interpret vertex data as commands -, that would very likely cause crashes or other problems on hardware and might be ignored by emulators (ex. via sanity checks like "if pointer is invalid, ignore command"). If you're certain that the start address you're using is correct, I'll have a closer look at the display list in the screenshot later.

I have been using E700000000000000, I don't see why it would be a problem either. I also added Navi's display list before it enters the list shown:

 

It's supposed to make Navi's orb always face the screen, because Navi's orb is just a square plane. I just placed it in a new spot for it to work with the new model (DE0000000405C660 is the display list shown earlier).

 

EDIT:

Here is Navi's display list:

 

EDIT2:

I just noticed that Navi ends with a POPMTX (D8) after a MTX (DA)... I will have to fix that, looks like the console is overflowing with MTX stacks.

 

Source: http://wiki.spinout182.com/w/F3DEX2

 

EDIT3:

It's still crashing on console, I even re-arranged some things.

 

HeavyZ is saying the Title Screen works fine, but when he starts a file with Link in the map (and Unicat) the game crashes. If I put Navi back to normal, it plays fine.

[Airikita]

Unicat is still crashing the console, but not the emulator... here's another look at her display list again (which was changed lately):

[DeathBasket]

We really don't understand much about making hacks for this game that will work on hardware, do we?

Did you change anything else at all other than the display list? I've run into things before that have crashed just because of the way a piece of code was written. It might also have to do with filesystem errors or something, I don't know. Did anybody ever figure out the exact reason Zelda's Birthday doesn't work on console?

[Airikita]

We really don't understand much about making hacks for this game that will work on hardware, do we?

Did you change anything else at all other than the display list? I've run into things before that have crashed just because of the way a piece of code was written. It might also have to do with filesystem errors or something, I don't know. Did anybody ever figure out the exact reason Zelda's Birthday doesn't work on console?

I have narrowed it down to Unicat after several tests with HeavyZ's help, and I am waiting to fix the problem. The whole point of the crash debugger topic was to force the crash debugger to tell me why Unicat is crashing the console.

 

But lately people have been asking questions going nowhere, instead of helping me with my posts.

 

If we can narrow it down, I can fix the error.

 

Again here's the display list:

 

Asking rhetorical questions is only pissing me the fuck off today. (Nothing personal)

 

 

EDIT:

0xE6 G_RDPLOADSYNC (usage unknown)

0xE7 G_RDPPIPESYNC (usage unknown)

0xE8 G_RDPTILESYNC (usage unknown)

0xE9 G_RDPFULLSYNC(usage unknown)

 

*looks at the list..... looks at the display list... looks back...*

 

ARE YOU PUTTING RDPTILESYNC BEFORE RDPLOADSYNC???

 

I don't even.... THINK... that's a good idea... This is messy. I bet the system uses E60000000000 to load things beforehand, but in any scenario, this is programming disaster!

 

The RDP likely uses a specific pipeline, and this could be messing it up!

[Airikita]

So I'm looking at my Unicat texture. The FD has setting 10 (rgba16), and the texture itself is.... 0x200 in length!

 

When I convert Unicat's texture with SoulofDiety's texture converting tool, it is supposed to be 0x1000 in length... So, I don't know what happened with your tool, but SoD's texture converting files are highly accurate when it comes to converting a TGA to an exact RAW of OoT's textures. I imagine this might be causing a crash.

 

Yay, now for the fun part of re-arranging stuffz! But I need to get back to my essay...

[xdaniel]

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.

Edited December 11, 2013 by xdaniel

[Airikita]

I was offering a suggestion, not a challenge. I was saying you can use SoD's texture converting tools to better your tool. See, UoT used other tools to make the map editor we all know today. You could just make an option for someone to upload the file path to the TGA needed to go to the model (user can have that as an alternative option) and you can move the raw data to move around.

 

Cooliscool programmed the UoT, yes, but he built it on existing tools.

 

I was adding a suggestion because I believe you are capable of working with it, I never insult friends.

 

EDIT: also, considering your tool DOES NOT WORK ON HARDWARE, I suggest you work on hardware compatibility. I'm getting fucking pissed about your attitude towards MY ISSUES and YOUR TOOL.

[HeavyZ]

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.

xdan, your programs are all awesome. Though I do think Airikita is only trying to be enthuesiastic about N64 compatibility and trying to get some help with her mod. If you've seen my recent thread than you know I really am all for N64 compatibility, and that I would like to encourage that. Please continue making awesomeness, you've done a lot, and I think I can speak for everyone who isn't a jackass when I say we're all thankful we are able to do so much so easily when we mod our Zelda games because of you. I hope you didn't get offened if you've read my Zelda hacking and hardware compatibility thread. I'm not a programmer, or some bad ass hacker... I just wanted people to care enough to test things if possible on hardware and help get Zelda hacking even bigger. I actually had the idea to start that thread because I was chatting with another programmer and they didn't seem to care at all about hardware compatibility.. it was just really discouraging.

Keep up the good work whether it's hardware compatible or not, though if you do get any ideas on why someonthing might not be hardware compatible and you wanna test it then hit me up, if you don't care about any of that then hey I'm not downing you. Everything you do for Zelda 64 hacking is a step forward for all of us either way

[xdaniel]

I was offering a suggestion, not a challenge. I was saying you can use SoD's texture converting tools to better your tool. See, UoT used other tools to make the map editor we all know today. You could just make an option for someone to upload the file path to the TGA needed to go to the model (user can have that as an alternative option) and you can move the raw data to move around.

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.

 

Cooliscool programmed the UoT, yes, but he built it on existing tools.

 

I was adding a suggestion because I believe you are capable of working with it, I never insult friends.

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.

 

EDIT: also, considering your tool DOES NOT WORK ON HARDWARE, I suggest you work on hardware compatibility. I'm getting fucking pissed about your attitude towards MY ISSUES and YOUR TOOL.

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.

[haddockd]

Now now kids </old man speak>

 

Seriously though:

 

Airikita,

 

Perhaps if you wrote your concerns in detail in a way that didnt really mention negativity towards any particular tool(s), perhaps that may lead to a more constructive conversation about those functions. I do not pretend to know about all of your posts or your relationship with xDan but the way this convo is going does not sound like it will peaceably resolve things. I mean, the end goal is to have tools that meet your needs, correct? Surely there are better ways to accomplish it than lots of capital letters

[Airikita]

I explained everything in detail, including information regarding hardware incompatibility. Yes, it works, it works for EMULATORS, it does not work with N64 console from what HeavyZ is telling me. I explained this other issue with the pipe sync last time, and listed the commands. I also explained how the arrangement works differently in existing files (such as gameplay_keep display lists) and to look at them carefully. The wrong RSP order can cause graphical glitches on the console.

 

Unicat works on all the emulators, but fails on the N64 console.

 

I could look up information on RSP programming later today if I have time if you need more pointers. IN FACT I have an idea that each pipeline order depends on what each tile setup is. I will have to look into my rom for that information, but I have given a good amount of information to explain that the DList order is improper for RDP output as HeavyZ has relayed to me MANY TIMES that Unicat crashes the game when a new file is started. It does not crash at the title screen because Unicat never appears in the title screen (Navi doesn't spawn).

 

I have also removed MTX pop and push commands to just run Unicat's model, I have even took navi's model, cut out the MTX push/pop she uses, and linked just the panel that Unicat was created. Same problem, all scenarios fail.

 

I recommend looking at this: http://wiki.spinout182.com/w/F3DEX2

 

Consider it like programming, but don't look at like like a big obstacle. I would gladly assist you in order to complete a list of algorithms for the display lists. I'm sure xdan has enough information that the stuff comes out properly in terms of how each command works, but there was a horrid way unicat's display list was "coded" (ordered) that I tried fixing, but there is still something wrong.

 

If you really want me to help, I'll gladly take up the offer.

 

Also, xdan, don't take my anger personally... I have just been busy, and it just so happens I get little information. To me, I thought you were working on the display list ordering since you weren't replying, so I didn't understand you were having issues. Look, I'm sure I could take a look at your source (and learn some C# over the holidays) it would be a wonderful project since I can't get my mod going until things work accordingly.

 

I will examine all objects in OoT, including special ones with hierarchy, like Stalfos. I can run comparisons in each AI to find out how the display lists are fully used creating a complete F3DEX2 code guide of objects.

 

I'm frustrated about this too, as I found this tool highly useful. It still is useful, so we can still improve it.

[xdaniel]

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.

[Airikita]

Browsing through the topic pages, I noticed something I posted WAY before Unicat:

https://www.the-gcn.com/topic/1815-n64zelda-hacking-tools-dlist-conversion-etc/page-2?do=findComment&comment=27720

 

Apparently I noticed something out-of-order before...of course, that could have just been silly-noob-me not referencing the D7 first... however, that's not always the case with models. Still, 0xD7 command is listed as 0xD7 F3DEX2_TEXTURE, which I understand should come after 0xE7 G_RDPPIPESYNC, as commands usually follow after 0xE7 is called first.

 

That being said, I will have to run comparisons within the OoT ROM, and I can make a list if I could have the most recent, and most completed (however incomplete it may be), list of all F3DEX2 and G commands. It's nothing that I need to examine the graphics library to understand, the commands are worded in common programmer's-speech that I can understand.

 

As long as the list has the correct naming conventions, then there will be no issues in formulating a document explaining RSP programming for N64 graphics (along with some more know-how I'll just pick up... gotta do some digging first).

 

On top of that, that was a Gibdo's head ripped from the game, and had textures modified.

 

 

EDIT:

Observation on first display list in Gameplay_keep:

 

 

E700000000000000     -> G_RDPPIPESYNC
    |
    v
E300100100000000     -> F3DEX2_SETOTHERMODE_H
    |
    v
D7000002FFFFFFFF     -> F3DEX2_TEXTURE
    |
    v
FD70000004004058     -> G_SETTIMG
    |
    v
F570000007014050     -> G_SETTILE
    |
    v
E600000000000000     -> G_RDPLOADSYNC

 

 

Note: already we see that the pipe is loaded/opened stream first, leading to the logical graphics (E3 and D7) loaded to memory for changes. Then, FD, F5, and E6 send the data in the order of what was presented. Since E3 was presented before D7, FD has to precede F5 for the mode to be set on the image, but also the tile is affected. The mode before the texture suggests some sort of rendering has to be activated before the texture can, therefore, be drawn, and the image is then set/activated before the tile is set to allow the rendering to be ready for the tile it is applied to (whatever geometry/rendering mode that may be).

    |
    v
F3000000070FF400     -> G_LOADBLOCK

 

This finally submits the data to a part of memory to be set in the rendering data, as this section of code is completed


    |
    v
(new start)
E700000000000000     -> G_RDPPIPESYNC

 

A new stream is opened as the preceding rendering cycle is completed in the appropriate order described above. Any misplacement may not be noticeable in an emulator, but this will affect how the hardware outputs it to the screen. A new rendering sequence must be activated to clear any preceding pipes (or "ports" in internet logic, if that helps make sense) so that the new rendering can follow the current frame/cycle.
    |
    v
F560040000014050     -> G_SETTILE

 

*This appears to copy the pre-exisitng F3DEX2_TEXTURE and F3DEX2_SETOTHERMODE_H from before to the next tile/geometry mode.
    |
    v
F20000000007C07C     -> G_SETTILESIZE
    |
    v
FC127E03FFFFF3F8     -> G_SETCOMBINE
    |
    v
E200001CC81049D8     -> F3DEX2_SETOTHERMODE_L
    |
    v
D9F3FFFF00000000     -> F3DEX2_GEOMETRYMODE
    |
    v
D9FFFFFF00030400     -> F3DEX2_GEOMETRYMODE
    |
    v
FA000000FFFFFFFF     -> G_SETPRIMCOLOR
    |
    v
0100400804003F88     -> F3DEX2_VTX Fills the vertex buffer with vertex information (ex. coordinates, color values)

 

*Seen here, it is obvious that 0xFA would have to precede 0x01, but also note how the GEOMETRYMODE commands precede 0xFA. Ordering is important to load and activate certain directives in the rendering process.
    |
    v
0600020400000406     -> F3DEX2_TRI2
    |
    v
DF00000000000000     -> F3DEX2_ENDDL

(returns to previous operation and continues to the next line after where was last left off... this could be linked to a 0xDE pointer, or hierarchy)

Basically the F3DEX2 commands have to compliment any data loaded rendering in order for the appropriate rendering to talk to the RCP in order to display the image appropriate to the design intended.

 

The F3DEX2 commands have to COMPLIMENT the G commands. This means that the F3DEX2 sets up the rendering operation that the RCP can output with the G commands appropriately, but corresponding F3DEX2 commands have to be activated BEFORE the data is sent by the G commands.

 

Your tool shuffles these around frequently, and I noticed missing commands in Unicat.

 

Each new rendering complimented mode in F3DEX2 action has to be started my E700000000000000 to create a new operation before the next geometry mode can follow suit. Each set has to compliment its own set. Each compliment, therefore, needs the appropriate commands to complete the part of geometry, in order, and a full set is needed for the operation.

 

I can look at a longer sample if you wish to further this investigation.

[Airikita]

(new post because last one is too long)

 

Now to observe a fresh raw convert dump of my Unicat:

 

 

E700000000000000     -> G_RDPPIPESYNC
    |
    V
E3000F0000000000     -> F3DEX2_SETOTHERMODE_H
    |
    V
D700000207D007D0     -> F3DEX2_TEXTURE

*This is good, it has estabolished the F3DEX2 modes, but...
    |
    V
D9FEFFFF00000000     -> F3DEX2_GEOMETRYMODE
    |
    V
D9FFFFFF000F0000     -> F3DEX2_GEOMETRYMODE

What happened HERE??? We're just setting F3DEX2 settings WITH NO COMPLIMENTS!!! We are already missing 0xFD G_SETIMG and 0xF5 G_SETTILE!!! No-no.

To make it worse, we're now skipping to geometry modes, shoving shit into the pipe and clogging it up (literal methaphor)
    |
    V
E300100100008000     -> F3DEX2_SETOTHERMODE_H

*Facepalming... What? You didn't send the other one, now we're making a new one? What does this do?
    |
    V
FD10000006000800    -> G_SETTIMG

*I wonder how much that would send... I'm afraid to know if all the preceding info would blacklog the G mode.
    |
    V
E800000000000000     -> G_RDPTILESYNC

*You're setting a tile sync without SETTIMG it first? This seems misplaced...
    |
    V
F500010007000000     -> G_SETTILE

*Um.... you set this after... no, worse, this won't even sync, and you set up a false sync first with nothing!
    |
    V
E600000000000000     -> G_RDPLOADSYNC

*This might not be a bad thing, but more comparisons will have to be made.

However this is now missing 0xF3 - G_LOADBLOCK, which is used in the last example. I would dig into this deeper, not leaving such a detail out if OoT is using this.
    |
    V
F0000000073FC000     -> G_LOADTLUT   Loads a palette to use for CI-type textures

*The previous command FD10000006000800 in this chain is 0x10 (FD "10") which, in SoD's notes, is "10 - RGBA16 18 - RGBA32", perhaps this needs to be looked into more with other comparisons. This may be incorrect, but maybe the notes are wrong too.

 

*This also appears to be misplaced, and should be before 0xE6, because this will not be sent, and will sit as backlog possibly mixing with the following set after this.

 

Unless it is part of the next set, but it doesn't appear to be from what you have stated that my RGBA16 texture must be a CI 8, but what I have for notes, and what works with texture importing, does not match your assumptions that image type 10 is a CI texture.
    |
    V

(new set)
E700000000000000
    |
    V
FD50000006000000
    |
    V
F550000007014060
    |
    V
E600000000000000
    |
    V
F3000000073FF100
    |
    V
E700000000000000
    |
    V
F548100000014060
    |
    V
F2000000000FC07C
    |
    V
E200001CC810307C
    |
    V
FC127E03FFFFF3F8
    |
    V
FA000000686868FF
    |
    V
0100400806000A00
    |
    V
F9A1FC9C00000000
    |
    V
07FEFFFC00007FFF
    |
    V
065FFC9C00000000
    |
    V
0020000000007FFF
    |
    V
065F036400000000
    |
    V
0000FC0600007FFF
    |
    V
F9A1036400000000
    |
    V
07DDFC0100007FFF
    |
    V
0600020400000406
    |
    V
DF00000000000000

 

This is what I gathered from this, you seem to chain F3DEX2 commands with NO complimenting G commands. This is problematic already from previous observations.

[xdaniel]

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:

 

The general rule is that a gDPPipeSync macro must be inserted after a (group of) primitives but before an RDP attribute change command as shown here:

 

gSP1Triangle(...);

gSP1Triangle(...);

gSP1Triangle(...);

gDPPipeSync(...);

gDPSetRenderMode(...);

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:

 

Converting materials...

- '01___Default': Converted to CI8, 16*64; texture at 0x0, palette at 0x400.

- '02___Default': Converted to CI8, 32*32; texture at 0x600, palette at 0xA00.

- '03___Default': Converted to CI8, 32*32; texture at 0xC00, palette at 0x1000.

- '04___Default': Converted to CI8, 64*32; texture at 0x1200, palette at 0x1A00.

- '05___Default': Converted to CI8, 64*32; texture at 0x1C00, palette at 0x2400.

- '06___Default': Converted to I4, 32*32; texture at 0x2600.

- '07___Default': Converted to CI8, 32*32; texture at 0x2800, palette at 0x2C00.

- '08___Default': Converted to RGBA16, 32*32; texture at 0x2E00.

- '09___Default': Converted to CI8, 64*32; texture at 0x3600, palette at 0x3E00.

- '10___Default': Converted to CI8, 32*64; texture at 0x4000, palette at 0x4800.

Converted 10 materials with 10 textures, 10 of them unique.

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...

Edited December 13, 2013 by xdaniel

[Airikita]

Well, I probably exaggerated. Either way, I would assume that is the issue. Compare it to a pot, a single-rendered object. That way there's no room for error.

 

Heck, you can probably base it on something simple like the sun or moon. Don't take my notes personally, I just observe what I analyze. Some notes on RCP/RSP/RDP are inconsistent, and I have a basic knowledge of pipes in hardware. So, I'm mostly going by references. Still I would assume there has to be that consistency with display lists.

 

Like I said, don't take my notes personally. I mean, you can observe different objects to find out the complete order of things. It's likely that there would need to be some look-in on what G modes would be appropriate for different sets of F3DEX2 commands.

 

EDIT:

It's alright btw, I figured you would be able to figure out my notes. Anyways, I only observed one sample. I mean, there's shitloads of samples I could have compared it to, but I know you know more about this than me. I could help more if you still need it, I could make lists of different sequences if you want me to create notes.

 

If not, that gives me more time for another project I have in mind.

[xdaniel]

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?

[HeavyZ]

Yeah I'd totally be down to test whatever is thrown at me

[xdaniel]

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!

[HeavyZ]

Keep it up, I'm actually a little excited just thinking we might soon be looking at custom maps/models on the actual N64 console ^ ^ out of the 3 major hacking/programming communitys for N64 games (Mario 64, Zelda 64, and Goldeneye/Perfect dark) we will have at least 2 fully hardware compatible (Zelda, Goldeneye/Perfect Dark), as long as we're not using out dated programs and doing things correctly.

[xdaniel]

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.

[Arcaith]

Just tested it on hardware, area refused to load - crashed.

[Airikita]

Oh well, it won't be shut-deal first try... hardware testing is extremely ambiguous, even if you could view the data somehow.

 

I'm sure there's more details, but my brain is shut-off on hacking right now. Just got over some exams this week. One more, and it's freedom for the holidays. I would love to dig up some RCP/RDP/RSP related information, but eh... it's not like that information is readily available, because not a lot of hardware would use it the same way.