Leadwerks Editor on Linux
Things have gone so remarkably smoothly so far in the process of building Leadwerks Linux, that it makes sense we would encounter some issues sooner or later. In this update I will talk about some of the challenges recently encountered.
I was able to get GDB to debug an application built with the Leadwerks static library, in this case our editor. It took me a while to realize you have to hit "continue" once or twice when the application starts, because GDB pauses the program when it connects. This is a bizarre design choice that lead to lost hours of productivity. GDB itself is not a complete debugger; it shows variables only in the top-most function in the call stack, and does not allow you to examine other functions without manually adding "watches" for specific variables. When you don't know exactly what you're looking for, this is an onerous task. Limitations like this may be the reason Valve is working on a debugger for LLVM. I will be sure to ask about this when I attend Steam Dev Days in January, although I do not expect it to be ready soon enough for us to use. In the meantime, the limitations of GDB are annoying, but I can deal with it. It's very nice to be able to run and debug our editor on Linux.
I have been able to get the Leadwerks editor running in just a couple of days, which is fantastic. It looks great, although some Windows-themed icons need to be replaced, and some of the widget sizes are a little off. Functionality is sort of hit and miss at this point; for some reason menu and viewport events aren't registering, and there is lots of broken functionality. However, all the problems have to do with the UI rather than the underlying application. A lot of it is simply because I have a preprocessor definition for Windows, a different one for Mac, and nothing declared yet for Linux. In most cases, either the Mac or Windows default is appropriate. For example, our application menu switches depending on which window is active, whereas on Windows each window just has its own menu. This is mostly a matter of "test and discover" rather than writing new code and I will continue working to make it 100% functional.
Native Look and Feel
I greatly prefer the native look and feel GTK gives us, rather than using our own "home made" GUI. Leadwerks for Linux looks like a Linux application, so you know how to use it right away. There's no learning curve for special widgets and controls, because it just uses the standard UI you're already used to. This gives a consistent appearance that makes the editor feel like it's at home in Linux. Especially after I replace those Windows-centric icons. ;)
Revenge of the Drivers
I wanted to switch my main dev machine back to an Nvidia card to do some testing. (I started with an Nvidia card, installed proprietary drivers, and switched to an ATI card with no issues.) Unfortunately, the reverse does not seem possible. I uninstalled the ATI proprietary driver, got some message about "jockey". I swapped in the Nvidia card, and I can only get a black screen with an unresponsive cursor. I put the ATI card back in, and it's using the open-source default driver, and the "Additional Drivers" dialog doesn't detect any available drivers. I ran some other stuff in the terminal I found online, but nothing worked. Typically I have found once I get to the point of entering random terminal commands I find from Google, it's over anyways, and the only thing to do is reinstall the OS.
The lesson here is that you really can't swap out GPUs once you install your drivers. (I'm sure there's a way to by someone who is a driver expert, but it's beyond me and the average smart person.) As things stand now, Linux is great for pre-configured hardware (Steam Machines, anyone?), but the driver uninstallation process should be cleaned up in order to meet the needs of PC gamers. I will likely end up running three installations of Ubuntu side by side, one for each graphics vendor.
While we're talking about PC gamers coming to Linux, there is one serious problem that I think is going to hurt a lot of people. To put it simply, installing a dual-boot system is not a solved problem. I recently had one user who wanted to try out Ubuntu, so he made a dual-boot install and it made his Windows driver unbootable. My approach has been to remove all other drivers, install Linux on its own physical hard driver, then replace the other drive and use BIOS to switch back and forth between boot drives. I also considered a physical switch mounted in one of the 5.25" bays, which is kind of cool but I worry about the implications of switching power to different components, and whether they are properly grounded. By bypassing the GRUB boot loader, there is absolutely zero opportunity for operating systems to interfere with one another, and I can easily reinstall an OS when needed.
At this stage of development, I feel like we've knocked out all the risks and challenges I identified at the beginning of this campaign. Let's look back at what I said about Linux graphics drivers in the original campaign description:
"We expect to encounter some graphics driver bugs. This is always the case when you are pushing advanced graphics. Fortunately, we have good relationships with the major graphics hardware vendors, and have been able to get driver bugs fixed on other platforms in the past. Valve Software has done some of the heavy lifting for us here, by prompting the graphics hardware vendors to get their drivers in good shape."
It turns out these worries were unwarranted, as the drivers I have tested work flawlessly on Linux.
Although there are lots of little issues with our GTK UI at this stage, it's debuggable and basically working. So I'm confident the fundamental things we need to complete this are there.
In conclusion, we've been through the difficult parts of porting a complex application to Linux. Although some annoyances and limitations have been discovered, overall I have found Linux to be a completely viable platform for application development.