The filebrowser is now at a state where it can actually be used. Instead of making the text area completely scrollable, I instead made it scrollable only as you type. With that working, it's enough to be usable at least. You can't move the cursor within text that already exists. While that's slightly unfortunate and a little annoying, it will be enough to make the browser work between now and when I add in that functionality. With the scrolling in place I added some simple hooks to catch when the user presses enter in the text area.

With all of the above in place, and the work from yesterday, the browser is now in a "happy" state. If you select or type your way to anything that isn't a directory it is assumed that what you want to do is overwrite said file path. For now I'm going to leave it to the caller/user of the filebrowser to perform any double checks with the user that this is, indeed, the action they want to take.

While the browser isn't the prettiest thing around, it's all I need to replace what Allegro had given me, and what is currently missing from Neverfall. Once I can inject this into the game things will be back on track after so long of an intermission. I can't wait! Inserting the new filebrowser into Neverfall won't be so plug and play, though. The Allegro broswer blocked, while mine does not. There's going to need to be some logic changes to handle the fact that you must manually poll my file browser. In any case, here's what it looks like in action (top left):

Alright, it's been a long while. Sadly, I never did look at doing the GUI file browser stuff natively for each os. Instead, I came upon the realization that there were some major bugs in the GUI stuff I had already written. For a long while I was getting errors when freeing my memory, being accused of mucking around with memory after freeing it! That wasn't the actual case. The real problem was a buffer overflow issue. I made the very bad assumption that strdup would duplicate a string and the entire amount of memory allocated to it. That was a very bad assumption, and I'm not even sure why I made it. Of course strdup only creates a buffer large enough to copy a string up to the EOL delimiter. If that happens to be shorter than the original string's buffer length, too bad--you get a smaller buffer. The real problem came later, when I was attempting to cat two strings together, and passing the buffer limit length as the total size that could be copied. See where this was going? I was strncat'ing into the strdup'ed string with a buffer size that could be much to large. It took a while to finally dig this bug out, but it's finally squashed. Finally! I have been on the case of this particular nasty bug for over a week.

Now that it's gone I can freely traverse directory structures without a problem. The next step is to do "something special" when you hit a file and double click it (that is, select it). Once that is all set, the last step is to link the editable text area so that when you press enter after typing in a filename, it will create that file if it doesn't exist. I'll also have to take into account that if you type a directory name, you should traverse to that directory, instead of trying to save a file as a directory name.

Making the text area work properly (as one would expect, with scrolling text if it does not fit in the editable area) is going to be a bit of a pain. Making the interaction in the file browser work correctly shouldn't be so much of an issue. It's the scrolling of the text that's going to cause all sorts of problems.

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!