Unigine Announces Its OilRush Game For Linux

[binstream]

will there be a x86_64 build and does the game support multi threading?
Do you support vendor specific special functions like nvidia 3d vision?

Yes, there will be both 32/64 builds available.
The game efficiently utilizes multiple CPU cores.
Yes, Unigine engine do support 3D Vision. I don't know what other vendor-specific features are interesting for you.

[Desti]

Hardware requirements of the game are really moderate: OilRush runs smoothly on NVIDIA 8600 / ATI 2600.

Ask your questions, if any.

Hi,

will there be a x86_64 build and does the game support multi threading?
Do you support vendor specific special functions like nvidia 3d vision?

[nanonyme]

HOWEVER... applications are free to bundle key libs with their application. AS long as the ogl interface doesn't change OR libc doesn't then its just a case of finding the correct libs.
Thankfully *NIX has a SANE method of library management and as such multiple version of the same lib can live side by side ALSO thanks to the LD_LIBRARY_PATH variable applications can have local version of libs in their install directory

Yes, that's technically possible, I know. It just seems to be pretty much against the ideology on GNU/Linux platforms and would likely lead into quite a bit of yelling if someone actually tried shipping per-application libraries. As I said, in OSX that's an every-day thing, Linux people aren't used to that. (and there's a good reason for why it's not done: it wastes hard disk space)

[nanonyme]

Thats why were in need of a distribution system like steam. Packaging worries are less, more patches(sometimes so much that it annoys the user).

Okay, that's simply you not reading my post at all. Steam doesn't solve these packaging worries, just moves them to Valve/game developer instead of distros. There.

[babai]

Sense: you make none.
You obviously don't understand that there might be other reasons - like, say, maintenance-related - than just ideological behind wanting it to be opensource. There's pretty much three options here.
1) Game companies keeps spending resources on porting the game to future GNU/Linux userspace API's and ABI's
2) Distro maintainers keep spending resources on packaging deprecated versions of system libraries along with the system and desperately hoping that if they fix security holes, it won't break the applications which need them
3) The software - or at least the parts of it which connect with the userland - are opensource and community can push patches to ensure that it works in the future too. You probably have seen this with ATi and nVidia closed source drivers too that users end up pushing patches to make them work with newer kernels than the development companies are capable of. Users tend to want to keep their software working if possible.

Thats why were in need of a distribution system like steam. Packaging worries are less, more patches(sometimes so much that it annoys the user). If there should be one request to Unigine then it should be abandoning DRM.

[Naib]

It really wouldn't be as simple in Linux as it is in Windows. Heck, Steam in OSX would be trivial compared to Steam in Linux too. In Linux you run into that icky icky userspace with all of its dependency problems and your program might just be compiled against the "wrong" versions. If we went the OSX way, it might just about work: as in all installed programs would be shipped with the libraries they need.

Doesn't have to be. YES application versions can screw with apps and to keep everything running happily apps need to be re-compiled or slightly tweaked when such libs change.

HOWEVER... applications are free to bundle key libs with their application. AS long as the ogl interface doesn't change OR libc doesn't then its just a case of finding the correct libs.
Thankfully *NIX has a SANE method of library management and as such multiple version of the same lib can live side by side ALSO thanks to the LD_LIBRARY_PATH variable applications can have local version of libs in their install directory

UT2k4 ships with a libSDL and an openal in its System folder
etqw ships with a libgcc, libjpeg, libSDL, libstdc++, libCgx86
HoN ships with a libcurl,libfreetype, libpng14, libspeex, libfmodex, libgcc, libspeexdsp, libstdc++

ALL to maximise compatibility (via controlling a certain version and build of some libs the app needs) across many distro AND as the distributions adapt.

UT2004 was released in... 2004 and still runs great on my Gentoo system. There are applications that were released around 2004 that will not run in Vista or Win7 and yet it is linux and its dynamic system that gets slated... seems to be more compatible and stable then windows could EVER hope to be

To make out that in Linux having an application wouldn't be simple isn't taking into account everything that linux provides for flexibility.

[nanonyme]

This works really well in Windows land. Show me an example as successful as Steam in Linux and you have me convinced.

It really wouldn't be as simple in Linux as it is in Windows. Heck, Steam in OSX would be trivial compared to Steam in Linux too. In Linux you run into that icky icky userspace with all of its dependency problems and your program might just be compiled against the "wrong" versions. If we went the OSX way, it might just about work: as in all installed programs would be shipped with the libraries they need.

[kazetsukai]

Yeah that'll really drive Linux forward, releasing it in some convoluted confusing way that require Linux users to have "someone else" install it for them. No, fail, wrong.

This works really well in Windows land. Show me an example as successful as Steam in Linux and you have me convinced.

There needs to be one cross-distro installer released for Linux that installs menu entries on any distro and be completely distro-agnostic working with Linux standards and be easy to run, i.e. from the GUI with a few clicks, so that any user on any Linux distro will have no problem.

Your "ideal" has been tried many times before - and failed. You're basically the guy with the "cool game idea", and nothing to show for it. Why don't you take a look at package management design and start solving the problems with RPM, DEB, and the like.

That would actually be productive, versus your "no lets just slap down what I don't like, regardless of the fact that it has proven itself to work" strategy.

[nanonyme]

For all those shouting to make this open source or they wont use it or all that BS pls convert ur closed source mobo bios, gpu bios, and cpu microcode to opensource and then come back.

Sense: you make none.
You obviously don't understand that there might be other reasons - like, say, maintenance-related - than just ideological behind wanting it to be opensource. There's pretty much three options here.
1) Game companies keeps spending resources on porting the game to future GNU/Linux userspace API's and ABI's
2) Distro maintainers keep spending resources on packaging deprecated versions of system libraries along with the system and desperately hoping that if they fix security holes, it won't break the applications which need them
3) The software - or at least the parts of it which connect with the userland - are opensource and community can push patches to ensure that it works in the future too. You probably have seen this with ATi and nVidia closed source drivers too that users end up pushing patches to make them work with newer kernels than the development companies are capable of. Users tend to want to keep their software working if possible.

[not.sure]

What I'd love to see with this engine would be a FarCry-ish game. Old-fashioned, conventional gameplay, but visually stunning.