Airikita

How's the tool going? Think you'll have it working and uploaded before the holidays end?

Are you saying that the cube will never cover Link, but just grow larger and larger as Link approaches it?

Disclaimer: I didn't make this.

Is this specified in the sketchup models, or also part of any model in obj format?

The only -real- breakage with gi models is the size of the display list. Obviously more vertices will make the game crash, because I -think- I remember around 0x2000 in length was the limit, or that was the file I tested that was too big. Majora's Clock was a real squeeze. I think those two will be fine, but more testing in the future will be needed. I will be buying myself an ED64 as soon as I get the money for it.

Hooray! Can't wait, I am SO pumped to start working on things over the holidays. MERRY XMAS! EDIT: Can I have that awesome cube for my mod? I'll put a sign next to it commemorating this day.

Just updating that I won't be hacking Pokemon Stadium 2 until more of this project is tweaked more. Perhaps even leave it out of the equation and make custom models. I might make something else that would make this more intense. That is, of course, if everything eventually works out. EDIT: Project will be worked on next week!

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.

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.

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.

*snore*..... *wakes up* huh? what? Might be, if xDan doesn't already know about that information. It would be good to look over, sure.

I enjoy all video game music, and I'm loving Smooth McGroove's latest acapellas:

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

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.

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?

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.

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.

(new post because last one is too long) Now to observe a fresh raw convert dump of my Unicat: 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.

http://n64.icequake.net/mirror/www.white-tower.demon.co.uk/n64/ *Groans*... this pees in my cheerios now... Onward: This could reference more to xdan's topic, since this relates to F3DEX2 issues. Some of the commands do DMA'ing for both processors possibly? I am seeing that there is now piping issues to address with the RDP and RSP processors, meaning the commands would have to be aligned to use the proper output. What's confusing is how this also is linked to the AUDIO output... that's right, audio. Unrelated, but uses the same RCP.