Announcement

Collapse
No announcement yet.

Ryan's Tools For Linux Game Porting, Development

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Ryan's Tools For Linux Game Porting, Development

    Ryan's Tools For Linux Game Porting, Development

    Phoronix: Ryan's Tools For Linux Game Porting, Development

    Last week at the Chicago Flourish conference, well known Linux game porter/developer Ryan "Icculus" Gordon shared some of his recommended open-source tools and libraries for Linux game development...

    http://www.phoronix.com/vr.php?view=MTA4MjI

  • gbudny
    replied
    @icculus

    I really want to see Croteam HIB for Linux and Mac OS X similar to:

    http://www.joystiq.com/2012/01/24/in...ightning-deal/

    Did you ported Serious Sam to Mac OS X?

    http://offload1.icculus.org:9090/~ic...otoshopped.jpg

    http://icculus.org/~icculus/ssam/

    Leave a comment:


  • icculus
    replied
    Originally posted by fettouhi View Post
    Is there a video from your talk at Flourish?
    They usually publish them within a few days...probably this upcoming week? I assume http://twitter.com/flourishconf will let everyone know.

    --ryan.

    Leave a comment:


  • fettouhi
    replied
    Originally posted by icculus View Post
    I think my interactions with Valve have been overstated.

    --ryan.
    Is there a video from your talk at Flourish?

    Leave a comment:


  • icculus
    replied
    Originally posted by entropy View Post
    But - would you have taken the offer, if you weren't required to move?
    I think my interactions with Valve have been overstated.

    --ryan.

    Leave a comment:


  • icculus
    replied
    Originally posted by curaga View Post
    Thanks for the links. Though, looks many of them are simply public domain replacements for better known libraries (zlib, libpng, freetype). Are there really places where you can't reasonably use zlib-licensed code?
    Where I recommended replacements (stb_*, miniz), it wasn't a licensing issue. The usual libraries have perfectly fine licenses.

    zlib is fine, but has all this bulk and complexity to support ridiculous systems...as illustration, miniz provides a drop-in replacement in 300 lines of C code.
    libpng fails (and fails in hard-to-understand ways) if you used different build options between what you built and what's on the end-user's system, which means you have to ship your own libpng on Linux.
    libjpg and libpng force you to use setjmp(), which is unforgivable.

    All of these have dozens of C files and possibly complex build details. The alternatives tend to be a single .c file you drop into your project.

    --ryan.

    Leave a comment:


  • icculus
    replied
    Originally posted by e_tank View Post
    i agree, why not bullet?
    I'm sure it's fine, but the slide was accompanied by a statement of "I don't know much about these, but they exist if you want to do more research." I just haven't had much opportunity to work with open source physics libraries.

    --ryan.

    Leave a comment:


  • entropy
    replied
    Ryan, please allow me an offtopic question.
    I'm aware you can't talk about the VALVE offer details.
    But - would you have taken the offer, if you weren't required to move?

    Btw, thanks for all your amazing Linux related work!

    Leave a comment:


  • curaga
    replied
    Thanks for the links. Though, looks many of them are simply public domain replacements for better known libraries (zlib, libpng, freetype). Are there really places where you can't reasonably use zlib-licensed code?

    Leave a comment:


  • e_tank
    replied
    Originally posted by Vax456 View Post
    Also, out of curiosity, why is Open Dynamics Engine on the list, but not Bullet?
    i agree, why not bullet? don't get me wrong, ode is great and has some advantages over bullet, chief among them would probably be its ease of both use and integration into a project, but bullet is a far more advanced physics engine these days. bullet is actively maintained and developed, and it's gjk and epa implementations are robust and mature. ode recently saw a new release (its first new release in years) but it's mostly just maintenance work, although the new collision system offered by libccd is a step in the right direction. hopefully development will continue to advance for ode and exploiting temporal coherence (for detection, contact generation, and warm starting the solver), which imo is a big missing feature from ode, won't be too far off now. (CCD is probably the biggest missing feature, but baby steps..)

    Leave a comment:

Working...
X