Misc. Linux Questions

This is not necessarily Braid news. If you don’t do any Linux programming then you may want to skip this posting!

I’m trying to do some basic game stuff under Linux and don’t really know what a reasonable way is to do them, and the cost of experimentation is very high. So I am hoping someone out there can just answer these basic questions…

  • What is a reasonable way to read mouse input? Reading X11 mouse events is not sufficient since (a) it’s had GUI acceleration applied to it, and (b) it clamps at the edges of the screen. libGII seems to be one way to do this — is it reliable and useful? Can I “ship” a game with it (to the extent that anything is shippable at all under Linux)? Are there alternatives?
  • Under X11, is there a way to constrain the mouse pointer to a window without other undesirable effects (such as stealing the focus and locking the GUI)? Last time I tried this (a couple of years ago) I couldn’t figure out a way to do it.
  • For audio output, should I be using ALSA or something else? In a past project I used SDL but the SDL audio API seemed quite lacking for serious game programming.
  • Thanks!

251 Responses to “Misc. Linux Questions”

  1. Nicholas Vining Says:

    Disclaimer: I used to work for Loki Games, who back in 2000 drank a LOT of Linux and SDL kool-aid, and were partly responsible for the development of OpenAL. Also, I’m currently working on a Mac and Linux port of a Very Big-Named First Person Shooter, where we are using both SDL and OpenAL.

    That said: your best bet really is to use SDL for everything but audio, and OpenAL for audio. SDL has had a lot of time and energy devoted to making it work quickly, and easily, on X11, which is a fairly non-trivial proposition otherwise. The only bad news is that the audio support does suck, but OpenAL fills that gap very nicely. If you need decoding of sound on top of what OpenAL offers, grab SDL_sound from Ryan C. Gordon’s website at http://www.icculus.org/. The advantage to using OpenAL over ALSA is that it internally wraps both ALSA and OSS, and gives you 3D positional sound as a layer on top of both of those if you need it. (Even if you don’t, it’s still a good library.)

    In terms of actually shipping anything under Linux, it can be done; you just end up bundling all of your non-standard dynamic libraries for SDL and OpenAL with the game, and then tricking the Linux shared library preloader into loading yours instead of what’s in /usr/local/lib, usually by means of a shell script that actually runs your executable. Yep, it’s a mess. :-) That said, it is definitely possible to ship games with SDL and OpenAL that Basically Just Work. I don’t know if the same is true for GGI and GII, but I don’t know anybody actually using them for commercial software either.

    Drop me an e-mail if you have any more Linux-y questions, or if you just want somebody to bitch at about the porting experience. (FWIW, Ryan and I both do porting professionally, and we both try to be indie-friendly; if you just want to get something out on OS X and Linux, it’s not necessarily prohibitively expensive to just dump it on one of us and be done with it. I think I’m currently cheaper than Ryan, but whatever. :-) )

  2. Sean Barrett Says:

    Unless I misunderstood something, back when I did a Linux project a couple of years ago, SDL audio was a non-starter because its per-sound volume controls were 8-bit only. But OpenAL was a huge pain for 2D sound because it _only_ offered a 3D sound API, so you had to clumsily set up a listener and do a bunch of math to get out the 2d audio you wanted.

    Maybe this has changed since, but that was super-frustrating.

  3. Jonathan Blow Says:

    I replied to him privately, but in terms of sound, I don’t even want volume control. I just want to pass exactly one stream of pre-mixed audio to the output and have the sound system just get the hell out of the way, otherwise.

    The thing I didn’t like about SDL audio was the annoying callback structure and accompanying complete lack of any useful information about the state of the audio device (how many samples are queued or whatever).

    Meanwhile, SDL for everything else seemed kind of useless as I couldn’t get any of the mouse or window functionality out of it that I wanted — and these things were basic functionality that you would want for any high-end game (a couple of major parts of which were the items in this posting).

  4. Paul Visschers Says:

    I’ve been fiddling around with OpenGL directly for a bit, but this SDL might be much more complete. I’ll have to give it a try, and hope that the Haskell bindings are good.

  5. Nicholas Vining Says:

    I replied to Jon privately as well, but apparently (according to Ryan, who has written more of the bowels of the SDL audio code than I have) the reason for the callback structure is that some platforms just plain don’t support locking and unlocking a buffer and being done with it. Examples include most Linux audio drivers and Mac OS X. So if he is to be believed it’s not necessarily a limitation of SDL as much as it is part of its objective to be as close to directly mapping its functionality onto the libraries of the platform that it’s running on, as much as possible. Ryan may come here and poke the blog as well, and you can all beat him up with your SDL complaints. I know I do. :-)

    The mouse driver is an interesting one, and now I’m curious because I haven’t really thought about it all that much. Poking around in the X11 mouse driver now, stay tuned…

  6. Jonathan Blow Says:

    Well, I think it’s fine for SDL to make a decision like that. But what that means is that SDL is not an appropriate API for a high-quality game that cares a lot about game feel; it’s better as an API for mini games or whatever. Which is fine. There’s a place in the world for that, but it’s not what I want for my game.

    To phrase it another way, I don’t want the sound in my game to be kind of assy just because someone else out in the world wanted to maybe have their game run on the PalmPilot as well as Linux.

    Back when I looked at the X11 mouse drivers (a couple of years ago) it was obvious where the actual number I wanted was stored, right there in the data structure…

  7. Jonathan Blow Says:

    Re “most Linux audio drivers”, ALSA has been built into the kernel since 2.6, right?

  8. Andrew Doull Says:

    IrrKlang is a 2d and 3d free audio crossplatform API you may want to look at. (http://www.ambiera.com/irrklang/)

  9. Ryan C. Gordon Says:

    Hey, Nicholas asked me to stop by.

    “Assy” is subjective, of course. In practice I’ve had SDL audio work out well with high-end titles in the past. I recognize that the callback can be really awkward, though, but you could conceptionally treat it the same way you treat a locked DMA buffer…write to a block of memory as a ring buffer and have the SDL audio callback, which runs in its own thread, pick up pieces as needed.

    The latency isn’t bad if you pick reasonable settings for the audio callback. But like I said, it’s subjective.

    Anyhow, it’s largely academic. Most things should be using OpenAL, if you want my opinion.

    There _is_ ALSA, but I think writing to this level is sort of risky. Lots of people still (still!) don’t have it enabled, some have buggy drivers, some have drivers that block in open() when something else has the audio device opened. Some are layering PulseAudio or JACK (etc) over top of ALSA, and expect you to talk to those instead of the hardware. Some drivers just simply don’t support hardware-level DMA buffers, even if they should.

    And, oh yeah, tomorrow the kernel developers might decide to change direction entirely and flush ALSA for something totally new.

    I don’t want to be an apologist…audio on Linux is a mess. Part of the benefit of SDL or OpenAL is that they hide this behind a stable API. SDL goes a long long way on Linux to make smart decisions at runtime about what facilities are available and pick the best ones (it does this on Windows, too…having a seemless fallback to the generic waveout interfaces has proven very useful for those with buggy DirectSound drivers). Having spent too many years dealing with the low-level APIs on Linux, I can’t in good faith recommend them to any one. It’s just such a crapshoot that can be avoided with some minimal abstraction in an open source library.

    Then again, as Vista’s DirectSound3D removed all hardware features–features that are still available if you use OpenAL–I can’t in good faith recommend the low-level on any platform. :)

    If you want to brave it, though:


    Look for “mmap” on that page…those are the DMA buffer interfaces.

    As for the mouse things…XChangePointerControl() may do what you want, but I suspect it’s not going to be exactly what you’re looking for…we’ll probably need to get a change to XInput to get real fine-grained control.

    My lecture about Xlib sounds almost identical to my lecture on ALSA, though: you’d be better off to use SDL for mouse input and let SDL improve without needing to adjust your game’s code. Ultimately, there’s no reason every application should have to manage this themselves.

    Feel free to drop me an email if you want to discuss this further. Improving gaming interfaces on Linux benefits my work, too. :)


  10. pascal Says:

    While you’re at it — I discovered, that most SDL(?) games I tried (Bridge Builder, Defcon, for example), where unable to do anything useful with absolute (i.e. Tablet) instead of relative (i.e. Mouse) input. They usually just jump the pointer to (0,0) when you move the pen. So while I don’t have any solution for this problem, it would be nice, if somebody could solve it, because especially “mousy” games like Defcon would be great to play with a tablet (or a Tablet PC).

  11. Nanette Says:

    I am not a gamer, but I work with many children, teens, and adults who are. I appreciate the sensitive nature of Braid. I, like others who have posted comments, would love to see a PC version. I would buy it. I wish I had the skills to put my ideas on identity quests into a game!
    Dr. Nanette

  12. LGW Says:

    This multi-part article is the best new source of information on programming games for Linux operating systems. All the parts of the article have been linked from this web page: http://linuxgamingworld.com/index.php?q=node/73

  13. JP Says:

    If this means that a Linux version of Braid is still in the cards then thanks for putting in the effort Jon, there are folks out there who appreciate it (all 3 of us, who probably already bought it on XBLA anyway).

    SDL 1.3 seems to have a lot of little feel-relevant features that some projects have been clamoring for but I’m not sure any are relevant here. The most recent roadmap I could find has a lot staked out but no timetables:


  14. Eric Says:

    Maybe PortAudio is worth a look? I’ve seen it used by many cross-platform audio tools.


    Mailing-list is pretty active, they may be able to answer specific implementation questions.

  15. Jonathan Blow Says:

    Hmm; just from looking at the documentation, portaudio doesn’t look any different from SDL in terms of being useful to games that want to do accurate sound.

  16. Dave Says:

    Not sure if this is relevant, but have you tried sdl_mixer? It adds much needed functionality to SDL audio.

  17. Jonathan Blow Says:

    But this is exactly my point — I don’t want *more* functionality. I want *less* functionality, but that works better and allows me to do what I need at a high level of quality.

    One of the big problems with Linux these days is that people are writing all kinds of random crap code when there aren’t even dependable foundations that apps can use.

  18. Mike Nelson Says:

    I think Ryan’s comments on this is right on for the most part. Although I don’t have much experience working with sound. I have used OpenAL but not to the level that you are looking for. SDL has worked well for me for large and small projects. I’d guess that SDL with OpenAL is probably your best bet. Although you maybe need to go with direct ALSA/OSS for that level of audio if you’re unlucky there.

    It just looks like a minefield outside of SDL. Of course for a trivial SDL example there’s that lod project of yours that a ported to Linux a while back.

    Granted, this may require you to work a differently in the API’s but what else is new in the wonderful world of API’s?

  19. Jonathan Blow Says:

    Mike: I already have SDL audio working in a different project. My complaint is that it’s not sufficient for what I want to do!

  20. Apreche Says:

    “One of the big problems with Linux these days is that people are writing all kinds of random crap code when there aren’t even dependable foundations that apps can use.”

    I think that’s a little harsh. There are plenty of dependable foundations, just not for games.

  21. Jonathan Blow Says:

    Then why has most of the major functionality of my Ubuntu 8.04LTS desktop failed in obviously-buggy ways at one time or another (often repeatedly?)

    I am talking about stuff like NetworkManager corrupting its own config file and failing to work forever after, or the Gnome desktop manager never remembering where my icons go (I don’t know where they are going to be, but I know where they are NOT going t be — where I put them before), or the fact that I can’t seek forward in an mp3 without crashing the audio system, or that I can’t sleep my laptop, or that hibernating my laptop takes ages, and … there’s a lot more but I already typed it all out to someone once today.

  22. Jeroen Stout Says:

    Hi Jonathan

    A small non-Linux related question (though in all fairness my Ubuntu install never recognised my wireless network card, even after multiple fixes which broke everything from the wired network to Ubuntu itself):

    Is the PC version still on it’s way? It’s just that in the time Braid has been out I have heard increasing amounts of raves, and have to say I enjoyed listening to interviews with you through various podcasts – but yeah, it’s increasingly difficult for me to escape spoilers at this point. So in that regard, will it be out any time soon or would it be best for me to go live under a rock until the mania is over?

    It’s awesome work from what I’ve seen so far, though, Braid is giving indy games a really good name :)


  23. Andrew Martin Says:

    This is the kind of thing I point to when people tell me that Linux is the wave of future. I’m not saying it’s not possible, but it’s not so long as the development of things that are often trivial in a Windows environment are such a headache in Linux.

    When you look at what Microsoft offers for developers of games and enterprise software and then take a look at what you’re going to have to deal with in Linux, the choice is pretty easy.

  24. Jonathan Blow Says:

    Yes, the PC version is on its way, but it might be a little over a month before it is released.

  25. Francis Says:

    I have to recommend StackOverflow.com. It’s perfect for questions just like this. It’s currently in beta (for only a few more days) but I can get you in now. You’ve got my email in this post.

  26. GameJunkieJim Says:

    OMG, I <3 Loki games. Thanks to them I was able to play Myth II on my computer without jumping through hoops.

    Shame the source was lost… :(

  27. Onawa Says:

    Hey Jonathan and crew of Braid.

    Just thought i’d drop you a line and let you know I 100% appreciated your game and wrote a couple articles on the subject. My latest is here:

    article ‘Braid Revisited’

    and I hope you have some time to read it.

    thanks much for helping jump start the revolution

  28. Patrik Rak Says:

    I would second using SDL and OpenAL. We used it in Linux/MacOS port of Cold War ourselves. It’s far from perfect, but it’s still way better than any of the alternatives we have tried. We can discuss this in more detail in private if you want to.

    Neat game, by the way, really enjoyed playing through it today.

  29. Jonathan Blow Says:

    For now I have tabled the Linux port. I am not actively working on it. Sometime in the future I might pick it up again, but man, I dunno.

  30. Sofox Says:

    What is a reasonable way to read mouse input?

    Under X11, is there a way to constrain the mouse pointer to a window without other undesirable effects

  31. Sofox Says:

    Apologies for the second post, but has anyone suggested OpenGL? I understand it is a 3d library but I hear it has been used for 2d (with orthogonal perspective) and some nice effects can be gained from it as a result (easy rotation etc. the list is big).

    If you do use OpenGL, you’ll need a toolkit or some other approach for abstracting things like Keyboard, Windows, Mouse etc. While SDL can be used for this, you could also check out GLFW ( http://glfw.sourceforge.net/ ) which seems to be reliable and robust. It also has the functions “glfwSetMousePos” and “glfwGetMousePos”, which are the equivalents of the two SDL functions I listed above.

  32. Jonathan Blow Says:

    SDL_GetMouseState only tells you the position of the mouse pointer, not how much the user has moved the mouse. SDL_WarpMouse has the traditional problems with clamping due to hitting the edges of the screen, and anyway doesn’t actually constrain the mouse to the window.

    Yes, I have been using OpenGL for 12 years. Please understand that I am a professional game developer and not a newbie of some kind.

  33. Joseph Garvin Says:

    If I’m not mistaken the wine project has had the same trouble with mouse input and Xorg needs a new extension proposed to fix it. Warping the pointer to the center of the window maybe hackish, but what exactly is the problem with? Or with stealing focus for that matter? The majority of people will play the game fullscreen, and die hard hackers complaining about lost focus can customize their window manager to ignore it anyway.

    I’m also sorry to hear about your hardware troubles, but to balance your experience I’d like to point out that I bought a new laptop last year and everything worked on Ubuntu out of the box except for sound, which was luckily fixable. Nor has NetworkManager ever failed for me. Suspend works flawlessly.

    But that’s beside the point. Your hardware experiences (that is, experiences with drivers that likely had to be reverse engineered) have nothing to do with whether or not there’s a “dependable foundation” for apps, i.e. a decent software stack. The LSB (Linux Standard Base) provides a decent set of GUI functionality you can depend on and build packages for, so I think the poster was right in saying the foundation is there, just not for games.

    FWIW I think a Linux version would be awesome, and I would buy it.

  34. Jonathan Blow Says:

    Using the X11 focus stealing stuff, I had problems with the UI locking up when the app crashes, or the ability to un-steal focus (why can’t the user just alt-tab out of the window?) etc. It is just the wrong tool for the job.

    Warping the pointer to the middle of the screen has the problem that the input saturates when the user moves the mouse pointer fast enough that it hits the edge of the screen or window between warps. The degree of saturation is dependent on the user’s mouse acceleration / speed settings which are unpredictable. etc.

    I think that only a small number of the problems I have with Ubuntu are due to drivers, and I understand how hard that can be. My biggest problems have nothing to do with drivers…

  35. Beemer Says:

    Tabling the linux port? Damn…I read up on this game about a week or so ago and was thrilled to see your blog post with Linux questions. I realize you want quality out of all the aspects of your game, but really – the play’s the thing.

    What’s the problem with sound? There’s tons of games out there where the sound is just fine in linux. What makes the sound in your game more difficult to produce?

    I was looking forward to trying this game out and buying if it lived up to what I already read…

  36. ORB Says:

    Hey 1 sec, are u releasing Braid on Linux? really? really?

  37. Jonathan Blow Says:

    The main issue with the sound is latency. That’s not a showstopper; I still could do it, but it’s just annoying that the situation is so sucky. Really the reason I am not motivated to work on this right now is the poorness of the development tools in general. The libraries are secondary but also very important (inability to do the very basic mouse / sound stuff that Windows has had for 10 years, and the extreme disappointment that is the newly-released OpenGL 3.0 specification. GL3 especially… it seems to be saying that there isn’t really a future in graphics programming on anything but D3D, which is a hard pill to swallow.)

  38. Sofox Says:

    “SDL_GetMouseState only tells you the position of the mouse pointer, not how much the user has moved the mouse.”
    Then use this instead, every time the mouse is moved, this event is generated: http://www.libsdl.org/cgi/docwiki.cgi/SDL_MouseMotionEvent

  39. Sofox Says:

    (Again with the double posting! Apologies.)
    “SDL_WarpMouse has the traditional problems with clamping due to hitting the edges of the screen, and anyway doesn’t actually constrain the mouse to the window.”
    Try this:

  40. Jonathan Blow Says:

    These functions you are pointing out, on Linux, are essentially just wrappers around the equivalent X11 functions, and so have all the same problems.

  41. Mike Nelson Says:

    > Really the reason I am not motivated to work on this right now is the poorness of the development tools in general.

    Interesting. I prefer to work in Linux (or even cygwin) because of the outstanding development tools. But of course this is all just matter of opinion.

  42. Nicholas Says:

    MikeNelson: Linux has outstanding development tools? Other than valgrind, it’s hard to imagine what – gdb doesn’t really stand up in terms of useability (or, for that matter, just plain working) versus, say, MSVC or XCode. I like Linux quite a bit, but come on :-)

  43. Jonathan Blow Says:

    What is it that you find good about the tools? It appears to me that they are about 12 years behind what I can use on Windows.

  44. Mike Nelson Says:

    I think that it’s really a matter of preference. Taking gdb for example, like Nicholas mentions. gdb is an extremely powerful debugger. It’s just not the same type of interface that is common for debuggers in IDE’s, but it allows you to have finer control and sight into your debugging. This type of thing is true for me for all the tools like bash, grep and awk, sed, make, vim, exuberant-ctags, etc., which are mostly what I find useful on Linux/Unix. All of these little tools do their own little thing that they do really well and are firmly established tools that have been around for ages. I don’t know how I lived with them for so long.

    Note that you don’t even have to go to Linux to use these tools anyway. You can these under Cygwin or natively on Windows. You can edit in your favorite editor/IDE and have these other tools on hand as well if you like.

    It can be a learning curve to get a handle on these tools but you can do some pretty powerful stuff with them. It’s hard to quantify but once I got used to using them I continually find easier ways to work. On the other hand a lot of these things are just little time savers. You can do the same type of things without these tools but it can take a bit more effort.

    In my opinion, IDE’s like VC++ try to do the work of a subset of these established tools and usually not very well. Personally I’m tired of IDE’s in general because of this fact. It’s not just Window’s IDE’s but all IDE’s in general. Linux IDE’s have all the same shortcomings. They try to do too much in one app and it’s hard to hit all of those targets well — although IntelliJ (for Java coding) comes very close to hitting them, but it’s the only one I’ve seen that does it well.

    For me I usually edit in vim calling out to things like make and subversion. The interesting thing is when I’m working like this I don’t step through code very often at all, can go months without using gdb. I only use it when I am at a loss. Having the debugger integrated right into where you edit code (not to mention the dubious siren of easily hot-modifying code) is just way too tempting to use. Without this I’m sure that I work faster in the end without just jumping into the debugger all the time and spinning cycles in there. Also, it’s also like going back to the way I coded in the 80′s which just feels more comfortable to me. I feel more in control and productive this way.

    But all of this is really just a matter of preference. The tools probably don’t make that much of a difference in the end. There are other reasons outside of development that I like Linux as an OS so it feels more comfortable that way too. Some just prefer to work in Windows, some like to work in Linux, some like to work on a Mac, etc. I was just trying to balance what you said about the tools in Linux with an opposing opinion. The fun thing about cross-platform development is that you can do your primary work on the platform you prefer.

    Geesh, this post got long.

  45. Jonathan Blow Says:

    I don’t believe it. You are seriously calling ‘make’ a good tool, rather than a miserable piece of garbage? I don’t know if we can even have a serious conversation about this.

    I don’t agree that gdb provides any kind of finer control over debugging or any kind of better view over the running program. I can only think of ways in which it is worse. If you’d like to enlighten me as to exactly what the advantages of gdb are, then I look forward to it…

    When you say that you go months without using gdb, do you mean that you use printf debugging or something like that (or whatever the equivalent is in Java)? You are seriously recommending this?

    What kinds of apps do you write that that you can printf-debug them and it’s not a serious time sink? Games just seem way too complicated for that. I have printf-debugged games in places where I had no choice (e.g. on the PS3) and it bites rocks.

  46. PHeMoX Says:

    “It bites rocks”, LOL. Oh, sorry. Proceed! :)

  47. Won Says:

    I code in Linux every day for work. More of an EMACS man myself.

    ‘make’ is pretty awful in just about every way you can have an opinion. Fortunately, I don’t have to use make. Visual Studio’s debugger is so far ahead of gdb, I don’t think you can really make a comparison. Unfortunately, I don’t have any alternatives, so I’m stuck pining for Visual Studio (although the debugger is really the only part I miss). Gdb particularly stinks for C++. As a result, the code I wrote ends up having lots of unittests that facilitate printf scaffolding. I certainly wish it were more interactive. I loved using edit and continue.

  48. Aaron Says:

    Ah, down to the nitpickings of development tools.
    At least you’re not doing web development. Debugging a web app is absolutely amazing in all the wrong ways.

    I’d love to see Braid on Linux; but it honestly doesn’t matter to me as long as it hits the PC in some form or another. I already reverted back to Windows XP after a year of using Linux exclusively because I tried the Gimp and it was just nowhere near as usable as Photoshop for my admittedly amateur use cases. Not only that, but I couldn’t get Photoshop CS2 to run in Ubuntu for more than two days. (Literally! It worked fine, then pfft. I tried reinstalling it 3 times.)

    I love the integration of the GNU toolchain in Linux and how I can choose a window manager that lets me map all window movements to keyboard shortcuts so I can avoid the shoulder-pain inducing mouse; but I’ve come to accept that games are on Windows and that’s just the way it is. Sometimes you just have to use what works instead of working towards an ideal.

  49. Joseph Garvin Says:

    BTW, the extension for Xorg I mentioned might be needed for absolute input is called XInput2, there was a post on the wine-devel mailing list about it today.

    My experience coding C++ for the last two years comes from porting a large app from Windows to Linux. My initial reaction to the state of development tools was largely the same. Visual Studio highlighted my code nicely, had decent code completion (although still doesn’t handlecompletion when templates are involved very well, although I don’t know of any IDE that does), and handled calling the compiler, displaying its error messages, stepping through with debugger etc. for me.

    Then I moved to emacs, which does none of that out of the box. At the time Before resorting to emacs I evaluated KDevelop and the CDT for Eclipse. Kdevelop crashed trying to index the boost libraries for code completion, had tons of weird and unnecessary options (why is there a special configuration section for gameboy games? I hadn’t setup a gameboy project…), and often lost track of the current line when stepping through with the debugger. Some of these have been fixed in the latest version, you may have better luck. The CDT did basically nothing for you when I tried it, it didn’t even find the compiler correctly, and indexing took forever. So I configured the hell out of emacs and made do. The CDT looks to be in much better shape now, you should definitely try it.

    What is it that the visual studio debugger does better than GDB? To be clear, is the problem with the command line interface or with the features? GDB is designed to be built on top of — it has a separate machine interface (i.e. really meant for IDEs instead of having them try to parse the command line text output) that KDevelop added support for relatively recently and that I think the CDT uses. Things are maturing, so don’t let the initial bad taste lead you to think the situation is hopeless.

    For what it’s worth, my nicely configured emacs is much more productive for me than visual studio was. But it takes a lot of initial time investment, patience to talk to people on IRC or newsgroups to get things ‘just right’, etc.

  50. Tor Gunnar Says:

    For what it’s worth, I thought Braid sounded very interesting when I first heard about it, but then forgot about it since I couldn’t play it anyway. Then I read a post on an unrelated forum about a possible Linux version, which brought back the interest and I visited the site for the first time. I really hope you get back to working on Linux support for Braid or any future games.

  51. Greg Says:

    I know this is a Linux post, but I was wondering, Jonathan, if you could tell what API / SDK you used to port Braid over to PC. I know you said you coded in C++, but maybe you have some advice for good Windows tools for gaming-dev beginners?

  52. Jonathan Blow Says:

    Braid was written on the PC originally. Just using Visual C++.

  53. Greg Says:

    Wow, that was a fast reply! Do you mean that you coded a graphics engine from scratch? What about OpenGL, playing audio, etc? Thanks so much, and I’m eagerly awaiting the arrival on PC!

  54. yakfist Says:

    JB obviously has a chip on his shoulder about Linux so I don’t think anyone can have a constructive conversation with him about the pros and cons of Linux game development (and I admit, there are several cons).

    At the end of the day, if it’s not important to you to support an operating system primarily designed to free its users and developers from commercialism, stick with something you prefer and are more comfortable with and that will make you money. At the same time, if you are an exlusive Linux user, realize right now that you have not chosen a platform that is appealing for commercialists. If you want to live partly outside of the culture of commodification, you have to accept the consequences of your choice and give up aspects of that culture you may find appealing.

    Anyway, Braid is a neat game.

  55. Jonathan Blow Says:

    I wouldn’t say that I have a chip on my shoulder. I genuinely wanted it to work. What you are saying about being outside the culture of commodification is exactly what I wanted.

    However, the development tools are just not very good, and it turns out to be too big a sacrifice. As I was telling someone in a conversation the other week, it was hard enough (and very expensive) to make Braid on Windows, where the tools were a lot better. Braid could easily have failed and never been completed. If I had had to develop Braid on Linux, where it is so much harder to build software, it probably would have failed. You wouldn’t have gotten to play the game, ever.

    So, that is too big a price to pay. I was willing to suffer some friction, to have to patch the source of whatever tools I was using in order to get them to do what I wanted. But the friction is just too great; the development tools are just too poor. I can’t take that much of a hit, because I would never get anything done.

  56. Doug Johnston Says:

    For sound, how about fmod? Especially for multi-platform games.
    Might be a little much for what you need to do, but I thought I’d put it out there since no one else has mentioned it.

  57. Meneer R Says:

    >you have to accept the consequences of your choice and give up aspects of that culture you may find appealing.

    It’s funny though. I run linux and I own a Wii and I would love to play this game. But somehow i’ve placed myself out of the market.

    >So, that is too big a price to pay. I was willing to suffer some friction, to have to patch the source of whatever tools I was using in order to get them to do what I wanted

    Well, you tried. Maybe someday you can release it as a standalone wii-disc or something? How is the support on Wine? If that works out of the box, then that would be acceptable.

    Anyways.. it’s not your fight. I like games, and there a lot of games I like. I feel that I would love this game. But i can live without it; and appearantly; you can live without my money ;-)

    I do think in general, that this whole idea of limiting yourself in the PC gaming market is the biggest marketing failure of an industry in the last century. At every corner people that might like and buy a game are cut out of the market. It does not run on their OS. it has DRM and does not garantuee it will work 10 years from now if the authoring company is bankrupt; it’s not for sale online; it’s only for sale online; it’s doesn’t work with a intel graphics card; it doesn’t work in combination with Norton Antivirus 23.37372; it doesn’t work with Windows Blasta; etc. etc.

    Then we get to the consoles; which generally have bad backwards compatility; some of the very old games you can purchase online [again] .. but you have to pay again to play again .. company X (sony/nintento/microsfot) pays company Y to make game Z exclusive to system G (hello, anti-competitive; let’s destroy our own market bullshit) ..

    And it goes on and on…

  58. Andy Sloane Says:

    I think XWarpMousePointer, or whatever wrapper around it you want to use, may be your best bet. It’s what we do in the Linux port of Vendetta Online… each time we receive a mouse input event, we warp the mouse back to the center. It’s somewhat tricky because you then receive the event for the mouse moving back to the center, so you have to compensate for that. This is obviously only for capturing relative pointer motion, not absolute position, but I’m assuming that’s what you want.

    It’s pretty hard for a user to move the mouse all the way to the edge of the screen this way, even at 640×480. You can tell X to confine the pointer to the window with XGrabPointer(), but we don’t bother. We don’t bother disabling acceleration either. It’s not pretty but we have few complaints.

    I’m curious why you want to do that in Braid, though. Are you seriously considering controlling Tim with the mouse? Or is this for the interface, in which case it’s not sensible to warp the pointer at all? If that’s the case then I’d use XGrabPointer and make it easy to switch out, like by ungrabbing when you’re in the options menu.

    We also use ALSA, and not SDL, for audio.

  59. KodaK Says:

    Linux makes an excellent server.

    I ran it for years as my main desktop, probably before 99% of the current Linux userbase ever heard of it, and I’ve gone back to Windows for my main desktops. I still administer a huge number of Linux servers of many types, but there are just too many hoops I have to jump through and sacrifices I need to make to do the things I want and need to do on a desktop OS.

    I completely understand what you’re saying about the costs versus the benefits because I’ve made the same calculations. As a user, though, not a developer — and I understand that those costs are multiplied tenfold for a developer. I hope you continue to take a look at it, but I completely understand your stance at this point.

  60. josh Says:

    If you want all of your shared libraries to load out of the same directory as the executable, you can use the -rpath=$ORIGIN option when compiling.

  61. Noah Kantrowitz Says:

    I will echo the earlier mention of FMOD for audio. While it is far from faultless, it does offer a decent balance between cross-platform availability, acceptable API, and tool chain.

  62. John C Barstow Says:

    Regarding the mouse, the X folks are aware it sucks and are working on a new XInput interface, but that probably won’t be available until early 2009.

    Regarding audio output, I’d point you to this recent post on sound APIs. I suspect you want to use the glitch-free PulseAudio interface or the JACK interface.


    Personally, I’d re-evaluate in 6-12 months when most of the buggy stuff has been sorted. PulseAudio, for example, is *much* better than it was 3 months ago and if you’re developing 6 months out I’d give it a go when Intrepid ships. X has just shipped the 1.5 server with decent hotplugging (a very long time coming) and 1.6 will have much better input APIs (along with multi-pointer/multi-touch support).

    Regarding tools, it takes quite some time to adjust from the IDE world to the command-line driven philosophy (I think it took me about two years). The two mindsets are very alien.

    Also, to do effective development in Linux you should choose either emacs or vim and use them seriously for an extended period of time (by which I mean a few months). They are extremely powerful and effective once you are used to them; after a couple years of using vim I can’t go back to Visual Studio without shuddering.

    Autotools sucks, but there are more palatable alternatives (look at CMake, which handily generates Visual Studio project files).

  63. Jonathan Blow Says:

    Yeah, I will check out the sound situation shortly in the future.

    But, I already use emacs as my main editor and have for almost 20 years! So that’s not the problem. Command-line sort of is a problem, though. I started out in the command-line world back in college, and did things that way for a long time. I know some people who still prefer to program that way for some reason, but for me it just doesn’t work.

    I would say the biggest problems, development-tools wise, are the lack of a reasonable debugger, the slowness of gcc, the lack of the Visual C++ “IntelliSense” kinds of features, and edit+continue, and the extreme disappointment that is OpenGL 3.0. At this point Direct3D is a far, far superior environment for programming and debugging. And that is pretty lame, because when it started out it was horrible and sucky and OpenGL was obviously superior; but GL just lost ground, year after year, until we get where we are today.

  64. Foobar Says:

    FWIW, there is now discussion (and more comments) on this issue over at Reddit at http://www.reddit.com/r/programming/comments/742tt/professional_game_dev_asks_for_serious_advice_on/

  65. Ryan Says:

    As someone who has programmed on both platforms, but would sacrifice a goat if I could choose Linux as my primary platform, let me pass my own judgement on tools:

    1. If you don’t use Vim or Emacs for editing, you are not a real programmer.
    2. Command lines tools on Linux save oodles of time and RSI fatigue — *if* you took the time to learn them
    3. GDB blows for C++. VS is an amazing debugger. But that’s about it.

    There is the following front-end for GDB. Does it help bridge the gap for you?


  66. Jonathan Blow Says:

    Hmm, I feel like my reply a couple of messages up has been ignored.

    Ryan, I have been using Linux in one way or another since kernel version 0.91. Please don’t come here with your “*if* you took the time to learn them” silliness.

    I haven’t tried that particular front-end but it doesn’t look as good as Code::Blocks, and I don’t find Code::Blocks very usable.

  67. Indy Ray Says:

    Ya know, I’ve been using visual studio’s debugger for years, and after trying out gdb the one thing which I have not found a way to do in Visual Studio that just works in gdb is inspecting returns. I’ve found this very helpful when I’m calling functions and perfoming math, and directly passing them into functions. I have not found a way to do this in Visual studio that doesn’t require pulling the return out into a variable, rebuilding and in general restarting(I’ve found edit-and-continue to be pretty iffy) or atleast running to the next iteration.

  68. Jonathan Blow Says:

    Yeah, this is definitely one thing that Visual Studio is not so hot at (also inspecting variables that get assigned as the last line in a basic block, before a closed-brace). But, these things are easily worked around… in my coding style I usually assign something to a variable before I return it, anyway, so that I can just put a breakpoint on that line (makes the user-interface easy) or insert some extra code if I want to.

    The one thing gdb does, that Visual Studio does not do, is let you call live code from within the debugger. That’s kind of dangerous and is only useful probably for simple things like routines that print out your data structures. But, I’ve only found myself wishing Visual Studio had this ability on a few occasions. Edit+Continue mostly makes up for it, and of course has many bonuses of its own.

  69. Ryan Says:

    Jonathon, I just wanted to say that I meant that comment in general, not directed at you. I was just stating my opinion, so there is no reason for either one of us to think the other is “silly”. :)

    Using the shell (and other Unix tools) is extremely fast and powerful way to get things done, but it has a high barrier to entry. That’s just a fact.

    I am sorry you feel that the command line isn’t helpful to you, but many people respectfully disagree with you, for their own reasons. If you’ve no interest in learning why they think so, then I have no problem with that.

    Nemiver, following the Unix way, is *not* and IDE, it is only a front-end to GDB.

    The reason why VS is such a good debugger, because it allows you to look at your code while debugging the same way you would editing — except that it has this nifty way of changing the running instance variable through the editor.

    Just fired up nemiver, and no it doesn’t allow you to change instance values on the fly by just placing the cursor over them. Shame.

  70. Scott Says:


    Jesus, this is why almost nobody will write commercial software for Linux. I’ve used *nix for as long as Jonathan (perhaps a bit longer) and I finally got sick of all the dorks who think that they are mightier than thou.


    You are obviously wasting your time porting for Linux. I am glad you tabled it. They wouldn’t have been grateful anyway and probably would have bitched about you needing to release your code so they could code X feature or fix X bug.

    On a side note, I bought Braid on my 360 and I love it. I am glad to support an indy developer of your talent and I thank you for such an innovative and enjoyable game.

  71. Chris Says:

    Jonathan: reading this comments thread reminds me of exactly some of the comments I’ve got from disbelieving Linux users. I’ve been programming for Linux and Windows for almost exactly the same amount of time (well over 10 years) – in fact, probably Linux for slightly longer – and to this day I still massively prefer the tools under Windows. Yes, I do speak sed and awk and grep and vim and ctags all that, and I know that with some effort I can probably configure vim to do all the stuff VS does out of the box but here’s the thing: I’m a *programmer*. When I sit down to do my job, I want to be writing, reading and debugging code in as efficient a way as possible, not spending weeks configuring my dev environment and writing scripts for things it ought to do out of the fucking box.

    For what it’s worth, when I went from being a games dev on Windows to a systems coder on Linux, I found Slickedit to be a pretty decent Visual Studio clone/replacement (and in some ways superior – its IntelliSense-alike is way ahead of VS, but then everyone uses Visual Assist, right?). It’s got a visual interface to gdb that tries to emulate the VS debugger, too, and a full dependency/build system that replaces make. It’s not free or Free, but if you’re spending a lot of time in Linux, it’s worth it.

    And yes, the audio layers in Linux all suck ass. There seems to be some disease within the “community” that says all problems can be fixed by adding more layers of abstraction, without realising that the basic problem really is at the bottom of it all and all these abstraction layers are simply putting lipstick on a pig, to coin a phrase.

    I’m back on Windows again for my day job now, and I can’t say as I miss Linux terribly.

  72. Indy Ray Says:

    Edit+Continue is great when it works reliably, still trying to figure out what it is with my projects that prevent it from working, it then becomes easy to call functions when you have that and the ability to drag the execution point around (Which I also just recentlly discovered).

    I also generally end up keeping a toolbox of watch window snippets that I keep around to simply introspect into my more complicated data structures through watch window. It would be nice to be able to force the debugger to call the function though, and I doubt very hard on microsoft’s part.

    Personally the majority of my functions return in a more functional style, and I find in the debugger that this’ll often continue for a handful of functions. I have though found that in limited cases (mostly just with primitive data types) you can check the return type by watching the registers (generally EAX for non FP data)

    I also generally have luck with assignments on the last line by steping in and then back out, but it’s still a bit iffy.

  73. James Hofmann Says:

    You might want to check out what the Stepmania project did for its Linux audio. It does its own thing to communicate with the low-level APIs in a cross-platform way, IIRC…and it’s MIT licensed so you are OK to reuse that code. It got used for two commercial products(In the Groove and Pump It Up Pro) so the quality should be up to snuff as well.

  74. nate Says:

    If I were creating a game, I would look into Qt by Trolltech. The newest release (4.4) allows you to develop for Windows, Mac, and Linux using the same c++ codebase. You have the ability to play sounds through pulse and can access OpenGL through the GLWidget (or directly of course).

  75. PhilArmstrong Says:


    I’d be interested to know what features gdb actually lacks compared with the Visual C++ debugger: I do a fair amount of development under C++ on unix, and just reach for gdb by default. I can inspect C++ data structures + objects just fine, place watchpoints / tracepoints / breakpoints etc etc etc.

    Is it the lack of pointy-clickiness that drags? I can see being used to just being able to set a breakpoint by clicking on the appropriate line in the editor being handy, but it doesn’t seem like a dealbreaker.

    (btw, the mouse pointer warping trick to get continuous relative mouse movement has always worked fine on any of the Linux game ports I’ve played. Sure, it looks like a horrible cludge but it does actually seem to work — I’ve *never* had the window edge clip the movement for me.)

    NB. Of course, one approach to Linux support is simply to develop under Windows, but run the thing under wine occasionally just to make sure that it works (or poke the wine people to chivvy them into filling in the holes you need filled!). IOW, punt all the compatability issues and cludges to the wine developers :)

  76. Dark Shikari Says:

    I’m amazed at comments talking about the superiority of Windows development tools, or saying that *nix tools are “behind”; every time I have to leave POSIX platforms I cringe at the complete lack of support for anything sane on windows. MSVC still doesn’t support much of any of C99, and its been almost a decade now–how is that for *nix being “12 years behind”? I have to throw away loads of useful features in the apps I work on because of support for MSVC (every day I consider the possibility of telling the few people who insist on using such outdated software to screw it and use gcc or ICC, and eliminate support entirely). I have to fill my code with MSVC-specific ifdefs to work around its bugs and limitations.

    I cannot understand how anyone would *willingly* subject them to the torture I have experienced every time I’ve had to use Windows development tools. I write all my Windows apps POSIX-compatible and then compile them in mingw; its simply so much less work. And this is without even touching the Win32 API, which is its own special nightmare that could have an entire book written about how unbelievably convoluted it is.

    Also, after spending about a week using VS for a small project of mine, I have to say as a text editor its really rather mediocre (and, IMO, that is the primary job of an IDE: be a text editor, since that’s what you spend 90% of your programming time doing). I much prefer Notepad++ for simplicity and functionality.

  77. vfdsvf Says:

    Game-dev is a very specific domain, so I thought I’d just drop a comment to balance things a little. When I switch to windows for games or graphical editing, I feel I’m stepping in the past. Speaking of stable systems for production as a server administrator, I avoid anything MS/windows the best I can. About dependable foundations, your comment only apply to games. But I can agree there’s a lot of broken GUI for Linux out there.

  78. dorftrottel Says:

    You’re in luck – there was just an article posted about sound APIs in Linux: http://0pointer.de/blog/projects/guide-to-sound-apis.html

  79. Michael L. Says:

    Jonathan, you’re doing the typical new to Linux Development “OFGWTFBBQ THIS IS SHITTY SHITTY SHITTY BECAUSE THERE IS NO VISUAL STUDIO”

    Yeah, there isn’t. As you’re apparently *very* used to IDE’s, and probably not even used to configuring it to use 3rd party tools that often. If I’ve read your lack of experience correctly, you’re in for some work, especially since you’re at your own little concern rather than at a shop with a person who can setup all this for you the first time as happens with most people new to Linux.

    Unfortunately for your own learning, you are not under the tutledge of someone who can tell you to stop whining about this (which you are) and give basic pointers. I have no doubt you’re a talented developer, but like many talented developers, I think you’re over-valuing your own experience when evaluating this new area. Time to put on your humility hat, not your ridiculing asshole hat. You need us, we don’t need you. There is a lot of black magic and dragons in linux development, and one of them will eat weeks of your time if you aren’t careful.

    gdb has tons of ways to insert callbacks, pullout data, pop between threads and other such fine controlled features that it will blow your mind when you actually have to use it to do one of these things. The VISUAL interfaces to gdb only allow you to access VS type control for the most part, you have to learn the command line part to really get into the very powerful features. Additionally, you have to learn a lot about gcc to compile in all the stubs to get gdb to do the fantastically awesome things it can do (including allow you to make your own routines that are called in any number of critera, a pile more powerful than “printf’s on a PS3″). I will point out any investment in learning this toolset will possibly pay off for windows too if you find an intractable problem, as you can also use it for much in the way of windows development.

    Some changes of paradigms you need to get into your head to effectively develop on Linux.

    1. It is often easier to develop software than to find software on Linux

    It’s REALLY easy to get something effective but not very robust going on Linux. You may go “I don’t want to write a shitty sound layer by hand”. I don’t think you should. However, writing a tool that looks at sounds buffers, or a small patch to something you partially already understand in a library is probably something you can do in a few short days. This would take a LOT longer on windows usually, as there is an interface (the API) which you cannot pierce, or at least not easily. In Linux, while there is an API, you can burrow down deeper and instrument the hell out of a library, using some custom tool you make if you don’t want to learn about gcc, gdb and gprof. When pissed off how YUV overlays refreshed (in SDL) on one project, I used gprof to build a call tree and quickly rewrote 2 functions of the SDL library to fit our needs. This took 3 days to make it work perfectly, and this was an embedded project (which generally means, longer than desktop).

    2. Make is a tool that is exceptional for many purposes. Some peoples’ makefiles are evil incarnate, and will torture you eternally if you don’t ask for help.

    Make’s algorithm for determining what needs rebuilding is not very well suited to many projects, nor is the cross awareness of makefiles especially great in large tree structures of files. C++ projects, which have their own issues with nasty compile time lengths, really can hurt here.

    That said, it’s an excellent build tool for a great many purposes it’s used for, because of the level of control and the low level of specification required by people who know what they’re doing. I like the directions lots of other tools are going, but nothing other then ant is getting a huge following, and it comes with many people a taint of Java (which is a four letter word to many people who aren’t java devs).

    3. We don’t really give two craps who you are.

    I personally like your game. But in general, a lot of the REALLY devoted people you want to answer your questions can have their head down in linux related stuff so much they have no clue who other people are. Also, their livelihood isn’t predicated on getting jobs necessarily, so they’ll frankly give you the finger if you’re nasty or will return nasty back at you. There is much more to linux development than anyone can ever learn, and being sure of yourself is just a recipe for sure embarassment in this world. I’m a pretty self assured guy, but I go and put on the humility hat whenever I ask for help or make statements about the tools. I don’t care personally about the adoption of desktop linux, and lots of people you need to answer your questions don’t either. And really that’s the only benefit braid on linux brings to linux. It’s another “Look, there ARE games on linux” sucess story if you get it working.

    4. If you do this correctly, braid should port to OS X with little additional work (and using similar libraries and tools).

    And your knowledge of the tools will port near completely and you’ll be able to understand the differences more easily.


  80. Jonathan Blow Says:

    Michael, your post is a shining example of the problems I have when trying to talk to the Linux development community, with regard to game development at least. Thanks for telling me “You don’t need to do that” and “You’re doing it wrong” and “Linux is really the best if you just change your standards and learn to love it”.

    I have been using unix operating systems for 19 years (since before Linux existed)! This is longer than most Linux users of today, so when they assume I am somehow inexperienced, I just have to laugh. I learned C and C++ almost 20 years ago using gcc and gdb and I wrote programs that, at the time, seemed kind of sophisticated to me (though they were baby programs compared to what I am doing now). This is not a “new area” for me as you are assuming.

    It’s been 20 years, and gcc is still pretty much the same! gdb is still pretty much the same! Make is still pretty much the same! These are the key tools of software development and they have not changed in 20 years (apart from, say, improved C++ support in gcc). There’s a word for that: it’s called stagnation.

    My posting here was not even about Braid. I may have Braid ported to Linux, but I will pay someone else to do it so that I can spend my effort working on my next game. This was about adopting Linux as my primary development platform for all future projects. I wanted to do this because I find Vista to be frankly sickening. However, as bad as it is, Vista is still my best option. I can’t get work done efficiently enough on Linux.

    Yes, if I had many man-years of my own time to spare, I could write a lot of scripts and modify all my development tools until they do a few of the things that I want. But then I would never get my game done!

    Games are harsh and brutal. They require every ounce of attention that the developer can put in. Any less than full attention, and the game is going to suck, or fail to be finished at all. I can’t be screwing around spending months or years writing new tools.

    I am saying that the development tools on Linux are bad, not because I am somehow uninformed, but because I have spent a while using tools both on Linux and Windows, and have experience across both platforms, and from my perspective, having gathered all this information, the development tools on Linux do seem well below par.

    (If you think “popping between threads” is a “fine-controlled feature that will blow your mind”, then you are not even in the same ballpark of expectation as I am. Dude, that is a basic, basic piece of functionality without which any debugger is useless for modern development.)

    It just amuses me that I keep getting responses like yours; and it only amuses me because I don’t permit it to frustrate me. It’s this defensive reaction wherein, if I find something lacking about Linux, then according to “the community” it must be because I am inexperienced and ignorant and arrogant, or any other kind of wrongness that can be conjured up. Well, I don’t think that’s the case. I think the development tools are clearly judge-able as bad by anyone who has experience on both platforms. Even beyond the basic gcc/gdb/make stuff, we can start talking about performance and rendering-oriented debugging. Have you ever seen PIX? Have you seen D3D’s debug modes? Have you seen someone step into a vertex shader in Visual Studio? These things stomp on the Linux environment’s face, with steel-toed boots, that are covered in spikes everywhere, where those spikes are made of depleted uranium.

    And as game developers, we often find the Windows environment lacking. It is obviously flawed in a lot of ways that cause problems for us, that prevent us from doing what we are trying to do in an efficient manner. So even with all that stuff I am talking about, if we still find Windows frustrating, you can imagine what we think of Linux.

    I think maybe there is just a difference in perspective here. Game development is very complicated and very demanding and in order to craft a high-quality experience we need a lot of precision over what we are doing.

    Almost all of the apps you see developed on modern Linux systems are pretty simple compared to high-end games, and that might be part of the problem. Maybe you guys just have a fundamentally different level of expectation. Like, if you think those programs are really complicated and thus it’s okay if they are just at the edge of what your development tools can accomplish, then that’s why things are the way they are now. When in fact maybe it’s the converse: those programs *seem* really complicated *because* they are just at the edge of what your development tools can accomplish?

  81. Aenin Says:

    Linux is built around a “metric ton” of programs that do one thing really well. It does NOT shine in integration.

    Yes, it’s easy to whip up small programs and applets to test things. Yes, you can dig around in the kernel fairly easy. The Linux kernel certainly is awesome, but last time I checked, users didn’t live in the kernel. I think we forget this sometimes.

    Integrated applications that provide extensive functionality or a seamless interface are quite rare on Linux. Part of this is because of the different mindset of the developers. We’re quite content to memorize a million different console applications, switches, configuration files, etc. It saves us time, after all. The other part is that the modern, graphical platform was built in bits and pieces, by thousands of individuals in different eras with differing visions of the future. And every time someone finds something lacking, instead of fixing what’s there, they build an entirely new interface to solve the problem. I.e. creating another incomplete interface and moving the target yet again.

    That’s why today you have so many different options, none of which is complete. Any time there’s a problem, a hotshot coder will insist that he can do it better from scratch. And if anyone has any complaints, they’d best memorize the source code before they even think of sharing it. Instead of, you know, doing the sensible thing and pointing out holes in the implementation.

    A platform is only as strong as its development tools. The tools must be there for your target developers. You’d think it’d be easier to please Jonathan, since he already uses emacs as his main (!) editor. He’s got extensive roots in POSIX-based systems. He already did a lot of homework before posting this. You’d think that the Linux crowd would give him some credit and treat his opinion like it’s actually worth something. Instead of just telling him to conform like everyone else.

    Linux is supposed to be about freedom. Free thought, free software, etc. It’s got some fairly good technical stuff under the hood. However, in terms of making software that works without configuring, it’s years behind everything else. And anytime people try and write an extensive software application for it, they run into limitations. The platform will never grow if we put on the blinders and insist that there are no problems. It’s wonderful that there are so many options for Linux. However, not everyone has the time to memorize each one and the strengths and weaknesses thereof. Some people really just want to get work done.

    I’d go farther (far beyond Jonathan’s statements and into my own thoughts) and say that, in general game designers are visual people. If you want games on Linux, build tools that game designers want to use. Don’t expect them to conform to a crappy environment. They have a clear idea of the atmosphere and feel of their games. If your platform won’t provide what users and developers need then it will stay a novelty, at best.

    Re: “You need us. We don’t need you.”

    Pardon my language, but what the hell is this? Conceited comments like this are untrue, unnecessary, and completely unhelpful. I’m tempted to uninstall all five Linux distributions from my computers right now and disassociate myself from it entirely. I hope you’re not representative of the Linux majority. I certainly don’t need an operating system with this as the community catch-phrase. I’m not down with your “1337″ pissing contest.

    By far, the large majority of gamers already have another operating system that is not POSIX-based. There is no “need” to publish games for Linux. Jonathan’s been trying to reach a demographic on their home turf. It’s not likely to make him nearly as much money as any other platform, and porting software doesn’t satisfy artistic vision. Many people recognizd this and have posted comments attempting to help. Jonathan, thank you for putting forth the effort, of your own will, to introduce a high-quality game to an operating system that is desperately in need of attention. Take a break from it, if you need to. Maybe the OS and the community will mature further in the interim.

  82. GimbalGambit Says:

    > “These things stomp on the Linux environment’s face, with steel-toed boots, that are covered in spikes everywhere, where those spikes are made of depleted uranium.”

    LOL… thank you for that, Jonathan… and for keeping such a good attitude while a bunch of people try to teach you how to write code. :)

  83. markus Says:

    Jonathan, Linux is a collection of horrible API growth.

    There is no smart leader that oversees all what a modern OS should really be able to do, yet at the same time they seem to be confused why the adoption rate is so low …

    I have hope that Ubuntu might even gain as much momentum that what SHOULD be possible WILL be done, because I think Mark is a great guy.

    But otherwise, the whole *nix situation is just a collection of misdesigns. People still follow the FHS and extend it, believing that it will help (but it is instead a problem of its own, and noone will change that)

    The only good thing for Linux is that the commandline stuff really can be great. This is surely only for few people, but for these few they will really be able to be very productive – a typical server OS.

    PS: You made a few mistakes though.

    “Make is still pretty much the same! ”

    Actually make is one of the few things which really improved over time :) it still sucks that a Makefile requires idiotic tab, but other than that make is fairly easy and straightforward. You should read how many people bitch about autoconfigure AC_* macros! This is why scons and cmake have gained so much attention, they are – compared to AC_* stuff – a lot easier to work with!

    “the development tools on Linux do seem well below par. ”
    I agree with you about GUI stuff completely, and I can totally understand you. However the tools as such as not as bad under Linux, they just require more knowledge :(

    Personally I use Ruby for everything. Any minute I can spend in ruby instead of C or with awk/sed/vim are 5 minutes of life time gained when I dont have to read ancient docu, and the best thing is – i dont f*cking care about the underlying OS anymore. This is why I also promote python – the moment we can MOVE AWAY from shell scripts will be a HUGE gain for the new generation of Linux hackers. The younger ones. ;)

  84. Meneer R Says:


    >When in fact maybe it’s the converse: those programs *seem* really complicated *because* they are just at the edge of what your development tools can accomplish?

    This is an unintended and unfortunate side-effect of the multitude of tools. The defacto standard tools are indeed, as you calll, in stagnation.

    There are alternatives, but they never seem to gain ground, because a toolchain, from an infrastructure perspective is the core of an ecosystem.

    Unlike the kernel, that has a benevolent dictator, the defacto toolchain does not have such a thing. It doesn’t even a roadmap.

    All of these tools are being supported; but there isn’t anyone working on a new generation. A next level.

    I can’t really speak for Visual Studio [i haven't developed on Windows for such a long time] ….but it seems quite obvious that the GNU toolchain is just stagnating and that the best hope; the sort of project people would rally behind; the MONO project; is a clone project ..

    What fragmentates the market even more is the shift to webbased software. For a large class of sofware (intranet, database, etc.) the browser has become the dominant middleware.

    Which removes a large incentive to improve the old toolchains. What’s left are a handfull of desktop apps, games that still use the old toolchain. We don’t use the GNU toolchain on the server side .. we use it less and less for the desktop apps where we can sacrifice performance and just go with a dynamic language .. .. and well …. ..

    .. you can’t expect a complete toolchain to be maintained by game developers … esspecially when there is little commercial benefit to do so..

    So, I think this stagnation you speak of, is because we are in some sort of transitive state where the browser (or something like it) will become the next middleware .. the new platform.

    At the beginning we were put downloadable DLL’s in the browser (activeX) .. now we are putting html-and-javascrit engines in desktop apps. It seems quite clear where we are headed.

    But some (presumbly large) game company needs to submit those patches for Gecko and Webkit to allow a 3d canvas with shader support. That would change an industry overnight.

  85. J Says:

    this is not related to windows/linux, but is to Braid development. perhaps this is the wrong place for this, but anyway…

    it seems to me the interesting graphical thing Braid does is the extensive use of particle effects. things that would not traditionally be considered a particle are treated as such and use particle effects to get the mesmerizing “moving painting” effect. is this a Braid innovation? to your knowledge are there other games that use particles in similar quantities and ways?

    i was also surprised that you said Braid already pushes current gen PCs with its effects. naively, i think “oh, it’s 2D, that doesn’t require much horsepower” ;) so what is the most demanding part of Braid? since there’s not really much AI to speak of, again it seems like it must be the graphics. is it the particle effects again? are computers just not well optimized for particle effects? after all, current cards can push millions of polygons.

    i also saw in an interview that you said the music streaming is somewhat intensive (you couldn’t put braid on a PSP disk due to music streaming). is that because of the ability of the music and sounds to play in reverse and at variable speeds?

    i guess in general i’m curious as to what the hard parts are for a system playing Braid, resource-wise, as well as what you think are your main technical innovations in Braid. just playing it, although i certainly appreciate everything, it’s easy to take things for granted.

  86. Hundred Says:

    Don’t bother, Linux users are both arrogant and petty.
    They will not buy your game, and will not appreciate your effort.
    Linux has been a passing fad, irrelevant footnote in the history of computing for the last 8 years (since the dotcom crash).
    Move along, there’s nothing to see here any more.

  87. Colin Says:

    My suggestion would be to forget about a Linux version of Braid for now. When you finish the Windows version, maybe you’ll get lucky and it will run under Wine. If not, it’s probably easier to either fix Wine to run Braid or modify Braid to work around where Wine is breaking than it would be to port it natively to Linux.

  88. Alex Says:


    As a professional developer of industrial visualization software, I can only agree with essentially everything you brought up. A (very large) customer is currently paying us to port a massive simulation application to Linux. What can I say ? It is hell. And that’s probably still an understatement. We have to constantly push schedule. Not due to problems with our software, but due to problems with Linux and its development tools. The whole project is becoming a nightmare. And ironically, most of our developers have had extensive experience with Linux before. But nobody thought that it would become this bad.

    The dev tools available under Linux are an incredible pain to use. Their primitivity is astounding. GDB is next to unusable with modern C++ code, crashes constantly, and makes you feel like you just time warped back to the beginnings of the computer age. It is beyond my comprehension how anyone in their right mind can by happy with these so-called tools. My only explanation is that they just *don’t know* what possibilities are offered by a modern development environment. Or maybe it’s just cognitive dissonance.

    And then there is the documentation. Or better, the complete lack thereof. The mere thought of comparing incomplete, imprecise and not up-to-date man pages with, say, MSDN gives me cold shivers down my back.

    Anyway, as much as I’d like Braid to get the largest market penetration possible, my suggestion would be stay the fuck away from Linux yourself. It’s just not worth the time, money and sanity you’ll lose. Just hire some masochist somewhere to do it for you…

    About IDEs under Linux. After extensively researching many possible alternatives, after weeding out the complete garbage (KDevelop, Anjuta) from the not-as-bad-but-still-garbage (Ecplise, Code:Blocks), we finally settled on Netbeans with CND:


    This is as near as we could get to VS under Linux. Still beta, but has a very active and very non-GNU professional development team. Bug reports and feature requests are taken very seriously. The whole thing is backed and managed by sun. While it still suffers from the limitations of the underlying tools (especially GDB), they do their best to work around them and to make the shortcomings as transparent to the user as possible.

  89. Jonathan Blow Says:

    J: Braid doesn’t really push high-end PCs at all; they can handle the game pretty easily. But the Xbox 360 is significantly slower than a new PC in several ways, and it has its hands full with some parts of Braid.

    The fill rate comes not just from particles but from the many layers of translucent bitmaps we are drawing in order to achieve all the parallax.

    And yes, the problem with the PSP is that the music could play at any rate at any time. If the songs always played at 1x forward as in most games, I could just stream them off the UMD.

  90. Michael Says:

    Have you considered Solaris? OpenSolaris is really nice and Sun Studio is available for free, dtrace is also an awesome debugging tool. I know that OpenSolaris doesn’t have the same following Linux does but it’s a really hard to beat platform, it’s also nice having guaranteed backward compatibility.

  91. Michael L. Says:

    > it must be because I am inexperienced and ignorant and
    > arrogant, or any other kind of wrongness that can be conjured up.

    Or perhaps you continually come off this way in your information gathering threads as you have here? I was pre-warned about this by friends in the game industry before I read your blog, but I still came to mention OpenAL (which the gentleman from Loki already had, so I instead suggested writing a tool and stop acting like a whiny teenager). Whether you are new to this or not, you come across exactly like a IDE-only windows developer the first time you hit unix with your poetic disbelief that people could generally eschew IDEs and integrated debuggers.

    >I think the development tools are clearly judge-able as bad by
    >anyone who has experience on both platforms. righteous anger that its suggested the great Jonathan Blow use the tools
    >on the platform he’s trying to work on, and further comparisions that only
    >he is making>

    No one else is saying anything about the tools being better or worse except you. You stomped on someone who suggested gcc/gdb can be powerful because they said make was something they find useful! I wasn’t saying that switching threads was powerful, I was saying gdb has many powerful ways to debug things. You can write 10-15 lines of C code to then compile a special way in gcc to then switch thread contexts in a highly predictable way then dump data out a socket when condition X occurs. That is exceptionally powerful.

    >Almost all of the apps you see developed on modern Linux systems are
    >pretty simple compared to high-end games, and that might be part of the
    > problem. Maybe you guys just have a fundamentally different level of >expectation. Like, if you think those programs are really complicated

    *lol* All of the apps I see? No, I went from military testing/calibration systems, to emulators of custom processors, to embedded set top boxes squeaking the high quality HD video decode performance out of underpowered chips while running custom web browsers to display channel guides to porting linux to run on little bitty arm chips to decode H264 decoded video on gas pumps. None of these are very simple at all. I’m guessing at least 1/2 of those are more complex than the games that are coming out of your shop, and I try to avoid the huge projects. You may be able to conjure up some strawman developer, but the person I know who has the *simplest* job programming linux software write HD encoders….and that isn’t simple.

    Do *not* mistake linux *game* development for linux *software* development.

    I am *sure* you’ve compiled and even written a few programs on linux, but I’m equally sure from your lack of civility that you’ve not developed much in the way of large, modern linux applications, because success in doing that involves asking questions politely and getting your information*, not starting flame wars. Other than web browsers and the kernel themselves, *most* of what you get in ubuntu or whatever isn’t a large scale linux application.

    And also, I recommended spending a couple hours writing a tool to debug something you understood partially rather than learning a new thing, and mentioned this is because tool writing is easy on linux, then gave an example of doing so. And if you are not using tools to make your games that you have written, you’re doing very wrong.

    Tools (written inside the shop) are a very big part of game development, and you’re the one out in left field if you think they’re not. Hell, there are entire divisions of tool development in large shops, and even you should be using hand tools to do tasks that could be repeated someday.


    *You have to be civil and ask questions because the documentation available is beyond the pale in terms of being old and poorly maintained.

  92. Michael L. Says:

    “using hand tools” should be “using hand created tools”

  93. Jonathan Blow Says:

    “… not developed much in the way of large, modern linux applications, because success in doing that involves asking questions politely and getting your information*…”

    Putting aside the question of whether or not this is true… you are stating this as though it were somehow a good thing? Or, in fact, anything but a horrid, deplorable thing? I want to write software! I don’t want to hang out on forums and mailing lists and spend weeks reading them and searching here and there for little tidbits that might, just possibly, relate to the thing I am trying to figure out.

    Every hour I spend doing that stuff is an hour that I was not working on the actual game, and thus, when it is finally done (if we assume constant development time), the game will be one hour less good. This is exactly my point.

  94. Hamish Says:

    Hey Jonathan,
    would it be easier to bypass linux all together and make a port that works in a bundled version of WINE? Kinda like google does with picassa and google earth. That way you’d only have to get it working in your controlled wine sandbox. In theory, it would be a LOT less work.

    You’ve probably already thought of this, so please reject this post if you have. Anyway nice game Jonathan! Good luck!


  95. Justin Carmony Says:


    I’m sorry you’ve had such hostile response from some people. I applaud your investigation into Linux as a development environment. I’ve tried the same myself before. I can totally empathize with the concept of “every hour spent elsewhere is one hour less on the project.” Tabling a project makes sense, and some “zealots” just don’t get it.

    I look forward to Braid on the PC and your future projects!

  96. .net coder Says:

    Hey Jon,

    Don’t bother with commercial software on linux, it is in no way worth the hastle. The users are the cheapest yet are also the most demanding.

    I would also like to suggest that you consider not releasing on the pc as well. Most of the people that play it on pc won’t pay for it, so your time may be better spent working on a new console game.

    The xbox arcade is only $200, so most of the people that will pay for it already have.

    The best way to target linux users is through web apps as a bonus pickup. Everything else is a waste unless your product is server related.

  97. Jason Noakes Says:

    “Every hour I spend doing that stuff is an hour that I was not working on the actual game, and thus, when it is finally done (if we assume constant development time), the game will be one hour less good. This is exactly my point.”

    Stop peddling the straw man argument. I develop on Linux and Windows and both platforms have learning curves, pros, and cons. You see Linux as difficult simply because you are more familiar with Windows. I bet you didn’t learn development in Visual Studio, all the Win32 and D3D APIs, and all the quirks of the system in a few hours, so don’t expect the same from a completely new platform either.

    I’ve spent just as much time in forums and scouring the internet for solutions to crazy Win32 behavior that wasn’t clear from MSDN as I have for POSIX and Linux behavior that wasn’t clear from the man pages.

  98. Jonathan Blow Says:

    Jason, all I can say by way of elaboration is, it is different in some fundamental way between the two platforms.

    For example, I just shipped a game on the Xbox 360 where I was the only programmer. I had never seen the platform before. Yes, the APIs are kind of like Windows, but most things behave in their own weird ways, there are lots of quirks and bugs, and there weren’t even necessarily forums where you could go to find things out. (There’s an NNTP server, but often what you want is just not there).

    However, it all worked out all right in the end. I could get things done whether by asking around, reading header files, or just trial-and-error in C++. The reason is because, at the low level, the APIs allowed things to be done, unambiguously. The system software fundamentally understands the kinds of things I might wish them do, and makes them possible, even if it’s unclear for me at the beginning exactly how this happens.

    With Linux, I do not have this feeling. Witness the earlier comments in this thread about how it is in fact impossible to do some fundamental things in X11. I think that is the biggest problem: the system does not support some basic, basic things, and people have historically kludged around this with wrapper layer over wrapper layer, and the Linux community has come to believe that this is a good thing, when really it is kind of rubbish.

    And this leads to a very low quality of information. It feels like hundreds of people have told me “use SDL” when SDL is just too abstracted to do what I need. I just need something very simple, basic, fundamental audio-wise, but most people on message boards giving advice don’t stop to think about it, or else don’t have the same view of the problem space, I don’t know what really, and so the answer I get is inappropriate or just wrong. And that’s frustrating when it happens over and over and over.

  99. Chrismurf Says:

    I hear your frustration, and hope you find a way to port to Linux – Braid looks great, and I’d love to give it a try. I’m not sure if it’ll be helpful, but on the Audio front I’d point you at : http://0pointer.de/blog/projects/guide-to-sound-apis.html.

    It’s been accused of pro-GNOME bias and killing kittens, but I at least found it somewhat educational.


  100. bemo56 Says:

    This is probably a bit late, but you could just make a Windows version that conforms to the limitations of the WINE project (specified within their documentation). Let anyone using Linux that wants it figure out how to run it. Simple and kills 2 birds with one stone.

  101. Jason Noakes Says:

    Part of the reason that what you want on Linux doesn’t exist is because no one has written it yet. Linux is mostly written by people who do it because they want to. Many who have wanted what you want either didn’t know how to write it (and didn’t join the community to find out how to contribute), or just gave up when they saw it didn’t exist, brushing Linux off as useless.

    I understand that you just want to focus on games; that’s your choice. But don’t belittle the Linux platform because something you want doesn’t exist. It contains many important and useful things for many people. It’s not somehow “worse” overall than other platforms – it’s just different.

    For game development specifically, not many developers who are passionate about games and Linux have done the work for Linux that is needed to get it where you want it to be. If you are passionate about the future of games on Linux, help out. If not, go somewhere else.

    If you don’t like it, help change it. If you don’t have time, then don’t bother. This isn’t the community rejecting you – this is the community asking for help. Don’t say “If I can’t do this, Linux sucks” – say “How can I help Linux do this – it’s important to me to solve this problem”. The answer may be “develop or improve a library” – that’s how Linux works. If you aren’t interested in spending some of your time in this capacity, don’t port to a platform that requires that kind of thing.

  102. AMIGrAve Says:

    Hi Jonathan,

    I think your best move would be to ensure yourself that your game runs fine on wine and you should not loose time anymore on a Linux port.


  103. Jonathan Blow Says:

    Jason, I’ve been told that Loki tried this back in the day, and they were basically ignored. And they were even a company with employees and manpower to devote to these issues.

    Part of the problem is that these things are cross-cutting. If I were to start a Making Games Good On Linux Initiative, it would involve modifications to the X server, a few kernel modules, possibly some part of the kernel, gcc, gdb (or else ignoring gdb altogether and creating a more-integratable debugging library), some IDEs, etc. It’s a lot of changes touching a lot of diferent pieces managed by a lot of different people and I don’t have authority over those people, of course, so how do I know that this work is going to be incorporated by the maintainer of each piece? Probably more often than not I am going to get into the same arguments here about “You don’t want to do that” or “You can already do that by doing (horrible kludge workaround X which doesn’t really work, produces a low-quality result and causes pain for the end-user)”. If the work isn’t going to be adopted with any kind of certainty, then why should I invest all that work?

  104. Jani Mikkonen Says:

    Linux hater’s blog lead me to this blogpost and while it seems this topic has been discussed quite extensively, i’d like to mention another blog post which covers sound api mess linux has. Maybe it could give you Jonathan some ideas about the side stuff you where asking about:


  105. Stoffe Says:

    We love the Braid demo here at our (game development) company, and I would love and buy a Linux port. I don’t use Windows and I’m completely uninterested in owning an X-Box.

    I know I’m not the main audience, but still I want to let you know I’m here, and I’m NOT going to tell you that it’s your fault that Linux game development sucks. It does, because noone ever saw it as an important enough thing to put any effort into. Doesn’t mean it’s not fixable, but as with anything else, that takes a concentrated effort.

  106. MaurizioPz Says:

    Jonathan, I admire your willingness to still talk about porting to linux after all the negative responses you got.
    I hope you’ll succeed, I’ll like to play it on linux.
    I’m sorry that because some user have a bad attitude about the lacking bits in linux the whole community gains a bad image.

    LINUX IS NOT PERFECT. We know it, but some of us can’t seem to understand it.
    It’s a shame that when someone points to what should be changed, trying to help, some folks respond “than change it”. Not everyone has the time to change everything.
    A well written bug report should be enough to change. The developers should spend their time working on this bugs instead than telling people to fix their software.

    The fact that the source is free is not an excuse to ignore your userbase.

  107. Stoffe Says:

    Oh, and another path to go could be to try to use Winelib, possibly with the help of Codeweavers: http://www.codeweavers.com/services/engagements/wine_port/

    I’m of two minds if I should recommend that path. :) On the plus side, Wine and Codeweavers have the potential to let me run my old games (Grim Fandango or Planescape: Torment!) at some point in the future which I find extremely important (I view old Windows games as legacy documents, not applications, just like SCUMM games). So everything that puts some testing or even some money their way is good. Also on the plus side, it puts another great game on my computer. :) On the minus side is of course the way it’s not native and most likely will not fit into the rest of my environment (package manager etc). It may also be that Wine can’t (easily) handle your requirements.

    Anyway, thought I’d mention this. Good luck!

  108. Jannet Says:

    Have you considered publishing braid through Steam?

  109. zugu Says:

    Hi Jonathan,

    Please don’t follow the advice of .net coder above. Not all PC users are cheap bastards that will pirate your game. Actually, most of them are irrelevant since they wouldn’t have payed for the game anyway.

    So please listen to people who will pay for your game and code for them.

    Also, how about about using Valve’s Steam as a distribution platform?

  110. Davidoff Says:

    JB, I really wonder why you waste any time with Linux. As you already know Linux is just a mess, the kernel is a mess, APIs/ABIs (where existing) are a mess, and the userland tools are a mess, too. The release cycles are short, and every new release breaks compatibility with lots of functions and applications. If some part of Linux has flaws, it won’t get fixed but replaced by at least two new projects that get rid of that particular flaw but introduce a sh*tload of new flaws instead and break compatibility with anything else. Development is driven by personal egos and not by technical reasons. If one of the developers doesn’t agree with other people in the project he’s working on he leaves the project and starts a fork which is also incompatible to the original project but incorporates what he thinks is best. Of course because of ‘freedom of choice’ this fork has then to be supported by the main stream *additionally* to all other extisting programs that do the same. The community itself consists mostly of Zealots that live after a “open source and freedom for everything” way which has to be enforced on others if they want or not. It already has reached a semi-religious state where debates over to disallow closed source code get much more important than to get rid of all the mess and all the flaws Linux has. Head figures like Stallman are highly embarassing and show the attitude the Linux Community has, and this Community is also the reason why Linux is stagnating. It’s also remarkable that the ones that suffer from most attacks by the Community are the companies that actually support Linux and Open Source in general. If you develop for Linux but are not willing to make your programs or drivers open source then expect to be treated like crap by Stallman & Co. The whole “freedom” thing of Linux is just hypocrisis.

  111. Davidoff Says:

    JB, someone already mentioned Solaris/OpenSolaris, and I can second that. If as you say you know UNIX then you probably know Sun Solaris which not only runs on SPARC but also on x86/x64 (average PCs). Some time ago Sun has open sourced Solaris, so there is a complete open source version (OpenSolaris) available. Of course Solaris itself is still available for free from Sun, it has predictable life cycles, it has sane APIs/ABIs, it has a very good development environment (Sun Studio) which is also available for free, it has great debugging features (D-Trace), the world best file system (ZFS), it has virtualization technology that Linux only dreams of, it’s developed by sane people and not fanatic mostly incompetent zealots, it’s supported by a well-known established company, it supports a wide range of hardware (not as much as Linux, though, but still runs on the majority of systems), and it lacks the semi-religious community (although there is an OpenSolaris Community which consists mostly of professionals). Solaris is all what Linux could have been.

    Solaris/OpenSolaris is increasingly becoming popular even with Linux users (there are enough sane Linuxers that are fed up with the mess, the stagnation and the community), especially on the server (where Solaris wipes Linux in every aspect) but also on the desktop. If you can I really recommend to have a look at it because I’m sure you will find on Solaris what you were looking for on Linux. You very likely won’t regret it!

  112. Daniel Lehmann Says:

    I too hope you are not discouraged by those negative comments. I would like to see this game on Linux. Maybe we could take this as a chance to improve Linux in the areas you suggested. Maybe you could be supported by the Ubuntu community or even Canonical themselves?

  113. Daniel Lehmann Says:

    I created a Ubuntu Brainstorm entry here:


    Maybe this does end up in a win-win-win situation. Thanks for all your efforts so far!

  114. Steentje Says:

    I’m just blown away by the comments in this thread. Why are so many people continuously telling JB that he’s a newb? I mean, sure, the FIRST one to say so in this thread, I can understand. Every next one saying so, that’s just dumb, or lazy. If you want to argue with someone, please read what they’re arguing first.

    I applaud JB for not giving up completely, and instead of frustrating himself, outsourcing the port. It’s great that he wants to pay for that, investing in a platform which gets ignored by most game makers. Seriously, thank you very much for that.

    I recognize the “you don’t want to do that” response. I’ve seen it many times over. I don’t understand why anyone thinks having to beg for API specifics is acceptable, either. If devs get sick of the same question over and over, maybe that’s a hint that it belongs in documentation. It’s really quite sad that this has remained an issue despite corporate interest in linux generating millions in revenue.

    Linux is absolutely wonderful once it’s working, because it tends to keep on working forever. However, as soon as you have some update or some sort of config change, it may stop working, and it’s a pain in the ass to figure out why. The only reason it might seem not so bad, is because it was a lot harder to get things to work the first time around.

    I still prefer using linux for everything, but seriously, the above issues are very real, and flat-out denying them or saying “it’s in development” just doesn’t sound convincing when it’s been over a decade since the linux kernel, and much longer since the start of gnu. This open source movement predates windows, and it just has no excuse to be any worse. It may have an EXPLANATION, but that’s not the same thing as a reason to forgive the stagnation.

    One last thing… Why is it so bad to want a GUI-oriented IDE? Wasn’t the whole purpose of the OSS movement to encourage and support diversity based on want instead of tunnel-vision ego-maniac marketing people deciding what people ought to want? Why do people think it’s okay to tell someone what interface they ought to want to use?

    The main reason I chose and continue to choose for linux, is because I can choose whether I want it in GUI, or in CLI. I’m free, and greatly appreciate this freedom. Conformist pressure to use CLI is not just elitist, it denies the very liberty that linux is supposed to offer.

    Excuse the rant, I just needed to get that off my chest.

  115. Dennis Says:

    To get untransformed mouse events you might want to use libXI. The xorg mailing list should be the right place to ask.

  116. Stoiko Says:


    We really enjoy your game here at our gamedev shop. Good work!

    As for the Linux side of things, i’m writing a game using SDL/Opengl simultaneously on the Windows and Linux. These OS-es are actually so close in terms of game development, that my codebase is almost the same for both *nix and Windows. For a long time I was developing in VS and later ported to Linux and now im coding in Kdevelop and port to Windows like about every week. There are number of benefits (stability, structure and overall better code quality) when you code in a multiplatform fashion from the start and im sure that you are aware of that.

    So please dont give up on that Linux version yet. Keep your code multiplatform, and release the game on Linux if you feel it matches the quality of its windows twin.

  117. Wayne Says:

    This reminded me , back in the day at uni we laffed and laffed at comedy sound samples being played remotely on the (victims) Sun boxes across the comp sci lab. Tthe sun boxes had an internal speaker and we jsut ftp’d a sample and telnetd on to issue this this:

    cp audio.au /dev/audio

    The point? Well, perhaps the simple modern Linux equivalent

    cp audio.wav /dev/sound

    or summit?

    carry on…

  118. David Says:

    As usual, the OSS community comes and shows it’s ass. Of course Jonathan is keeping his cool. These humorous little zealots are about as relevant as the guy who stands on the street corner and screams at you about the end of the world in 3 weeks.

  119. Anon Says:

    “Time to put on your humility hat, not your ridiculing asshole hat. You need us, we don’t need you. There is a lot of black magic and dragons in linux development, and one of them will eat weeks of your time if you aren’t careful.”

    Hey, nice Eric Raymond impression!

    I’m sure that the fact that the feasibility of his project depends on the whims of a bunch of arrogant zealots has no bearing on the decision to tackle it.

    Hint: a Linux port of a console title is a labor of geek love, it really does not make any economic sense at all. Since the general attitude seems to be that any real-world consideration such as budgeting must fly outta the window anyway when developing for the Glory of Linux, maybe it’d be wise to be nice to the guy who, by the way, is hosting the discussion?

  120. John Doe Says:


    Ignore those Linux lusers and focus on where the money is – the Windows users. I’m willing to shell out cold hard cash for “binaries-only” copy of your game.

    Focus on where it matters – gimme game I can play, I pay you money and I keep it for my self. I don’t share it with Linux lusers.

  121. Brian C. Johnson Says:

    The core problem is, simply “Learning Curve”. Having worked on all the major consoles, various versions of Linux, Windows, MacOS, etal, one thing keeps coming up, over and over again:

    It takes a lot longer to learn the Linux environment than any other environment. All the apologists in the previous postings have said the same thing. “You just have to learn the environment.”

    No, I don’t.

    When you’re trying to make a profit, that Learning Curve is going to determine which platforms your product goes out on, plain and simple. And the Linux Learning Curve is prohibitive to Game Development.

    The Linux community, if they want professional, high-end games, are going to have to come together, and create a better environment for the developers who don’t know the OS.

    Until that happens, it’ll be the same arguments, over and over again. And games still will not be ported over to the linux environment.

  122. Jason Noakes Says:

    From Loki came the SDL, which many hold as a vast improvement in game development over the previous libraries on Linux.

    Loki may have shown that there wasn’t a large market for games on Linux – I’m not surprised. But what’s your point? If you don’t want to put in the effort to port to Linux because the market isn’t big enough to make it worth your while, that is a very different problem than not porting to Linux because the platform is inferior in your view. I happen to disagree, but look at it this way: even if you had tools on Linux that matched you perfectly, there still wouldn’t be a market.

    I understand the cross-cutting concerns on Linux. The same concerns exist on Windows – they were just solved by a large team of paid developers. If someone paid a large group of Linux developers a lot of money and they were asked to create a state-of-the-art game platform, they could do it as well. There’s no fundamental difference here. In fact, many people consider SDL to be more useful to their type of game development than DirectX and Win32.

    You can see from this thread that there are already people working on improving sound, X, and other things, and they are doing it in their spare time. That’s impressive if you ask me.

    I still believe that if you want to see your game on Linux, or any future games on Linux, you ought to donate some of your time and help out. Write motivating articles (like this one, but with more specific details) and get the various cross-cutting projects interested. Suggest specific improvements. Make some changes and demo how important they are.

    If you don’t have the time, then as I said, Linux isn’t your platform. This isn’t a knee-jerk reaction from a Linux zealot – this is simply me explaining why it is this way. Many people react negatively because after they work hard in their free time making Linux what they want it to be, developers from other platforms jump on board and the first thing they do is criticize Linux for not being the same as their old platform. Your comments may have been much more constructive, but they can easily be taken negatively (especially when you say things like Linux development tools are terrible compared to your platform), which will instantly put off many from the Linux community.

  123. Igor T. Says:

    Having done extensive work in the driver industry related to hardware used at the graphics card level on both major companies used by the wide linux public, I can say this:

    1) GNU/Linux sucks less than it sounds, but it still sucks quite enough to be annoying in terms of actual development. These are a bunch of kids that need to grow up and understand that they are the less than 1% of the market. In other words, they need us, we don’t need them. The reason why ports are made to their platform is not because there is a need to do so in general, but because a client has asked us to due to the fact that gnu/linux is the lego of the operating systems and therefore customizable in certain application niches. Note that I say niches.

    2)I don’t agree on the fact that GCC is a horrid piece of s*it. It IS actually better than the default thingies comming from a major company that dominates the OS platform today. Usually i prefer working with intel compilers nowadays. GDB’s quality is not a valid argument since today we are doing unit testing in C++ code most of the time. However yes, it is utter crap and it would not pain me at all to have something better.

    People involved into GNU/Linux should think about something simple: Castro did not deal out capitalism from Cuba, he just converted it into statal capitalism.


  124. Brian Says:

    >If someone paid a large group of Linux developers a lot of money and they were asked to create a state-of-the-art game platform, they could do it as well. There’s no fundamental difference here. In fact, many people consider SDL to be more useful to their type of game development than DirectX and Win32.

    Actually, that *is* the fundamental difference. Linux thrives in the enterprise, where money is being poured into it.

    We’re seeing some money being put into desktop Linux by Mr. Shuttleworth, unfortunately though he is not tackling the fundamental problems that plague desktop Linux, specifically “openness and choice.” I know this is likely considered blasphemy by some, but if Linux is ever going to be successful on the desktop, they need to devote their resources to the kernel, one window manager, and one software stack, and then improve where lacking and integrate. There are far too many distro’s for any ISV to ever want to try and support, hell, even Ubuntu has Ubuntu, Kubuntu, Xubuntu, Edubuntu… it is ridiculous.

    Develop a platform, and people will come. Develop a million implementations of various functionality and cobble it all together, and enjoy your habit.

  125. RandomGameDeveloper Says:

    Jason, some response to your comments:

    >> In fact, many people consider SDL to be more useful to their type of game development than DirectX and Win32.

    Not professional game developers, which is the case of Jonathan here.

    >> Many people react negatively because after they work hard in their free time making Linux what they want it to be, developers from other platforms jump on board and the first thing they do is criticize Linux for not being the same as their old platform. Your comments may have been much more constructive, but they can easily be taken negatively (especially when you say things like Linux development tools are terrible compared to your platform), which will instantly put off many from the Linux community.

    The Linux community should be able to handle criticism, get out of their religious stand and try to understand the needs that the platform is supposed to fulltill. The opinion of the tools in Linux being far behind Windows is shared by lots of people, saying that you are just “different” or that developers just need to learn the way is just not acceptable (or at least is going to put off many developers). The questions that the Linux community needs to ask are the following:

    - Who is driving a serious effort to provide a strong toolchain for Linux development at all levels? Is this Eclipse? Netbeans? Code Blocks?
    - Who is working on usability for those tools? Who is trying to improve debugging tools?
    - What is the graphics story for Linux? Is OpenGL the solution? What about sophisticated debugging tools for graphics applications?

    You are asking Jonathan to spend some time trying to solve those questions, but as you can see the scope is too large, the effort is non-trivial, and the expertise required too high.

    Jonathan might come across as an arrogant jerk, but that does not invalidate his criticism.

    Instead of taking a defensive stand or an apologetic stand, take notes, understand what he is asking, and if you have the power to do so bring up the issues with other Linux developers.

    The issue at hand should be easy to understand, the toolchain is dated, hard to use, and has a very steep learning curve. The story for graphics, audio, input, and other game development mandatory components is not really there. The first part is not inherent to game development, improvements on that front will help ALL Linux developers, amazingly enough there has been very few improvments in that front for a long time.
    The second issue is trickier to address, as you mentioned somebody interested on the topic should contribute.

  126. Scott Ritchie Says:

    The problems you’re running into are the same ones the Wine project has.

    Relative mouse movements, for example, has been handled by the hack you described earlier – moving the pointer to the center and then hoping it doesn’t escape the screen too fast.

    This, as you said, was buggy and incomplete. Which is why a Wine devloper (Francois Gouget) has been largely responsible for demanding a new freedesktop.org extension to X to allow relative mouse movements. That should be available sometime in the next 6 months (for the next x.org release), which is probably in the same timeframe as your game. The only downside is that your game then depends on the upcoming versions of the various distros.

    Wine also has a way of constraining the mouse cursor to a particular window when Direct3d demands it, but I’m not sure how it’s done. Honestly, ask our wine-devel list and you’ll probably get a good answer.

    And, of course, not doing a Linux rewrite of your application and instead porting with Wine is always an option. If your application already runs (or almost runs) in Wine, this may be much easier to maintain and much, much cheaper to do. Codeweavers offers such services, and as an added bonus you get a Mac port for free too.

  127. Scott Ritchie Says:

    Oh, regarding Stoffe’s comment about Wine ports:

    Wine itself is a native library, and applications can be well integrated with a bit of effort; this includes installing the program with the package manager and putting links into the proper spot of the Applications menu. Aside from Wine bugs, there’s no reason a port with Wine needs to be any worse than an application ported through other means – fixing those Wine bugs and providing that packaging is exactly the service Codeweavers sells.

    (disclaimer: I’m a Wine developer, but don’t work for Codeweavers. I make the free Ubuntu packages and am working on some better integration into the desktop myself)

  128. Michael L. Says:

    >>“… not developed much in the way of large, modern
    >>linux applications, because success in doing that involves asking
    >>questions politely and getting your information*…”

    >Putting aside the question of whether or not this is true…
    >you are stating this as though it were somehow a good
    >thing? Or, in fact, anything but a horrid, deplorable thing?

    Are you capable of talking in anything but histrionics, or do you think that’s a mandatory part of a sentence, like punctuation?

    You don’t get it. You really missed it.

    I, nor anyone else that I can see on this entire thread, are saying THIS IS BETTER or THIS IS GOOD. Some people have said its different. Some have said, its a matter of opinion. Other have said there are some powerful tools available. We’re saying “this is how it is”. Grow up and talk in even keeled sentences that aren’t 90% rhetorical pap. Work is very doable, and there are very powerful tools available. If you’d like to go rhetorical and not actually look into them, well, then you’ll fail.

    Linux is this way because they don’t have a very large company pumping billions of dollars into supporting their operating system who has the power to create a massive API for you. Only when companies do that do we get something as cohesive as what comes out of large companies. You have linux fanboys confused in your mind with actual software developers. We know how crappy parts of linux development are, the amusing thing is that you don’t need straw men to attack linux, there are piles of actual shitty things lying around that are easy to point out as flaws.

    >Every hour I spend doing that stuff is an hour that I was
    >not working on the actual game, and thus, when it is finally
    >done (if we assume constant development time), the game
    >will be one hour less good. This is exactly my point.

    Ahh, so the 80% of your internet posting time you spend writing overblown bon mots doesn’t make your games JonathanBlowsInternetPosting * 0.8 less good?

    Sounds like you’re not ever going to have the ability to put out a native linux game. I’m going to second another poster and recommend you make sure WINE doesn’t work for you *right now* before you spend any more time on research about actual linux compatable APIs.

    I think it’s much more suited to your temperament then having to interact with humans to get information (like you’re going to keep having to do if you use the quantity of linux APIs you will need to have a game creation environment working). It’s probably also a good reason to stay in business for yourself, as its one of the few places people who are committed to this style of communication have room to excel in. I recommend a book on that called The Illusions of Entrepreneurship by Scott A. Shane further on in that vein.

  129. Jannet Says:

    Michael L, you’re obnoxious.
    Screw you, and screw your “Linux” thing.

  130. Sarastic Developer Says:

    Wow. Michael L. is fucking hardcore. He can program Crysis in assembly using only a simple text editor, and it only takes him 2000 years. Meanwhile, Jonathan and other developers are just weaksauce since they don’t have all the time in the world, and they must rely on the Devil’s tools like Visual Studio to improve their productivity. Because in the end, it’s not completing a game on time that matters. No, it’s how hardcoe you are and how big your ego is. It’s how many years you wasted trying to get simple things in Linux to work that matters. And like Michael said, instead of trying to complete their games in a timely matter, they should just devote their time to making Linux a better platform. Because the community will appreciate that alot, and that appreciation will magically turn into profits, feed their families, and all those years wasted are magically returned.

  131. RandomGameDeveloper Says:

    Michael L, you are drinking the wrong type of kool aid…

    >>> Linux is this way because they don’t have a very large company pumping billions of dollars into supporting their operating system who has the power to create a massive API for you.

    This is not true, Linux has had lots of money injected into it, it also has very bright people working on it and some amazing projects. There is a strong group of professional developers making money from Linux. Jonathan’s criticism, regarldless of your perception of him, is very valid. Again, to reiterate, his comments are about how the prefessional tools on other platforms are better than the corresponding tools on the Linux side. For software development that is depressing, it shows that the Linux community has not invested heavily on this front and they are ok with this
    But it is NOT OK, because it adds yet another barrier to adoption, which at the end benefits the community (better tools, better applications, more developers, etc, etc), it is something so obvious and at the same time so broken.

    You get all defensive about this, and your turning this into a personal attack on Jonathan. Which is a very classic example of how the Linux community cannot take criticism, and how everything turns into a religious fight for them.

    Your comments show this clearly:
    “this is how it is”
    “It is often easier to develop software than to find software on Linux”
    “Make is a tool that is exceptional for many purposes”
    “We don’t really give two craps who you are”
    “Tools (written inside the shop) are a very big part of game development”
    “You need us, we don’t need you”

    This shows that you think that you somehow represent the Linux community as a whole, that you are as arrogant or more so than the people you are trying to attack, and that you have no freaking clue of how games are written (Trust me we do not spend time writing our own IDEs or debuggers for C++)
    Two gems from your comments, you say that gdb will blow our minds, you also say that make is very good. You are obivously years behind in the state of the art for both debugging tools and build tools.

    Programmer productivity matters, and matters a lot. This is something that the Linux comminity does not get.

  132. Scott Ritchie Says:

    >Sounds like you’re not ever going to have the ability to put out a native linux game. I’m going to second another poster and recommend you make sure WINE doesn’t work for you *right now* before you spend any more time on research about actual linux compatable APIs.

    Even if Wine doesn’t work, it may still be cheaper to pay Codeweavers to fix Wine than to rewrite your application. Sometimes what’s missing is actually a very small bug.

  133. Linux user Says:

    Developing and distributing commercial applications for linux is a nightmare. The lack of any kind of standardization, API and ABI compatibility between versions and across distros is mind boggling. It is even more frustrating, when in fact this would really be a non-issue if the distros collaborated on providing a standardized set of tools that would be supported in a non ABI breaking fashion for several years (along all the latest and “greatest” masturbatingmonkey-4.2.3-kubuntu7.4-beta.omega binaries that they choose to include by default).

    Knowing that “collaboration” is a foreign term to the OSS community, one would expect that failing to provide compatibility across versions and distros, the next sensible approach would be to provide tools to make deployment trivial across all the flavors of masturbatingmonkey. And in fact there are deployment tools, except they are not standardized either, and there’s almost as many of them as there are major distros.

    And people wonder why there is no interest from major software vendors to deploy on the linux platform… But hey, according to some comments above “We don’t need you. You need us.” … Yeah that’s right you somehow need “us”, never mind that “we” have virtually no market penetration on the home user desktop.

  134. IG88 Says:

    Honestly, you’d be far better off just making it for windows and then spending the time you’d otherwise waste on porting to start your next project.
    Sorry…that wasn’t at all an answer to your question…but I had to go along with the conversation…

  135. Ryan Says:

    Jonathon, Like it or not, you’ve come across as very dismissive of something you come across as not understanding. Why are you surprised your negative comments got a negative reaction?

    No one is saying Linux is good. We’re just saying its not what you say it is. We’re not saying its because you aren’t smart, or have never tried to learn Linux, but because you haven’t yet succeed to learn Linux.

    You keep telling us how long you’ve been “using” Linux, yet you display fundamental misunderstandings of how it works. I’ve been “using” Windows since 3.11; but that doesn’t make me anyone you’d want to hire as a lead windows developer.

    Bottom lines here:

    - Each platform has its own history and culture, and it shouldn’t be surprising that the culture take a while to get used to, or that it favours one kind of development over another.

    - Games developers have their own sub-culture. Windows developers have their own sub-culture. Linux developers have their own sub-culture. Game developers need what Windows gives them, and will always find Linux lacking — short of some company like Sony devoting MS-like money *solely* for solving the problems you mention (recall SDL came from Loki).

  136. Greg Says:

    This game looks absolutely stunning. That list of reviews on the front page has definitely piqued my interest – it sounds like the kind of beautifully crafted game experience that has been missing from the game development culture for a long time. Its awesome to see an indie game developer kick this much ass. I can’t wait to buy the PC version!!

    From one developer to another, please, PLEASE don’t waste any more of your precious time and energy on a Linux port. *PLEASE!!*

    You said this:
    “Yes, the PC version is on its way, but it might be a little over a month before it is released.”

    Take the time you need. If I come back in a month, and I see this flame war against the linux dorks is continuing, I’ll have yet another thing to hate about linux – not only has it wasted my time, it has wasted the time of a genius game designer/developer, and critically delayed the release of a masterpiece.

    Don’t worry – I’ll buy a copy of the PC version of your game no matter how long you take.

  137. Brian Says:

    >Game developers need what Windows gives them, and will always find Linux lacking — short of some company like Sony devoting MS-like money *solely* for solving the problems you mention (recall SDL came from Loki).

    So let me clarify: What you’re saying is that if someone wants something meaningful done on Linux, they need to be willing to invest millions of dollars? It’s incredibly ironic that you’ve identified the fundamental problem with desktop Linux while trying to defend it.

  138. Wayne Elgin Says:

    Note to self:
    Never, ever, ever, ever ask for help programming on Linux.

  139. Jason Noakes Says:

    I keep hearing people saying or implying that development tools on Linux are lacking and worse than those on Windows.

    I’d like to be more specific here, because I develop on Linux and Windows, and the only way I can get any real work done is to use a Linux-like layer (cygwin) and the gcc compiler, make program, shell, and gdb debugger on Windows.

    Some of you may believe that *IDE* tools are lacking on Linux. That may be a fair statement; I have no experience with IDEs on Linux. I think if you are the type of developer who likes Visual Studio, then you won’t like many of the options on Linux.

    However, for those of us who prefer a different set of tools for development, the command-line toolchain on Linux (and other platforms) is VERY good. The gcc compiler is up-to-date with respect to almost all of the C99 and C++98 standards, and also has support for C++0x. The GNU extensions are very useful and other compilers integrate them over time. The make system, if used right, provides a very simple way to express dependencies between modules. Developers who know what they are doing can use this system to build large projects efficiently, and most Makefiles allow many types of customization that would be more difficult with other build systems.

    My point is this – don’t call another toolchain “worse” just because you don’t like it. It may be different but it’s not inferior. There are improvements that can be made, but the same can be said for IDEs as well – nothing is perfect.

    Stop calling names and be constructive.

  140. Michael L. Says:

    >Michael L, you are drinking the wrong type of kool aid…

    >> Linux is this way because they don’t have a very large
    >>company pumping billions of dollars into supporting their
    >>operating system who has the power to create a massive API for you.

    >This is not true, Linux has had lots of money injected into it,
    >it also has very bright people working on it and some amazing

    Who’s invested >100 million dollars making game API’s for linux (remember, target of the you was Jonathan, who wants game APIs, I’m not talking about linux investment in general)? Microsoft has several different groups dedicated to gaming support. Linux has no companies investing that much on game APIs.

    >Jonathan’s criticism, regarldless of your perception of him, is very valid.

    -True, yes, valid in light of the discussion? Not really. The discussion was “How do I do X”. Jonathan turned it into a tirade against tools we don’t really like (and I and others have listed several deficiencies for). Reread

    > Again, to reiterate, his comments are about how the prefessional
    > tools on other platforms are better than the corresponding tools on the ? > Linux side.

    While he definitely expresses that feeling at length filled with colored metaphors, I was chiding him for attacking people who were trying to help him.

    >For software development that is depressing, it shows that
    >the Linux community has not invested heavily on this front
    >and they are ok with this

    Actually a large collection of linux developers don’t care about the state of the gcc toolchains. They write web software and software in high level languages rather than low level languages like C++ and C most of the time. They quickly get their lower level libraries compiled then stop caring, happy in their python/ruby/perl/cgi/wsgi/whatever worlds. Those of us who *do* still write system software in C and its ilk areas would love if someone dropped a godly debugger on our head funded by millions of dollars, but are no more eagar than you game developers to go write them. I, personally, don’t want to write it.

    >You get all defensive about this, and your turning this into
    >a personal attack on Jonathan.

    Have you read what Jonathan wrote? Do you think that’s an effective communication style to get information out of people? He has to cool that down. I don’t care if he wants comments on how to knit better, you start going off like he does *when asking people for suggestions*, people shut down.

    >Which is a very classic example of how the Linux community
    >cannot take criticism, and how everything turns into a religious
    >fight for them.

    Why do we need to be dressed down by someone who’d like some help again….? We didn’t ask for a summation on how Jonathan Blow thinks about things on the tools. He went into full scale ridicule mode on a dude up above (not me) because the guy said he found make useful.

    So lets take linux out of this entirely. Go back to knitting. If Jonathan came to a group of knitting experts, and said “how do I get a toe sock to work out when I’m using yarn X”, and he went off on a little old lady who said she successfullly uses yarn Y sometimes, would you be defending his going off on a random person? His communication style will not fly on the mailing lists he’ll need to ask questions on to get answers to work in this environment. He’ll get killfiled in an instant.

    My issue with Jonathan is that he’s an ass to people who were trying to help. I frankly *agree with both of you* that generic linux tools are far behind specialized commercial debug tools (which the particular debuggers he spoke of are). Guess what? Most projects I work on (and this is largely because I’m embedded), I buy a commercial debugger if I can!

    > This shows that you think that you somehow represent
    > the Linux community as a whole,

    No, I don’t. I do know, as you do, that no community answers questions from people who shit down their throats about how their way of doing things is so crappy, and how they’re not worth listening to. People like Jonathan routinely get ignored when they start going off like this, and I *do* think he’ll get no traction if he starts pulling this shit with them.

    > that you have no freaking clue of how games are written
    > (Trust me we do not spend time writing our own IDEs or
    > debuggers for C++)

    I don’t think you really follow what I’m saying. I’m not saying “write a debugger and an IDE” I’m saying to write a introspection stub in your application that makes debugging threads easier by introducing determinism into the thread changes then writing data out a socket is a short matter of 10-15 lines of C code when using gdb and gcc’s advanced debugging features. Didn’t ever say the things were better, just that they were powerful.

    I’m talking about the real, in the trenches tools that people doing hard things write to debug difficult bugs are often quite fast to write with the interfaces gcc and gdb provide. And whomever hired you may not do that sort of debug but it happens. I do know and am good friends with a number of flesh and blood commercial game devs who *talk with me about these sorts of tools* because we both make them to debug things in our work.

    >Two gems from your comments, you say that gdb will blow our minds

    No, I say the many ways to do many common debugger tasks will. The fact you can change threads in the UI, based on changes in the data, programatically in a C handler compiled into your program or remotely via a debug header is what’s amazing.

    Jonathan misread that to be an endorsement of the debugger and an example of some new fangled features, when it is in fact the fine grained options for each of those mechanisms that I find compelling. Can D3D’s debugger do all of the above?

    >you also say that make is very good.

    “for some tasks”. Show me that its not very useful for some tasks please? Oh yeah, that’s logically impossible.

    Make is *excellent* at small programs, or uncomplicated ones (Do X to all C files if the corresponding H file changes, Do Y to all H files, Do z to all .sdpoi files then pipe them into an email if the corresponding C file changes. That’s a 6 line makefile. How many lines does say…ant say to do this? Or how many steps are required to say that in Visual Studio now?).

    The amount of UI poking you have to do to check settings in visual studio compared to an actual makefile is measured in orders of magnitude of time. One of the default debug procedures I’ve seen to deal with this in the past is to have VS spit out a make file then check out what it has for all the special linking and compile options are (This was in a windows shop, mind you).

    Make is *not* easy on new people. It’s a build programming language. And god it blows at compiling C++, as C++ has way too many weird dependencies (another point you casually glossed over that I had already made when you ripped my statements out of context). I’d love something better to standardize on. But ant doesn’t seem to be taking off everywhere (java associations along with XML verbosity have doomed it, I fear) so what do you suppose people use? What company do you suggest pay for its development?

    > You are obivously
    >years behind in the state of the art for both debugging
    > tools and build tools.

    Of course. That’s why I buy them all the time. Because I’m really far behind so I get picked to buy them to make sure the other dinos can use them :o D

    I *continually* am pointing out Jonathan is trying to make this thread where he solicits help from the linux development community on how to do something on linux, into a whining pissfest on how he doesn’t like how we *have to* do things.

    >Programmer productivity matters, and matters a lot. This is
    >something that the Linux comminity does not get.

    From a C++ developer? Really? Go write some mono/.NET or python if you want productivity. If you’re writing C++ still you want lots of control and just so happen to want to get some things done along the way.

    We *do* get this point. We use a lot of little tools, a lot actually, to get a lot of things done you do in IDE’s. Some of us use IDE’s (Eclipse seems popular). We use multiple language environments probably too much (I want to shoot someone every time I see a yacc specification). Both Vi and Emacs have intellisense now, but its a few years behind too and is not part of the default configuration.


  141. Sverik Says:

    I suggest you directly contact the developers of other Linux games, they should have more insight into the whole Linux gaming thing. These might give good reference:
    Neverball http://icculus.org/neverball/
    xmoto http://xmoto.tuxfamily.org/
    8 Kingdoms http://kralovstvi.sourceforge.net/
    Glest http://glest.org/en/index.php

  142. Jannet Says:

    Michael L, you’re still obnoxious.
    Go away.

  143. Igor T. Says:

    Michael L, L stands for loser?

  144. Stavros Says:

    ““Time to put on your humility hat, not your ridiculing asshole hat. You need us, we don’t need you. There is a lot of black magic and dragons in linux development, and one of them will eat weeks of your time if you aren’t careful.”

    Wrong. Linux people have a cute tendency of vastly overestimating their numbers and significance. You’re a niche within a niche taking up 0.93% of the market, most of which is on the server. You’re being done a courtessy, don’t assume that there’s talk of a Linux port out of necessity, it makes no financial sense to invest the time and effort to do so.

    You’re being done a service, try to be at least a little grateful for it.

    It really makes you wonder why people still bother after what Corel was put through (people who’ve been around long enough may recall Corel making their crown jewels (Corel DRAW gfx suite and WordPerfect) availible for Linux back in a time where there was no Open Office and no professional graphics tool (the later still does not exist)), only to be snubbed and at best ignored, at worst publicly lynched by the Linux mob^H^H^Hcommunity. They even developed their own distribution (which was sold to Xandros after they realized it wasn’t worth their time, effort or money).

    Loki, for all their effort didn’t get much love, either.

    “Why do we need to be dressed down by someone who’d like some help again….? We didn’t ask for a summation on how Jonathan Blow thinks about things on the tools. He went into full scale ridicule mode on a dude up above (not me) because the guy said he found make useful.”

    After having to explain a dozen times that the tools he’s being suggested don’t suit his needs, only to have them suggested again and again and again, can you blame his for being frustrated? JB made what he wanted clear. He made clear that what was suggested was inadequate, and then people get defensive and start treating him like a retarded child with Down syndrome who needs to be convinced that he’s doing it wrong, and he doesn’t need what he wants and that the sub-par tools are the be-all-end-all.

    As I recall, it was you who made that absolutely pretentious and condescending post about how he’s a whiney VS.net nooblet. The discussion wasn’t even about the toolchain, but about what libraries exist to get basic, fundamental sound and mouse functionality to work. The guy wants a solution, not a kludge. You can’t jump down his throat for having standards and expectations. Telling him that he should write his own tools? Come on, he’s a game developer. He wants to write games not system code for fuck’s sake.

    It’s asinine, Linux users want game devs to support their platform, but on top of that, rather than supporting the game devs with robust frameworks, libraries, tools and stable APIs, they want the game devs to do that for them, too? And he’s the whiney, needy teenager?

    @ JB
    I applaud you for making the effort, but frankly this is what awaits you in Linuxland, even if you deliver the product, you’ll get a public lynching because whiney ingrates don’t approve of how the package is delivered, just like Corel, it won’t be enough, and they’ll start chastising you for not releasing the source. Is it really worth that kind of time, effort and frustration for an insignificant niche market that only barely outnumbers the userbase of NT4 and Win98?

  145. dan Says:

    > The amount of UI poking you have to do to check settings in
    > visual studio compared to an actual makefile is measured in
    > orders of magnitude of time.

    That’s rubbish. Stick to things you know.

  146. Dotan Cohen Says:

    As a Linux user without Windows or a console machine, I would love to try Braid. I\’ve heard of Braid only a few weeks ago and it stands out as one of those must-try games in my memory.

    I suggest that you write a detailed list of the problems that you\’ve encountered (most have been mentioned here in non-aggregate form) and forward it to Suse, Canonical, and Red Hat. Those are the companies that can write the software that you need to develop by. It won\’t happen overnight, but it will happen.

  147. RandomGameDeveloper Says:


    >> No, I say the many ways to do many common debugger tasks will. The fact you can change threads in the UI, based on changes in the data, programatically in a C handler compiled into your program or remotely via a debug header is what’s amazing.

    >> Jonathan misread that to be an endorsement of the debugger and an example of some new fangled features, when it is in fact the fine grained options for each of those mechanisms that I find compelling. Can D3D’s debugger do all of the above?

    Again, you show your ingnorance on the WIN32 field, why would the D3D Debugger need to do this? And Yes, most of the WIN32 debuggers have pretty advanced features (VS, WINDBG, KD), all attack the problem at different levels, and allow customization at different levels. They are fairly extensible, and one of the extensions is for debugging D3D, which allows stepping trhough shaders.

    >> “for some tasks”. Show me that its not very useful for some tasks please? Oh yeah, that’s logically impossible.

    >> Make is *excellent* at small programs, or uncomplicated ones (Do X to all C files if the corresponding H file changes, Do Y to all H files, Do z to all .sdpoi files then pipe them into an email if the corresponding C file changes. That’s a 6 line makefile. How many lines does say…ant say to do this? Or how many steps are required to say that in Visual Studio now?).

    >> The amount of UI poking you have to do to check settings in visual studio compared to an actual makefile is measured in orders of magnitude of time. One of the default debug procedures I’ve seen to deal with this in the past is to have VS spit out a make file then check out what it has for all the special linking and compile options are (This was in a windows shop, mind you).

    >> Make is *not* easy on new people. It’s a build programming language. And god it blows at compiling C++, as C++ has way too many weird dependencies (another point you casually glossed over that I had already made when you ripped my statements out of context). I’d love something better to standardize on. But ant doesn’t seem to be taking off everywhere (java associations along with XML verbosity have doomed it, I fear) so what do you suppose people use? What company do you suggest pay for its development?

    LOL, who is writing simple programs? Maybe for high school students?
    You do not measure a tool by a simple task that it does well, certainly at this point and age I would consider most projects non-trivial. How easy is it to maintain a make build system? How easy is it to extend? How does it compare to other build systems? I will help you a bit here, Have you ever seen MSBuild? NANT? Boost.JAM? The Indsutry has left behind make, the problem is that the Linux community has not realized that. The tools are already there, nobody needs to pay for the development, they already exist. You should educate yourself on the field before making these type of comments.

    >> From a C++ developer? Really? Go write some mono/.NET or python if you want productivity. If you’re writing C++ still you want lots of control and just so happen to want to get some things done along the way.

    Typical Linux fanboy stand, you keep doing this over and over on this thread. You assume ignorance if people disagree with you. I am a professional C++ and C# developer, undeniably C#/Mono take productivity to the next level. The thing is, as game developers, working on cross platforms titles (PS3, Wii, 360, PC) we cannot do it. So we are doomed or blessed to use C++ for the problem domain, which adds a lot of constraints to our workflow, but even under that worflow you can become much more productive with better tools, and that is what we need. Again, productivity matters, at all levels, go use language X or Y is not an acceptable solution, so how do you address productivity under those constraints? Having better tools. Not sure what yo do not get here. You are assuming that C++ programmers do not need productivity because we use C++, which is a ridiculous stand.

    >> We *do* get this point. We use a lot of little tools, a lot actually, to get a lot of things done you do in IDE’s. Some of us use IDE’s (Eclipse seems popular). We use multiple language environments probably too much (I want to shoot someone every time I see a yacc specification). Both Vi and Emacs have intellisense now, but its a few years behind too and is not part of the default configuration.

    For what is worth, I checked Netbeans last night, which somebody suggested on this thread, and found it to be fairly complete and good quality (at least it hides a fair amount of complexity and is very usable).

  148. Jannet Says:

    Mention Linux, get poop flinging simians.
    Unless you derive some ironic pleasure from seeing the Linux monkeys scrambling about, please close this this post.

    Linux Losers are losers.

  149. Michael L. Says:

    @ RandomGameDeveloper

    As to those build systems I’ve actually heard of the use of each of them or a close relative. I didn’t know MSBuild was called that. It or an earlier version of it was used on all windows projects in one shop I worked with (and modified build routines). Lots of screaming and yelling from them too about “why doesn’t the make system do X”. NANT is a redo of ant for all the verbosity and isn’t appealing to the same people. (Are you telling me there aren’t XML haters on windows too? I really don’t care either way about XML’s verbosity, and have used ant).

    I’m sure MSBuild is widely available for linux and therefore apropos to this discussion.

    Jam is used occasionally. It or one of its relatives was the build tool for some of the applications on a project I was on. Never had to modify it though, they had a librarian (honestly, that was his title, always reminded me of discworld, speaking of Simians) who was the only one allowed to change the build files. This edict gave me the apparently mistaken impression it was very difficult to deal with or some expensive proprietary thing that involved lots of training. Glad to find out its actually something some people like.

    I’d love to take a second look at it if it’s not tied to boost and I’d even consider trying it on a client who doesn’t have a large pile of make experts that I have to spend yapping with to convince to install it.

    In general the default for projects is *still* make, but its not because we like the tool

    Make is going to keep being the de facto standard for a large portion of projects for a technical reason beyond the obvious social ones (everyone knows how make works to degree now, so lots of companies just use it because they don’t have to retrain).

    It has to do with all the heterogeneity that is infinitely frustrating to release software for, as one of the tried and true solutions to getting things working in the myrid of environments is something called libtool. And libtool (last time I looked) was still bolted to the hip of automake and autoconf. Which work off make as you’d guess from their names.

    It is hell, but a higher circle of hell then supporting everything manually, and to boot, it actually appears to work for most cases. Lots of the libtool use cases are only for programmers who release source code (as it centers more on compiling than running things) whom I’m imagining aren’t you and JB. But until a libtool replacement exists, or libtool starts using something other than makefiles, lots of people *who are no more interested than you in writing tools* are going to keep using make as it is what comes out the end of the libtool pipe. And they know they may need libtool someday soon.

    Again, it feels you’re going with this position you’ve made up for me where I’m supposedly saying the linux tools are “teh best” and how I’m behind the curve because I still use it. I’ve never contended that, I’ve contended the general debugging tools have power.

    I still use make because I’m largely modifying pre-existing software and writing firmware and it already came with a makefile, or the project may need libtool in the near future. The tools work *fine* for what’s in place, and are a standard for the reasons above. They are even *excellent for some applications* as a result, as its pretty terse and compact.

    You *are* ignorant about a lot of things (especially why experienced unix developers use make). And I am ignorant about your game specific debuggers (as I’ve indicated several times by asking questions and by indicating I’m not a game developer). Like I said: Unix development is too large for any one person to know it. But humble, not an asshole.

    As to why I “attacked” Jonathan:
    Whether you or he felt justified in doing so, Jonathan *still* went off on someone who recommended tools after Jonathan asked for tool and library recommendations. Even if his reaction *is* justified, it *will* be ineffective in talking to the linux community to get all the information he needs to move to linux as a dev platform, and will probably be just as frequent if it’s from being told solutions that don’t work for him for whatever reason. I never called him a nooblet, I said he’s reacting like lots of new people to linux. His behavior is identical from theirs and will get the same reception if he asks for help and blows up with comments about “not being able to have a serious conversation if you think X”, not matter why he actually acts that way.

  150. Richard C Says:

    “The one thing gdb does, that Visual Studio does not do, is let you call live code from within the debugger.”

    John, I’m not sure if this has been answered as I didn’t bother to fully trawl the thread, but this is possible in VS as of 2005. You just type the function call into the immediate window and it’ll run the code then and there. Very handy at times.

    the return value thing is somewhat supported too – the auto watch window will show return values if you’re stepping through the code.

  151. RandomGameDeveloper Says:


    >> As to those build systems I’ve actually heard of the use of each of them or a close relative. I didn’t know MSBuild was called that. It or an earlier version of it was used on all windows projects in one shop I worked with (and modified build routines). Lots of screaming and yelling from them too about “why doesn’t the make system do X”. NANT is a redo of ant for all the verbosity and isn’t appealing to the same people. (Are you telling me there aren’t XML haters on windows too? I really don’t care either way about XML’s verbosity, and have used ant).

    The use of XML on the tool had little to nothing to do with how usable the tool is. Not sure why everything has to be a religious fight (“XML haters”), and all the screaming and yelling for your previous shop does not take away the merits from MSBuild. You know, you have people that write bad code with Visual Studio, and people that write good code in Emacs. That does not say anything about the quality of the tools.

    >> I’m sure MSBuild is widely available for linux and therefore apropos to this discussion.

    MSBuild was brought up to deal with your “VS hating”, under VS there is a very powerful and configurable platform, that is light years ahead of make. Which is pretty much equivalent to NANT.

    >> I’d love to take a second look at it if it’s not tied to boost and I’d even consider trying it on a client who doesn’t have a large pile of make experts that I have to spend yapping with to convince to install it.

    >> In general the default for projects is *still* make, but its not because we like the tool

    You are right, is because of stagnation and religiosity. You can excuse legacy projects, but make is dominant for basically all the projects developed and release under Linux.

    >> You *are* ignorant about a lot of things (especially why experienced unix developers use make). And I am ignorant about your game specific debuggers (as I’ve indicated several times by asking questions and by indicating I’m not a game developer). Like I said: Unix development is too large for any one person to know it. But humble, not an asshole.

    The whole Unix is bigger than the Universe argument is fairly stupid. And I can apply it to everything: “Game Development is too large for any one person to know it” “Windows Development is too large for any one person to know it” “Mac Development is too large for any one person to know it”
    What is your point? It is obvious why the state of some tools in the Linux world is the way it is, stagnation and religiosity (and sometimes pragmatism), there is no hidden mystery there that is beyond the understanding that only Linux users have. Make sucks, is behind. It is used because there is existing expertise (pragmatism), and because Linux developers are happy with the status quo (stagnation and religiosity)

  152. J Says:

    this debate is getting a little beyond me.

    why do game developers have to use C++? is it because they need a lower-level language to get acceptable performance? just curious.

  153. RandomGameDeveloper Says:


    We have to use C++ because it is the common denominator for all platforms out there. All the consoles support C/C++, and provide APIs to access the hardware features. Performance is also a big issue, since usually games need to squeeze as much performance from the platform as possible.
    Some games provide the core functionality in C++, and expose extensibe functionality via scripting languages (like Lua or Python), but we are still stuck with C++ for the most part.

    There is some efforts to move beyond C++, efforts like XNA (from Microsoft), and Mono allow running Managed code on Consoles. These are maturing fairly fast, but adoption will be very slow. Getting all the console providers on the same page is a very big effort, but there the efforts are gaining momentum.

    Note also that middleware companies have all their offerings in C++, so you start facing the chicken and egg problem.

  154. Meneer R Says:

    I am a linux user; and I find some of the comments by linux users here offensive.
    I also find some of the anti-linux comments offensive.

    It works like this:

    Hey, THEY Suck. No THEY SUCK.

    Now replace for the word THEY

    “Linux community”
    “Windows developers”

    AH, well .. point made.

    Here is black list of fanboys that just can’t help themselves and get offensive:

    Micheal L.

    Seriously, this whole identification with a product and then get project any opinion about that product onto yourself, its a disease.

    But looking back, most of this discussion was pretty polite, up until Micheal L. trolled it up to extremes.


    For me, it seems quite logical that linux is a hard target for anybody: freedom is by definition much harder to support.

    I’m not suprised that the smaller game developers would stay clear and stay on one single integrated platform, where things Just Work ™.

    I am however suprised that the big middleware guys are not filling up this gap. It’s not so much the market share .. as the competitive edge .. when you start to be dependent upon one non-interchangeable vendor .. well, you shouldn’t want that.


    There are so many players, which could and should have invested in this. Valve should be worried for competitor from Microsoft itself; and it would be wise if they secretely had a linux and mac port ready to go… (and turn steam on linux into a set of default libraries .. )

    .. another player would be EA that just doesn’t seem to get DRM right .. just ditching the OS support all together and just making the game-dvd’s bootable would be a much easier support endevour (and be OS neutral at the same time)

    .. And why isn’t google financing some 3d canvas with GLSL support for the browsers? If they want to turn games into an advertisement platform, they need to bring the games to the browser; away from the distribution-locking of Valve,Nintentdo, Microsoft, Sony, etc. ..

    And why isn’t Epic making the UnrealEngine with it’s unrealscript more suitable for things OTHER than 3d shooters. It’s practically a PLATFORM for games. The Java of shooters.

    And WHY isn’t Sun pushing Java onto the consoles ..

    There is a lot of money to be made in gaming; but the platforms are so fragile; the customers so unhappy; the market too fragmented .. and the marketing focusses only on the virgin 15 year old white males. (except for Nintendo .. cudos to them) . ..


    Considering the amount of money in this industry .. making sure that developers like Jonathan .. can JUST create games and distribute it everywhere to everyone .. .. seems like it should be somebody’s bussiness model..

  155. JonB Says:

    Hi Jonathan,

    I’m also a professional games developer and long term unix user. I’ve never done any commercial development on linux though – of course it’s rare. However I have done some stuff there. For linux (and windows) I use eclipse and the CDT. It takes a little to get used too but I actually prefer the IDE to Visual Studio these days. The debugger integration is great, wrapping gdb – the only thing I’ve wanted and not yet found is setting hardware breakpoints on memory locations. I find it a great tool, like I say I also use it on windows (on top of cygwin and mingw). With the latest versions I also believe there is a visual studio alike key mapping whcih for someone who used visual studio professionally like I do would be great. I started with eclipse long ago enough to have to learn the keys though!

    Eclipse will also do automated builds with different configurations (release, debug, profile, master etc) – no makefile pain with the option of spitting out a makefile for a project too. Alternatively you can import or create makefile based projects. The one thing for me that’s not so good is that the organizational structure in the IDE has to mirror exactly that on the disk.

    For development libraries I’m also using SDL to wrap OpenGL and provide windowing and input and OpenAL for the audio. If you just want to play an audio stream this is simple in AL, there’s some pretty good samples knocking around. I’m actually currently porting this little engine to ‘windows proper’, it now compiles under Visual Studio, next the D3D port.

    Constraining the mouse is a pain, I’ve not bothered with mouse input (as yet) but I understand why it *has* to be constrained to the window – even in full screen mode the window should be borderless and the size of the screen with the mouse constrained. Why? Some of us have multiple monitors and when gaming a full screen app you really don’t want to click on the other monitor and loose focus going through all the D3D surface and buffer recreation pain!

  156. Joe Says:

    I haven’t read the entire list of comments above so I apologise if this has already been suggested.

    Why not e-mail some of the teams behind some of the games on Linux (like Tremulous)? I would imagine that they have met and solved some of your problems and so could at least point you in the right direction.

  157. Bobby Blade Says:

    I’m a linux user and I’ve already bought Braid on the XBLA, but I’d be willing to buy it again on PC even if it didn’t have a Linux-native port but worked through Wine.

  158. Visitor Says:

    I just wanted to say that Michael L. is the most patronizing and condescending hypocrite that I have seen in quite a long time.

  159. Vek Says:

    As a game programmer type myself, I always find it laughable when linux supporters talk about how much ‘better’ the linux environment is for development. It’s just not true. Its years and years behind. And losing ground. This is coming from someone who has developed on both environments, works on Free Software (whee) and happens to love Qt (for example) far more than I should.

    I think the reason the belief is otherwise is that a lot of staunch linux supporters simply haven’t actually worked within the windows development environment – they haven’t see what the latest Visual Studio can do, or when they have, they haven’t done much debugging in it or really used the features. There’s nothing GDB can do, for example, that the IDE in visual studio cannot do except visually, immediately, and with just a click or two.

    And thats only scratching the surface. You nailed it with PIX. Another example is the nvidia nPerf stuff – being able to see the program render a single frame of a game from beginning to end, being able to fast forward and rewind through frames, interactively, to be able to inspect the state of each texture unit, texture, mesh uploaded, scrub through all the draw calls of a single frame… and now the XNA stuff thats developing, and is out there for absolutely free includes the power of Visual studio…

    I mean, really.

    And then you get some guy says that the text-based gdb environment is better somehow. Its headshakingly sad, really. And its probably why the environment is stagnant, while the windows/mac dev environment is speeding off into the distance

  160. Josh Says:

    With Linux, you can make your own hardware, if you’re good with electronics. Or just farming.

  161. PhilArmstrong Says:

    Vek: That’s exactly the kind of feedback that I was asking for upthread! Thanks for the more detailed input.

    It does sound to me though, like many of the advanced features that you talk about are very specific to game development (or perhaps ‘advanced graphics program development’?). I think it’s fair to say that the integration of the Linux / Unix development stack with the graphics / sound system is very poor indeed. I certainly wouldn’t argue with that.

    However, there seems to be a general thrust on this thread that the Linux/Unix development environment in geenral is sub-par. I just don’t see that. Pointy-clickiness and text-mode interfaces can be just different ways to get at the same feature set. Indeed, my experience of having to deal with VC++ has usually consisted of spending ten minutes every time hunting through the various menus (the build system was the worst offender IIRC) looking for the right checkbox to tick to get the required feature turned on. I’m not sure this is actually an improvement over the alternative :)

  162. Joachim Bengtsson Says:

    For sound, I’d also recommend fmod. High level enough to get to concentrate on making a game, and less of a hassle than openal.

    Also, I’m surprised to see such a long flamebait thread and not a single Mac zealot! Therefore: Xcode and Cocoa über alles! :)

  163. Joachim Bengtsson Says:

    Sorry, read your thread and here’s a better reply: I used fmod just as an audio pipe, reading the audio stream from my own sound engine. Worked well for me after I had figured out some basics of audio programming, but being a newb I didn’t really have the kinds of requirements you might have, but it should be a lot better than SDL.

    The code is pretty awful but here’s how I did it: http://www.friendlystapler.se/browser/RMS/trunk/Source/Implementation/Sound/Playback/FMODRaw.cpp

  164. dan Says:

    >> Pointy-clickiness and text-mode interfaces can be just different
    >> ways to get at the same feature set.

    I think that’s they’re arguing that life is easier when everything is integrated plus GDB doesn’t have the same feature set as Visual Studio.

    So how about some concrete examples, can GBD do the following?

    1. Edit code whilst debugging, recompile & continue execution without restarting the app.

    2. Set execution point. I.e. move the execution point within a function for example; to re-execute a block of code.

    3. Immediate window. Separate window for running functions within the application & inspecting their results.

    I don’t know the answer but would be interested to find out.

  165. PhilArmstrong Says:

    dan: exactly. I’d be much happier with concrete examples of where the Unix/Linux toolchain falls down than sweeping accusations of crapness.

    Taking your individual points in turn, all IIRC of course:

    1) I don’t think so. That’s quite nifty: presumably you can’t make any changes which alter the shape of data structures when you do this though? I guess this only works on unoptimised debug builds? In principle, you *can* patch the underlying binary if you want to & continue execution in gdb. Xcode uses this to implement this feature under OSX using gdb as the underlying debugger but that requires some support from the compiler and linker that I don’t think exists under Linux. Sounds like a suitable Google summer-of-code project if not! Maybe I should suggest it…

    2) Yes, absolutely.

    3) Well, given that you usually drive gdb from a prompt this functionality is always available. I’m pretty sure it’s existed in every front-end to gdb I’ve ever seen as well, from emacs to Xcode, although ICBW of course.

  166. PhilArmstrong Says:

    As an aside, there’s an interesting post on gdb-devel by one of the developers of fix & continue in Xcode talking about their experiences with it:


  167. RandomGameDeveloper Says:


    There are concrete examples throughout the thread, make vs modern build systems is one of them.

    Another example is performance of gcc vs vc that somebody else mentioned.

    This is not about IDE vs no IDE, or how awesome you could be if you heavily customize your environment. There is certainly a fair amount of user unfriendliness on the Linux toolchain, sure the core has lots of capabilities, but those capabilities are usually not presented on a way that is easy to use, digest, and master.

    Another example here, which is not directly related to Linux, is dtrace. Probably one of the most amazing debugging tools on any platform, yet hard to master because it is layers and layers of command line options. Maybe the solution is to wrap lots of these tools into user friendly applications, which seems to be a no brainer, and that is what Windows and Apple do, it does not seem to be a priority for the Linux community.

    Developer entry barrier is very high, telling people that they need to learn how to use emacs, learn all the command line tricks, etc is not attractive.

  168. dan Says:

    Thanks for the straight answer Phil.

  169. LKM Says:

    @Joachim Bengtsson: I’m actually interesting in finding out what Jonathan thinks about the situation on Mac OS X. While Visual Studio has some advantages over Xcode, I generally like Xcode and think the Cocoa APIs are mature, stable and full-featured.

  170. James Says:

    sod linux just port it to mac, 10% vs >1% desktop usage

  171. James Says:

    <1% i mean

  172. mercurysquad Says:

    Hi Jonathan,

    I’m not sure you still need the advice or not, and I’ve only skimmed over the (amusing) replies, but a quick search didn’t return any results so I’ll mention this now:

    Have you looked into the JUCE framework? http://www.rawmaterialsoftware.com/juce

    It’s a cross-platform application framework using which you can develop apps which are source-compatible (as easy as a recompile) for Windows, OS X and Linux. It’s got a really nice audio API. Although they still use callbacks, it handles every audio-related stuff on all 3 platforms, and all you have to do is open the default audio device, and provide it audio buffers on every callback. No nonsense.

    It was originally created for pro-audio app Tracktion (www.mackie.com/tracktion3), but the framework is now GPL’ed.

    Hope that helps.

    BTW I’m myself a CS student and audio/multimedia programmer. Linux audio is a mess :-) If you want something even simpler than JUCE, just use OSS. It’s API is well documented. The only problem is that the linux kernel by default doesn’t include the new OSS v4.

  173. Jonathan Blow Says:

    I haven’t seen JUCE, but all the cross-platform libraries I have encountered are part of the problem, not part of the solution.

    There is this weird idea in Linux (and the open-source community in general) that wrapping things with more code somehow makes them better. This is untrue — it almost always makes things worse. And yet, in Linux we encounter wrappers around wrappers around wrappers, and the situation becomes silly very quickly.

    As an earlier commenter said, if the core of the system is unable to perform some task, then no amount of wrapping will ever overcome that deficiency. All the wrappers do is increase the opportunity for bugs, decrease the understandability of the system, occlude low-level features that the developer would like to use, make code harder to follow in the debugger, increase code size, make the program run more slowly, cause the code to have poorer heap management (resulting in, say, decreased locality and increased fragmentation), defocus the community’s development efforts and thus their ability to get useful things done, increase the number of module dependencies and thus make the package more difficult to install and to maintain, and increase the amount of noise involved in the discussion of that problem space.

    Oh, the wrappers probably do some other things too, but I feel that I have listed enough.

  174. Jonathan Blow Says:

    (Though I did after writing this rant go and look at the page for JUCE and it seems to not quite be in the category of things I am talking about — it looks like JUCE is really trying to be its own thing.

    But given that I don’t want to target the JUCE environment, I would be using it just as an audio wrapper as suggested above, and then all the same criticisms come into play — this time with regard to the usage of the API in this particular way, rather than the existence of the entire API to begin with.)

  175. nigel_ht Says:

    I haven’t tried Torque in years but when I was thinking cross platform I was considering it before I moved on to C# and MDX/XNA. Mostly for OSX since I wasn’t jumping up and down to get used to ObjectiveC. I believe it uses OpenAL for sound.

    Not 2008 AAA quality but good enough for what I was thinking of doing. And no one coder shop is going to produce a AAA title anyway. TGE Advanced is finally out of beta but Windows only but the older TGE is cross platform.

    I too am an old unix/linux weenie from years back. My first intel PC ran linux (slackware 1.1.2) as well as DOS/Win3.1. I remember thinking “Gosh, this thing is faster than my Sun IPC on my desk”.

    xemacs/gdb as a tool chain was awesome in 1990. A lot less so in 2008. Yes, I prefer VS over doing it the hard way. Even in 1990 Sun’s development suite was far better but rather expensive. In comparison, MS’s tools was always either cheaper or better or both than their Unix equivalents.

    So it was free and so-so or expensive and decent vs cheap and decent. Today is little different except that NetBeans and Eclipse only suck a little bit in comparison to Studio or XCode. Folks still shell out for IntelliJ IDEA and I used to use Kylix for C++ until Broland killed it.

    At which point I bought a Mac. Finally a real desktop unix (certified UNIX03) that didn’t suck.

  176. Linux Victim Says:

    I think most Linux supporters don’t notice it themselves, but, their thinking is very clearly totalitarian.

    You know how the German Democratic Republic, the communistic germany, that existed after world war 2 until the fall of the wall, called the Berlin wall? “antifaschistischer Schutzwall”. That means “anti-fascistic protective barrier”. So, in their lingo, the wall protected the “good” GDR against the evil capitalistic Germany, the federal republic of Germany.

    But, clearly, the fascistic one was the GDR. This state had secret police, torture rooms etc.

    The same thing with north and south korea basicaly. Have you seen North Korean propaganda?

    That is exactly what George Orwell wrote about. And the “Linux community” has all the ingredients that would classify totalitarism:

    Choice is good, UNTIL you chose something that the party doesn’t approve! Choice is good if you chose firefox, if you chose IE, then you’re a moron and you should be blocked and choice is bad!

    Manipulation and lies. There are plenty of examples. And when caught, cry “FUD”.

    Presentation as victims: That one is important. The Linux community is never at fault you see: If they are caught, they always cry, that they are not at fault, MS is evil .. and so it goes. Totalitarian states present themselves as victims always too.

    Manipulation of history. Plenty of examples here too. The most glaring is the myth, that Microsoft started a war against Linux almost since the dawn of time. That is a blatant lie. The community hated MS (and other companies) long before they in turn noticed Linux. You only need to look at linux newsgroups from 1995 and earlier.

    Back in the days, 10-12 years ago, I was a linux “fan”. Mostly because I just loved to tinker with the computer, but I almost immediately realized that Linux won’t win the desktop then. And it still hasn’t.

    But still, I liked Linux.. Until I discovered the Linux community. When I first read Slashdot in 1999 (or was it 2000?) and all the other Linux “communities” on the net, like the advocacy newsgroup or heise.de, the German slashdot (I am from Germany) my love quickly went away. Never have I seen such ridiculous hateful people before.

    Replace the word “microsoft” with “negro” or “jew” and many postings of the FOSSists would be considered as hatespeech.

    The stupid hating of a single company is what drove me completely away from the “community”. Yes, MS, pardon, “M$” used some qusestionable tactics.. but hey, it’s the business world. And I could list dozens of companies right now, who are much worse, take Monsanto, Exxon, Nestle, pharmacy companies, Nike with their sweat shop labour, Coca Cola (google coca cola and south america) and many many others.

    Even the beloved IBM dealth with the Nazis:


    I guess the hate for MS is because the freetards are indeed that: intellectualy retarded. Yes, they can code (badly), but that’s about it. They never experienced real evil in this world and real cruelty, and that’s why they are projecting all their silly nerd anger at a single company. Like ungrateful little children who scream at their parents, because they ordered them to go to bed.

    Reading slashdot is like reading crazed postings of cultists. What was always mind numbing, at least for me, was the uncritical affirmation that the freetards received for many years from the media. No one was critical with them. No one gave them ever a good pounding, they could write total madness, like, in one year Linux will take over, Bill Gates is the Satan incarnate, Steve Ballmer is worse than Hitler, and no one wrote one critical piece. It drove me mad. It was as if the inmates have taken over the asylum and the doctors are helping them.

    And that fu… self elevation. They are acting, as if they cure AIDS and cancer with their sloppy coding. As if they are damn heroes in a epic war, UGH.

    My dear Jonathan, this post is a bit off topic but I sincerly warn you: Don’t let the Linux cult get you. Don’t waste time with it. Look what you got: You asked a question and you’re immediately crucified for not following “the right way”.

    Like some commenters already posted here, Linux resembles more like a cult than anything else. If you’re thinking Linux and FOSS is primarily about technology, then you’re dead wrong. After almost a decade of experience with the beloved community, it’s clear to me, that Linux is a lost cause. Because much of it is based just on hate. Hate for MS, hate for commercial vendors, traditional Unix companies, commercialism, RIAA, MPAA or whoever the main antagonist is at the moment, it doesn’t matter. Much of the main motivation for many in the FOSS movement is indeed just hate, hate and nothing else but hate.

    And that is why they will fail. Linux has only around 0.9% market share on the desktop, and stagnating at that since a decade. And that is good so, because hate just will and cannot be successful. And it should not be successful.

  177. Shish Says:

    Guh at the drama on all sides, anyone mind if I try and be productive?

    For each of the things you want to do, can you list what the end result that you want is, possibly with a note on how you’ve currently achieved it in order to clarify? That way everyone can either STFU or reply with “here is a code snippet demonstrating the desired end result”.

    eg, for sound, I’ve seen lots of discussion about how current APIs aren’t able to do what you want, but not many specifics on what that is — there’s mention of playing sound at speeds other than 1x? I’ve not played the game, so I have only vague and possibly incorrect assumptions of the desired end result here…

  178. Jonathan Blow Says:

    For audio, I just want to play one 16-bit stereo 44100Hz or 48000Hz audio stream, with low latency and good control. That’s all.

    For a game like Braid, yes there is a lot of mixing of different sounds at different rates, but the game itself does all the mixing and just outputs one stream. This is the way all reasonable audio is now and in the future (hardware-based audio mixing is a red herring and has always been).

    An example of “good control” might be to pre-queue some samples to go out, but invalidate them if I later decide that an extra sound needs to be mixed in ASAP.

    But really the latency is the most important thing. There are at least 2 major problems with with callback models such as SDL’s: (1) It’s very hard [or impossible] for me as the app developer to know what the actual latency is and to tune my app for the best possible result; (2) Because the callback comes from another thread that I do not control and cannot block, I can’t do nontrivial work inside the callback function; so I need to queue up samples from a different thread in my app and pass them into the callback via a lockfree data structure. This is really annoying to have to program, but worse, it adds latency (because I have to buffer up enough sound to potentially handle any callback that may asynchronously happen).

    That said, it is still at least possible to play sound via SDL, just in a lower-quality way; so the situation for sound is not as bad as with the mouse input / window focus, where it seems to be impossible to get the proper result at all.

  179. Anonymous Coward Says:

    OMG, “Linux Victim”, you’re absolutely ridiculous. Yes, there are zealots using Linux, but most Linux users just don’t *care* about Microsoft and oh by the way, it’s exactly the same the other way around. Just read the LKML. Microsoft is hardly mentioned at all, except when discussing Linux drivers for their hardware.

    And it’s also really funny to see how you accuse the Linux Community of being oh so hate-driven while all you seem to care about is to explain how much you hate the linux community.

  180. Shish Says:

    Raw mouse input; no acceleration applied, no clamping at the edge of the screen:


    From my brief googling, reading from the device will give you raw PS/2 data by default; if you write a magic character into the device before you start reading, then it’ll give you ImPS/2 (more buttons + scroll wheel).

    Tested and working with my laptop’s nipple mouse + an external USB mouse (both work at the same time — you can read an individual mouse by opening “mouse0″, “mouse1″, etc instead of “mice”)


    OSS gives simple raw sound input / output to one process at a time; ALSA does multi-process mixing, though the API is more complicated than “open device, write”

    Given raw output, I think you’d need to implement your own queueing / invalidating / remixing thread, thus latency control is down to how you implement it? I’m no audio coder, so I’m not entirely sure how these things work…


    Tested using ALSA’s OSS emulation (the “snd-pcm-oss” driver).

    Also, one can use the raw-and-simple OSS API, but take advantage of ALSA’s mixing by running “aoss ./parrot” (aoss being a wrapper to rewrite OSS calls into ALSA calls — this would suggest to me that since it works, you should be able to just use ALSA calls directly, I just can’t find the documentation…). This has been tested using “aoss ./parrot” while also playing music with an ALSA-based player, and having both work.


    Further googling shows that ALSA has several APIs, including a write_sound_data(pcm_buffer) style one, as well as mmap access to a ring buffer, which should be enough to implement a queue on top of? (Writing to buffer[get_current_pos()+1] would allow you to edit the next item in the queue with nearly zero latency?) Again, I’m not an audio guy, I don’t know these things :P

    The IO methods:

    A minimal example of writing blocks of sound data (I suspect that having direct access to the sound buffer is more what you want, but I can’t find an example of that <_<)



    I’m pretty sure ALSA is the API to use here — everything else just builds on top of it

    Re: the comment that some people are still using old kernels which don’t support alsa — it was announced in 2003, all modern distros are using it (even debian, “the distro which never updates”), upgrading is free; there’s really no excuse for not having it…


    re: constraining the mouse to a window without stealing focus, not sure what you mean by that, aren’t they the same thing? (I’m guessing they aren’t, I’m just confused) Again, a description of the desired end result would help…

  181. Jonathan Blow Says:

    Shish: If that works, then it is one part of the solution (and is a lot easier than the other solutions I had been led to look at).

    The other part of the solution that would need to happen is the constraining of the mouse pointer so that it doesn’t do bad things while I am reading the dev file. X11 focus grabbing produces bad behavior for the user under way too many circumstances — he can’t alt-tab out unless the app fakes that, but what if the app crashes or has a bug; there were weird problems with popups and the like, too.

    Windows, for example, lets you constrain the mouse pointer to a sub-rectangle of a window, and that constraint only takes effect if that window has focus, but focus behaves as normal (you can alt-tab or whatever). That behavior is fine, because then you just constrain the pointer to the window and make it invisible. (There are actually bugs in the Windows implementation where the pointer gets a little stuck under some circumstances but you can alt-tab again and it fixes itself; it’s a kind of rare bug and it works well enough and the failure case is benign enough that it’s fine.)

    I don’t think Linux needs to have exactly this functionality, but *something* to cater to an application that is not pointer-driven, but wants to use the mouse, would be a good idea.

    Having audio only work for one process at a time is basically a non-starter, so OSS is a no-go there. (That used to be optional in Windows’ DirectSound — to lock audio output to your process so nobody else can play anything — but they took it out). What I have been told about ALSA is that if I try to use it, some peoples’ sound drivers will block if another process is trying to play things, and other drivers will just mix and play. I haven’t tried this myself, but if that is true, it sucks. Assuming it’s not true for very many people, ALSA would be the way to go (but I still have to look at the API in depth to see if it’s reasonable).

  182. Linux Victim Says:

    “OMG, “Linux Victim”, you’re absolutely ridiculous”

    So, really? I agree that some, maybe even many programmers on Linux indeed don’t care. But the thinkers, the one upon which the whole ideology is founded, do care. And that ideology is pouring into the general Linux populace, slowly but surely, trust me.

    I have years of experience with reading and posting on slashdot, heise, newsgroups and other places. I know how they tick. A few reads or postings in these places will do nothing. But, if you’re years into it, you discover the thinking. It took me a while to shackle all the FOSS propaganda off me, once I understood what’s it really is about.

    Fortunately, the likes of Stallman are quite frank about it, a bit more so than in the past. So, let’s look what Stallman is saying:

    The guru in his own words: (On the 25th anniversary of GNU)


    “The free software movement aims for a social change: to make all
    software free so that all software users are free and can be part of
    a community of cooperation. Every non-free program gives its
    developer unjust power over the users. Our goal is to put an end to
    that injustice.”


    Read that stuff! read it slowy: “Every
    non-free program gives its developer unjust power over the users. Our
    goal is to put an end to that injustice”

    That is totaly crazy.

    Damn shit, a FPS or MS word is an INJUSTICE that has to be put “to an end”?

    Look at the words “unjust power”, “injustice”!

    Such a choice of words almost is a scandal. Writing commercial closed source programs is put to the same level as poverty, epidemics and genocide, or what would you describe as “unjust power” and injustice”?

    And more from his article:


    “The road to freedom is a long road. It will take many steps and many
    years to reach a world in which it is normal for software users to
    have freedom. Some of these steps are hard, and require sacrifice.
    Some steps become easier if we make compromises with people that have
    different goals”


    Something like that could be put on the Amnesty International site, if it would be about torture. You just need to change a few words:

    “The road to abolish torture is a long road. It will take many steps
    and many years to reach a world in which it is normal for the police
    not to tortue. Some of these steps are hard, and require sacrifice.
    Some steps become easier if we make compromises with people that have
    different goals”

    Et Voila.

    This could be put on the AI site. And indeed, for the Amnesty International site it would be appropiate but it is completely crazy and mad and impudent by Stallman and his FSF footmen to put such a text on their website.

    And still more from Stallman:

    “Our goal is a world in which software users are free, but as yet
    most computer users do not even recognize freedom as an issue. They
    have taken up “consumer” values, which means they judge any program
    only on practical effects such as price and convenience”

    So, the people don’t recognize freedom, but in time we will make them recognize it! And if they don’t want freedom, we will force them to take it! Proletariats of the world, unite! Humans are stupid and don’t recognize freedom as an issue, but our great chairman Stallman will make them recognize it.

    And more:


    “The philosophy of open source presupposes and appeals to consumer
    values, and this affirms and reinforces them. That’s why we do not
    support “open source”.”


    Oh dang. the foundation for bloody rivalries is laid! Free Software and Open Source are two different things as it seems. In the future, must the Open Source leaders flee to Mexico, after the Free Software guru will ascend the throne?

    And more from Stallman:


    “For instance, experience shows that you can attract some users to
    GNU/Linux if you include some non-free programs. This could mean a
    cute non-free application that will catch some user’s eye, or a
    non-free programming platform such as Java (formerly) or the Flash
    runtime (still), or a non-free device driver that enables support for
    certain hardware models.

    These compromises are tempting, but they undermine the goal. If you
    distribute non-free software, or steer people towards it, you will
    find it hard to say, “Non-free software is an injustice, a social
    problem, and we must put an end to it.” And even if you do continue
    to say those words, your actions will undermine them”


    By now, every employee, who would have read such drivel from his boss, would have called a psychiatrist and made a date for him. Unfortunately, the lackeys at the FSF didn’t do it.

    Read aloud what Stallman wrote: Non-free
    software is an injustice, a social problem, and we must put an end to

    Madness. Pure madness and insanity.

    Thus, closed source software is according to Stallman an “injustice”, is a “social problem” and needs to be put to an end. The choice of words is just perverted. Closed source software is put to the same levels as cancer, poverty and hunger.

    This is fascistic thinking in its pure form. And the other “thinkers” like John Hall, “ESR” and others are not far from this absurd positions.

    Linux and FOSS is to technology, what Al’Quaida is to religion.

  183. Brian Says:

    @Linux Victim

    To be fair, even Linux folk see the absurdity of Richard Stallman’s statements.

    In reality, Desktop Linux is just a fad among the technically inclined folk who seem to populate the likes of Slashdot, reddit and to a lesser extent, digg. Linux gives hobbyist programmers a place to showcase their abilities and perhaps even produce something that sees widespread adoption (relatively speaking). On one side, you have people arguing that a commercial platform backed by billions of dollars worth of development in terms of 1st and 3rd party software is better than an operating system patched together by people all over the world. While it may seem absurdly obvious that the commercial platform is superior, a lot of people have on the Linux side are simply blinded by their allegiance to an operating system they feel they are a part of. On one hand, I can’t blame them, it’s human nature. I certainly don’t believe they are in some sort of quest for world domination.

  184. Linux Victim Says:

    “To be fair, even Linux folk see the absurdity of Richard Stallman’s statements.”

    Depends. Many do think they are absurd. But, a substantial amount of them don’t.

    I once once posted some Stallman crap with almost the same wording on a popular linux forum, and asked, if it is really ok to compare closed source software to “injustice” and social problems. Around the half said, they don’t agree. Another half said, they do agree.

    And if a half in a very popular linux forum (heise.de, German language) don’t find it absurd to compare closed source software to “social problems” then.. wow.

    Here is some other “RMS” drivel:



    “Non-free programs are dangerous to you and to your community. Don’t let them get a place in your life. ”

    Now, many complained about that in the comments section. But, quite a few didn’t object at all and AGREED to that.. If a “community” is so bat shit insane, that quite many of them agree to fascist theories, that all software should be the way some dictators propose, and all other types of software are “injustice”, “social problems” and “dangerous” and should be “put to an end” then fuck that.

    Let’s go away from Stallman. Let’s take another “thinker”. Let’s take Jon “maddog” Hall:



    “I received an email recently from a young man in Brazil who wanted me to come to his university and talk to the students and faculty about using Free Software. I am normally happy to advise universities to use Free Software, but usually this is done in conjunction with some large conference held at the university or some other venue. I just do not have the time to visit each and every school. But I did investigate the university of the student and found that Microsoft was indeed a sponsor of the University. In fact, the university had a large banner on the front page of their web site talking about Microsoft as a partner. It was the first time I saw a university advertising a commercial firm on their home page.

    I started doing a little more investigation of the student’s city and found that there was another university in the same city that was very active with Free Software. In fact, they had a mirror of Debian software and were actively promoting Free Software.

    At first I thought that perhaps the two universities could join forces and put on a “Free Software Day” where I could give a talk. Then I thought that perhaps the professors from the “Free Software” university could talk to the professors from the “Microsoft” university and convince the latter faculty on the benefits of using Free Software to teach students or do research. But the more I thought about the topic, the more I thought this was the wrong approach.

    The time has now come for a boycott of universities that use closed source, proprietary software. ”


    So, this quote especialy:

    “At first I thought that perhaps the two universities could join forces and put on a “Free Software Day” where I could give a talk. Then I thought that perhaps the professors from the “Free Software” university could talk to the professors from the “Microsoft” university and convince the latter faculty on the benefits of using Free Software to teach students or do research.”

    Is again spoken like a true fascist would do. They are so full of themselves, that they don’t even think for a second, that maybe, maybe, their approach is not the only one in the world. No, in their thinking, their approach is of course the ONLY RIGHT WAY. Why should only the professor of the Free Software university talk to the Microsoft university, to convince the latter on the benefits of Free Software?

    Couldn’t in theory the MS professor convince the Free Software professor to use MS Software?

    No, of course not! Since, MS software (and all other closed source software) is inhirently evil, as we all know, and alone the thought that it could go the other way around, than his proposal doesn’t cross “maddogs” mind for a second.

    By the way, he is wrong about the MS university being the only one, I know in Germany alone many universites with sponsored software from MS and other vedondors, shows again he much knowledge these guys really have.

    But the most important part of it is the comments section of the article, look again how many AGREE again on stuff like this. Mind numbing.

    I agree that not all people and slashdot and the like are free software fanatics, but, quite a few are. And these “quie a few” people don’t deserve the support they receive. I am a bit baffled, why no serious journalist took the time to read all the crazy shit Stallman and Hall and other open source “founding fathers” write. Oh, wait. I think I know the answer:

    One journalist once took indeed the time, and wrote a criticial pieces about Stallman:




    Stallman’s hold on the Linux movement stems from the radical group he formed in 1985: the Free Software Foundation. The Boston outfit, which he still runs, is guided by a “manifesto” he published that year, urging programmers (hackers) to join his socialist crusade. The group made Stallman a cult hero among hackers–and ended up holding licensing rights to crucial software components that make up the Linux system


    Simon Lok, chief of Lok Technology in San Jose, Calif., a maker of cheap wireless-networking gear, dumped Linux a few years ago in fear of the Stallman bunch. “I said, ‘One day these jackasses will do something extreme, and it’s going to kill us.’ Now it’s coming to fruition,” Lok says. “Some of this stuff is just madness. These guys are fanatics.” He adds: “Who do these people think they are?”


    But then, Richard Stallman rarely is pragmatic–and in some ways he is downright bizarre. He is corpulent and slovenly, with long, scraggly hair, strands of which he has been known to pluck out and toss into a bowl of soup he is eating. His own Web site (www.stallman.org) says Stallman engages in what he calls “rhinophytophilia”–”nasal sex” (also his term) with flowers; he brags of offending a bunch of techies from Texas Instruments (nyse: TXN – news – people ) by plunging his schnoz into a bouquet at dinner and inviting them to do the same.

    His site also boasts a recording of him singing–a capella and badly–his own anthem to free software. (“Hoarders can get piles of money / that is true, hackers, that is true. / But they cannot help their neighbors, that’s not good, hackers, that’s not gooood,” he warbles, which culminates in polite applause from his followers.) He hasn’t hacked much new code in a decade or more. Instead he travels the world to give speeches and pull publicity stunts, donning robes and a halo to appear as a character he calls “St. IGNUcius” and offer blessings to his followers. (GNU, coined in his first manifesto, is pronounced “Ga-NEW” and stands for “Gnu’s Not Unix”; the central Linux license is known as the GNU license.)

    And though he styles himself as a crusader for tech “freedom,” Stallman labors mightily to control how others think, speak and act, arguing, in Orwellian doublespeak, that his rules are necessary for people to be “free.” He won’t speak to reporters unless they agree to call the operating system “GNU/Linux,” not Linux. He urges his adherents to avoid such terms as “intellectual property” and touts “four freedoms” he has sworn to defend, numbering them 0, 1, 2 and 3. In June Stallman attempted to barge into the residence of the French prime minister to protest a copyright bill, then unrolled a petition in a Paris street while his adoring fans snapped photos.

    Now, after writing this and other somewhat negative articles about FOSS, which are essentialy true, read the above craziness by Stallman himself (“injustice software” etc.) this journalist (Dan Lyons) was basicaly crucified.

    Fake blogs by his name appeared, google bombs to link his name to questionable material appeared and many other nasty stuff. It must have been hell.

    At the end, he BEGGED for forgivenes, to make it stop:


    “In what many will consider either a total change of heart (or complete BS), Forbes columnist Dan Lyons was caught on video by Linux.com (also owned by Sourceforge) at a recent conference professing his undying love for Linux. The words, “pry it out of my hands at gunpoint” were even used at one point.


    In any case, old-hippie sentiments aside, Dan Lyons says that despite the many attacks on him as a supposedly anti-Linux attack dog, he loves Linux. And uses it. And that he has trouble understanding why anyone would think he doesn’t love Linux. ‘”

    He begs for “forgiveness” to the crowd, almost like the victims in show trials in Stalin’s Russia were made to do! What the hell of a pressure must the man had gone through, to “confess” to a camera, that the “loves Linux” (to make the attacks stop)

    The FOSS fanatics aren’t that harmless.

  185. Shish Says:

    It used to be the case that ALSA could only do multiple streams with hardware support, but then someone wrote a software mixing plugin, and it was declared stable enough to run by default in 1.0.9 (released 2005-03 — given that most desktop-oriented distros have 6-12 month release cycles, I would think it safe to say anything which is more than two years old is old enough to rely on)

    I’m afraid my knowledge of graphics functions is even less than my knowledge of audio, no idea where to start on the focus thing :( But that description should be clear enough for someone to implement (if it isn’t buried in there already)

  186. Jasper Says:


    Looking through the thread no-ones mentioned ddd, the data display debugger, which I thought was a great improvement to gdb when i found it a few years ago:


  187. Doug Orleans Says:

    A Modest Proposal: you could just release the source code and let someone else get it working on Linux.

  188. Mitchell Says:

    Linux Victim: You claim the Free Software movement is just a hateful cult, but it seems the only one being hateful is you. I cannot believe how many words and citations you have put together here, for the purpose of slander. You could have written your own articles with all that material. And against who? The Free Software Foundation has a mission to spread usable computer software to the world. You can be critical of their efforts or their mission, but you must really be a dark character to spend so much effort attacking a charitable organization. Did you kick any puppies on your way into work today?

  189. Stoffe Says:

    The “release the source code”-proposal is very interesting one, and of course it seems counter-intiutive at first – wouldn’t that mean that noone would buy it?

    Not necessarily. Those who pirate, pirate anyways, and there just is no way around that. Those who stay legal, will not pirate, but might they be tempted by a legal, free, port? Here’s the kicker: release the source only, and keep all other resources. Make it clear that it is ok to buy the game and run it with ported version of the source, when you have a legal copy. Copyright and whatnot protects you just as much with the source free as when not, and nothing changes in practice apart from a potentially larger market.

    A parallell could be made to how SCUMMVM works. If you have a legal copy of the game, you can play it on new platforms (yes, if you have a pirated version as well, but that don’t change the pirates will pirate equation). I think some games such as DOOM 3 and Neverwinter Nights used a similar model, where players bought a Windows version and downloaded a Linux executable, though I will not swear on exactly which games that was (Unreal shipped with Linux version on CD). That also seems somewhat comparable. I could definitely live with the proposition that I buy the game, then “patch” it to work on my system. And when a port is good enough, you could ship it yourself as well.

    I think it’s an intriguing proposition, and the community often wants the source to do the work, so let them. :) I can’t imagine you have any revolutionary code in there, just revolutionary gameplay. And since there are bound to be free clones popping up, why not have the real version?

    Anyhow, good luck again. =)

  190. Christopher Yee Mon Says:

    Well I’m not a developer, but I would totally buy a copy of Braid for Linux. I haven’t read the giant thread of comments, but I wanted to give you the headsup on a Linux podcast that discusses your blog post about porting Braid to Linux. On the Linux Action Show season 8 episode 6 http://www.jupiterbroadcasting.com/?cat=4 , They brought up the story and your concerns and the spirit of the comments. One of the hosts is a developer who brought up answers to some of the questions in the post.

    Put me down as officially wanting this port to happen. :)

  191. Christopher Yee Mon Says:

    oh incidentally the braid talk happens from 10:00 to 22:00 in the podcast

  192. ariten Says:

    There is a lot of people who would like to see the port and I just hate the idea, that the linux community we all love has responded in such an awkward way, not even appreciating the work you were willing to do.

  193. A Gamer Says:

    If you are going to release it for Windows, I will pre-order it now. If you release it on Steam, I will buy it for friends. If you release it on Linux, I might play a port of it on my phone some day.

  194. Mitchell Says:

    Christopher and Ariten: As Jonathan Blow keeps saying, this article is about getting a development environment on his linux desktop, not necessarily for porting Braid to Linux.

  195. Patrick Walton Says:

    Jonathan, you definitely aren’t the only one to feel that way about GCC, GDB, and make. The GNU development tools are really showing their age and they’ve accumulated a lot of cruft.

    There’s hope, though. I’m pretty sure that eventually GCC is going to be replaced by LLVM, which is much much faster and has the backing of Apple (they’re already using it for OpenGL shaders). Among other things LLVM is designed so that IDEs can hook into it to allow the deeper integration you’re talking about for point and click debugging, Intellisense, etc. Valgrind has the potential to replace the aging GDB. And Make is being replaced by CMake, which works with Visual Studio too. CMake improved my productivity so much I don’t even touch make anymore.

    The technology isn’t there yet, but I think it’s worth keeping an eye on the Linux dev tools in the future.

    (Full disclosure: I’ve contributed to LLVM.)

  196. mhn Says:

    I’m pretty clueless but I think using alsa is pretty safe / the most reliable / common system. The alsa dmix plugin (I guess it’s been standard for many years) enables as many apps as necessary to play at the same time (for quite a lot of years) without the need to use esound, pulse, aarts.

    In my experience (user only), just using alsa always gave the best results. I even disabled the aarts / esound / pulseaudio servers started by my distros, because they only added problems !

    Personally, I wonder to what extent building proprietay apps for Linux systems is safe, as everything changes regularly (kernels, libs, APIs ?…). If those games could work with wine, a working wine installation would ensure their functioning forever (?). Just a thought, tell me what you think !

    Anyway, some proprietay 3D games do work very well (Unreal Tournament, Rainslick, Penumbra). Some really suck : I’m sorry, but the ports performed by Runesoft all have issues. (is that only their fault, I dunno)

  197. mhn Says:

    To complete my post, above… Just one remark : I browsed quickly the comments above.

    All communities of any kind (especially passionate people) have “extremists”. Please just remember those are the ones that make most of the noise, and pull the trigger easily.

    For a few years now, I’m a Linux only user. I support OSS. That doesn’t prevent me from realizing some things are wrong and could be better. That doesn’t make me automatically criticize Windows either. I think ordinary people think this way… But they are less audible.

    Anyway. I would definitely purchase the game :) And probably also if it worked with Wine.

  198. Eu-Ming Lee Says:


    I feel your pain. I’m a professional game developer working on porting a DirectX (Renderware, no less) project over to an open source OS. eclipse, the javamachine that runs eclipse and gdb both dumped 400 Mb cores that gave no stack when it encountered a line like

    foo = new int[0];

    It is incomprehensible to me when people say that using gdb is in ANY way superior to Visual C++. I have not found a way to click up a call stack and see local variables at higher levels in the call stack by mousing over them using ddd, the debugger that doesn’t crash 10 out of 10 times. Since I tend to code with a live debugger on, the Visual Studio IDE really is an integral part of the development process— code, test, and run all in one step rather than split up into several phases.

    Needless to say, it greatly impacts my productivity to go to development tools that make it feel like 1987. I understand it is possible to break up my workflow in such a way that it is more efficient for the tools that I’m using, but I’m spoiled and want to work as fast as I’m used to.

    If given a bunch of punch cards and a 2 week wait before compiling the next batch of cards, then maybe my process will be different than my “live debugging and coding” technique— with flowcharts and a bunch of other work I don’t really want to do. But given that I know with the right set of tools I can work really fast versus knowing that I can’t, I’d simply prefer to have the right tools.

  199. Alex Says:


    I’m not a coder myself, but I do use linux and wasn’t sure if anyone brought up the idea of just releasing Braid in windows — but making it as Wine-friendly as possible? I’d be just as happy to pay for a windows game I can run with Wine in ubuntu then a linux port of the game (possibly even happier, as I could play on both without any *major* differences)

  200. PhilArmstrong Says:

    Wow, this thread is still going :)

    It’s especially interesting how resistant people are to just using gdb directly. Perhaps this a reflection of usage: by necessity, the code I work on (non-game related) creates and modifies large. complex objects. Having to click on endless subcomponents in the VC++ gui has driven me nuts in the past (can you automate that in VC+ btw? I’d love to know, since I’m going to have to do some more windows coding soon.) whereas in gdb I can have a few scripts that can rummage through the guts of an object and print out the information I need.

    NB. For those of you who yearn for pointy-clicky debugging under Unix / Linux, have any of you tried anjuta or kdevelop? They might give you that pointy-clicky goodness that you crave – I haven’t tried either in ages, so can’t comment on maturity or featurefulness of the code at all mind.

    NB2. To the person who commented about DTrace upthread: by all accounts DTrace is awesome. It’s a Solaris thing of course (since ported to OSX too IIRC): Linux does have something similar, but it has a slightly different approach & isn’t as mature as DTrace is (probably on a par with the OSX DTrace port I’d guess). If you have a nasty performance problem with a unix program then it’s probably worth building on Solaris just to get access to DTrace, just as people have ported to Linux purely to be able to use valgrind on their code.

  201. Eric Anholt Says:

    1) DGA input is the only way to get the events you need, which is really sad as every other aspect of DGA is so hated by us developers. But the input guys haven’t got around to giving us the relative events we want out of XI yet (but once that happens, XI2 should be the API you want — relative motion and individual addressing of each device), and it might just take someone else just stepping up and doing it.

    2) Isn’t that just XGrabPointer? I’m not an input guy; I don’t know if it has side effects you wouldn’t want.

    3) ALSA. It’s the API for native access to the sound device, and the preferred API for layering on top of PulseAudio. Be sure to read Lennart Poettering’s posting on the “safe ALSA subset”, though — your app will almost always be run on top of pulse.

  202. foo Says:

    “It’s been 20 years, and gcc is still pretty much the same! gdb is still pretty much the same! Make is still pretty much the same! These are the key tools of software development and they have not changed in 20 years (apart from, say, improved C++ support in gcc). There’s a word for that: it’s called stagnation.”

    Here’s a different point of view (“Get to know GCC 4 – What’s new in the GNU Compiler Collection release series” – M. Tim Jones, 28 Oct 2008):

    Today, GCC is the most popular compiler toolchain available. The same source base can be used to build compilers for Ada, Fortran, the Javaâ„¢ language, variants of C (C++ and Objective-C) and covers the largest number of target processor architectures of any compiler (30 supported processor families). The source base is also completely portable and runs on more than 60 platforms. The compilers are highly tunable, with a large number of options for tweaking the generated code. GCC, in short, is the Swiss Army knife of compilers and redefines the meaning of flexibility. It is also the most complex open source system that exists: Today, GCC is made up of almost 1.5 million lines of source code.


  203. gnud Says:

    I’m no game programmer, but I’ve dabbled a bit in audio programming.

    Have a look at libao http://www.xiph.org/ao/ – and the basic sine wave example http://www.xiph.org/ao/doc/ao_example.c

    I’m not sure about your question though — and I think some other answers were made because of misunderstandings. In the post text, you say that you feel sdl is lacking for “serious game programming”. So people suggest a more feature rich lib like openAL. But in one of your comments, you say that you just want to play a premixed audio stream with minimum fuzz. For the latter case, I would think libao could fit well.

  204. Jonathan Abbey Says:

    When I was doing C/C++ programming on Unix/Linux, I was utterly devoted to the UPS debugger (http://ups.sourceforge.net/). Far better than gdb in terms of providing good visibility into the code.

    Sadly, the author hasn’t put out a new release in the last five years, and I don’t know whether it would be useful with modern GCC, NPTL, etc.

    Seems like a damn shame that it isn’t being maintained any more.

  205. Grim Says:

    Porting a game to Linux is not necessarily the same thing as porting it to X11 (or even porting it UNIX-like operating systems in general). Porting it to X11 means that the game can run on a Linux host but use an X-server running on a different operating system (say Irix or HP/UX). SDL supports this (but doesn’t depend on it). Porting a game to X11 is clearly problematic.

    If you feel the no need for X11 and don’t care about any other portability issues either, you can just use Linux kernel APIs directly (with the downside that it will work only in Linux, not in any other Unix-like OS). As you probably already know ALSA is the kernel API for sound. For reading the the mouse (and all other input devices) there are files in /dev/input for this. Open any of the /dev/input/mouse* files to read any one of the connected mice (or the file /dev/input/mice for all events from all mice). It’s very easy to use, just an emulation of the PS/2-protocol (with all extensions available). As an alternative you can read the files /dev/input/event* for a much more complete interface to all kind of input devices (mice, joysticks, touchscreens, keyboards, joggwheels and web-cams and such with buttons on it). You can query them for functionality and use anyone which can do the job.

    It’s simply not true user-land API to the Linux kernel changes very often. (The internal kernel APIs does, but that is irrelevant for application developers.) No sound API has ever been deprecated (ALSA has been added but OSS is still around and there is also OSS emulation drivers for ALSA), no input API has ever been deprecated (but the current one was extended almost ten ears ago). Only a handful very minor APIs and experimental ones have ever been deprecated (but can usually still be compiled in). I can agree that a bunch of random libraries break ABI now and then. But the Linux kernel API is actually very stable. Perhaps not entirely perfect, but I bet a few APIs has been deprecated or changed since Windows 1.0 as well (for example the int 33h mouse API went away while the Linux mouse API stayed the same).

    As for the argument about some Linux users still not using ALSA. Why care about them? It’s the same kind of people who still run windows 95 (except that newer linux kernels don’t require better hardware). I think it’s totally reasonable for a modern game to require a linux version newer than ten years.

  206. Brendan Miller Says:

    Yeah.. there are real problems with the development tools, and real complacency in the community.

    I can offer you a few tips on making your Linux dev environement more reasonable in the future if you are still interested. I’m a Linux developer, but not a game developer, so I can’t really give you tips on SDL or whatever, but here’s how I’ve made the dev environement more friendly.

    Make replacement:
    Make is truly awful, but it is also awfully familiar to a lot of Richard Stallman wannabes, which is why people still use it. Here are some tools that are actually good

    1. scons
    2. cmake

    I use scons. It’s good for writing a pretty concise C++ build scripts and it understands the C++ preprocessor and does automatic dependency analysis.

    Don’t use it for anything else though. It advertises Java, fortran support, etc, but only the C++ stuff is reliable.

    Scons and cmake are cross platforma and work on windows and can generate visual studios projects.

    There are no good C++ IDE’s for Linux, but there is one good C++ *editor* that will let you jump to definitions, do code completion, jump to definitions, etc. Visual slickedit. It can generate tag files of all of your source code in a way that is independant of the build system.

    It’s originally windows and before that DOS software that was ported to Linux. I heard that it used to be pretty widely used at Microsoft before they rolled out visual studios. It’s also expensive commercial software so… there goes some of the benefits of using Linux. Shrug. On the other hand, I use it to *write* commercial software for Linux, so I don’t really care.


    I feel a little sheepish pointing you at a tool I don’t use myself. I’m much more unit testing and logging oriented as far as debugging goes. However, I have heard good things about this:
    Which is a commercial debugger for linux. It is *not* a GUI wrapper around GDB, there are plenty of those.

    As far as libraries go… think static compilation. Version skew is too persistant of a problem on Linux to ship commercial software without it. DLL hell is way worse right now on Linux than it ever was on Windows.

  207. Eclipse Says:

    wow! that’s surely an hot topic. ;)

    I’m an indie developer too and we’re currently rewriting our own engine to be pc\console crossplatform and to support mac os x.

    We took a look at linux too, and i really have to agree with Jonathan about everything.
    Today quality games are maybe the hardest stuff to develop, they just NEEDS the machine horsepower much more than your average application, they needs to use audio very well and in a very performant way, same for inputs, and of course they need also to use well the GPU, and i’m talking about milliseconds to take care of all that stuff.
    They there’s also a lot of content in audio or 3d\2d form, so a lot of stuff to manage in memory too.
    I’m sure it’s something that all the linux devs around there without any serious game dev experience never cared about. All the stuff can be good if you need to do some sort of small command-line utility or even an average gui based application, but for games like Braid, sometimes you just f*ckin need a good IDE, an awesome debugger, and maybe even more (like the awesome Visual Assist X suite or tools like PIX from the directx SDK).

    In the end, for linux enthusiasts: maybe the tools that you consider great and totally fits all your needs can be almost useless crap in proper game dev, and it’s true, try it to discover it yourself.

    PS thanks for Braid, Jonathan, it’s truly an awesome game and it totally blew my mind off several times, i hope to see the pc version out soon too but i expecially expect a new game announcement ;)

  208. Rob Says:

    Whilst I may have missed another reply to the low latency audio question.

    There’s 2 main areas with conflicting aims :

    o Professional Audio Applications, minimise latency, power usage not considered – JACK
    o General Audio, media players, games and effects, low enough latency, low power desired (preserve battery on laptop) – ALSA or a Sound server like PulseAudio

    The OpenAL is probably a way to use ALSA or OSS, unfortunately when ALSA was accepted, OSS was not killed off, and just stayed alive enough to confuse and prevent focus on one sound architecture, and getting that right.

    The lead developer of PulseAudio appears to be trying to solve your problem. To use it, you it would appear that using the PulseAudio supported subset of ALSA would be a good option. Whilst it is clear, the current situation is confusing and transitional, http://lwn.net/Articles/299211/ shows developers are working on it. The libsydney suggestiopn might be a better and more portable solution. There’s info around on a PA version minimising interrupts, and using “just in time” processing to avoid drop outs, being high resolution timer based, so working in similar way to MacOSX and Vista.

    ALSA was included in mainline 2.4.0 kernel, and was actually developed earlier and included in some 2.2 based distributions like SuSE in 2000. As a low level sound API, it really ought to meet the apparently “simple” requirement sound requirement you mention without mangling and mungeing things too much, with layers and features you don’t need.

  209. Jonathan Blow Says:

    I appreciate the breakdown, but from my standpoint as a game developer, there’s not such thing as “low enough latency” in the way described. Games would definitely be in the “minimise latency” category because you want as absolutely close to zero as possible to create a good experience. So JACK would seem like the API to use — if it were universally supported.

  210. Morris Says:

    Hey Johnathan,

    You should know better than to get in argument with a linux user, it’s like talking about someone’s religion.


    But I have a coding question. What do you find harder to code for:

    The PS3 or Linux? One advantage of the PS3 I imagine is that you know what every end user has.

    Thanks for the great game (Braid)

  211. Rob Says:

    > there’s not such thing as “low enough latency” in the way described. Games
    > would definitely be in the “minimise latency” category because you want as
    > absolutely close to zero as possible to create a good experience.

    All the OS implementations have latency, they have to buffer none of them are instantaneous, just like calculations or memory writes are not actually instantameous. “low enough” would mean that in your game, the sound has no perceptible lag, but has good synch with intended visual effects. Furthermore control has to be provided to stop or alter sound already buffered for output, giving the illusion of instant control.

    In some blog critiques of ALSA by the OSS lobby (which was based on Soundblaster driver used in DOS times for many a game), involved it being too low level and over concerned with low latency.

    So actually as JACK is a layer over ALSA and satisfies pro sound applications, raw ALSA would be the minimal latency solution.

  212. Jonathan Blow Says:

    With (for example) the DirectSound interface, I write directly into the buffer that is being DMA’d to the sound card (or perhaps a facsimile with copy-on-unlock semantics; I dunno), and I can go back and change stuff that I’ve already written, if I need to. There is a cursor that tells me “if you write before this you will probably get into trouble since it may be already on its way to the sound card” but I can even ignore that if I want.

    My point was just that when non-game people say “low latency”, in my experience they have a very different idea of what that means than I do.

    It’s hard to get good communication with Linux users though, because there are a lot of options and no reliable information about them anywhere. (For example you change your mind about which API provides minimal latency in these last two comments. So as a third party who has no experience with either API, am I supposed to believe one conclusion or the other now? Now multiply that by N thousand pundits and M APIs that play audio. It is a total mess.)

  213. Matt Says:

    >With (for example) the DirectSound interface, I write directly into the buffer that is being DMA’d >to the sound card (or perhaps a facsimile with copy-on-unlock semantics; I dunno), and I can >go back and change stuff that I’ve already written, if I need to. There is a cursor that tells me “if >you write before this you will probably get into trouble since it may be already on its way to the >sound card” but I can even ignore that if I want.

    Is this what you have been needing to do, or just an example? I enjoyed reading all the comments minus the stupid religious ones, but I felt you were a little vague about precisely what functionality you needed and that this contributed to alot of wasted time and troll posts.

    I suppose in Braid you have a pretty uncommon use of sound playback :)

  214. Jonathan Blow Says:

    I don’t necessarily need to do exactly that, but that is one paradigm that works just fine. The key is that I as the programmer know how much latency is happening; it’s not hidden inside some magical buffering that I can never see.

  215. Jonathan Blow Says:

    (And also that the amount of latency can be made arbitrarily low!)

    Braid does a lot of unusual stuff with sound but it’s mostly done at a higher level. At the low level all I want to do is stream a bunch of 44100Hz samples to the speakers. The fact that that is so hard to do in Linux is what’s so annoying.

  216. Matt Says:

    I’m pretty ignorant of audio programming. I kind of assumed at some level you might have the option of filling some buffer with some pcm data and expecting it would come out your speakers at some point.

    How do mp3 players, audio editors, and other games do it? Is it just that they go through apis that are too crude or imprecise?

    I mean, I can sort of understand if you are trying to manipulate a buffer after it is out there because you are turning the music backwards or something, and this is unconventional so maybe they don’t let you do it.

    But for strict playback.. I’m a Linux user and there are lots of other games and apps that seem to play normal audio just fine, with no synchronization problems. I’m very ignorant of what might be involved in either case though.

    I’ve been in that boat too where I’m trying to find documentation on something a little obscure and my solutions amount to googled mailing list posts. Very irritating!

  217. IWantCookieNow Says:

    I love Linux and I would love to see Braid on Linux, though I would understand if you don’t want to do it, the small market share is reason enough to avoid the hassle of targeting an entirely different platform – even if it was good for game development.

    It is sad how many people here either tell Jonathan that all Linux users are assholes and therefore don’t deserve Braid, or that Jonathan is an idiot for not liking the Linux tools available for game development.

    Not doing any game development myself, I actually prefer Linux for C++ development, but I understand that the needs of game developers haven’t got much love from Linux and therefore it is hard to use. And indeed, for people who like working with IDEs, Visual Studio obviously seems to be the preferred choice. (I don’t like using IDEs myself because I’m a control freak and need to be in control of every detail to be happy, but of course that’s a matter of taste.)

    So, saying that developing for Linux sucks in general is not true. But not generally false, either, unfortunately.

    I think we all need to calm down a little and try being more diplomatic.

    Thank you Jonathan for even _considering_ using or supporting Linux!

  218. lord bla Says:


    I really don’t want to get into any fight here. I’m a passionate Linux-user and developer. I started programming on Linux and since my job and hobby-projects allow me to only develop on linux, I never got in touch with VS at all. What I know is I don’t like using Windows nor Mac. Not because I hate the products nor the companies but because I like the way I’m allowed to admin and use my Linux installations. I didn’t like using xp and vista is a big performance-mess imho. Yes, with every new release of your Linux-Distribution features get added and bugs come up, but one get’s used to this kind of problems and should be abled to fix them within hours or max. days.
    From my point of view, developing on Linux is a pleasant thing but it really needs some time to gather information about what library to use for wich specific job. That’s really not a simple task, but it’s well worth planing.
    Instead of try&fail I directly ask the people behind the projects if what i plan is possible and what’s the best way to do it. I need a special way my mousepointer to behave? I go to #sdl on freenode and ask. When ever i did that, one of the developers behind sdl answered me in seconds, highest minutes. I run into problems? I ask again. And guess what? Those guys are even happy about feature-requests, especially if they are made by skilled developers.
    And yes, Linux and Windows are completely different, so yes, you have to learn new things if you are mostly used to developing under Linux.

    Regarding Ubuntu’s stability: yes, this is an issue, a big one. NetworkManager is a nice idea, but is still completely unreliable. Good thing there exist alternatives (wicd for example). Same goes to things like pulseaudio. Ubuntu is on a very wrong way here, esp. regarding it’s core-components, Damn they still have a 2 year old bug that requires root-privilegs to acces a lot of scanner-models. Thank god ubuntu can be made rock-solid with some work and knowledge and there exist other distributions that go for stability rather then faked usability..

    From a deverloper’s point of view you don’t really have to care about that. Sure, your very own linux-installation should run stabe for dev. and testing, but you can support only certain Distributions and tell consumers they must have certain dependencies installed and working. For example, as you seem to rely on low-latency sound, let the game require jack. Most modern Distris have it in their repositories and imho it really drops latency a lot.

    I still hope for a Linux-port of Braid and wish you all effort. I don’t have any Windows-Installation at all so I can’t play braid before it get’s ported. Wine is not an option for me if I shall buy a product. Also, I’d love to see the game on the Pandora some day (hint, hint)

    Last but not least: I don’t think using Linux is in any way related to lack of intelligence, arrogancy or any there mental problems, like some people stated here. We are talking about operating systems and those are a matter of needs and taste. Linux fits my personal needs and my taste more then Windows and Mac. That doesn’t make me any better or worse then prefering a different OS. Jeff from Wolfire games stated in his blog that Linux-users are hungry for games and are willing to spend money on native ports. While there are certainly more then 9 times more potential consumers on Windows, Linuxusers make 5% of his users, windows “only” 45%. Don’t measure the Linux-users will to buy games by the sales of Ankh and compareable offers. The Linux-version of those cost 15x more then the CD in the low-budget corner of your near-by Supermarket and are even bad ported. It seems like the Linux-port of prey does pretty well since it’s going a different route.

  219. BlackAura Says:

    For sound output, you pretty much don’t have a choice in the matter.

    JACK, PulseAudio, and other similar systems are either too new, or not widely used enough to even consider. You just can’t rely on them being there, and in the case of PulseAudio, it probably wouldn’t meet the latency requirements.

    That brings the choice down to using ALSA directly, or using OSS.

    OSS is closest to the DirectSound model. You set up the output hardware, get a pointer to a ring buffer, and can query the API to get the current playback position. The API is pretty old-style Unix-y (open the device node, use ioctl calls to set it up or query the device, use mmap to map the buffer), but it’s dead simple to use. Back in the day, games just used OSS, and everything was good.

    When running ALSA drivers (which all current Linux distributions do), OSS doesn’t support software mixing, so unless you have a real sound card with hardware mixing (virtually nobody does anymore), you can’t use the sound hardware at all if something else already is. It’s the same thing that happens in Windows XP if you try to use kernel-mode streaming, or that used to happen in Windows 98.

    Using the ALSA API directly gets around this problem, since it supports software mixing of multiple streams, in the same way KMixer does in Windows XP. Both systems add an additional latency (~30ms in Windows, but ALSA’s doesn’t seem to be documented anywhere – it’s probably much higher). The catch is that ALSA’s API is really hard to use. Notably, it requires you to write samples to the device at regular intervals, rather that just using a shared buffer, so it’s very sensitive to timing. Imagine a version of SDL’s audio API that continually bothers you with low-level rubbish that you don’t care about, and you’ll pretty much get the idea.

    The approach most Linux games take it to just use OSS, and hope that the lack of software mixing doesn’t become a problem. It’s not ideal, but Linux users will probably be used to it, and probably won’t be expecting anything better.

  220. Eruaran Says:

    Hi Jonathan, I’m sorry to hear you’re finding the task of porting to GNU/Linux to be a prohibitively difficult task. I’m not a developer so I’m only speculating but on the sound issue at least, I’m wondering if talking to Aaron Seigo might be helpful ? The KDE team have done a lot of work with ‘Phonon’ which is an abstraction layer which makes life a lot easier for developers. Basically the idea is that you don’t need to know anything about audio back end stuff, Phonon handles it for you… As I said I’m not a developer but I’m hoping this might be useful, even if not for this project but a future one.

  221. RealNC Says:

    You can use OSS instead of ALSA. I’ve coded a simple wav player in OSS in 20 minutes after bashing my head against the wall with ALSA for a week.

  222. Vadim P. Says:

    World of Goo and Celetania were released natively for Linux a week or so ago, both have sound working quite okay.

  223. JaumeI Says:

    Well, not that I don’t want a native Linux Braid game or anything, but I just tried the demo with Wine and, at least in Ubuntu, it works out of the box without any more problems than minor sound glitches (and I mean really minor). So, at least while we have that native version, we can still play your fantastic game ;) .

  224. Stoffe Says:

    JaumeI: the important part of that info is that if so, it’s probably a really small job for CodeWeavers to do a (Wine-based) port for real, that can install and work seemingly natively. (See above in comments)

  225. Ben Ruijl Says:

    Porting code is always a problem, especially when the original code was not made to be ported later on. I suggest you use OpenGL with the 2.0 specs to do the rendering. It should be intuitive, and maybe you don’t have to recode the shaders if you used CG instead of HLSL. For audio, I’d recommend fmod although I am not sure you can use that for free, depending on your license) and for text Freetype.

    For my projects, I don’t use libraries like SDL, I just build the OpenGL screen from basic X11 commands. To check where the mouse is, I use XQueryPointer in the idle part of your main loop (where all the rendering happens).

    If you have any questions, feel free to contact me.

  226. David Marrs Says:

    I’ve come to this discussion v.late but I’m interested in what you think is so wrong about gdb, Jonathan. I’d presumed because it needs to be plugged into a text editor and doesn’t provide an out-of-the-box IDE experience, But from http://braid-game.com/news/?p=364#comment-3498 you say that you use emacs. One of the major features of emacs is its integration of the gdb. And as someone who hates emacs, I have to say that it’s very nice; better than the vim plugin that I use (though that works well enough for me). I’d also be very surprised if emacs didn’t have intellisense-style completion by now, as this kind of thing has been around for donkeys years now.

    Your lack of love for Linux as a DE raised my eyebrows as my position is the complete reverse. All the really useful tools (including the ones I run on windows) are unix ones. Still, each to his own, I guess.

    Anyway, for what it’s worth, I found this discussion after googling braid + linux, hoping that there may be a port.

  227. aaron m. Says:

    wow. i know it’s been said before in here months ago, but i simply cannot believe the self-righteousness of *certain* linux users. not all, but some. i’m honestly disgusted to the point where i am not even willing to consider working with linux in any fashion if this is how members of the “community” assert themselves within it. guess what? he doesn’t need you. he is doing you guys a service by busting his ass in an attempt to port over his game which, by this point, i’m not even sure you deserve.

    anyway, i know this is all old news, but i seriously can’t believe that there are people out there who have their heads so far up their linux kernel that they blame the operating system’s lack of usability on the user. kudos, guys. that kind of smugness takes a special kind of jerk-off.

    jonathan, you’ve made a great work of art and really haven’t deserved the grief you’ve gotten over this nonsense. you have my future support (and dollars) from now on.

  228. Stathis Sideris Says:

    At least one friend of mine has played and completed Braid on Linux using Wine, so i think the releasing it bundled with Wine in the same way as Picasa is probably a very good idea. Maybe hire a tester an retain your sanity?

  229. Phil Armstrong Says:

    And…it’s still going!

    Aaron: ever tried pointing out flaws to a Mac devotee? Some people get emotionally attached to their OS choices: in the OS arena, far fewer of them get emotionally attached to Windows, because they never actually chose it themselves. (Although I’ve seen a few scary windows devotees in my time.)

    Getting slightly back on topic, there’s an ‘overview’ guide to Linux sound APIs here http://0pointer.de/blog/projects/guide-to-sound-apis

    The “safe” ALSA subset sounds like the least-worst option: unfortunately it doesn’t allow mmap() buffers. Sadness ensues…

    (NB: the document linked to implies that this is simply because not all hardware supports playback from mmaped buffers: does windows have the same limitation, or has DirectSound simply orphaned hardware that can’t do that? I suppose you could emulate an mmaped buffer in the library, at the cost of some inaccuracy in any reporting of the current state of the system)

    The Linux Plumbers conference is trying to make this kind of thing better; it’s a slow grind though. See http://lwn.net/Articles/299211/ for the key quote about the Linux sound APIs from Lennart Poettering: “It’s a mess”. I don’t think anyone who’s posted here is going to disagree…

  230. Phil Armstrong Says:

    At least you can test for the availability of the mmap() method with snd_pcm_hw_params_set_access()

  231. makomk Says:

    “With (for example) the DirectSound interface, I write directly into the buffer that is being DMA’d to the sound card (or perhaps a facsimile with copy-on-unlock semantics; I dunno), and I can go back and change stuff that I’ve already written, if I need to. There is a cursor that tells me “if you write before this you will probably get into trouble since it may be already on its way to the sound card” but I can even ignore that if I want.”

    Errm… I think you’ll find that doesn’t do quite what you’re expecting. The exact behaviour depends on if you’re using XP or Vista, but in either case there’s generally a software mixing layer between your card and the buffer. (On Vista, there’s always a software mixing layer, even if your sound card supports hardware mixing.) The latency is… non-trivial, and the internals are not exactly well-documented but almost certainly involve mixing and submitting data to the hardware in large fixed-size fragments.

    Anyway, the good news is that it appears you can do the same thing by using ALSA’s mmap API (http://alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___direct.html) together with snd_pcm_rewind and snd_pcm_forward. The documentation is… sparse, but adequate. (The bad news is that this isn’t guaranteed to work for all hardware and configurations, though this is getting better.) Alternatively, you can use the PulseAudio API, which also has a way of modifying samples you’ve already written – but next to no documentation. (Thanks to the new glitch-free feature, PulseAudio should also give you *very* respectable latency when doing this – probably better than Windows.)

  232. Jonathan Blow Says:

    Regardless of the actual implementation — which is not what I care about — the fact is that the latency, which is the only thing I do care about, is very low. You say it’s non-trivial, but that is not my direct day-to-day experience — in reality the latency on Windows is so low that I, as a programmer, just don’t need to think about it. Of course the data is being sent to the hardware in fragments, but they are not “large” enough to cause problems. And of course the data is probably being copied into kernel space and then out whatever bus to the audio device, but again, empirically this does not cause a problem.

    If the Linux sound API gets to this point, where I can just write some code and know that sound is going to play in a low-latency way, and work on most peoples’ machines, then that’s great. I don’t care about any implementation details or any other functionality, actually. (The taking-back-what-I-already-wrote was just one example I was putting forth of functionality that exists in Windows that can be useful, but I can live without that in most cases, it’s just a way of shaving extra latency off if you want to be daring).

  233. Owen Lynn Says:

    I find it sad that it took almost to the bottom of the reply chain for someone to actually answer his question.

    It’s an operating system. It’s not a political movement, it’s not going to save your soul, it defines how an application is supposed to use the hardware.

    Good grief, with friendly helpful people like this on the linux side, who needs Microsoft?

  234. makomk Says:

    Hmmm… latency. By default Alsa apparently uses a fragment size of 1024, which means you’re not going to get under 22ms latency. Windows is in about the same ballpark, from what I recall. Mac OS X and PulseAudio use a more complicated system that can in theory achieve better latency, but then you really do need stream rewriting in order to avoid audio glitches.

    “You say it’s non-trivial, but that is not my direct day-to-day experience — in reality the latency on Windows is so low that I, as a programmer, just don’t need to think about it. Of course the data is being sent to the hardware in fragments, but they are not “large” enough to cause problems.”

    Presumably you’re making sure you have a sufficiently large minimum amount of audio queued at all times. The exact minimum, of course, depends not just on the fragment size, but on arcane stuff like the OS scheduler behaviour (and this applies to Windows as well as Linux) – I doubt it’s that small, though. At a wild guess – about 50ms?

    Really, Linux and Windows audio isn’t hugely different, at least in principle. They have to deal with the same hardware and the same fundamental problems, after all.

  235. Beemer Says:

    Ok – from reading through this, basically the issues are:

    Sound latency
    Poor dev tools

    If you want to make a linux port *and* not frustrate yourself, why not have someone like Ryan Gordon do it for you? (Aquaria is finally coming to Linux via Ryan as an example).


  236. Mars Hall Says:

    I love Braid. I love Linux. As a lover of Braid, i wish like hell it’d come out for Linux. And, as a lover of Linux, i accept the very real possibility of relying upon Wine or QEMU to make those two paths cross (all irony of piling ultra-complex wrappers onto the already-existing ones aside). Either way, thanks, Jonathan, for looking into bringing Braid to Linux as far as you have, for as long as you have, and HUGE kudos for bringing it to PS3 and OSX (all joking of being able to choose which corporate behemoth to support aside) :o P

  237. ALT-F-X Says:

    No, the real problem is a bunch of Linux guys tried the orginal Windows and hated it. They have been using the same dev tools for 15 years and they don’t realize how much the tools suck. End of story. RIP Linux Braid :’-(

  238. Brad Carps Says:

    I find it rather astonishing that the open source community zealots just don’t get why new Linux users and pragmatic developers don’t want to start learning C and contribute to the community. Here, it’s simple: stop being lazy and start working on the hard things (like foundational problems). It’s not our job to fix your software; it’s our job to attract people to your software by making killer apps and promoting them.

    Michael L; Re: As to why I “attacked” Jonathan:

    You fail to see the wisdom of some of your own words. If someone slights you in conversation, responding in kind only escalates it, and you were more than willing to respond, in spades; it’s quite clear your intentions were initially hostile (while his were initially not). Not only can you not claim any moral high ground, your attitude further tarnishes the reputation of the Open Source development community.

  239. Kazagistar Says:

    Thank you very much for this discussion. I have re-read it, and it has really changed my perspective on many things. After some research, I think LLVM and CMake are indeed the toolkit of choice, and I will also strive to learn VC++, if only to be a more rounded and less zealotry-prone developer. Yes, I have issues with Microsoft, and no, I don’t buy the argument that because they are better then certain other companies they are good. But the Linux community should take note: better products tend to lead to more users, so when users complain and go use a competitor’s, that means the products themselves need improving.

    BTW, I have bought Braid for myself as well as for numerous friends… I think it is the best puzzle game of all time, and it has truly inspired me to work on my own (paling in comparison, but nonetheless enjoyable) projects. Thank you.

  240. Glen Stark Says:

    Hey Johnathan

    I haven’t played Braid yet. I’m still hoping for a Linux port! If you do port it/get it ported I promise to buy 3 copies.

    I’m posting to just say that I’m sorry for your frustration, and I’m sorry for your experience with the Linux community. For what it’s worth, my platform of preference is Linux, but I keep finding myself in Windows work environments. Whenever possible I set up a Linux boot for whatever work I do, and just do the testing in Windows. But I program primarily mathematical and scientific software which really has different concerns than game programming. I almost never have to think about threading, for example (although I do think about parallelisation a lot).

    What drives me nuts is rampant fan-boyism. It’s not just Linux, it’s all over the damned place. I find it kinda sad how tribal we remain in the 21′st century. Okay, we can be glad our tribalisation has gotten a little more plastic and abstract, I guess that’s progress, but it would be nice if people could get past that kind of stuff and have rational discussions about merits, consequences, deteriments and subjective experiences without all the chest beating.

    If you ever have the time and inclination, I think it would make a wonderful article, if you were to write up your experiences (both technical and social) and send them to one of the online Linux publications. Perhaps it would even help some of lower level devs to address your issues.

  241. Rusty Broomhandle Says:

    I am not a developer, well at least not a particularly hardcore one, but I do have a suggestion nonetheless.

    If you do indeed prefer the development tools available to you under Windows, but would like to develop something for Linux+Windows, then for any such project, develop it using an API that is already cross-platform. Use the tools available to you under Windows, but make sure the code is clean BlablablaAPI code so that it can be built on other supported platforms.

    I am thinking along the lines of Ogre and suchlike.

    Of course it’s too late for Braid, but yaknow – in future.

  242. Ollie Says:

    Just came by the site to hunt for a Linux version of Braid. Great game and I am going to get it for my PS3 though I would much prefer to have this game on my laptop. If you don’t port this to Linux I hope your future games will be built with a Linux version in mind. Thanks for creating such a great game.

  243. JP Says:

    Wow, worst thread ever. Sorry to see you got so many negative or useless responses, Jon.

    If your patience with Linux isn’t still completely exhausted, you could try to write up the problems you ran into – the most purely technical, non-tool (IDE, debugger) ones at least – with X input and OpenAL as bugs or requests to those respective projects. If the answer you get is the dreaded You Don’t Need That, well, screw them. If not, then maybe someone in the future will find the platform less lacking.

    If you’re paying someone else to do a port, definitely get them to write a postmortem or wishlist of “things that would have made this much easier”.

    Barely anyone is really thinking strategically about games on Linux right now, whereas there are thousands of people at MSFT whose full-time job is to improve their platforms. So it’s a question of first steps.

    My hope is that if a few developers started speaking up with experiences like yours, at least some of the drivers of the big component projects might take notice. Like you said earlier though, it requires some participation on the part of the game devs, and encountering even a bit of regressive resistance is enough to make anyone feel like they’re wasting their precious time.

    Linux has grown to where it is now by people scratching itches, though, and if the drivers of this hypercomplex messy amalgam of an OS at least know the itch exists, maybe someday the benefits would start to exceed the costs of said participation.

    Until then, though, it’s kind of like volunteering at a homeless shelter, but with more irascible nerds.

  244. Tayron Says:

    Jonathan Blow Says:
    September 9th, 2008 at 9:29 am
    SDL_GetMouseState only tells you the position of the mouse pointer, not how much the user has moved the mouse.

    I don’t mean to be disrespectful, but that’s extremely easy to do. just keep the old mouse position and subtract it from the new one, each update…

  245. srdagalp Says:

    I am a Linux user and programmer, and if I move from Windows to Linux my way to work does not fit in the windows. The same goes for windows to linux. Anyway when I need to work on windows I focus on having the job done, and do not write to Microsoft to make comparisons between what I have in Linux. All these posts and debates about what is best seem to me useless, the conversation should be about reaching a goal. Apparently Jonathan Blow just want to unload their frustrations about linux on who have the patience to answer it, and for what?

  246. cheesybagel Says:

    For all you Apple zealots ranting about the superiority of XCode over GCC and GDB, I remind you that XCode uses the GCC and GDB you loathe underneath. It merely provides some UI sugar on top of these tools.

    I remember using the DDD graphical interactive UI for GDB like a decade ago. DDD features debugging data display capabilities that I have never seen in any of these supposedly superior IDEs you mentioned. Oh and I do use Visual Studio 10 on Windows on occasion. The fact is VS isn’t that great a tool for developing C/C++ code. Try merely visualizing a linked list data structure in one of those IDE debuggers and you will see what I mean.

    Emacs and Vim with their zillion extensions can do anything an high end C/C++ IDE can do and more. If you have some kind of phobia of multiple CTRL key combos or have a defective Escape key, you can always use Eclipse CDT for C/C++.

    As for the solutions to the sound and mouse problems, Ryan C. Gordon said it all here in the start of the thread. Use SDL for everything you can in your game. If you need sophisticated audio use OpenAL. If you need 3D graphics use OpenGL.

    Hitting the lower level multimedia API layers in Linux sucks. It also sucks on Windows. Just do not use them unless you are a middleware person, like an SDL or OpenAL developer. Last time I tried that battle (on Windows and Linux) I spent so much time chasing platform dependent bugs and writing backends for zillions of mostly deprecated low level APIs someone, somewhere, still used, that I went back to middleware sound APIs.

  247. James Says:

    I have Linux 10 & the audio is making a constant high pitched whining sound. I have no idea what the problem is.If you can help me I’d greatly appreciate it. Thanx

  248. Tomek Bury Says:

    Hello Jonathan,

    I wrote a small SDL program to test audio latency on Ubuntu Lucid. I can not notice it.

    The program is crude but does roughly what you want to achieve. It plays back an audio from a buffer using SDLs callback. On key press it resets the read pointer and additionally toggles background colour. There’s no noticeable delay.

    The SDL by default chooses playback through Pulse. I haven’t modified any audio preferences on my box and I was using libSDL from Ubuntu repository.

    I can send you the source, if you’re interested.

  249. Tomek Bury Says:

    Hello Jonathan,

    As for the mouse what you might need are not events from mouse *cursor* but from *mouse* itself.

    I’m not sure how is it implemented in SDL but a quick test I made suggest SDL does not report actual mouse movements. SDL seems to recreate them from mouse cursor movements, which has issues with focus and edges you were experiencing.

    I suggest to try this command:

    $ xinput test-xi2 “Virtual core pointer”

    It should report relative *mouse* movements (event type 17), regardless of mouse cursor position, edges, focus and so on. This is what you’re after if I understood correctly. This also what SDL should report, if you ask me.

    Whan the mouse cursor happens to be over the xinput window, you’ll also get mouse *cursor* events reported (event type 6), which contain cursor position, both, absolute and relative to the window.


  250. Tomek Bury Says:

    Here’s SDL bug report I filed:


    It outlines the problems and suggests use of XInput2 as a solution.

  251. Alex Says:

    Like many others here, I feel the need to apologize for the grief that many of these responses have put you through, and find it amazing that the thread is alive over two years after it started.

    Anyway, I find Tomek\’s comment about his test program for SDL audio interesting. If that isn\’t sufficiently low-latency, then JACK probably is the way to go.

    If I were you, I would ship JACK along with Braid, attempt to connect to a running server and start your own copy if there isn\’t one. JACK takes a bit of setup to determine the best latency offered by the hardware available, but once you\’ve determined what latency is available, JACK will guarantee the latency settings you give it. Just spend some time playing with JACK settings in QJackCtl on your own machine to see how buffer sizes can effect latency.

Leave a Reply