Recently
(07/18/02-Day 10)
The new file format is really working out well. I'm going to implement some visibility culling soon to see how well it runs.
I tried implementing VAR (speedup for GeForce cards) today. In the Screenshots section you can see what my early attempt looked like (hey, it's hard to troubleshoot an extension for a card you don't have through your friend...) but I got it working 98% (as in there's a few graphical glitches to iron out still). It's slower than CVA's however, because I've never implemented VAR and I'm not quite sure how to do the fencing. I'll work on that tomorrow, or maybe hold it off 'til I can borrow an nVidia card.
As you can see, a full 256x256 is being rendered at 15fps at 800x600x32 on a GeForce2MX. That's actually about right for a GeForce2MX w/o VAR done right. I'm going to have a friend bench it on a full GeForce2 GTS later, I'm expecting ~30fps.
Visibility culling will obviously be a large boost.
Well that's all for now, possibly for today.


(07/17/02-Day 9)
Yesterday, I also implemented the automatic extension-checking-and-loading system. It's working smoothly.
Today, I got my butt off the ground and drafted version .1 of the format. Currently it half-supports unlimited textures (read: 4.5 billion), and technically supports chunked terrain data and octrees, except that I haven't yet implemented culling for these or even implemented them in the heightmap conversion tool I made (which is a pain in the butt). This file format will change over time but it's a first step and that's what's important.
I also heard that Cube can have seperate index things similar to glDrawElements(), which will greatly speed up rendering on the Cube (Nintendo GameCube that is), but for PC's OpenGL, glDrawElements() is out for certain types of terrain - a major speed improvement is lost for this type of terrain :-(.
I'm wondering whether or not it's possible to make the Cube a shared-project anymore, or if I'll have to start some new code for the Cube. I hope I can make it shared. That'd be much easier.
I'm going to add full renderer support for visibility determination vs. frustum using AABBs (axis-aligned bounding boxes) before I make a conversion utility that will actually work with them.

(07/16/02)
I put in some renderer instances based "global" texture management that now dynamically handles textures instead of loading them into an array in a pre-specified order as was done before. Texturemanagement is now fine until I get into dynamic texture-related things (i.e. dynamic terrain loading).
May do more later.

(07/15/02)
Work has resumed. Today I sat down and made some siginificant improvements to the internal code structure. It can now be considered a "game-ready" engine, instead of a dirty test renderer.
There's lots to be done of course, though. I almost sat down and re-wrote from scratch, but then realized it would be less work to convert all the current code over to the structure I want. That structure is a very plugin-like structure, where there are different types of things being rendered that are managed as much as possible by themselves rather than by the user.
Tomorrow I hope to work on texture management, and possibly turn many things into classes.

(07/13/02?)
Project has been on hold while I talk to the person who I started coding this for.
I'll probably resume work within 3 days.
I'm happy with it so far, though. It looks great and is getting quite speedy. Right now it's a formidable terrain renderer in my view. Within a week it could be a top-quality one, with even bigger draw distances and overhangs and dynamic loading.