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

Days 76 - 74

Only 74 days left till demo;

Progress made,

I've correct multiple errors in SDLGameBase; Primarily with the Audio and Graphics setup, as well as tweaking it's loop setup.
Worked with IGTL::WMod music player; fun stuff there, looked up how to work mod files, made a few different players, still eperimenting
Updated the BRF 3.0 specifications greatly; I'm going to focus on that and RenderBase since I might have help in making graphics! (yay artists!)
Made some threads, working on the thread pool for procedural loading and fun stuff, although it hangs badly.
Got glextplus.h to work perfectly, extensions are now instant and very easy, as well as stable and no GLEW bullshit.
Played a bit with particles, I can now toggle correctly from HD to SD resolutions regardless of screensize
Screen resizing needs tweaking

Next,

BRF 3.0 format specs need to be finalized in mechanics, and then Section types need to be added, as well as the required basis data types. Compressions to implement (done before) are the generic RLE compression, Quad encoding (MIF/QIF image format) and LZSS generic style algorithm for some data compression. Also, more thought about breaking apart the different sections to make more logical sense.

Manditory screenshot for the dev blog:

Please note this is a SD screen with the HD box overlayed into it. Each green square is 1 meter accuracy, and you probably recognize that collision box from previous posts. The white thing is a "stream particle" that flows around, I was just playing with it so I could check visible FPS with the threads. SO YOU KNOW, the "FPS" is the fixed internal game frames per second (never changes), the IFPS is the number of frames run inside of that one game frame (yes, this is over 100,000 FPS (493,900 to be exact), try it yourself and see. You need this to catch network messages, but this will drop a lot when I get this thing fully threaded) and, I have the VBO (vertex Buffer Object) extension loaded and ready.

Only 74 days left! (Planned demo Feb. 2nd 2009) Wish me luck!

I hate GM, I love Blender

So I hate GM again.

Usually doesn't take long. ;P


However, now I have developed a much more robust triangle stripping algorithm that directly translates into huge vertex/VA savings in rendering. This is a really good thing, as instancing a model requires copying the base meshes's vertex VA, which means each instance takes a good chunk of memory (for a 1300 vertex red dragon, that translates to ~1800 vertices for strips, or 3900 for raw triangles. So, each instance requires 4*3*1300 bytes, which is about 16 kB, lol)

Either way, now it's onto making good things like a Memory Manager so I can dump ram as I see fit, and do tracked allocations and all that low level shit that I shouldn't have to do again. Also, I now have to use VBO's (if you card supports them) to do the rendering, and this is a very interesting thing:

VERTEX ARRAYS ARE SLOWER THAN IMMEDIATE MODE

Why, you ask? Draw a picture for yourself. Immediate mode is a 1 direction pipeline. The GPU pipeline just gets pushed data. The end. Vertex Arrays require synchronization of the GPU and system memory, which is about like trying to unflush a toiet. My FPS drops from ~230 to near 20 with immediate mode versus VA's. With VBO's, I can get into the 780 FPS range.

Therefore, use VBO's. Make sure your array data is SEPARATE (do not stride) so you can easily plug in instance VA data.

More testing is required, but here is a toolchain picture that makes me happy:


Note that this is a goofy looking stupid lizard monster. Also, note that it has collision boxes (defined each by two verticies inside the keyframe). Also note, that that collision information is exported correctly into SDL. Does this look anything like Mortal Kombat or Mugen to you? Exactly. The problem is, this lizard has bones. And, I had to write MORE scripts to convert it's animations into mesh keyframes. And MORE scripts to read and export the animation file that defines the animations, as well as game information like attack boxes and physics and so forth.

However, it's really nice to be able to quickly make something, and see it work in the game. No doubting that at all.

Until next update.

-Z

Blender and Game Maker

So I got a GM bug again.

GM is quite fun to toy with, but WOW it can't do motion or collisions AT ALL. Anyways.
I have techniques to make it work, so I'm cool.

Also, I was thinking about it, and since GM can draw primitives like triangle strips, I figured I could make it load 3D or 2D Odin Sphere style models

So I did.

(cue more stupid goofy lizards monsters, but in 2D!)

Turns out, it works fantastically well, and, since I do all the sprite and modeling in Blender, I can reuse the work for just about anything. Plus, it's really easy and super fast to make animations in this setup. Unfortunately, Blender has a real problem that I'm going to complain about for along time. (Why the FUCK did they put a KEYFRAME ACTION editor when the fucking keyframes are stuck on the GLOBAL timeline?!? REGULAR actions are LOCAL timelines, so logically, KEYFRAME ACTIONS should FUCKING be on the FUCKING local TIMELINE!! GOD FUCKING DAMMNIT! ARRGHGH!!!!111!1!111!!)

But! It does work, and it looks way better than sprites when animated. I'll be fooling with this as a break, until I get more discrete space things to work.

If you like this idea, go try it out yourself, or IM me and I'll throw you the python script exporter I wrote for Blender. It's pretty nice to have.

-Z