Ryan's Tools For Linux Game Porting, Development

[gbudny]

@icculus

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

http://www.joystiq.com/2012/01/24/indie-royale-presents-the-serious-sam-lightning-deal/

Did you ported Serious Sam to Mac OS X?

http://offload1.icculus.org:9090/~icculus/ssam/photoshopped.jpg

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

[icculus]

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.

[fettouhi]

I think my interactions with Valve have been overstated.

--ryan.

Is there a video from your talk at Flourish?

[icculus]

But - would you have taken the offer, if you weren't required to move?

I think my interactions with Valve have been overstated.

--ryan.

[icculus]

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.

[icculus]

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.

[entropy]

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!

[curaga]

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?

[e_tank]

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

[e_tank]

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 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 after several years but it's mostly maintenance work, although the new collision system offered by libccd is a step in the right direction. hopefully exploiting temporal coherence (for detection, contact generation, and warm starting the solver) isn't far off.