[72] No talk of the Peninsula Nation

The general thought process this week has gone more of less something like this:

1. How do I put textured 3D models on-screen?

2. How do I structure the API and structs and unions and whatnot to satisfy all of the capabilities and information necessary or desired for this?

3. How do I best store 3D model info in the first place?

4. What storage method is both easy for C to parse, yet polymorphic enough to hold each and every basic data type AND their array counterpart?

5. Oh, and the parser needs to be able to load every material library that a given 3D model uses, so I'll need to at least jury rig some sort of way to store arrays of strings...

And probably some other minor stuff I'm forgetting/don't care enough to write.

At this point I've solved problems 3-5 and a bit of 2.

About 3-5. I call my new format for formats "Block-Tag System/Storage" (leave any jokes about its abbreviation at the doorstep, please).

Here is what a BTS file looks like when viewed in a hex editor.

This particular file is the equivalent of a .mtl, but it's smaller in size and, as designed, far easier to parse in C than an actual .mtl.

Now, here is that same file, but I wrote it out in a more human-readable form:

(All of the info is displayed in exactly the same order as it appears in the actual file.)

And here's the python code that converts a .obj and it's required .mtl(s) into .ttm and .ttl(s) respectively (huge composited image ahead):

And here's that "bit of 2" I was talking about earlier (another huge composited image):

As an aside to finish this off, I found a way to forcefully keep a certain resolution for all rendering, including RenderGeometry(). It just involves rendering to a texture of a fixed size (instead of directly to the window), before drawing that texture to the window.

Using this method, I can take something like this image (a good test image for many situations)...

...

... and render to something like a 32x32 texture, before stretching and copying its contents to the screen (I was also testing gradients here, which is why the bottom fades to black).

(Also, this was only one call to RenderGeometry, which is why this is only showing half the image.)

The window doesn't even need to be in the same aspect ratio, as RenderCopy can just arbitrarily stretch the source texture to its destination!

So yep, that's it.