Frayed Knights for Linux - a maybe

[Licaon]

I've tried the pilot episode of Frayed Knights (http://www.rampantgames.com/frayedknights/) "An Indie Computer RPG of Comedy and High Fantasy. Now in development." a few days ago. When i exited the game a was greeted by a web page asking me feedback about how the game went. I answered those questions and in the comment box i also asked about a possible Linux/Mac port.

Today i just stumbled upon the Frayed Knights - Feedback Frenzy (http://www.rampantgames.com/blog/2008/05/frayed-knights-feedback-frenzy.html) blog post and i decided to ask about the Linux/Mac port and the answer was: Mac support has been planned from the get-go for the full version, but not the pilot. Linux support is supposedly only a small jump from there, or so I've been told. We shall see. If so, I can't see why we wouldn't support it.

One of the main reasons I chose Torque (http://www.garagegames.com/products/torque/tge/) was its multi-platform support.

BTW gamers, the pilot works in WINE, atleast you can see what is all about :D

[Svartalf]

Today i just stumbled upon the Frayed Knights - Feedback Frenzy (http://www.rampantgames.com/blog/2008/05/frayed-knights-feedback-frenzy.html) blog post and i decided to ask about the Linux/Mac port and the answer was:

BTW gamers, the pilot works in WINE, atleast you can see what is all about :D

Torque's got some...issues...word on the street has it, for Linux support. Several indies are commenting that it doesn't QUITE work as nicely as they claim on that front.

If he can get it there or get someone like Ryan or myself to make it play nicely, that'd be a win overall (Nice games are ALWAYS welcome- and fostering the indie community in making things cross-platform and making sure they don't give away the rights to alternate platforms would be one of the better ways of getting things going in a more positive direction...

[SlackerTD]

Torque Game Engine 1.5.2 runs well enough on Linux (the Penny Arcade game is using TGE). Torque Game Builder is a different beast... better off to forget that exists. Only one game that I know of has been put out with TGB for Linux & that isn't using the latest version of TGB (I can't get any of the newer TGB builds to compile anymore). As for Torque Game Engine Advanced... that never did run in Linux, probably never will since it doesn't have OpenGL in it.

Right now, Linux support is "community driven" in TGE. It's been that way for a long time now. While that sounds nice, in reality, GG has been very slow in getting patches put back into the engine. Many of the people who have helped out in the past got tired of dealing with the delays.

Back on topic of the game itself above... if TGE was used, it won't be too hard to get a Linux version out. :)

[Svartalf]

Torque Game Engine 1.5.2 runs well enough on Linux (the Penny Arcade game is using TGE). Torque Game Builder is a different beast... better off to forget that exists. Only one game that I know of has been put out with TGB for Linux & that isn't using the latest version of TGB (I can't get any of the newer TGB builds to compile anymore). As for Torque Game Engine Advanced... that never did run in Linux, probably never will since it doesn't have OpenGL in it.

Right now, Linux support is "community driven" in TGE. It's been that way for a long time now. While that sounds nice, in reality, GG has been very slow in getting patches put back into the engine. Many of the people who have helped out in the past got tired of dealing with the delays.

Back on topic of the game itself above... if TGE was used, it won't be too hard to get a Linux version out. :)

Fair enough... There were rumblings from people about TGE not being worth the time for stuff on Pandora with that being the reason given. It's good to know that someone could probably sweet-talk Greenhouse and Hothead into a Pandora version if things start looking good over there on the handheld. :D

[Kano]

I think multi-plattform support is definitely the future. Maybe Linux is no real mass market but gaming consoles are - now even capable to buy games via download. Best for all would be: game engines based on OpenGL and only small parts of OS specific changes. You can see that this is possible when you look at the Quake/Doom engines or OpenSceneGraph - latest example game: Zero Ballistics. As many games are done with existing 3d engines hopefully those get multi-plattform support soon and would be very easy to support em all.

[SlackerTD]

Unless GG starts changing what they are doing with regards to Linux, I would only think the Linux support of TGE will degrade over time. I'd still like to see it go back to the way it used to be... them doing the work on it or having someone PAID to do it... not a community effort. With all they've posted over time & how hostile they are to that, it isn't likely to happen.

[Svartalf]

Unless GG starts changing what they are doing with regards to Linux, I would only think the Linux support of TGE will degrade over time. I'd still like to see it go back to the way it used to be... them doing the work on it or having someone PAID to do it... not a community effort. With all they've posted over time & how hostile they are to that, it isn't likely to happen.

Heh... That was the takeaway I got over on the Pandora console dev forums. TGE was "okay" but you're probably better off doing IrrLicht (and it's game engine kin...), OGRE, or somesuch like it for a title if you didn't already have the title in hand and was making it happen on Linux for x86 and ARM for the desktop and Pandora spaces.

Perhaps they'll change their tune with all the changes going down right at the moment- if they want anything in the PS3 space, they're going to have to do most of the work anyhow. Ditto MacOS.

[Svartalf]

As many games are done with existing 3d engines hopefully those get multi-plattform support soon and would be very easy to support em all.

Only if you get to support Vista OpenGL... >:-D ;)

I certainly don't wanna do THAT nasty task ever again if I can help it... :D

[SlackerTD]

Ditto MacOS.They actually have someone who does work on the Mac side of things. Even with that, they still don't have OpenGL in the newer TGEA. They say they might have something for Torque 2... time will tell. Even then, we still might get squat for Linux. Ever since this posting (http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9244) on Linux support, things have gone downhill.

[deanjo]

From the above link.


Third. Linux does not love back. Too many distros. Much incompatibility. Moving target. Not much community support from Linux users coming back to Torque. Little to no revenue (less than 3% of what we do). Little to no love from the Linux community for our efforts.
In a nutshell, why game publishers ignore linux. OS X at least is a fairly static target. Getting a server ported over to linux is fairly simple. Required packages are relatively stable target. On the client end though, every week it seems there is a "new improved" api / toolkit / etc that claims it's going to be the new standard.

Just looking at the Pulseaudio diagram for example can be a dizzying experience. Flexible, sure, but how the heck is the developer supposed to figure out what libraries are compiled with what support and make their decision on that so it works on nearly every system?

http://upload.wikimedia.org/wikipedia/commons/1/14/Pulseaudio-diagram.png

[Licaon]

who said that they should support bleeding edge?

stick with something stable in the long term, Debian, or Ubuntu LTS or Slackware whatever, i don't care...

and distro packagers will start caring too, will slow down this stupid 6 months cycle that looks like it's not helping anyone and anything... when 2000 ubunteros come flocking to their forum 'cause the game doesn't work in Ubuntu but it does in Debian, things will change, one way or another, either Ubuntu fixes the distro, either they provide patches or support for game developers, or either 2000 ubunteros get back to basics in Debian

[ivanovic]

Sorry, but I don't understand the connection between the release frequency of a distribution and incompatibility of games. One example is the (by now) ancient UT2004 which still works perfectly on my bleeding edge Gentoo Unstable. As long as the binary is well done, there is *no* problem whatsoever with many updates to a distribution. In general noone force a publisher to use "open" libraries, so that they can write the stuff themselves (or buy it from somewhere) and just statically link.

Sure, a publisher can only support some fixed basis, but in general there should be no problem with most distris. It is just the glibc that matters, the rest of the libs used tend to be statically linked, so there can not be a real problem in this area. I think the excuse "we can't support Linux because there is too much variety" is just plan bullsh** and nothing else. If a company is willing to, it is possible to support it in a way that the binaries will even still work as expected in 4 years.

[Licaon]

On the client end though, every week it seems there is a "new improved" api / toolkit / etc that claims it's going to be the new standard.

i was talking about this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Kano]

I think some publishers don't know when they compile their games maybe on Debian etch it will run in most cases on everything newer, but now the other way around. Also you don't need to compile everything statically, as you can use a wrapper script that sets LD_LIBRARY_PATH to use the libs provided with the game.

[Svartalf]

In a nutshell, why game publishers ignore linux. OS X at least is a fairly static target. Getting a server ported over to linux is fairly simple. Required packages are relatively stable target. On the client end though, every week it seems there is a "new improved" api / toolkit / etc that claims it's going to be the new standard.


Considering that you can target OSS and get most of the sound APIs, OpenGL 1.5/2.0 (Depending on your title's requirements...) for graphics, and then use either Debian Etch or the apgcc/apg++ wrappers from Autobuild to make stable apps...

I'll state this again and again. This has less to do with the "problems" people keep "bringing up" with Linux and "games", and more to do with percieved LACK OF SALES POTENTIAL with our community.

[deanjo]

Considering that you can target OSS and get most of the sound APIs,.


ARRRGH!!!!
/bang head against brickwall
OSS Emulation has too many issues with hanging devices resulting in the sound device blocked after first call. This has been a long outstanding bug and one only has to google "/dev/dsp1: Device or resource busy" too see the long list of hits and what a truely huge PITA it is. (Just ask any teamspeak user....)

This is one example where a depreciated interface should be left dead. ALSA has replaced it since 2003 in the kernel. The number of systems still running native OSS is dwarfed by systems running ALSA. Even when OSS was the "defecto standard" in the 2.4 kernel, most major distro's opted to use ALSA with the one long outstanding exception being at the time Redhat.

[Svartalf]

ARRRGH!!!!
/bang head against brickwall


Try a little harder- you've not put a hole in it yet... ;)

The reality is, unless ALSA is available elsewhere...and on all sound cards (heh...there you go...not all sound is supported right under all cases with ALSA...) you're going to have to rely on OSS emulation on ALSA and PulseAudio- or get the whole bloody mess of sound card support worked out so there CAN BE ONE API like you want.

Unless you can get EVERYONE largely on the same page, you're not going to get what you want there. ALSA is not it. Hasn't been ever since it started. It's difficult as hell to code to- while it's much, much more capable than OSS ever was, it brought too much complexity to work with along with that. No, I'm not a big fan of OSS, mind, but it DOES work across a BUNCH of system configs largely correctly and it's what many of the players still use if they're not using OpenAL to manage the sound access for them. Oh, and OpenAL's busted for the SI on Linux and not everybody uses OpenAL-Soft...

Help get the distributions to get their damn act together and it'll happen the way you want. Until then, you're stuck with that deprecated interface.

[deanjo]

Try a little harder- you've not put a hole in it yet... ;)

The reality is, unless ALSA is available elsewhere...and on all sound cards (heh...there you go...not all sound is supported right under all cases with ALSA...) you're going to have to rely on OSS emulation on ALSA and PulseAudio- or get the whole bloody mess of sound card support worked out so there CAN BE ONE API like you want.

Unless you can get EVERYONE largely on the same page, you're not going to get what you want there. ALSA is not it. Hasn't been ever since it started. It's difficult as hell to code to- while it's much, much more capable than OSS ever was, it brought too much complexity to work with along with that. No, I'm not a big fan of OSS, mind, but it DOES work across a BUNCH of system configs largely correctly and it's what many of the players still use if they're not using OpenAL to manage the sound access for them. Oh, and OpenAL's busted for the SI on Linux and not everybody uses OpenAL-Soft...

Help get the distributions to get their damn act together and it'll happen the way you want. Until then, you're stuck with that deprecated interface.


I totally agree that ALSA can be a pain to code for but when done right it works and is stable. ALSA really has to cleanup and add some GOOD documentation. OpenAL needs some loving attention too. Developers have to start embracing it as will eventually ease the pain of porting. Right now IMHO there are too many projects out there that do too many overlapping jobs, many of which are depreciated or are developed at a snails pace. It's time some of these projects are axxed all together and those resources pooled together into a larger, more complete solution. Compiz / Beryl saw the light and came to their senses, if only more projects would follow their lead.

This is where LSB should be pushed and embraced and refined. ALSA is currently being evaluated for inclusion in the next version of LSB.
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-TrialUse/LSB-TrialUse/book1.html

[Thetargos]

I think some publishers don't know when they compile their games maybe on Debian etch it will run in most cases on everything newer, but now the other way around. Also you don't need to compile everything statically, as you can use a wrapper script that sets LD_LIBRARY_PATH to use the libs provided with the game.
Which is what most commercial Linux games do, anyway, just see NWN's 'nwn' launcher script, or UT2K*, or UT99, etc.

[Thetargos]

Try a little harder- you've not put a hole in it yet... ;)

The reality is, unless ALSA is available elsewhere...and on all sound cards (heh...there you go...not all sound is supported right under all cases with ALSA...) you're going to have to rely on OSS emulation on ALSA and PulseAudio- or get the whole bloody mess of sound card support worked out so there CAN BE ONE API like you want.

Unless you can get EVERYONE largely on the same page, you're not going to get what you want there. ALSA is not it. Hasn't been ever since it started. It's difficult as hell to code to- while it's much, much more capable than OSS ever was, it brought too much complexity to work with along with that. No, I'm not a big fan of OSS, mind, but it DOES work across a BUNCH of system configs largely correctly and it's what many of the players still use if they're not using OpenAL to manage the sound access for them. Oh, and OpenAL's busted for the SI on Linux and not everybody uses OpenAL-Soft...

Help get the distributions to get their damn act together and it'll happen the way you want. Until then, you're stuck with that deprecated interface.
Sound on Linux is still its Achilles ankle in regards to Multimedia and gaming. If, and only if Pulse Audio picks up and really becomes the kind of framework that GTK or QT are for X11 on Linux (doing the low level windowing, etc; even wrapping OpenGL in X11, for instance, with GLX and such, but for OpenAL in this case), things could start happening. A HAL and common framework like PA could become, would mean that ALSA would only have to worry about the drivers and some libraries, in the way Xorg works and if no driver is found, PA would use a null device (to keep things from stop working). I know ALSA is much more capable than OSS, I also know it is much more Complex, and thus "harder" to code for, but so is "bare" X11. That's why I tend of think of things in the X11-WM/DE paradigm applied to sound infrastructure and architecture.

Will ALSA/PA become what they seem could be the logical evolution? One can only guess, sit tight and wait.

[deanjo]

Which is what most commercial Linux games do, anyway, just see NWN's 'nwn' launcher script, or UT2K*, or UT99, etc.

Which is also why people now have to go start hacking the startup scripts to get the games to run on newer distro's. NWN for example is broke on most modern distro's to prevent it using the SDL libraries that shipped with the game. Let it use the systems libraries and all is OK again.

[SlackerTD]

Which is also why people now have to go start hacking the startup scripts to get the games to run on newer distro's. NWN for example is broke on most modern distro's to prevent it using the SDL libraries that shipped with the game. Let it use the systems libraries and all is OK again.Not necessarily true. I had a case recently where the version of SDL shipping with Dark Horizons:Lore Invasion wouldn't run for some distros, the system provided one wouldn't run either. The solution was for me to package the SDL that I was using in Kubuntu 7.10 & for people of 4 distros I know of to use the shell script to correct the issue.

[deanjo]

Not necessarily true. I had a case recently where the version of SDL shipping with Dark Horizons:Lore Invasion wouldn't run for some distros, the system provided one wouldn't run either. The solution was for me to package the SDL that I was using in Kubuntu 7.10 & for people of 4 distros I know of to use the shell script to correct the issue.

I didn't say it was the only solution, I was just using what had to be done for NWN to work on newer distros as an example.

[duby229]

This is where LSB should be pushed and embraced and refined. ALSA is currently being evaluated for inclusion in the next version of LSB.
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-TrialUse/LSB-TrialUse/book1.html

I dont agree with LSB at all... Not even a little bit..

The problem with LSB is that it literally prevents innovation in every possible way. One way of going things may not be the best way. So if I develop a different way of doing that same thing, it may not be compatible, but eventually it may well replace the old way... This is what is commonly known as progress. Better methods replacing deprecated methods. LSB completely eliminates that possibility... Innovation dies with LSB...

Just look at the package manager that LSB requires and then you'll knwo exactly what I'm talking about.

[deanjo]

I dont agree with LSB at all... Not even a little bit..

The problem with LSB is that it literally prevents innovation in every possible way. One way of going things may not be the best way. So if I develop a different way of doing that same thing, it may not be compatible, but eventually it may well replace the old way... This is what is commonly known as progress. Better methods replacing deprecated methods. LSB completely eliminates that possibility... Innovation dies with LSB...

Just look at the package manager that LSB requires and then you'll knwo exactly what I'm talking about.

The LSB does not limit innovation at all, but ensures that a common solution is available. I assume your griping about RPM being package standard. LSB can still be adhered too with debs when alien is used.

Again, if there is a better solution to an issue the lsb can be changed and amended, thus why I said it has to be refined. LSB should be viewed as a common set of required tools to maintain cross compatibility.

[duby229]

But then you have the problem that if LSB can be changed at will (which it cant be), then what is the point? In that case it has no value at all becouse it serves no purpose.

Additionally your assuming that all folks will be using RPM, or Apt. The fact is that is not at all the case. Your also assuming that all people will be running xorg. Your assuming that all people will be running alsa. Your assuming that all people will be running apache. Your assuming that all people will be running udev. Ands many,many,many,many more assumptions that all prove to be simply false.

I'm sorry but it just doesn't work that way. If you change one of these LSB required components then you will break compatibility. But if I'm running a server I dont need xorg installed. I may choose to use a modern version of OSS instead of the deprecated version that is in the kernel. I may well opt to use a framebuffer device for the display if I am using my system as a PVR. And there are many,many,many,many more examples then just these where LSB simply does not work.

I'd even go so far as to say that LSB will only work for less the 0.000001% of the entire linux community, and even in that extremely rare case it will be entirely deprecated and unsupported in less then three days of use.

The fact of the matter is that LSB does --not-- ensure compatibility. It actually breaks compatibility in the simple fact that LSB makes it entirely impossible for most folks to do what they want to do. Not to mention that it makes replacing deprecated components impossible.

The moment you replace RPM you've broken compatibility. The moment you've replaced glibc, or udev, or hal, or binutils, or xorg, or alsa you have broken compatibility. In order to maintain compatibility you will permanently be stuck with the packages and versions of those packages that you've chosen. This is exactly what LSB does, and it is exactly what is wrong with it...

[Svartalf]

I didn't say it was the only solution, I was just using what had to be done for NWN to work on newer distros as an example.

For example, other vendors provide dynamic link versions of their titles for dealing with the odd problem or an ABI breakage- but provide statically linked binaries (yes, it's big, but then the result ends up being consistent across a HUGE range of distributions and versions of the same...) and only get broken when something dramatic happens in the glibc ABI or the Linux kernel hooks. Loki's stuff ran until the ABI got changed sufficiently enough to break them all to hell.

[Svartalf]

The LSB does not limit innovation at all, but ensures that a common solution is available. I assume your griping about RPM being package standard. LSB can still be adhered too with debs when alien is used.

Again, if there is a better solution to an issue the lsb can be changed and amended, thus why I said it has to be refined. LSB should be viewed as a common set of required tools to maintain cross compatibility.

But Alien's a band-aid on the problem. You see, the standardization was a good idea- LSB is just poor execution that only the RPM based distributions can actually follow. In fact, I think SuSE and Red Hat are the only ones that slavishly follow the thing, being that they're the main ones for coming up with it. Debian can't really follow it that closely because it's really, really Red Hat centric if you read it closely. Worse, RPM, internally does all kinds of goofy-loopy things. Which version do you want to support and realize that the packaging tools vary on macros, etc. so you're not going to get consistent results there either.

LSB's a poor execution to a nice idea. Don't know if you CAN get that execution any better though without ditching the notion of packaging being controlled by the spec. You should specify ABI's and API's provided and a certain specific range for this version of the base standard. Until you get to that stage, it's just not going to work. Most of the problems with binaries, etc. is because we can't keep consistent across distros with ABIs (we didn't have a consistent C++ ABI until recently, for example...) and the lot. Not about where binaries should be put, not about directory structures, and not about what packaging manager you're using. LSB specifies all of it. You might as well be using Red Hat at that point.