Second (late night) entry for the Riley Texture Manager.

BOOYAH! The viewer portion of this application is now almost fully operational. You can now select multiple files, and the viewer animates them at 10 frames per second. If you choose a lot of files, there's a brief delay in the animation starting up as it loads, but that's expected. The only funky thing I need to fix is that the display incorrectly resizes itself when the user resizes the window; and I want to change the label above the display area to show the current filename. I also need to confirm that it functions properly when tasking in & out of a full-screen game.

This means I've pretty much knocked off two of the four tasks remaining, as listed in the previous entry. I think for the moment, I'm going to skip ahead and start on the batch conversion stuff. There are four different "modes" I'll be going for: static overlays, animated overlays, backdrops, and general textures. I'm hoping that with this one big thing solved, development will pick up the pace a little...

Eighth entry for the Riley AA-Prop Maker application; first entry specifically for the Riley Texture Manager.

The viewer aspect of the Texture Manager is now partially operational. In the above screenshot, I resized the window down as small as possible (so it would fit on this site). Currently, it supports DDS, BMP, TGA, JPG, and PNG formats -- all of which are directly supported by Direct3D. I plan on supporting several other file formats, but until I have them working I'll keep them a secret. ;) I also plan on detecting whether an image is part of an animated sequence, and automatically running the animation as though it were an overlay sequence.

Images larger than the viewing area will always be scaled down for a best fit. Smaller images retain their original size (ie. I don't scale an image larger than its actual size). For transparent images, I am currently displaying them against a blue screen background. I plan to add a "View" menu, with choices for Blue Screen, Green Screen, purple (for those used to the Windows Texture Viewer), and black.

Both Windows and DirectX gave me a bit of a surprise while getting the viewer to work. When responding to the user resizing the window, Direct3D requires you to completely reset the device (for reasons I won't go into here). This process takes a good second or so, and as such I didn't want to continuously perform the reset as the user is resizing. I thought I'd be able to use the SetTimer Windows function, with the intention that after a brief delay the screen would repaint itself. Read the fine print in the documentation, however, and you'll discover this function isn't particularly useful. Windows apparently considers such timers to be "low priority", meaning they only run the event you attach to them when nothing else important is going on. In practice, I found it was only running the event after I minimized the window, which for my purpose made it totally worthless. I ended up just setting a flag indicating the device was invalid, and running the reset the next time the mouse moved over the window. :p

Going forward, my plan is:

1. Clean up some things related to the viewer, and ensure I'm properly handling "lost" Direct3D devices (which will occur, for example, when you task into a full-screen application that uses DirectX as well -- such as, say, The Movies ;) ).
2. Look into using the Windows CreateTimerQueue functions to get animated image sequences to run (since SetTimer is apparently useless :p ).
3. Look into the additional image file formats I'd like to support. There is a wonderful open-source library called ImageMagick that I hope to use for this purpose.
4. And finally, get the batch conversion to DDS stuff working!

As fans of The Movies are aware, The Movies Online suffered a crash of some sort and is currently The Movies Offline. The only official word thus far is "our technicians are still working on it trying to recover the pieces!" Let's all hope they are serious about ensuring TMO continues -- even if we have to start with a clean slate (ie. re-upload the movies we want online).

In other news, my application development is coming along. I will continue its development no matter what happens with TMO. I've invested far too much effort in modding the past year, and haven't even completed things to a point that I can really get going on my Public Transit film. That film (and all the modding applications I need to produce it) will get done, even if the only people who see it are friends and family.

As mentioned in a prior entry, I will be releasing a Texture Manager application first. This will be used primarily to view and batch convert image files to DDS, with automatic resizing for overlays and backdrops. I've got bits of the application window put together, and have managed to overcome pretty well all the major Windows-related hurdles. I hope to have screenshots up soon, and should be able to get it out to a few select folks for beta-testing before the end of the month.

Seventh entry for the Riley AA-Prop Maker application.

With summer weather admittedly getting in the way, I have managed to find some scraps of time to work on this. ;) This is more of a babbling "yeah, I'm on it" post than anything else...

Most of what I've done the past few days has involved organizing my code into modules I'll be able to re-use for all my planned Windows applications. I've got a R3TMAppWindow class, which acts as a base class for the main application window. It does the dirty work of creating the application window, so that I won't have to worry about it for every application. It also includes initializing and saving out an INI file that will store application settings, including the last position and size of the main window. That way, the application can restore the window to the same location on the screen each time it's launched, and retain any other settings of its choosing.

I also went out on a hunt for all the icons I want to display in my applications. It turns out Windows stores alot of its system icons in shell32.dll. Rather than recreate icons for folders, "My Documents", "My Computer", drives, etc. I have my application set up to just extract them from there. The nice thing about doing it this way: it retains the same look as the user's current operating system (meaning Vista folks will get the Vista icons).

And here's a bit of an oddity I only realized the other day. Starting with Windows 2000, the access keys for menu items are only underlined once you press the ALT key. I only noticed it because, after attaching the menu to my application window, I noticed the underlining was missing. Some applications bypass this and manually draw in the underlining. You can change this setting in Windows XP by going to Control Panel -> Display -> Appearance -> Effects. According to what I've read, the option is in a completely different place in Vista. My question is: Why? Why not always underline the access key? Was Microsoft actually getting complaints about this?

Sixth entry for the Riley AA-Prop Maker application.

Windows programming can be brutal. Believe it or not, MS Windows first made its debut 23 years ago -- in 1985. A time when Pascal and C were the two main programming languages "fighting for dominance." Remnants of Pascal are still scattered throughout Windows, as evidenced by the Windows callback procedures (aka message handlers).

I did do some Windows programming many years ago. But it's not quite like riding a bicycle -- you remember it, sure, but you can't just pick it right back up again after many years of absence. I definitely had a few hair-pulling moments this evening. :p

But I've managed to pass the first hurdle. I've got a good grip on it again, and got a "splash screen" implemented -- something I know I'll be using for those first few seconds when these applications are initializing. I also have the basic screen layout figured out for the Texture Manager application I mentioned in a previous blog post. The next hurdle will be getting the menu attached, and implementing the controls that will let users navigate the file system (and The Movies content).

I'll be taking a few days break from it, as I have some voice-overs to do, and some props to make, for a few different folks. Back to it again on the weekend...

Fifth entry for the Riley AA-Prop Maker application.

More changes to the content registry. All of my command-line applications to date only ever needed to search for one file at a time. Entering the world of GUI applications, I now want to give the user the ability to search for files. After running some test cases, I realized some deficiencies in the way the content registry is running its searches.

Upon initialization, I was creating a giant sorted list of all filenames found in all PAK files. This works well if you know the filename, or at least what the filename starts with, as it uses a binary search. With about 65,000 files to search through, a binary search only needs about 16 comparisons to come up with the first match. But what if you're searching for *.msh or *.dds or even *wall*.dds? Suddenly you need to run through every one of those 65,000 files to find matches. Upon running an appropriate search, I found it was taking a good 10 seconds -- an amount I'd like to shave down.

So I put more time and thought into how I could reduce typical searches. The key comes in knowing that, most of the time, you're looking for files in a specific folder. If you're looking for *.dds, you look in \data\textures\ (and possibly its sub-folders as well). There are about 25,000 texture files in all sub-folders, so we can immediately narrow the search by a good 62%. If we only look in one particular folder at a time, the savings is even higher.

To accomplish this, I've reorganized the internal storage for the PAK portion of the content registry. There is now a sorted list of directory entries, each containing a sorted list of files. The directory entries are also placed into a hash table -- this is primarily done to assist the initialization process (it acts as an automatic way of resolving unique directory entries across multiple PAK files), but I keep the hash table active as it also adds that extra tiny speed gain for searches (though likely only in the order of milliseconds). An additional benefit to this new storage strategy is that it gives applications a way of examining the available directories.

These changes have now been implemented and fully tested. The test searches are running much quicker now. And perhaps the best news: I am now ready to start tackling the Windows GUI stuff!