Leadwerks Editor in Linux
Entry posted by Josh ·
2,713 views
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.
GDB
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. So the limitations of GDB are annoying, but I can deal with it. It's great to have the editor running and debuggable on Linux!GTK
I have been able to get the Leadwerks editor sort of kind of working 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.
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. With this approach, there is absolutely zero opportunity for operating systems to interfere with one another, and I can easily reinstall an OS when needed.
Challenges Met
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:It turns out these worries were unwarranted, as the drivers I have tested work flawlessly on Linux. (I'm presently talking to the Mesa developers about their upcoming drivers for Intel HD graphics.)"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."
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.
-
2
0 Comments
Recommended Comments
There are no comments to display.