A setback, and starting with new things...

So I spent most of last week working out some way to effectively change the resolution of FFVI without having to quit and restart. You see the issue is that with the Irrlicht Engine, you cannot dynamically change the resolution and everything will be fine. You have to actually properly shut down the IrrlichtDevice and create a new one with a different resolution setting.

I spent about 3 or 4 days working some code in to make sure everything that needed to know the device was going to change, knew.. but it started getting to the point where I was writing a hack to make a hack work so it would hack another hack into making the whole thing work. Not even close to clean. I can deal with some hacks, as they tend to be temporary, but this was just getting rediculous, and I knew some of them just couldn't possibly be temporary.

So I scrapped everything I had done in that direction and looked at it from a different perspective after taking a small break. In a matter of 2 nights, I wrote up a new means thru which to not only effectively, but CLEANLY do what I wanted to, and I proceeded to work out all the memory leaks, and all now looks well^^ I'm quite happy with how my code turned out.

After that, I went thru my to-do list, cleaning up a buncha stuff that got dirty while I was doing all this, and got back down to the major points on the list again. The 2 things that really stuck out was to go back thru my code and fix everything that I had left notes to myself to fix, and to implement a means thru which the various menu items could actually DO something. (Technically, the latter is a member of the former, but ah well...) This menu item action thing is actually the last piece I need to implement to have 100% of my previous code working again, but it's actually going to take a bit before I get them working again, as I'm going to do it properly this time.

And the new thing! I am now writing a virtual machine to execute external scripts. These scripts will be specific to FFVI3D, but will be easy enough to figure out. They'll likely be in a similar style to BASIC, but I might go so far as to make them feel more like C/++.. Not that any of this will matter to the player, but it'll be a LOT easier for when I get around to putting some events/ingame cutscenes/etc.. in. I'll also be using scripts to define what each menu item will do when selected. But I really haven't gotten far into this yet, so I'll update later on it.

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