N64/Zelda hacking tools (DList conversion etc)

[xdaniel]

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.

Edited December 15, 2013 by xdaniel

[Airikita]

Oh interesting, are there different procedures for image types? I wonder if certain algorithms are used for certain F3DEX2 requirements, and not just for images.

 

gi objects are single models, so those are perfect comparisons. I know Navi's orb is a CI texture, so it wouldn't mix with my Unicat. Seeing as SoD's texture notes are wrong (for display lists) I might need to find a full-colored and transparent model, like a fence, to compare it to.

 

EDIT:

Hah, well, looking at a leaf that uses an RGBA-16 texture in gameplay_keep, it uses F5100000070D4350 and F5101000000D4350, so I doubt the texture is off. Looking at display list at offset 0x356A0 in gameplay_keep.

 

Perhaps the modes used determine if a texture is CI or RGBA?

[HeavyZ]

Patch 2 crashed after room was selected about to test 3 and edit this post in a min

[HeavyZ]

You definitely made progress with the 3rd patch, but how much I don't know...

The game still crashed as soon as I selected it, but when I hit reset (ED64 only saves if you hit reset before powering off console so I'm used to always hitting reset) the map/model or whatever was shown. I actually seen the model/map on hardware!

 

edited: oops forgot to just edit my last post sorry, and trying to send the video I recorded to my email so I can upload it to show the picture of the map, it just flashes when I hit reset so it's extremely difficult to just take a single snap shot of it

[Airikita]

Woah, that's a great sign then! I'm sure it'll be smoothed out when we figure out how things are ordered, and the proper settings. I trust xdan with the settings. I mean, everything is output properly, for emulators, so it's only a matter of perfecting it.

[xdaniel]

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 )

Edited December 15, 2013 by xdaniel

[HeavyZ]

0:11 - 0:12 you can see the map sorry I have the worst cell phone in history and the video quality is so poor. It's a T-mobile 2005? 04? sliding phone

 

http://www.youtube.com/watch?v=0-l2Tzxtp4Y&feature=youtu.be

 

Edit:

and yeah definitely a good sign I'd say, never got so much as a glimpse at a custom map on hardware before even if it was for a split second

 

Edit 2: gonna try out patch 4 now

 

Edit 3: tried patch 4 out, the result was the same as with the 3rd patch. I've found out that if I barely (big emphasis on BARELY) press down on reset it will actually stay on screen even though it's still crashed. Why is that I wonder?

[xdaniel]

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

Edited December 16, 2013 by xdaniel

[HeavyZ]

Lol lots of edits in my last post as well. Didn't see you commented or I would have posted a whole new post so you'd know I had the results.

This was my last edit in my last post:

 

tried patch 4 out, the result was the same as with the 3rd patch. I've found out that if I barely (big emphasis on BARELY) press down on reset it will actually stay on screen even though it's still crashed. Why is that I wonder?

 

Edit,

xdan I think you fixed the textures with patch 3, the problem is no longer the texures with that correction, I think it could be the scene header that is wrong now? I can't remember which map, but there was one that did the same thing on hardware, I can look to see which one it was

[xdaniel]

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.

[HeavyZ]

Alright, I'll be ready to test next time I see there is something to run! I couldn't find the room that I thought I remembered doing that already in the debug, maybe I was just over thinking or something remembering that room 120 didn't work unless a patch was used.

[Airikita]

0:11 - 0:12 you can see the map sorry I have the worst cell phone in history and the video quality is so poor. It's a T-mobile 2005? 04? sliding phone

 

http://www.youtube.com/watch?v=0-l2Tzxtp4Y&feature=youtu.be

 

Edit:

and yeah definitely a good sign I'd say, never got so much as a glimpse at a custom map on hardware before even if it was for a split second

 

Edit 2: gonna try out patch 4 now

 

Edit 3: tried patch 4 out, the result was the same as with the 3rd patch. I've found out that if I barely (big emphasis on BARELY) press down on reset it will actually stay on screen even though it's still crashed. Why is that I wonder?

Aw yeah, I'll be back in a few seconds...

[SanguinettiMods]

...Possible help? https://www.the-gcn.com/tutorials/article/7-f3dex2-display-list-tutorial/

[Airikita]

...Possible help? https://www.the-gcn.com/tutorials/article/7-f3dex2-display-list-tutorial/

*snore*..... *wakes up* huh? what?

 

Might be, if xDan doesn't already know about that information. It would be good to look over, sure.

[xdaniel]

...Possible help? https://www.the-gcn.com/tutorials/article/7-f3dex2-display-list-tutorial/

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

[Airikita]

Strongbox Warp room? I'm sure that works on N64 hardware too, but I wouldn't chance relying on beta room data. Interesting the alignment between Bmori1_room and object_timeblock on SetCombine.

 

You could always force a set rendering in your tool if the .obj doesn't match properly, but I'm sure you can just strip the basics needed.

 

EDIT:

For the culling portion...

F3DEX2_VTX and F3DEX2_CULLDL...

 

Sets the culling, then deletes it? I would look into this, could be for one side of the geometry to have a special culling mode. Maybe a type of transparency, or attempt at something.

[xdaniel]

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.

[Airikita]

Right okay.

 

It also appears the LoadTextureBlock and LoadTLUT follow a sequence. However, I can see it's not necessarily rigid, but I would assume it has to be within a certain way.

[HeavyZ]

About to test patch 5, I would have already tested a few hours ago if I wasn't super sick with the flu.. It's 6:17 PM my time as I'm posting this, so keep in mind that on the weekdays I won't be able to test until usaually about after 4 PM although Arcaith if you're not too busy to split the hardware testing with me on this then that's cool, just so xdan doesn't have to wait until later into the night his time until I'm back with results.

 

Be ready to check back in about 10mins for an edit to see how the patch works on hardware

 

Edit:

patch 5 had the same results as patch's 3, and 4

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

[Airikita]

This could either be the sequence, or how some sequences contain certain info. between object_gi_letter and Strongwarp Box map have a different E3 instruction where E3 comes after, but the same E3 in Bmori1_room_0 contains the culling info before a similar set.

 

It could also be related to how Strongbox Warp contains no E2 (F3DEX2_SETOTHERMODE_L) at the end? I still wouldn't rely on Strongbox Warp for a test sample in this study... but if this re-occurs, it may have nothing in common whatsoever.

 

 

EDIT: xDan beat me.

[xdaniel]

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

[HeavyZ]

I'll test it now and edit soon

 

edit:

DUDE YOU DID IT! It works I'm walking around in the map now!

[xdaniel]

I'll test it now and edit soon

 

edit:

DUDE YOU DID IT! It works I'm walking around in the map now!

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

[HeavyZ]

BOOM!!