I'm developing a simple online space shootout, kind of like Wings but with gravity wells and such.
The graphics engine I'm using is Ogre with Sepples, with some minor parts in Lua.
The question I want to ask is that it's common to ship the Ogre libraries with the game in Windows and Mac distribution, but how okay and doable is it to distribute the game to the Linux platform, with all the ABI differences and such, and even the latest Ubuntu not having the latest Ogre.
Would it be okay to compile the libraries and put them alongside with the binaries somewhere in /opt, and just start the game with LD_LIBRARY_PATH=something?
And even if so what platform should I compile on, not the latest Ubuntu but the version before?
I don't know what I'm writing, offtopic posts welcome too.
Name:
Anonymous2010-01-24 8:27
pew pew lazer
Name:
Anonymous2010-01-24 8:34
using namespace std;
tr1::tuple <string, string> about ("my casual gamedev blog", "my random tweets");
Name:
Anonymous2010-01-24 9:40
Just release the sources.
Name:
Anonymous2010-01-24 10:11
/opt?! That means it's a BINARY distibution!
I don't think you really "distribute" a game like this on Linux. From what I saw you either provide the source with a list of dependencies (or a configure that checks for them), or the user just installs the game through his package management system, which then takes care of dependencies.
Name:
Anonymous2010-01-24 12:05
IF U WERE DROPPED TO /opt TOMORROW, I WOULDNT GO 2 UR DELETION CUZ ID B N UPSTREAM BUGZILLA FLAMIN DA CUNT THAT MADE UR EBUILD! __
.' `.
|a_a |
\<_)__/
/( )\
|\`> < /\
\_|=='|_/
WE TRUE NERDS
WE OPTIMIZE OUR CFLAGS TOGETHER
WE TALKIN ON IRC TOGETHER
send this PENGUIN to every thread you care about including this one if you care. C how many times you get this, if you get 256 your A TRUE NERD
>>7
When scanning over /prog/, I read this as ``Rapid Butt Pee"
Name:
Anonymous2010-01-25 11:23
>>4
I should release the sources for the game and the modified Ogre I use, then expect some packager out there to download Ogre sources alongside mine, patch them with my patch, and make a separate package of Ogre called libogre-special-ultra-edition-for-this-one-game.
See that's why it's nice on Mac that it's standard procedure to distribute the libraries alonside the application.
>>13
Yeah, I know. Shit sucks. I use a Mac myself.
Name:
Anonymous2010-01-25 16:15
>>13 ogre-special-ultra-edition-for-this-one-game.
Have you considered static linking? It's common for binary distributions to use static linking for libraries that may have an incompatible version (if any) installed on the host.
For source distributions, freetards can fend for themselves. Or you can make patching a part of the build process and rename it to whatever you want.
>>1
Yes, just do what you were going to do; drop it into /opt/yourgame with the stock .so alongside it and symlink the launcher to /usr/local/bin. And wrap it up in a .deb for us, will ya?
Name:
Anonymous2010-01-26 4:20
>>16 Can't statically link OGRE, it's open sores.
I don't know about OGRE, but only the GPL places such silly restrictions: public domain(-like's), BSD, MIT, and modified GPL's like LLGPL allow static linking. LGPL allows dynamic linking, but I don't think it allows static.
I just checked OGRE's license, and it's MIT, which is even more free than BSD with restrictions: It lets you do anything you want, except you have to acknowledge that you used their code somewhere by providing a copy of the license (such as documentation or even just place it in the game resources where nobody looks). You don't even have to release modifications if you make them.
tl;dr:IHBT
Name:
Anonymous2010-01-26 6:00
>>13
Oddly enough, I've never had to consciously install a framework. It seems the only library you have to link against is Cocoa and you get pretty much everything.
>>18
You don't install frameworks, silly. You embed them.
Name:
Anonymous2010-01-26 22:31
>>17 I just checked OGRE's license, and it's MIT
Oh, what the holy fuck. They JUST changed that with the release of 1.7.0 three weeks ago. That's awesome!
I wonder why. Were they not making any money off it anymore, so they gave up? Do they think the engine will grow faster if commercial outfits start using it (and occasionally contributing code back) without worrying about licensing? I'm gonna crawl their forums / mailing lists to try to find out.
Name:
Anonymous2010-01-26 23:11
I don't like static linking, causes too much bloat. Perhaps I have no idea what I'm talking about, in that case don't listen to me.
I don't like static linking because it just gets dropped to /opt, cause its a BINARY package.
Name:
Anonymous2010-01-27 0:13
Seems they never really had commercialization in mind. Their commercial license was kindof just a 'penalty' people would pay in order to not release their changes (and minor protection against the Cedega effect). So they don't care much about losing that revenue; they just want more people to use it.
As the author of >>16 then, I'll go ahead and agree with >>15 and suggest static linking. Still do the rest though; drop it in opt/, and give us a deb.
Also, since you're static linking, try building it with -flto (and -fwhopr if necessary) and tell me if you notice a performance difference (and if you're feeling brave, try building the latest gcc with graphite loop support and turn on all the ipa shit.) I am curious to know what lto will do for your build. Then do a pgo+lto build, and again tell us what happens.
>>21
You know I brought up static linking because it was implied that the modified library would be used for only one application. In that scenario it's simply not bloat.
This is one area where Windows is certainly more convenient. One architecture (two now, 64 and 32-bit, but 64 is backwards-compatible), one executable (and dynamic library) format. It's gotten worse now though, with shit like .NET and SxS, but if you only link against MSVCRT and the other standard libs, it's almost guaranteed that it'll work on every single Windows PC out there.
Thus, not surprising that the majority of *nix software is distributed as source.