xdaniel

I remember this happening, and I do seem to remember that it's related to the resulting scene and room file sizes, so it having to do with the DMA table doesn't seem too farfetched. There's probably something about this somewhere on spinout's forums...?

Ughhhh, ignore my post, but also don't use the SetRenderMode function - 0x1C and, for example, 0xC81049D8 appear to simply be wrong as its parameters. The values are correct and come right from the game, but they're incorrect as parameters for that function. Just have the program insert the raw command, ex. 0xE200001CC81049D8, into the display list instead, like Helpers.Append64(ref DList, 0xE200001CC81049D8);

May I comment on this? First, you probably shouldn't do the subtraction inside the SetRenderMode function, but rather change the parameters of the calls to SetRenderMode, so that C1 already enters the function with 4 subtracted, so ex. SetRenderMode(0x1C, 0xC81049D4); instead of SetRenderMode(0x1C, 0xC81049D8); Second, is the resulting 0x4 even a valid flag for SetRenderMode? It doesn't appear to be according to the SDK's GBI.h: /* G_SETOTHERMODE_L gSetRenderMode */ #define AA_EN 0x8 #define Z_CMP 0x10 #define Z_UPD 0x20 #define IM_RD 0x40 #define CLR_ON_CVG 0x80 #define CVG_DST_CLAMP 0 #define CVG_DST_WRAP 0x100 #define CVG_DST_FULL 0x200 #define CVG_DST_SAVE 0x300 #define ZMODE_OPA 0 #define ZMODE_INTER 0x400 #define ZMODE_XLU 0x800 #define ZMODE_DEC 0xc00 #define CVG_X_ALPHA 0x1000 #define ALPHA_CVG_SEL 0x2000 #define FORCE_BL 0x4000 #define TEX_EDGE 0x0000 /* used to be 0x8000 */ You sure that's the correct way to fix this and won't cause issues elsewhere? Maybe I'm reading this all wrong, too, and you're not even doing what I'm thinking you are, and are actually right about this...

Dunno if it's of any help, but I hacked together a combiner calculator of sorts from what I have access to at the moment; can decode and encode combiner modes: https://www.dropbox.com/s/631tucbr07l8bm2/CombinerCalculator.rar?dl=0 Run like "CombinerCalculator.exe 0xFC119604FF13FFFF" or "CombinerCalculator.exe TEXEL0 0 PRIMITIVE 0 TEXEL0 0 PRIMITIVE 0 COMBINED 0 SHADE 0 COMBINED 0 SHADE 0". Example output: Combiner Calculator -- February 28th 2015 by xdaniel ------------------------------------------------------------------------------- Decoding combiner mux... -- Packed Mux ----------------------------------------------------------------- 0xFC119604FF13FFFF -- Cycle 0 -------------------------------------------------------------------- C [(TEXEL0 - 0 ) * PRIMITIVE ] + 0 A [(TEXEL0 - 0 ) * PRIMITIVE ] + 0 -- Cycle 1 -------------------------------------------------------------------- C [(COMBINED - 0 ) * SHADE ] + 0 A [(COMBINED - 0 ) * SHADE ] + 0 ------------------------------------------------------------------------------- Done! Also, http://n64devkit.square7.ch/n64man/gdp/gDPSetCombineLERP.htm and the sources to my HW-compatible converter and SceneNavi. I don't have any other notes about the combiner, I don't think, and even if I do, they're not here with me.

I'm out, sorry. Even if I wanted to dive into this whole subject matter again - which I don't for the known reasons -, my real life is a mess and will stay so for an undetermined amount of time (several weeks at least, after having already been a mess since January 3rd). I have no access to my desktop machine right now, and my laptop doesn't even have half of the data/programs/ROMs/etc. I have on the other system. Pretty much all I have here is the OoT3D/MM3D stuff, an Etrian Odyssey 1 ROM and some docs, and whatever I can get from my Github. Whoever is interested in taking this over: either have or gather some C# knowledge, ignore SO and Model2N64 completely, use the HW-compatible converter as a base (you know, the one I ragequit from and open-sourced a year ago, that no one has done anything with since), and make a whole new custom map importer based on whatever new knowledge has been gained over the last year.

Mesh type 0 and the basic composition of it as generated by SO should be fine. Entries for that mesh type don't need any additional data like clipping bounds or what have you, unlike type 2. That said, SO still doesn't work properly on hardware obviously, although there's one thing that comes to mind. I assume you've done this exactly as I said before, i.e. one opaque display list, one translucent display list, one opaque, one translucent, etc. Can't find the code snippet I remember posting, but I think that's how I implemented that there, like... [AAAAAAAA BBBBBBBB] [CCCCCCCC DDDDDDDD]...each set of brackets being one entry in the header. Instead of that, try doubling the amount of entries and putting a single opaque display list into a single entry with no translucent one attached, and vice-versa. So like... [AAAAAAAA 00000000] [CCCCCCCC 00000000] [00000000 BBBBBBBB] [00000000 DDDDDDDD]...with all the translucent entries following after all the opaque ones. If any of that makes sense. It's late, I haven't worked on this in ages, and I don't really care anymore for reasons stated more than enough times already. Would like to see SO create stuff that's at least playable on hardware, but... meh, by this point.

Pick-up from about a week ago, kinda sorta another birthday present I got myself: SARDINES, dood!

New viewer build: https://github.com/xdanieldzd/N3DSCmbViewer/releases/tag/v025-unstable2 - faster rendering, more stable, some Collada export fixes!