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.

I needed a break from working on mundane GUI stuff and in doing so I decided it was time to check out whether I could get all of this stuff building on my Powerbook (PPC). Most of the effort was fairly straightforward. Everything is building fine in terms of SDL, OpenGL, and my own wrapper library. Unfortunately, when I try to link with my framework everything falls apart. I'm still investigating as to why the system simply things the framework doesn't exist when it is, in fact, in the location I say it is. Very strange, but it could be some sort of compatability issue regarding using newer Xcode project files on a really old version of Xcode. The first step in fixing this problem is to get my developer tools up to date. Once that's done, hopefully the issue will simply resolve itself.

I have been slowly working on a very basic, plain GUI system that I can use to create a basic file browser for use in Neverfall's editor. I'd eventually like to make it skinnable, but right now the main goal is to have the most absolute bare-bones version of a file browser there can possibly be. So far I have generic buttons and listbox UI objects working. The listbox is a bit limited in that it cannot be scrolled, but that is scheduled to change soon enough. Below is a screenshot of a test application I've been using to tinker around with and tweak with these UI elements.



From what I can see, the absolute bare minimum I need to get a working file browser is buttons, a scrollable listbox, and a text entry field. Using those three UI elements together, I could probably create a makeshift browser that will allow me to continue the porting effort on Neverfall.

There was an issue with the downloadable code for Lesson 6 of the Allegro tutorials. The .zip archive has been updated to contain a proper working version of the code. Thanks to Jonathan for submitting the report!

I've been working hard on the port and discovered a whole bunch of stuff that was missing and/or broken from my library. Of note, the one I thought was a little funny was the drawing of primitive shapes. This is something very easy to perform using OpenGL, but for some reason I completely glossed over adding wrappers for it. Another mentionable item from the "broken things" list was my logic timing routines. While looking at the port running some graphical stuff, I noticed consistent and frequent stutters. This is different from shearing! Every handful of logic cycles that would pass, extra logic cycles would be executed and create a visible stutter. This should be the normal behavior when so much drawing is going on that the logic cannot keep up. Unfortunately, while I was observing it, there wasn't that much drawing going on at all. After taking some time to look at how I was calculating the logical loop timing I realized I was going about it all wrong. I took some time to think about how I really wanted it to work, and now it's much simpler. You tell the engine that you want your logic loop to execute X number of times in a second. Given that single number, it will try its best to run exactly that many logic loops in a given second. If things get clogged up a bit, the engine should run multiple logic loops in a row to keep up and prevent logic slowdown. This logic slowdown prevention has the side-affect of creating dips in framerate. I find this acceptable, though, instead of trying to keep a steady framerate and losing game logic accuracy. So far, in my testing, the game is able to execute without any problems or slowdown.

That brings us to the porting efforts in Neverfall. Behold:

This is a screenshot of the Neverfall engine running using my custom SDL-wrapper library instead of Allegro. Awesome! The editor is almost fully functional except for the saving and loading of maps, settings map links, saving object lists, and a few other minor details. So far, it's smooth as butter -- even when displaying one of the maps that would cause tremendous shearing in the previous library setup. While a lot of the functionality exists and works in the port, there's still a very long way to go. For one, most of the title and option screens will have to go and be completely reworked. Their main structure will be fine, but some of the effects are going to need to be changed.

The biggest obstacle that I'm going to need to tackle is file save/load as well as a file browser replacement. Allegro has a nifty built in, albeit ugly, file browser. It gets the job done, especially for things like editors that players will hardly (if ever) use. This sort of thing doesn't exist in SDL. There may be a library that does it, but as far as I have seen there isn't one. Hopefully I'm wrong. I'll probably end up writing a minimalistic version of a file browser that is much more feature limited than the one provided with Allegro. This is something that would be nice to have (and have working properly), but it's very low priority compared to getting Neverfall back up and running.

It's a slow, but steady process. Neverfall is finally almost getting to the stage it was in previously, except shear-free.