spinout

The only way to do varied transparency in textures without using 32bpp (ridiculous) is through IA textures. I think a good idea would be to look at what combiner/setothermode pair the spider web model uses and to use that combiner when doing IA textures.

Strange. Try running it from the command line (Start->Run [type] cmd [ENTER] -> [in new window type]cd "C:/path/to/mupen64plus-ui-console.exe" [ENTER] [then type] mupen64plus-ui-console.exe "C:/path/to/rom.z64" [ENTER] Then, maximize the window and take a screenshot of it, I cannot help you unless I know what is going wrong.

I'm assuming windows. Download and extract mupen64plus 1.99.4. Drag and drop mupen64plus-ui-console.exe to the start menu. Then drag and drop any ROM onto the mupen64plus-ui-console executable and it should run. I just tested it with a Debug ROM, it worked right out of the box.

http://spinout182.com/ar/nemu64.zip "And he never used PJ64 again..."

I've been great JSA, it's been good to see you back in the scene. I'd say drop into IRC but I'm hardly ever there, I think I'll PM you instead. Anyways, the reason I suggested that the objects and actors had to be first was because of this post. As for the DMA table and the problems it creates, I have done a filesystem hack (z-filenew) and have been working on an application which works with the filesystem i.e. fixing inconsistencies between the DMA and scene(+map pointers)/object/actor/overlay tables, applying compression, extracting/inserting files, etcetera - z64-fm.

That's a very interesting idea. I suppose that I could modify z64anim to have a "mode" where it just acts as an obj dumper/importer. As for objn64tool, it now produces collision with the -c flag. Collision types are assigned either by material, group, shading group, or object, and specific members of that group can be excluded from the collision generation so you can do things like water without having a separate collision file. I'm going to add this exclusion feature to the mesh generator as well. More info: objn64tool(.exe) --help. The link remains the same.

I think the fixes in the latest release are worth a new post, also bumping topic (edit doesn't bump) objn64tool.exe New options: -h FILE / --header=FILE <- create a header that declares everything in ld script -a mat / --scroll=mat <- set material <mat> up to be a scrolled texture (scrolling done by an actor or something). To be used with -h and -X options. BMP reading is finally fixed.

624 = 0x270 != 390 Anyways, I've heard that maps prefer to have the display lists last, after the actors, objects etc. So... you're going to have to do some recalculation. IIRC cooliscool's ancient zeldaedit had a built-in recalculator, you could give it a shot.

New binary - same url Changes: [tt] -N, --normalize-all Calculate vertex normals for entire model -n mat, --normalize=mat Calculate vertex normals for material mat (can be used multiple times)[/tt] EDIT: Still same url, new binary, fixes some bugs, doesn't warn when you have line commands. EDIT2: more fixes (there was a memory leak!) EDIT3: More fixes - should work properly by now (normals are not thoroughly tested)

I was trying to help someone on MSN today use the dumpobj feature, and it wouldn't work for them though it worked flawlessly for me. When I had the person try out the 'extract' command it also failed - it could not create the layout.txt file. I believe that some of the code which creates folders is failing for certain people, as the folders were never created in the extr or dump folders he had. I cannot reproduce this error in any way. I *believe* he somehow got what errno was - 2 ENOENT:No such file or directory. A component of a specified pathname did not exist, or the pathname was an empty string.

I'm posting this here as to not clutter up the URA project thread (which I must say is quite cluttered): objn64tool.exe [tt]Usage: objn64tool.exe [options] Options: -h, --help This help -v, --verbose Be verbose -x FILE, --linker=FILE Write symbols to file FILE (`-' for stdout) -i OBJ, --input=OBJ Convert obj file OBJ -o FILE, --output=FILE Write to file FILE -b ADDR, --base=ADDR Set base address to ADDR (ex: 0x06000000) -s SCALR, --scale=SCALE Multiply verts by SCALE Example: objn64tool.exe -v -x conf.ld -b 0x06000000 -s 2.0 -i test.obj -o test.bin Converts object `test.obj' to F3DEX2 binary `test.bin', scaling it by 2.0, using base address 0x06000000, writing a configuration to `conf.ld'[/tt] Supports RGB, RGBA png, RGB bmp. It reads materials strictly (i.e. differentiates between mapkd and mapka, sometimes incorrectly used by exporters), and builds mesh based on materials. Tr and Kd commands in the mtl map to SetPrimColor, etc... Throughly untested. Completely portable.

I would think that that would be part of the modeling phase, no?

I don't quite understand what you mean by that - wouldn't it be a combiner for each material? The combiner is basically the transparency and coloring itself, which is why everything would be separated by it's material, as materials have their own individual coloring and transparencies. As for collision, it would remain organized by groups, or all together if no group is present.

libobj maps MTL files to a structure like this - the names (with their comments) should explain it: [tt] char *name; //newmtl <name> char *diffuse_tex; //mapKd / map_Kd (texture in white light) char *specular_tex; // mapKs / map_Ks (texture when "shiny") char *ambient_tex; // mapKa / map_Ka (texture in shadow) objrgb ambient; //color in shadow ("ka") objrgb diffuse; //color in white light ("kd") objrgb specular;//color when shining ("ks") float alpha; //"Tr" or "a" float shinyness; //"ns" int is_shiny; //"illum" [/tt] It should be noted that the illum value has very specific values.

To be honest xdaniel, I believe that organizing visual mesh via groups is the wrong approach - though it does work well for collision. If visual meshes are organized by their groups, how can you implement mtls correctly? Say, for example, that a group contains two materials, and each of those materials have their own transparency and tint values - the only way to read these independently through SharpOcarina would be to split up the group (that is assuming you do implement Tr/a and Kd values). I do understand how much of a hassle it might be, though, to make SharpOcarina work this way. *Ponders about downloading MS SDK and forking SharpOcarina* nahhhh

This is what I leave my school computer to do over the weekend when I go home: It's been running for over 3 days now. (also, CMD fucking sucks)

Studying opcodes will teach you less than learning to program. Learn what memory and variables are. Stepping with Nemu's disassembler and watching memory and variables is one of the most effective ways to learn about MIPS assembly specifically.

Good to see you're still (?) active, JSA. How exactly did you do this? Did you RE some version of Doom and convert it to something the OoT engine can handle, or did you export obj and use xdaniel's tool to re-import it somehow? Regardless of the methods you used, I must agree that the results are excellent.

Yes. I would recommend trying to learn to program in one way or another, how all of this works will become much clearer. (tip: try C)

Aha. The 'mtllib' command loads the file associated with it - 'test.mtl' in this case. The 'usemtl' command specifies to use a material named 'mat1', which should be defined in the file 'test.mtl' as so: newmtl mat1 map_Kd texture_file_name.png Tr <transparency, 0.0 - 1.0> (Other mtl commands)

Change ori $s7, $zero, 3 to ori $s7, $zero, (NUMBER_OF_LINKS-1) in http://spinout182.com/4player/links.S

Texture coordinates are in OBJ files. What are you talking about? Perhaps an example of what you would like to do would help.

re: bits Ninty does it this way: #define GPACK_RGBA5551(r, g, b, a) ((((r)<<8) & 0xf800) | (((g)<<3) & 0x7c0) | (((>>2) & 0x3e) | (((a) >>7 ) & 0x1)) Edit: God damn this stupid auto edit-your-post-because-it's-cool-to-insert-®-and-enable-emoticons. Edit 2: I don't remember what OZMAV2 scaled things to, but I remember it was something obscure which I worked around when I used badrdp in z64anim. A lot of textures export weirdly/have "bad" mapping because they are mirrored and badrdp tries to accommodate for this by mirroring the texture manually and manipulating the UV coordinates - I, again, worked around this (custom mtl commands) when exporting for z64anim. (On the subject of z64anim, has anybody actually found it useful? lol) On another note, good seeing you here JSA

Well I guess I'm continuing this. Right now it is partially functional and I'm working slowly on finishing what is there already. Then I'll get to the hard parts. Still not sure where I'm going with this though.

I'm doing much more than creating a new filetable. I am writing an application which reads all the tables and turns pointers into indicies of entries in the filetable, sorts all the files, restores the file pointers via the indicies, then builds a new ROM with correct pointers everywhere. It will resolve any errors or inconsistencies found as well as compress the final ROM with lzo or Yaz0 compression if the user wants.