It turns out that the PPC build was failing because none of the source files were being compiled for the library. Ironically, if you don't set a target platform to build for, Xcode still runs through its business and does everything else that it can, or rather is told to, do. Once I squared that away, everything built fine. There's a bit of an issue with loading textures and endianness, which I wasn't prepared for. I thought the code I was utilizing for converting an SDL surface to an OpenGL texture was handling this, but apparently not. It's simply a matter of flipping a flag from one ordering to another when performing the texture generation, so it shouldn't be that much of a big deal. On the same front of getting the library building in new platforms I started a Linux effort, but that has only progressed as far as getting SDL, OpenGL, and a few other libraries set up.

On the flipside, the listbox has been modified so it can contain more items than are visible when drawn. You can now scroll to view the contents of the listbox that aren't visible by default. There is no indication that there are more (or not) items to view. Additionally, it doesn't make use of scrollbars. Instead it simply keys off of using the scrollwheel of the mouse to scroll up or down. While this is fairly limited, it's enough to build a usable listbox that can be made more functional later.

With the listbox mostly squared away the next step was to throw together a basic text entry UI element. An incredibly basic version is currently complete. It doesn't offer scrolling the text in a limited view. Instead, it simply displays the entire string contents always. If anything, I'd like to solve this issue over all of the others, but it's still usable in this state. As with the rest of the UI elements, it's very basic in looks. One interesting aspect to FTGL is that text in my engine is rendered from the top, as opposed to the bottom. This means that while you're typing text into the field, if a larger letter comes into view, all of the text shifts downwards. What I need to do is some basic calculations to always keep the text centered in the text entry boundary area. Trivial, but also unnecessary to get the basic functionality working.

With all of these components in a working or semi-working state, I am finally able to build the beginnings of a file browser. So far the browser can dig down into directory structures, as well as climb out of them. Actual file selection or choosing does not work. Right now, everything is considered a directory, so even plain files are attempted to be loaded and read as directories. While working on the guts of the file browsing code I had an interesting idea. What if I simply used OS-specific file browsers instead of rolling my own? Sure, it's a silly question to ask after I already spent so much time working on a minimalistic GUI set to achieve the same goal, but... it would simplify things so much!

I have experience using the Cocoa file browser. I have never used it straight through Carbon or the C interface. If it comes down to it, I'd be able to do some wrapping that would use Objective-C to perform the same task. If it's easy enough to pop open a file browser in Win32 that blocks the execution of the game and simply returns the string path to the selected file, then I am definitely going to pursue this method of doing file selection and browsing. Code and file structure is already in place in anticipation of situations just like these. If it's necessary to make a few little OS specific functions of modules, it shouldn't be difficult to throw into the build process.

I decided it's best to put down my current GUI stuff for now, and research just how difficult it would be to pull off native file browsers. Hopefully it's relatively easy.