Funded! This project was successfully funded on July 31, 2013.

Update #36

Leadwerks Editor on Linux

20 comments
10 likes

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

GTK

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.

Comments

    1. Missing_small

      Creator Alvaro F. Celis on November 5

      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:
      http://www.youtube.com/watch…

    2. Missing_small

      Creator Alvaro F. Celis on November 5

      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_small

      Creator Morten Haggren on November 5

      https://help.ubuntu.com/community/WindowsDualBoot

      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. Photo-1.small

      Creator Josh Klint on November 4

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

      Creator Francis Bolduc on November 4

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

      Creator Igal Alkon on November 4

      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: http://codef00.com/projects#debugger

    7. Missing_small

      Creator Vadim Peretokin on November 4

      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 (http://visualgdb.com) integrate GDB into themselves.

    8. Missing_small

      Creator Sascha on November 4

      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. Photo-1.small

      Creator Josh Klint on November 4

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

      Just go to google.com 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. Fb_profile_picture.small

      Creator Malachi de AElfweald on November 4

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

      Creator Henrik Danielsson on November 4

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

      Creator Henrik Danielsson on November 4

      @Josh Klint. Please don't blame GDB for Code::Blocks' shortcomings.
      Did you read this?
      http://wiki.codeblocks.org/index.php…

    13. Photo-1.small

      Creator Josh Klint on November 4

      Code::Blocks. :D

    14. Glajan.small

      Creator Oscar Norlander on November 4

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

    15. Photo-1.small

      Creator Josh Klint on November 4

      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."
      http://arstechnica.com/gaming/2013/09/gabe-newell-linux-is-the-future-of-gaming-new-hardware-coming-soon/

    16. Missing_small

      Creator Thorbjørn Lindeijer on November 4

      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. 95010156a6cb54670e7145d7abcaa24c.small

      Creator Anton Kochkov on November 4

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

    18. 95010156a6cb54670e7145d7abcaa24c.small

      Creator Anton Kochkov on November 4

      >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 https://github.com/gdbinit/Gdbinit 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_small

      Creator Michael Sartain on November 4

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

787
Backers
$42,358
pledged of $20,000 goal
0
seconds to go
  • Pledge $1 or more
    You selected

    265 backers

    ENTHUSIAST: Help us take Linux gaming to the next level, and receive exclusive news and updates on Leadwerks developments by email.

    Estimated delivery:
  • Pledge $10 or more
    You selected

    53 backers

    PENGUIN: We'll send you a sticker in the mail with our awesome logo on it. Put it on your computer, your skateboard, or even your dog.

    Estimated delivery:
    Ships within the US only
  • Pledge $25 or more
    You selected

    13 backers

    INTERNATIONAL FAN: Due to popular request, we're now shipping two rewards in one, anywhere in the world! Get a Leadwerks T-Shirt for you AND a Leadwerks sticker for your computer, skateboard, or dog. (Only international orders will receive the sticker.)

    Estimated delivery:
    Add $16 USD to ship outside the US
  • Pledge $25 or more
    You selected

    54 backers

    FAN: We will send you a stylish and comfortable Leadwerks T-Shirt in the mail.

    Estimated delivery:
    Ships within the US only
  • Pledge $50 or more
    You selected

    73 backers

    INDIE BACKER: Receive Leadwerks for Linux "Indie Edition" when it's released. This allows you to program games with Lua. (We use LuaJIT to make it run fast.)

    Estimated delivery:
  • Pledge $100 or more
    You selected

    162 backers

    BACKER: Receive Leadwerks for Linux when it's released. This allows you to program games with C++ and Lua.

    Estimated delivery:
  • Pledge $200 or more
    You selected

    79 backers

    PRO BACKER: Receive Leadwerks for Linux when it's released. This allows you to program games with C++ and Lua. You will also receive Leadwerks for Windows and Mac.

    Estimated delivery:
  • Pledge $500 or more
    You selected

    3 backers

    SUPER BACKER: Receive Leadwerks for Linux when it's released. This allows you to program games with C++ and Lua. You will also receive Leadwerks for Windows and Mac. You'll get early access to the beta of Linux for Leadwerks, plus a T-Shirt and sticker will be mailed to your home.

    Estimated delivery:
  • Pledge $800 or more
    You selected

    1 backer

    INDIE TEAM: Get a team license with support for five seats for your team's next project. You will receive a registration key with support for five concurrent installations (on Linux, Mac, or Windows), and five forum accounts you can assign to your team members, plus access to the Leadwerks 3.1 beta.

    Estimated delivery:
  • Pledge $4,200 or more
    You selected

    0 backers

    SITE LICENSE: Get a site license for your company's next project. You will receive a registration key with support for concurrent installations (on Linux, Mac, or Windows) within your company, and forum accounts you can assign to your employees, plus access to the Leadwerks 3.1 beta. The site license supports up to 30 installations.

    Estimated delivery:
  • Pledge $10,000 or more
    You selected

    0 backers Limited (2 left of 2)

    ULTRA BACKER: Leadwerks founder and GDC speaker Josh Klint will code anything you want full-time for a week. Communication will be conducted over Skype in the English language. Does not include proprietary knowledge and techniques. Timing can be anywhere in the next 12 months except the month of March 2014. Four weeks notice are required for dates after August 2013.

    Estimated delivery:
Funding period

- (45 days)