SoD's Software

[SoulofDeity]

It's been a long time since I've been really active on the site, and I'm not really sure if I've made a topic for my software (or even if this is the correct category?)

Anyway, here yuh go.

[*]dl2obj - this tool was my first attempt at ripping models from the game. it converts display lists in zobj / zmap files to wavefront obj's and extracts the textures as .tga files. really buggy, I suggest using one of my later programs instead. Lost the source to it, otherwise I'd post it

[*]dlpos - this lets you translate, rotate, and scale display lists. some notes, translations are done as signed short integers (-32768 to 32767), rotations are done in degrees, and scales are done on a 0 to 1 scale (meaning 1 = 100%; 1.5 = 150%; 2 = 200%; etc). Lost the source to this one too, otherwise I'd post it

[*]fcint - a tool I wrote a while back for converting fc instructions on glitchkill. I haven't used it in a long time, and I'm not 100% sure it's even done correctly. The source for it is here; but I strongly suggest building the source yourself from the following code:

 

#include <stdio.h>/* Color combiner constants: */#define G_CCMUX_COMBINED	0#define G_CCMUX_TEXEL0		1#define G_CCMUX_TEXEL1		2#define G_CCMUX_PRIMITIVE	3#define G_CCMUX_SHADE		4#define G_CCMUX_ENVIRONMENT	5#define G_CCMUX_CENTER		6#define G_CCMUX_SCALE		6#define G_CCMUX_COMBINED_ALPHA	7#define G_CCMUX_TEXEL0_ALPHA	8#define G_CCMUX_TEXEL1_ALPHA	9#define G_CCMUX_PRIMITIVE_ALPHA	10#define G_CCMUX_SHADE_ALPHA	11#define G_CCMUX_ENV_ALPHA	12#define G_CCMUX_LOD_FRACTION	13#define G_CCMUX_PRIM_LOD_FRAC	14#define G_CCMUX_NOISE		7#define G_CCMUX_K4		7#define G_CCMUX_K5		15#define G_CCMUX_1		6#define G_CCMUX_0		31/* Alpha combiner constants: */#define G_ACMUX_COMBINED	0#define G_ACMUX_TEXEL0		1#define G_ACMUX_TEXEL1		2#define G_ACMUX_PRIMITIVE	3#define G_ACMUX_SHADE		4#define G_ACMUX_ENVIRONMENT	5#define G_ACMUX_LOD_FRACTION	0#define G_ACMUX_PRIM_LOD_FRAC	6#define G_ACMUX_1		6#define G_ACMUX_0		7#define	SetCombine(pkt, a0, b0, c0, d0, Aa0, Ab0, Ac0, Ad0, a1, b1, c1, d1, Aa1, Ab1, Ac1, Ad1) {    pkt[0] = 0xFC000000 |							            (((G_CCMUX_##a0  & ((0x01 << 4) - 1)) << 20) |			             ((G_CCMUX_##c0  & ((0x01 << 5) - 1)) << 15) |			             ((G_ACMUX_##Aa0 & ((0x01 << 3) - 1)) << 12) |			             ((G_ACMUX_##Ac0 & ((0x01 << 3) - 1)) <<  9) |			             ((G_CCMUX_##a1  & ((0x01 << 4) - 1)) <<  5) |			             ((G_CCMUX_##c1  & ((0x01 << 4) - 1)))) & ((0x01 << 24) - 1);	   pkt[1] = ((G_CCMUX_##b0  & ((0x01 << 4) - 1)) << 28) |			            ((G_CCMUX_##d0  & ((0x01 << 3) - 1)) << 15) |			            ((G_ACMUX_##Ab0 & ((0x01 << 3) - 1)) << 12) |			            ((G_ACMUX_##Ad0 & ((0x01 << 3) - 1)) <<  9) |			            ((G_CCMUX_##b1  & ((0x01 << 4) - 1)) << 24) |			            ((G_ACMUX_##Aa1 & ((0x01 << 3) - 1)) << 21) |			            ((G_ACMUX_##Ac1 & ((0x01 << 3) - 1)) << 18) |			            ((G_ACMUX_##d1  & ((0x01 << 3) - 1)) <<  6) |			            ((G_ACMUX_##Ab1 & ((0x01 << 3) - 1)) <<  3) |			            ((G_ACMUX_##Ad1 & ((0x01 << 3) - 1)));				}int main(int argc, char *argv[]) {   unsigned int pkt[2];   SetCombine(pkt, TEXEL0, 0, PRIMITIVE, 0,	// color combine mode 0                   1, TEXEL0, PRIMITIVE, 0,	// alpha combine mode 0                   TEXEL0, 0, PRIMITIVE, 0,	// color combine mode 1                   1, TEXEL0, PRIMITIVE, 0);	// alpha combine mode 1   printf("XXn", pkt[0], pkt[1]);   return 0;}

 

[*]n64conv - a replacement for the n64gfx tool in the ZLE2 package. it converts raw texture data into tga files. to work, the files must be named in the following format: "filename_WxH_fmt.bin"

where W is the width, H is the height, fmt is the format (i4, i8, ia8, ia16, rgba16, rgba32); and the extension doesn't necessarily have to be .bin. no arguments, just drag-n-drop. Again, sry, no source

[*]ovldesc - a tool I wrote to dump information about actor files such as the locations of the sections and the relocations of the values and whatnot. Again, sry, no source

[*]tga2i4 - converts an uncompressed RGBA32 .tga file to raw I4 texture data. No args, just drag-n-drop. Again, sry, no source

[*]tga2i8 - converts an uncompressed RGBA32 .tga file to raw I8 texture data. No args, just drag-n-drop. Again, sry, no source

[*]tga2rgba16 - converts an uncompressed RGBA32 .tga file to raw RGBA16 texture data. No args, just drag-n-drop. Again, sry, no source

[*]tga2rgba32 - converts an uncompressed RGBA32 .tga file to raw RGBA32 texture data. No args, just drag-n-drop. Again, sry, no source

[*]z64dump - dumps information about the rom such as the location of the file, object, and actor tables and information about the actors including their object/group/actor #'s and the offsets/names of the objects they use. z64dump2 is currently being worked on. You can download the source here

[*]z64rip - my second attempt at a tool to rip zobjs and zmaps as obj or smd files, and an utter failure in my opinion. Nonetheless, it's here if you want it. Again, sry, no source

[*]z64dump2 - a prerelease of z64dump2. it doesn't have any of the documenting stuff like the original z64dump has yet, but it is capable of byteswapping, decompressing, and recalculating the crc of a rom in place just by dragging and dropping the rom on it, and can extract files from the rom. file type detection is also a lot better than zdec, with the exception that it can't yet detect which file is the .ztxt file yet in non-majora's mask roms. You can download the source here

[*]stripjs - a program I wrote to compress javascript code. also works fairly good with C code as well. might be useful if you're looking for a code obfuscator. you can download the source here

[*]zelda64 blender import script - a python plugin I wrote for blender to import zobjs and zmaps from Zelda64 games. zobj's are imported full skinned and ready for posing. Still a work in progress. If the faces appear reversed when importing, try using this one instead.

You'll need Blender 2.6 or higher and Python 3 for it to work. Installation is simple, just open Blender, change to the user preferences view, go to the addons tab, install from file; check to enable it, go back to 3d view, and hit Ctrl-U to save your user preferences.

[*]nettest - I little something I wrote while working on the networking part of my game engine. I didn't like how it turned out, but its still pretty useful if you're trying to figure out how to download webpages using window's sockets. you can download the source here

[*]Hylian Cartographer - the original build of Hylian Cartographer. Didn't do much aside rom filesystem editing and patch managing, and I highly doubt it'll work for anyone anyway because it was linked against a no longer available msvc11 beta runtime. Sorry, no source

[*]z64shell - a bunch of windows batch scripts I wrote that set up an a very user friendly environment for modding. setup is simple, just run the shell once and copy your unmodded roms to the roms folder.

There are 10 instructions: backup, decompress, emu, extract, fix, ide, makepatch, patch, restore, and rom.

To begin modding a rom, you first use the 'rom' instruction, like "rom zelootma". This will copy the rom from your rom's folder to the main folder. Whenever you start the shell, it does a search for the first .z64 file it can find in the main folder. If one exists, it'll use that one by default, so there's no need to use the "rom" instruction every time you start the shell.

Next, you type "backup" to create a backup. You can also create multiple backups by providing a name, like "backup beforetest". These backups can be restored using the "restore" command.

"decompress" decompresses the current rom (obviously), and "extract" extracts it. extract also sorts the files it extracts by file type, making files easier to find.

"makepatch" creates a patch. you can optionally provide a name for the patch like "makepatch mypatch". these patches are stored in the patches folder sorted by rom type and can be applied using the "patch" instruction. "fix" fixes the crc of the rom, which is useful when applying patches that affect the first 1MB of the rom.

The last 2 rely are rather large files, which I decided would be best to include separate. The first is "ide" is opens the ide used for assembly hacking. by default, this is galatea, but you can change it by editing a few lines in the z64shell.bat file. The second is "emu" which opens the emulator and plays the rom if the emulator supports command line arguments. by default, it opens nemu64, but again this can be changed. it also creates a configuration file for nemu64 (if it doesn't exist) that tells where to store the save files so they're not cluttering your rom's folder.

You can download them both ready for the package here or optionally get galatea yourself here and nemu64 here

------------------------------------------------------------------

 

Some other stuff I've built, but not necessarily made from scratch.

[*]x86-elf gcc - an x86-elf gcc cross compiler I built when I was goofing around with operating system development.

[*]n64sdk - a fully working setup of the official n64 sdk. took me forever to get working properly. much of the tools they used are 16-bit, so you'll need to be on a 32-bit operating system or run it in a virtual machine like I do to use it.

[Conker]

Dayuuuuumn, son!

 

Amazing stuff here, if I do say so myself.

[haddockd]

Wow. I always thought spinout made some of those tools. Thanks for setting me straight

[SoulofDeity]

Wow. I always thought spinout made some of those tools. Thanks for setting me straight

yeah, my programs are kinda all over the place, so I wouldn't blame you.also, should note that this is the first place I've uploaded or stated anything about z64shell. I've mainly just been using it myself, and I think people might find it really useful.

[Airikita]

Yup, he sent me some. There are tools by all sorts of hackers, including cooliscool. I would have to verify others, but I have seen some amazing stuff from SoD.

[SoulofDeity]

Yup, he sent me some. There are tools by all sorts of hackers, including cooliscool. I would have to verify others, but I have seen some amazing stuff from SoD.

Well the easiest verification is just to look at the output in the console. It'll say "programname by SoulofDeity"; and if it doesn't show up there using "--help" will print my name. If I didn't lose my winstuff folder in an ubuntu crash, I'd still have the sources to a majority of those.

[SoulofDeity]

Since I couldn't get xdaniel's model2n64 to work for me, I decided to go back to using spinout's wotf. Since a majority of the problems with people using it are just getting it to work at all, I went ahead and created another extension for z64shell that comes with a bare-bone minimal python distro (just the precompiled binaries needed to make spinouts scripts work) and added a new instruction called obj2zobj.

 

The arguments are simple, just "obj2zobj input.obj" or "obj2zobj input.obj output.zobj".

 

You can download the extension here

 

----------

 

In other news, I've decided to just say "screw linux users" and resume work on Hylian Cartographer in the way I find most comfortable. I'm making the effort to write the program, they can meet me halfway by dualbooting or using Wine.

 

There's nothing impressive to show yet, just trying to work out some annoying C# bugs to get transforms working properly, but I'll keep everyone updated.

[Jason777]

A newer version of spinout's OBJ importer is OBJN64Tool. Perhaps you should try using that instead of wotf. You can find it here: http://wiki.spinout182.com/w/Libobj

[SoulofDeity]

Thanks for point it out, but I can't get it to work either. It always crashes when converting the textures (tried both png and 24-bit bmp)

[SoulofDeity]

Got bored and wrote a new program for fun called "trololol the Zelda64 texture crapper".

I'll spare you the specs, but here's a vid of just what it does



It works on all Zelda roms as long as they're decompressed and big-endian swapped. No arguments, just drag-n-drop. You can download it here

 

 

EDIT:

oh, almost forgot, here's the source:

 

 

#include <stdint.h>#include <stdio.h>#include <malloc.h>int main(int argc, char *argv[]) {   printf("trololol Zelda64 texture crapper by SoulofDeityn"          "-----------------------------------------------------n");   if (argc < 2) {      printf("ERROR:  No rom specifiedn");      return 0;   }   FILE *fp = fopen(argv[1], "r+b");   if (!fp) {      printf("ERROR:  Failed to open filen");      return 0;   }   uint8_t *data = (uint8_t *)malloc(0x00101000);   if (!data) {      fclose(fp);      printf("ERROR:  Failed to allocate memoryn");      return 0;   }   printf("trolling rom...        ");   uint32_t i, len, w0, w1, inDlist = 0;   while (len = fread(data, 1, 0x00101000, fp)) {      for (i = 0; i < 0x00101000; i += 8) {         w0 = (data[i] << 24) | (data[i + 1] << 16) | (data[i + 2] << 8) | data[i + 3];         w1 = (data[i + 4] << 24) | (data[i + 5] << 16) | (data[i + 6] << 8) | data[i + 7];         if (inDlist) {            if (data[i] == 0xD7) {            } else if (data[i] == 0xD9) {            } else if (data[i] == 0xDF) {               inDlist = 0;            } else if (data[i] == 0xF8) {               w1 = 0x000000FF;            } else if (data[i] == 0xFA || data[i] == 0xFB) {               w1 = 0xFFFFFFFF;            } else if (data[i] == 0xFC) {               if (((w0 >> 12) & 0x07) == 2 || ((w0 >> 9) & 0x07) == 2 ||                   ((w1 >> 12) & 0x07) == 2 || ((w1 >> 9) & 0x07) == 2 ||                   ((w1 >> 21) & 0x07) == 2 || ((w1 >> 18) & 0x07) == 2 ||                   ((w1 >> 3) & 0x07) == 2 || (w1 & 0x07) == 2 ||                   ((w1 >> 21) & 0x07) == 0 || ((w1 >> 18) & 0x07) == 0 ||                   ((w1 >> 3) & 0x07) == 0 || (w1 & 0x07) == 0) {                  w0 = 0xFCFFFFEF;                  w1 = 0xFFFE753A;               } else {                  w0 = 0xFCFFFFEF;                  w1 = 0xFFFE7339;               }            }            data[i] = w0 >> 24; data[i + 1] == (w0 >> 16) & 0xFF; data[i + 2] = (w0 >> 8) & 0xFF; data[i + 3] = w0 & 0xFF;            data[i + 4] = w1 >> 24; data[i + 5] == (w1 >> 16) & 0xFF; data[i + 6] = (w1 >> 8) & 0xFF; data[i + 7] = w1 & 0xFF;         } else if (w0 == 0xE7000000 && !w1)            inDlist = 1;      }      fseek(fp, -len, SEEK_CUR);      fwrite(data, 1, len, fp);   }   printf("oknrecalculating crc...   ");   uint32_t crc[2], d, r, t1, t2, t3, t4, t5, t6 = 0xDF26F436;   t1 = t2 = t3 = t4 = t5 = t6;   rewind(fp);   fread(data, 1, 0x00101000, fp);   for (i = 0x00001000; i < 0x00101000; i += 4) {      d = (data[i] << 24) | (data[i + 1] << 16) | (data[i + 2] << 8) | data[i + 3];      if ((t6 + d) < t6) t4++;      t6 += d;      t3 ^= d;      r = (d << (d & 0x1F)) | (d >> (32 - (d & 0x1F)));      t5 += r;      if (t2 > d) t2 ^= r;      else t2 ^= t6 ^ d;      t1 += ((data[0x00000750 + (i & 0xFF)] << 24) | (data[0x00000751 + (i & 0xFF)] << 16) |            (data[0x00000752 + (i & 0xFF)] << 8) | data[0x00000753 + (i & 0xFF)]) ^ d;   }   crc[0] = t6 ^ t4 ^ t3;   crc[1] = t5 ^ t2 ^ t1;   crc[0] = (crc[0] >> 24) | ((crc[0] >> 8) & 0xFF00) | ((crc[0] << 8) & 0xFF0000) | ((crc[0] << 24) & 0xFF000000);   crc[1] = (crc[1] >> 24) | ((crc[1] >> 8) & 0xFF00) | ((crc[1] << 8) & 0xFF0000) | ((crc[1] << 24) & 0xFF000000);   fseek(fp, 0x10, SEEK_SET);   fwrite(crc, 1, 8, fp);   printf("okn");   free(data);   fclose(fp);   return 0;} 

 

 

[SoulofDeity]

Didn't really plan on making another post since I left the community, but I was helping someone from another website on their project and ended up writing another utility.

 

zobjfix - locates all the displays lists in a file and appends a hierarchy to the end of the file that includes all of them. no usage, just drag-n-drop. this was written because my import script doesn't support importing zobj dlists that aren't pointed to by a hierarchy.

search isn't very intelligent. it doesn't follow DE branches or perform recursive memory mapping; it just labells anything that starts with an E7 pipe sync and ends with a DF enddl a display list.

 

io_import_z64_v4 - version 4 of my zobj / zmap import script; animation support added thanks to RodLima from the spriters-resource community. RodLima was new to python when he worked on it, so there's a huge problem with performance caused by lack of file buffering and the segment io system that was already integrated. a single animation could take >= 30 seconds to import.

it was fixed later, but I lost the fixed version. when I find it, I'll post that as well.

 

Since the code.google service won't accept new uploads anymore, I moved the svn to sourceforge

[SoulofDeity]

A new program I just wrote requested by Sanguinetti that lets you generate, fix, and decode 0xFC SETCOMBINE combiner muxes and the clamp/mirror properties of 0xF5 SETTILE.
 

 

 

Download SoD's Texture / Combiner Mode Generator

 

 

I didn't have visual studio installed, so I started writing it in C with the win32 api; but the comboboxes were being douchebags so I just wrote it in Javascript as a .hta hypertext application. If you're a linux user and can't open this, just change the extension to .html and open it in your browser.

 

 

NOTE:

You don't need to have spaces between bytes. The program inserts them for readability

[SoulofDeity]

so, there's a person I've been helping in another community that's been having trouble ripping models from MM because of the file naming and whatnot. so I'm bringing one of my old programs up to date.

 

 

Just started it last night, and It's not finished, so far it

• byteswaps the rom if necessary
• determines if the rom is OoT or MM based on the internal name
• locates the file table
• decompresses files
• determines file types
• locates the code file (determined by signature of the last 32-bytes of the file which is the same for both OoT and MM code files)
• locates the scene table

Fyi, like the previous z64dump releases, it follows the rule that nothing is ever hardcoded. It uses smart-searching techniques to find things properly, meaning it'll work on any Zelda rom. Locating the scene table turned out to be a bit of a challenge, but I came up with a pretty good technique:

• navigate through the file table to find 3 scene files
• search for the virtual start and end offsets of all 3 scenes in the code file. at least 2 will be found.
• sort their appearance from least to greatest

For OoT:

• for all the appearances of the offsets that are found, if their difference modulo 0x14 is 0 then the program knows it's inside the scene table.
• recede backwards from the earliest appearing offset by 0x14 bytes until the 32-bit word at that address is nonzero is not the virtual address of a valid file table entry

For MM:

• for all the appearances of the offsets that are found, if their difference modulo 0x10 is 0 then the program knows it's inside the scene table.
• recede backwards from the earliest appearing offset by 0x10 bytes until the 32-bit word at that address is nonzero is not the virtual address of a valid file table entry

 

 

The idea here is that z64dump will use the scene, object, and actor tables to extract and sort files rather than the file table alone. It'll create folders for each scene to match the map files to the scene files, prefix scenes with their scene number, maps with their map number (according to the scene header), and objects with their object number.

Actors will be sorted into folders based on their group number, and have their actor/object number as a prefix (ie.  aaa:ooo_actorname.zactor).

 

The first 3 entries of the object table will be kept toplevel as they are always the gameplay_keep, gameplay_field_keep, and gameplay_dangeon_keep respectively; and possibily be given 'gk_', 'fk_', and 'dk_' prefixes. for tagging.

[SoulofDeity]

 

 

HELL YEAH BITCHES!!!  >83

 

 

Just finished adding scene / map extraction. It creates the following directory structure:

- data   |   '- scenes        |        '- scene#                                (for each scene in scene table)             |             :- maps             |   |             |   '- XXXXXXXX - XXXXXXXX.zmap      (for each map in scene)             |             '- XXXXXXXX - XXXXXXXX.zscene

Just need to smack on object table locating and actor table parsing, and this puppy will be ready for distro

[SoulofDeity]

Finally done

 

 

Download z64dump3

Download source

 

 

What it does:

• byteswaps the rom if needed
• locates the code file
• locates the file, scene, actor, and object tables using smart search techniques (no hardcoded addresses)
• extracts scenes, maps, objects, and actors and decompresses them if needed.
• uses the name table for file names if one exists

What it doesn't do:

• extract files that aren't inside the scene, object, or actor tables (because it's intended to match actors to objects and maps to scenes. if I wanted to write a rom decompresser, I'd just be reinventing the wheel since zdec already exists

The output is a file tree of the following format:

- data  |  :- actors  |  |  |  '- #                           (hexadecimal group number for each actor group)  |     |  |     '- aaa-ooo # name.zactor    (hex actor#-object# and file name for each actor)  |  :- objects  |  |  |  '- ooo # name.zobj             (hex object# and file name for each object  |  :- scenes  |  |  |  '- #                           (decimal scene number for each scene)  |     |  |     :- maps  |     |  |  |     |  '- name.zmap             (for each map file in this scene)  |     |  |     '- name.zscene              (scene file for this scene)  |  :- gk_ooo # name.zobj             (gameplay_keep)  :- fk_ooo # name.zobj             (gameplay_field_keep)  '- dk_ooo # name.zobj             (gameplay_dangeon_keep)

I'm sure those who want to work with the OoT 1.0 or MM roms will find this tool an invaluable asset.

[Airikita]

Sweet, now we just need peeps who will hack MM with this. Awesome work!

[SoulofDeity]

Was talking to the guy I've been helping out and he was having trouble importing scene 008 from MM into blender. Kept getting a blank mesh. Realized that scenes could actually have several headers, so I fixed z64dump3 to locate all the headers within zscenes for zmap exporting.

 

Also changed the naming scheme for maps to:

mmm # mapname.zmap

where 'm' is the index of the map's entry in the scene header's map list.

 

 

Download Fixed Version

[SoulofDeity]

*Re-upload of fixed v4 Blender import script

 

io_zelda64_v4 download

 

(removes line added by RodLima that causes crash at bl_info block)

[SoulofDeity]

Working on V5 of my importer. I've pretty much come to the conclusion that it needs to be written as a separate program now because there's some functionality that's too difficult to do with the blender api. However, I was tweaking my old script a bit just to dump secondary textures and made a weird discovery

 

 

 

 

I haven't added combiner support yet, so obviously the texture was fixed manually, but I noticed that in order to get the correct granularity for the grass, tile 1 had to be rendered with 4 times the uv-scale of tile 0. Or another works, it was scaling the uv's so that (logically) the material was 256x256 in size.

[Three_Pendants]

So your program will eventually allow us to create maps in Blender and then import them using Sharp Ocarina? Or am I misunderstanding the point of the program?

[SoulofDeity]

So your program will eventually allow us to create maps in Blender and then import them using Sharp Ocarina? Or am I misunderstanding the point of the program?

The original script was able to rip models and animations from the game, I'm going back and improving my previous work to add multitexturing and combiner support. If I'm up for it though, I may write an exporter.

[SoulofDeity]

Working on the new toolbox for V5 of my blender script. It's an enormous pain in the ass...Some of the controls like the list are way underdocumented (only 1 or 2 old examples on the web which don't work, I pretty much had to stab at it for hours on end until it worked) and you can't just create custom properties; you have to assign them to the current scene context and register operators to work with them. In short, it's like 100x more difficult than writing a normal import script.

 

 

On the bright side, I found out you could test using Blender's built in script editor. 

[Antidote]

You may want to update to 2.70, I think the shelf's API might have changed a bit. I could be wrong though.

[SoulofDeity]

You may want to update to 2.70, I think the shelf's API might have changed a bit. I could be wrong though.

The api recently had a complete change as of 2.5, it's very unlikely that's they've decided to make yet another enormous leap so soon. I will update however just to make sure, thanks

 

 

Ended up creating a class to generate listboxes since I'll need a few of them. Makes my job a little easier...

[SoulofDeity]

Was debating on whether or not I should make the importer as a blender plugin or a separate program this whole time and well...I think it's decided. I have no idea how or what kind of roids got into my bloodstream, but within a matter of a few hours I've written an entire framework for a game engine based on Zelda64's in C#.

 

 

 

There are 2 main namespaces; Graphics and Assets.

 

The Graphics namespace contains wrapper classes for low level rendering. This includes Frame, Surface (abstract base class for Render and Texture), Render, ColorFormat (allows custom color specification, with presets for common color types like RGBA16 and CI8), Filter (used selecting sampling modes, things like nearest-neighbor, bilinear, etc. along with mipmap and antialiasing levels), Palette, Texture, Shader, Program (container for multiple shaders which are linked together), and Mesh

 

The Assets namespace defines the assets and make up the visible part of the framework itself. This includes Scene, Room, Actor, Object, Script, Image (used by Graphics.Texture, but can be used for other things), and Material.

 

The Script class is the magic behind it. There are a set of events that executed at certain stages. When the static function Scene.Load is called, it sends a Destroy event to the current scene, loads a new one, and sends a Create message to the new one. These messages is passed to all of the rooms that are currently enabled, which in turn passes them to each object. Objects that have the Scripts.Camera script attached to them register themselves as a camera to the Scene.CameraList at the Create event which prevents them from being passed the Render event like normal objects and instead the entire scene is rendered for each object with that script attached; allowing for multiple viewports and optionally reflection. There are currently 4 events:  Create, Destroy, Update, and Render. I still need to add a 2D render event.

 

 

 

 

In summary, it started off as a simple importer but seems to be headed in the direction of becoming a full-blown Zelda64-inspired game engine.