Share this project


Share this project

We want to put 3D game development on Linux, so you can build and play games without leaving the Linux operating system.
787 backers pledged $42,358 to help bring this project to life.

Leadwerks Editor on Linux

Posted by Josh Klint (Creator)

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.

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 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.

Lee Zher Huei, Martin Kozub, and 8 more people like this update.


Only backers can post comments. Log In
    1. Missing avatar

      Alvaro F. Celis on

      I forgot, in case you are dual-booting the 2 OS's on a single drive and you want to remove the Linux partition and regain the empty space for Windows there's an application called EasyBCD that helps you doing the task and rebuilds your Windows MBR nice and easy, there's a videotut here:…

    2. Missing avatar

      Alvaro F. Celis on

      Interesting progress Josh. The approach of using separate drives for different OS's seems like a life-saver (at first) but once you get Kernel updates on your Linux distro it will re-write your Grub and generate a dual-boot screen (happened to me). However, this new grub will be written on the Linux drive and the windows boot info (and its MBR) will remain intact, so given the case you can still use the bios to boot straight from the Windows drive, or if you need to reinstall linux you can unplug your windows drive and format/install Linux without any worries of "contaminating" your windows drive with harmful boot info.

    3. Missing avatar

      Morten Haggren on

      The only time I've had any issues was with when I did manual partitioning and decided to try GPT in place of MBR - this caused windows to not recognize the disc halfway through the boot.

      ymmv ofc, but if all else fails maybe your local LUG is still throwing install fests?

    4. Josh Klint 2-time creator on

      I actually had to write makefiles for Android, and I auto-generated my own with the little language/compiler I made myself.

      Thanks for the input guys, I will definitely check out Valgrind.

    5. Francis Bolduc on

      It's true that if your programming experience has always been done in an IDE, the idea of having a separate program for text editing and debugging is hard to comprehend.

      It may even shock you that the opposite is also true. I'm not alone in saying that I'd rather not work in an IDE, if given the choice. I don't want to depend on IDE project management; they're usually platform-dependent and always inferior to stand-alone build systems.

      But then, I'm one of those persons who actually care about how (and why) things work. That being said, I also realize that there are other types of programmer who have very successful careers without ever knowing that there is a compiler and a linker that do the work behind the scenes.

      It's very hard to find a middle ground for those two types of people. For none of them will want to compromise, and for good reasons. Why should one or the other be less productive?

      In the case of GDB, somebody coming from an IDE background cannot realize how powerful it is, because the learning curve is so steep, and that's a shame. But for those who've been using it for years, they cannot work without it. For them, an IDE feels like a toy, not a tool.

      If you're willing to spend some time, I'd say that putting some effort in using GDB will be very rewarding. But if all you want is a Microsoft Visual Studio or Eclipse replacement, then you'd better abandon right now. Some will get close, but you'll never be satisfied.

      Sure, you can pin your hopes that one project or the other will get there eventually. But why not try the other workflow? It's certainly better than constantly being dissatisfied with inferior copies of your preferred IDE.

    6. Igal Alkon on

      Josh, I also was Code::Blocks user, but I found QtCreator much better for my current C++ usage. it also integrates with valgrind, that analysis tool mentioned by Anton. about GDB, I think it might be more of an issue of how Code::Blocks integrates with it.

      There's also this tool:

    7. Missing avatar

      Vadim Peretokin on

      GDB is not associated with Code::Blocks. Code::Blocks has added support for GDB; extent of that support relies fully upon them.

      Nemiver is a pretty good GDB stand-alone UI. GDB people themselves don't concern with a UI, that is true - they concern with making their debugger work well and be integratable into other software. Qt Creator, Nemiver and even Visual Studio ( integrate GDB into themselves.

    8. Missing avatar

      Sascha on

      ohh i made it into your post.

      @ Herik Danielsson. Yes i solved it but not like i expected it.

      I really think the main problem was because the installation of Linux saved the bootloader on all installed harddrives. And for some reason windows didn't even wanted to save its own bootloader again on one drive. No repair, no reinstall nothing worked. I could finaly reinstall when i removed all harddrives except the main drive with windows 8 on it.

      I wouldn't call me a pc noob i even used linux a long time ago already and i had dualboot back then which worked flawless. However i think that was windows xp and i probably had only one harddrive.

      Now i can dual boot with choosing the default boot-drive on boot (can do it quickly with a F-Key while booting which is probably a feature of my BIOS). either one which has GRUB on it or one with the windows bootloader.

    9. Josh Klint 2-time creator on

      The right-click trick in Code::Blocks certainly helps. Thank for the tip.

      Just go to and type in "grub messes up" and you can see there is a systemic problem. If a user's first experience with Linux is having it make their Windows installation unusable, that person will never come back.

      The Wubi installer for Ubuntu is a wonderful trouble-free experience, but unfortunately the Ubuntu installation it creates doesn't work well with the Windows file system, which is probably why Canonical no longer recommends it.

      Until this is improved, my advice for new users will continue to be to make a completely separate installation with the Windows drive removed, and select a boot drive with BIOS.

    10. Malachi de AElfweald

      As far as the black screen goes, that sounds a lot like the nouveau issues I had with Mint. Did you try the proprietary NVidia drivers?

    11. Henrik Danielsson on

      Also, dual-booting _is_ a solved problem. Two weeks later, that user hasn't even responded with how his Windows installation was messed up, or which install options he used. You can't expect them to have researched the subject at all based on that post.

    12. Henrik Danielsson on

      @Josh Klint. Please don't blame GDB for Code::Blocks' shortcomings.
      Did you read this?…

    13. Josh Klint 2-time creator on

      Code::Blocks. :D

    14. Oscar Norlander on

      What editor or IDE do code in? Most of the Linux editors and IDEs has GDB integration.

    15. Josh Klint 2-time creator on

      I just use the Code::Blocks interface. I will not use a command-line interface for a debugger.

      Listing Python as an added benefit does not impress me; that just tells me the developer's focus is split between two different things, and C++ will not get 100% of their effort and attention.

      Linux has some compelling advantages, but we should be realistic about its shortcomings so that they can be identified and fixed. Linux developers told Valve the lack of a good debugger was their number one problem, and now Valve is working to solve the issue.

      "When we talk to developers and say, 'if you can pick one thing for Valve to work on the tools side to make Linux a better development target,' they always say we should build a debugger," he said."

    16. Missing avatar

      Thorbjørn Lindeijer on

      gdb definitely allows you to see variables further up the stack, you just need to navigate to those frames with 'up', 'down' or 'frame X' commands. Although I much prefer to use a GUI wrapped around it as found in Qt Creator for example.

    17. Anton Kochkov on

      Forgot to mention gdb -tui interface, which is allow you to see both assembly and C/C++ code at the same time.

    18. Anton Kochkov on

      >GDB itself is not a complete debugger;
      Thats not true. I'vent heard more powerfull debugger at all. But it is like one of this type of software - which is needed to be configured to show its power. Remember, that gdb also have support for python scripting. See as example of such configuration power. Also, there is another powerful tool - valgrind, which is awesome for finding memory leaks and much more. Moreover, it have embedded gdbserver inside, so on each memory leak/error it can break to give you ability to do research of the stack, memory, etc from your gdb session (see valgrind vgdb and remote gdb debugging).

    19. Missing avatar

      Michael Sartain on

      > 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.

      Does the "backtrace full" command help at all? You can also limit it to a specific number of frames. Ie, "backtrace full 3"