Beginnings of real profiling, and small additions

So I've almost completed all of the little bits and pieces of my rewriting of my old code, and I've actually added some considerable amounts of other new stuff also while I've been going.

One recent addition was an optionSurveyor abstract class, so now I can have any class derive from it, and register themselves with the optionManager to receive news of changes in specific options. Very useful-- this'll allow me to make sure that as soon as any option is changed, all of the appropriate places will be informed so they can act accordingly- and if they're not, it'll be easy to make it so they are.

In doing that, I've started adding more support for actually CHANGING options dynamically while the game is running, such as resolution and whatnot. Virtually all of my currently used options can be changed runtime now and everything will restructure itself to accomodate the new options, but in setting up things to work with a resolution change (by far the most complicated option to change, since I need to completely remove the engine device and recreate it, losing a good portion of my dynamic data in the process...) I've noticed that I've got something that I'm questioning as whether it's a memory leak or not. "Memory fluctuations," I'll call it.

So I've now dug out a highly recommended profiling tool called AQTime 5 that so far I am [b]very[/b] impressed by. And it's promising much more than I could possibly ask for. With a price tag of only 5 or 6 hundred dollars, I'll have to give some serious consideration to purchasing it. Or a PS3. *shrug* But for now, I'm enjoying all 2 days of the demo that I've experienced so far.

I've been using it fairly extensively (after reading the boatloads of documentation required just to get STARTED with it!) to find many leaks in my code that I didn't even have a clue existed. I hadn't noticed them because they weren't continuous leaks, but rather gradual. A small leak in an initialisation routine here, one over there, etc... As opposed to something that's puking out 3mb of ram every 2 seconds, which I'm happy to say, I've caught all of so far.

With the help of this profiler, and having to patch up various small leaks, it's also forced me to structure some of my code in a better way to allow for some future code that I'm planning on as well, which is good. I think AQTime 5 and I could become pretty good friends. *sagenod*

Since I'm not even going to look back at all at my old GUI code, I can't get any hard numbers for you, but I know for a fact that now that it's about 98% recoded, I'm quite confident that it'll run significantly faster, cleaner, and more readably (I know, the last one only affects me..) than ever before.

I've also gone so far as to download the DirectX SDK and recompiled Irrlicht with symbols to help with my debugging, as well as allowing me to compile it without certain features that I never intend to use, allowing it to be significantly smaller, which is good. I won't know for sure how much smaller I can get it until I've virtually finished the game engine, but I suspect pretty small, as there's a lot of stuff in there that I don't necessarily need ^^v

GUI Rewrite

So I've all but completed my re-write of the GUI system in FFVI3D. I completely reworked how drawing was being handled by the different gui elements, and made the gui skin class act more like it should. Now the gui skin class actually has drawing functions for the fundamental ("primitive" if you will...) drawing aspects of the gui elements, and each element calls the ones it needs.

Additionally, the rectangles for the gui elements used to get recalculated every frame, but since the gui elements in FFVI3D will never change shape dynamically, there's no reason to do that, so I have them calculate them once when they're created. If at some point, I decide to allow them to be changing shape/position dynamically, it won't be hard to implement functions that will recalculate the rectangles at only that time, instead of EVERY frame, which is just wasting CPU cycles.

I completely re-wrote the XML loading algorithm to be not only more effecient, but to work in a cleaner, more appropriate manner, there were some gui elements that I used to stuff with some read-in values, and "init'd" them later, once all of the other elements were loaded (such as the direction map for selecting another gui element via keyboard/mouse wheel), but now I've come up with a way to allow me to link them together linearly so there's no need to "pre-init & init" them anymore. Cleans up the code a lot, and I'm a LOT happier with how it fits together now.

I've also gone thru and replaced all of the gui elements' texture references to instead be pointing at my custom animated texture class instead, meaning that EVERYTHING on the gui can now be animated, including the mouse cursor. For comparison, the only thing that used to be animated was an "overlay" object, which could be anything really, but at the point I had gotten to, that only applied to a flashing "selection bubble" overlaying the currently selected menu item.

Speaking of which, I reworked the animated texture class, so that when you're requesting the current texture, it no longer iterates thru a loop of mathematical calculations, but instead does some simple division/modulo calculations on 1 or 2 lines, once only. Also, no calculations are done at ALL if the animated texture doesn't contain any frames, or only contains 1 frame. Lots of fun little optimizations like that, I've been putting in as I go thru all of my code and rework it. I can really see this already running a lot better on the PSP than it did.

I also started implementing reference counting on my non-Irrlicht classes, using the Irrlicht reference counter class. Nothing major, but it makes for code that's easier to maintain.

Look forward to the last of the GUI reworking, and then various other small things that I haven't gotten around to re-enabling yet... After that, I really don't see much left for the rewriting- so I'll be looking forward to working on new features soon!

Re-arranging and getting caught up

So I've almost completed my reworking of the FFVI3D game engine up until the point I had it before I went on my break. I've just gotten to the point of working on the GUI, which means that almost ALL of the rest of the framework is already in place-- and then it's just a matter of trudging thru all the different GUI elements' code to make each one work.

I've been moving various functions around to their various PROPER places, to tidy up my existing classes, as well as to more accurately have each class doing what it's supposed to do. I used to have a series of classes I called "managers", but have come to the conclusion that they're actually more like 2 different series of classes- one of which is still the "managers", but the other is more like... "sub-managers" or some such. So I'm pulling out the whips and chains to put them down where they belong- back in the dark recesses where you won't see them, but rather their results.

I'm going to be completely reworking how the GUI layouts are stored in memory as well, to not only save memory, but also to allow (theoretically) for more layouts to be loaded at the same time. I had been thinking about doing this while I was coding it, but I just kept putting it off, and now is the perfect time to do so, since I'm reworking everything anyways.

Once I've caught up with reworking my code again, I'm going to make this a lot more serious and technical, as I discuss in more detail about what I'm doing, but in the meantime, it's just general updates on what's happening. Also at that point, I'll be using Labels for the posts to make it easier to find specific updates.