Slashdot Mirror

← Back to Stories (view on slashdot.org)

Crytek Open-Sources Their 'Renderdoc' 3D Debugger

Posted by Soulskill on from the more-tools-more-power dept.

An anonymous reader writes "Game studios now seem to be forming a habit out of opening up their debugger / development utilities. After Valve's notable VOGL debugger, Crytek has now decided to open source their Renderdoc debugger. Renderdoc had been available for free use since earlier in the year but now they have posted an MIT-licensed version of the code to GitHub. Renderdoc builds on both Windows and Linux but for now just targets the Direct3D 11 graphics API while OpenGL support is being expected later."

20 comments

  1. Why not the GPL? by Anonymous Coward · · Score: 0

    Would this not have been better released under the GPL?

    1. Re:Why not the GPL? by Ndymium · · Score: 1

      Why would this have been better released under the GPL?

    2. Re:Why not the GPL? by Anonymous Coward · · Score: 0

      Because.

    3. Re:Why not the GPL? by Anonymous Coward · · Score: 0

      Because! GPL!

    4. Re:Why not the GPL? by Anonymous Coward · · Score: 0

      Why would this have been better released under the GPL?

      No.

    5. Re:Why not the GPL? by Himmy32 · · Score: 2

      If only the MIT license was GPL compatible, and someone could add to it and then release a GPL'd fork.

    6. Re:Why not the GPL? by Anonymous Coward · · Score: 0

      Would this not have been better released under the GPL?

      Not for actual game developers. A lot of AAA development houses (including the one I work for) have a no-GPL policy for game engine code (you can only use in tools and then you still have to be careful).

    7. Re:Why not the GPL? by aliquis · · Score: 1

      Because GPL-nazi.

      NO THIS ISN'T A FLAMEBAIT. It's the freaking truth.

    8. Re:Why not the GPL? by vux984 · · Score: 1

      A lot of AAA development houses (including the one I work for) have a no-GPL policy for game engine code (you can only use in tools and then you still have to be careful).

      And this is a debugger. So what are you on about? Do you normally ship the debugger with your game?

      have a no-GPL policy for game engine code

      Well duh. If you don't want to release a GPL product, you don't want to incorporate GPL code in it since you don't have permission to release it under a proprietary license.

      But that's true of all 3rd party code -- you need to vet and document that you have licensing for all of it, to redistribute it in the manner you wish to redistribute it. GPL is easy because its one license and the terms are simple (and if you want to release a proprietary license its trivial -- the answer is don't use it). But the proprietary libraries you might use with your code -- those are a lot more work to sort out; as each one has its own payment structure -- some want per unit royalties, others are sold in tiers, others are buy-once-and-forget, others are priced differently based on the size of your development team, or whether its commercial or non-commercial or research use, some are licensed to your company for all products you release while others are licensed per "product you release"... and on and on. Proprietary code is the labyrinth -- the GPL is dead simple.

      (you can only use in tools and then you still have to be careful).

      Careful how? Because if you use 7-zip or Notepad++ you'll somehow not be able to release your game? Do you worry obsessively about using Microsoft Excel or Visual Studio or Photoshop? Because you can't ship any of that with your game either.

    9. Re:Why not the GPL? by jonwil · · Score: 1

      I think the OP is talking about using GPL code in in-house-developed tools used in creating the game (level editors etc)

    10. Re:Why not the GPL? by Rhacman · · Score: 1

      Why does the MIT license bug people so much? If people want to share their modifications they can and will. If people don't want to share their modifications it's not like publishing the code under GPL would have convinced them to, they just wouldn't have used the code at all.

      --
      Account -> Discussions -> Disable Sigs
    11. Re:Why not the GPL? by tlhIngan · · Score: 1

      And this is a debugger. So what are you on about? Do you normally ship the debugger with your game?

      A lot of places are very wary of the GPL. Especially GPLv3.

      One place I work now audits all the open-source/free-software code that enters the codebase. If it has a hint of GPL, it's almost always auto-rejected.

      Oh, and by codebase, that includes the tools as well. Because some tools emit code, or otherwise touch code, and it's better to be safe than sorry.

      Some GPL programs were allowed - e.g., gcc, but only the versions approved.

      Other licenses, like BSD, Apache, MIT, no problem - those tend to sail through the legal license audit easily. They even went out to say no new GPL code would be accepted - look for alternatives.

      Me personally, I release code under the 3-clause BSD or GPLv2. I don't agree with the GPLv3, so it's v2-only or 3-clause BSD (incompatible with GPL).

      And I guess Crytek feels the same - they don't mind anyone using it, just not locking it up under the GPL.

    12. Re:Why not the GPL? by vux984 · · Score: 1

      A lot of places are very wary of the GPL. Especially GPLv3.

      And the wariness is unfounded ignorant FUD. That's my point. I don't disagree with you that many places are very wary, but its generally ridiculous.

      Other licenses, like BSD, Apache, MIT, no problem - those tend to sail through the legal license audit easily. They even went out to say no new GPL code would be accepted - look for alternatives.

      For code going into anything you are going to release as proprietary this makes perfect sense. The GPL stuff won't be usable, so there no point looking at it.

      Oh, and by codebase, that includes the tools as well. Because some tools emit code, or otherwise touch code, and it's better to be safe than sorry.

      Has anyone ever "been sorry"? Ever? I mean, is there really an actual example of someone using a GPL tool to work on their project that released GPL code, that wasn't completely obvious to anyone with a shred of common sense?

      Because this argument has always seemed like FUD to me.

      Me personally, I release code under the 3-clause BSD or GPLv2. I don't agree with the GPLv3

      I respect that, but I don't agree with tivoization either or people doing an end run around the community intent by providing SaaS etc; so I think GPLv3 and AGPL have their place and are appropriate responses.

      And I guess Crytek feels the same - they don't mind anyone using it, just not locking it up under the GPL.

      Well, the MIT license is GPL compatible. So anyone can link it to GPL code and release it as GPL.

      I've got nothing against BSD or MIT

      The GPL is intended for developers who want to share their work, and have other people who benefited from it share their work back.

      The MIT/BSD/Apache licenses are for developers who don't need or care about that reciprocity.

      Nothing "wrong" with either.

    13. Re:Why not the GPL? by Anonymous Coward · · Score: 0

      GPLv3 is fine. AGPL never has a place and is a ridiculous violation of freedom zero. AGPL can go diaf with all the other EULAs.

    14. Re:Why not the GPL? by Anonymous Coward · · Score: 0

      And the wariness is unfounded ignorant FUD.

      Bullshit! The GPL is viral so using it in even in-house tools can limit your ability to provide those tools the community without releasing everything the GPL infected. If you have proprietary binaries as part of your tools (that are often also part of your proprietary products) you either can't release the tool or you have to re-license the proprietary element to a free license.

      This is why restrictive free software licenses are about exclusion and forcing an agenda while permissive ones are about co-operation regardless of your ideology, individuals have the freedom to decide how much they want to contribute without being forced. You don't wholly accept our faith and our religion? Well we wont work with you!

    15. Re:Why not the GPL? by diamondmagic · · Score: 2

      I seriously doubt the AGPL is legally enforceable. It's a copyright license (so you can still use the software), not a "conveyance license", not to mention the output of a computer program isn't copyrightable.

      --
      Wonder what the public key field is for?
    16. Re:Why not the GPL? by genkernel · · Score: 1

      Working as intended. If you use something that is GPL, you have to be sure to give it back, usually for free. When your business model depends on not giving up the entirety of what you made for free, the GPL is dangerous. Now the GPL is by no means an insurmountable obstacle to building non-free-as-in-beer software, but you have to watch your step. This is intended and necessary for what the GPL tries to do. I *like* the GPL because it prevents my code from being supplanted by proprietary derivative code. I *like* that the GPL does this. This is a feature, not a bug.

      That said, it is probably just as well this debugging software is not GPLed, because watching your legal steps requires resources (and there are significant penalties for screwing up). In the case of a debugger, you have to watch if it falls afoul of the "output is mostly code" clause. "Probably not" is probably not a good enough answer.

      --
      Any sufficiently advanced incompetence is indistinguishable from malice.
    17. Re:Why not the GPL? by genkernel · · Score: 1

      Firstly, not being able to release in-house tools is a complete non-issue.

      Secondly, if the programs are loosely coupled, the GPL, especially GPLv2, is very forgiving of proprietary code and GPLed code working together. You just have to mind your manners and know the rules. For the GPLv3, here are some basic rules from the GPL FAQ:

      For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.

      If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

      Furthermore, the system library exception may prove useful sometimes as well, though that is less common.

      In conclusion then, while there is a kernel of truth hiding very, very well around what you are saying, it is largely FUD. From the GPL FAQ again:

      Which programs you used to edit the source code, or to compile it, or study it, or record it, usually makes no difference for issues concerning the licensing of that source code.

      Finally, although far less importantly, if you suppose that the GPL is violated by your project in some subtle manner (just don't copy code, mkay?), chances are, it doesn't matter unless you are doing something particularly malign. In general, someone else will have to find some way to prove you violated the terms of the license. Furthermore, generally organizations like the FSF provide an ample chance to fix noncompliance, even deliberate noncompliance. I highly doubt there is a recorded case of someone being made sorry for using the GPL in good faith.

      --
      Any sufficiently advanced incompetence is indistinguishable from malice.
  2. When two licenses clash, the fault is with by Anonymous Coward · · Score: 0

    the more-restrictive one.... so in this instance, the GPL is the problem; it's the viral clauses of the GPL that torpedo your dreams, and those aspects of the GPL are political/quasi-religious choices that their advocates are trying to ram down the throats of everybody else who is generally willing to share code.

  3. Interesting by george1101 · · Score: 1

    I've seen something like this before. It's very useful to a debugger, because it's easier to experience the world of code through visualisation. Temporal-spacial debugging can indeed become an automated debugger in time, given the advances made in Artificial Intelligence... We will have to wait and see...