Days 73-70; ROOM AVAILABLE FOR RENT

Only 69 days left;

I was unable to get much accomplished; I lost a friend to the deadly frozen north this week.

As a result, I have 1 9x12 room available for rent;

Base rent is a fixed value of 316.50$ for rent, utilities are added on top (usually about 150 total, so rent stays below 400 a month)

Anyways,

I've created the BRF format specification, which is a generalized format for any data. As the original idea was not the greatest (wish I had some help) it was modified to merely specify a generic 4CC chunk based format so that chunk types are specific to the loader, and the BRF code has a lot of generic array routines and important conversions like htonl, ntohl and other equivalents (if you don't know and understand these functions, stop programming and get another degree. Or learn them.)
This allows you to inherit from the base loader class, and override either the generic load function, and read chunks as you will, OR:
Thread loading works.
This changes a lot of things, and enforces the need for a memory manager, because as you all know,
Threads cannot change values in another thread
What this means, is if your thread is loading a Mesh, then if that thread allocates memory, where did it come from? Ideally, it comes from your applications heap (threads share execution space) however, that isn;t exactly ideal. It's simple, and it does work, but if a THREAD allocates memory, and I am using a memory manager, then what happens if two things use that MM? Your CPU dies, that's what. Hard. Bluescreen easy.
So, to fix this, you must either make a new HeapAllocator that is for that thread, and then merge it with the main one, OR, add an additional mutex lock so that you can have the main thread itself create the memory using whatever heap it wants to.
In fact, the mutex solution is a good one, albeit slow.
In testing,
The normal loading procedure on a harsh test (5MB file, 4 bytes at a time) takes about 3 seconds. IT locks up the main thread too. yay.
The thread loader, operates concurrently with the main thread, dropping it's IFPS from 10000 down to about 3000 (which is still ~150000 FPS), however, the main thread continues to run flawlessly (meaning kinky loading screens are possible), BUT, the loading takes about 6-8 seconds. For a doubled loading time, I'll use the stream loading since it lets me load things behind your back, making level transitions flawless. Yay!

In summary:

*BRF format spec done
-Linkage files are separate.
*Thread loading possible and works

*Need to develop "MicroFormats" for each loadable data class.
-For example, 'Mesh' microformat needs to be developed (chunk specification for the generic BRF file)
*This necessitates a redesign of IGTL::RenderBase for the following reason:
-VA/IA paradigm is incorrect; Replaced with VD/PrimSet paradigm (more accurate, faster, abstract)
-RenderBase should not do anything that Graphics does; It should only manage the low level render state (IE, extremely minimal objectified support for abstracting hardware render objects like lights, materials, textures, VA/IA's), and the removal of immediate mode except in special implementations.

Also, the BRF specs don't make me 100% happy; I still worry about data concurrency and streaming issues like:

[tag][size]...
[data]...

Which should allow the header space to be loaded into memory, so you know all the chunks, and THEN the loader can continue on as normal... except, well, that requires nasty memory allocations issues, which is getting harder to work with across threads.

I should have had something out; Yesterday was supposed to be a milestone.

I failed.

-Z