Any news about the Linux version?

[MisterWhen]

I know its only a maybe on launch, would just like to have an idea of when it will be available

[ekianjo]

this port is taking forever...

[cyrollan]

this shouldn't be so difficult. in the source code, CTRL+F to find every instance of "Windows" and replaced with "Linux"

[JoZ3]

Originally posted by cyrollan (McNulty):

this shouldn't be so difficult. in the source code, CTRL+F to find every instance of "Windows" and replaced with "Linux"

work for ms office??

[Houdonni]

Pay for it to come to Linux?

How about the stupid people like me who BACKED THIS KICKSTARTER?!??!

Linux was promised as a funding goal! Did you guys forget this? Because we sure didn't.

[flesk]

Originally posted by billybigrigger:

Pay for it to come to Linux?

How about the stupid people like me who BACKED THIS KICKSTARTER?!??!

Linux was promised as a funding goal! Did you guys forget this? Because we sure didn't.

I backed the Kickstarter too because I was excited about a new Tex Murphy adventure and because I hoped it would come to Linux (I have since learned my lesson, never to pay for anything on a hope). Linux support was never promised as a goal for the campaign though, and it was only announced on their blog later that they would be releasing the game for Linux too.

[mike69de]

The same for me : i backed the project because I was in a bit sentimental mood remembering those old and good Tex-times, knowing that the game probably never would make it to Linux..
So meanwhile I use a swappable drive with win to pop it in when I want to play. Not the preferred solution but that was foreseeable...

[ekianjo]

it's almost as bad as Divinity Original Sin...

[ChronoWolf]

Hi all. Tesla project Dev here. I know it has been a LONG time since any news on the Linux version has surfaced. I do not speak for the rest of Big Finish games, but can offer my own perspective about the Linux port of the game.

As was stated earlier in this thread: the main reason why Linux support is not available (and STILL is not available) is due to the Bink 2 video codec used in the game to decode the Full Motion Video portion. I have it on good authority that the programming and design team worked EXTREMELY hard to try and get RAD Video Tools (the developers of Bink) to work with us on getting Linux support for their codec. But ultimately, the response from them was as follows:

A) They considered Big Finish Games not "big" enough to devote any more time and resources into working out a Linux solution for our game. And...
B) They do not really consider Linux support of their codec a priority, period.

Now, from what I have heard, they have spent a lot of time working directly with Triple A developers to continue to improve and enhance the codec for their needs, and specifically consoles (which is their larger market). This has unfortunately left the indie developers (like Big Finish Games) and those who develop on Unity a bit stranded. This has resulted in many of us heaving to appear to have broken one of our promises, when really, our hand was forced to do so.

Let me be clear: Big Finish Games worked tirelessly to get you the game on Linux, and aside from the video Codec, it is a Linux-Ready game. Big Finish Games was basically turned out to the wolves and was left abandoned by RAD Video tools with no way to getting the videos sequences working on Linux machines.

That said: Unity has made some nice developments in how it handles video. At the time of Tesla's release, OGV was the ONLY option for Unity, which was a vastly inferior codec, and not suited to the game's needs. That has changed. I cannot promise anything, but perhaps the new options available for Full Motion Video in newer versions of Unity may offer an alternative to our reliance on Bink 2 for Tesla's Video.

[DrMcCoy]

Thanks for the update! :)

Originally posted by Cubase:

A) They considered Big Finish Games not "big" enough to devote any more time and resources into working out a Linux solution for our game.

Unfortunate, yes.

Originally posted by Cubase:

B) They do not really consider Linux support of their codec a priority, period.

Correct me if I'm wrong, but:

The decoder itself is already available for GNU/Linux, right? That's what I have been lead to believe from the information on the RADGameTools homepage, and also from what a developer of theirs tweets about. I know for a fact that Bink1 does work flawlessly on Linux, and their homepage doesn't say that Bink2 wouldn't be available there.

I assume it's a standard dynamically linking ELF library, and probably with statically linking objects as well. What is missing is the glue to get that into Unity, right?

So, you have a Unity plugin that provides this glue for Windows, and I assume you also have the sources for that, right?

Now, I have no idea how Unity works, or about the Bink API, but I am a programmer, and I'm a bit confused about where the huge problem is here. Assuming the Bink API is relatively clean and, for the lack of a better word, sane, it should be relatively easy to extend the existing Unity plugin, that currently only works on Windows, to also work with the Bink Linux libraries, no?

Just semi-informed speculation, but I would assume that the Bink API provides method to decode the video, frame by frame, and write the output into either an interleaved RBG(A) or YUV(A) buffer, or several buffers per color channel. You'd then tell Unity to update texture you use to display the video with the buffered content, possibly interleaving the data first and/or converting YUV to RBG (possibly scaling the chroma channels back up).

I don't see where this would differ so much between the Windows and the Linux binaries of the Bink library. Am I missing something?

Originally posted by Cubase:

OGV was the ONLY option for Unity, which was a vastly inferior codec

I assume you mean Theora. Ogg is only the container (and yes, I'm aware it's a quite horrible one in its own right), and ogv is a common extension used for Oggs with video streams.

Yeah, Theora is unfortunately an outdated codec, more comparable to H.263 or its MPEG4 Part 2 extension. Even Bink1, with its brute-force nature of cramming in lots of different block types often looks better than Theora. On that front, I'm hoping Daala will develop into something rivaling the messy MPEG family. Or perhaps Cisco's Thor, or a combination of the two.

Originally posted by Cubase:

I cannot promise anything, but perhaps the new options available for Full Motion Video in newer versions of Unity may offer an alternative to our reliance on Bink 2 for Tesla's Video.

That would be great. :)

Just for curiosity's sake, which codecs are that, specifically?

[ChronoWolf]

Originally posted by DrMcCoy:

The decoder itself is already available for GNU/Linux, right? That's what I have been lead to believe from the information on the RADGameTools homepage, and also from what a developer of theirs tweets about. I know for a fact that Bink1 does work flawlessly on Linux, and their homepage doesn't say that Bink2 wouldn't be available there.

I assume it's a standard dynamically linking ELF library, and probably with statically linking objects as well. What is missing is the glue to get that into Unity, right?

So, you have a Unity plugin that provides this glue for Windows, and I assume you also have the sources for that, right?

Now, I have no idea how Unity works, or about the Bink API, but I am a programmer, and I'm a bit confused about where the huge problem is here. Assuming the Bink API is relatively clean and, for the lack of a better word, sane, it should be relatively easy to extend the existing Unity plugin, that currently only works on Windows, to also work with the Bink Linux libraries, no?

Just semi-informed speculation, but I would assume that the Bink API provides method to decode the video, frame by frame, and write the output into either an interleaved RBG(A) or YUV(A) buffer, or several buffers per color channel. You'd then tell Unity to update texture you use to display the video with the buffered content, possibly interleaving the data first and/or converting YUV to RBG (possibly scaling the chroma channels back up).

I don't see where this would differ so much between the Windows and the Linux binaries of the Bink library. Am I missing something?

I was personally not part of the team that dealt directly with RAD, but what you are explaning does seem like the logital steps that are taken in this process. However, what I *do* know is: the Bink 2 SDK (at the time in which we were integrating it into Unity) was far from perfect, and we worked closely with multiple RAD developers to iron out the kinks and get it working. From what I remember: it took a few weeks to get it working in Unity, even with a supposed "complete" SDK. In fact, it was some of the guys on our end who discovered a few loopholes and tricks to get it to work. None of those strategies would translate over to Linux, however, and regardless of how much we tried, we needed RADs assistance to get it to work... but by this time, they had already considered our business over.

Originally posted by DrMcCoy:

I assume you mean Theora.

Correct. Not only was the video quality / compression a problem, but audio/video sync was terrible! Often falling behind by as much as 2 seconds.

Originally posted by DrMcCoy:

Just for curiosity's sake, which codecs are that, specifically?

From what I understand Unity is getting closer to supporting H264 as an option. Though, I am not 100% about this. I do know they are trying to improve video... even it if means fixing the Theora issues.

[tuubi]

So the Bink 2 changelog[www.radgametools.com] entry for version 2.5g (dated 08-12-2015) saying

* Added Bink for Unity now supports Mac and GNU/Linux (in addition to Windows).

doesn't mean what I think it means?

[daniel.mantione]

I am really surprised reading this, because Bink is a very well known file format and therefore supported by open source libraries. For example the very popular libavcodec library allows playback of Bink (and Smacker as well to complete the RAD codecs familly). For what reason woud you be dependend on the official RAD code?

I am almost saying... let me play with the source code for some days; I'll fix this for you :)

[DrMcCoy]

Originally posted by daniel.mantione:

For example the very popular libavcodec library allows playback of Bink (and Smacker as well to complete the RAD codecs familly).

That's Bink1. Bink2 is, unfortunately, a mostly completely different codec. From what I understand, the person who reverse engineering Bink1 for ffmpeg/libav expressed explicit disinterest in RE'ing Bink2 as well. Which means Bink2 support in ffmpeg/libav is not likely to happen soon.

[corvusdeux]

Hi Cubase,

Sorry but in the official page of RAD Game tools, Linux platforms appear like platform supported, here: http://www.radgametools.com/binksdk.htm

Extract web text:
GNU/Linux for x86 CPUs

Bink 1 and Bink 2! Bink 2 requires x86 (no PPC support).
Available as a static library for GCC.
Supports SDL_mixer for sound output.
Allows you to offload much of the video decoding onto the GPU using GL 4.3 compute shaders - this is two to three times faster than CPU-only decoding (and the higher the resolution, the bigger the win). On AMD, make sure you have Catalyst 14.1 drivers. nVidia is still working on robust compute shader drivers (hopefully soon).
Includes a complete API for blitting using fragment shaders that is cross platform compatible with most of the Bink platforms! Use the GPU for beautiful video!
Supplies super-fast MMX optimized YUV to RGB converters to 16-bit, 32-bit, and 24-bit RGB.
Can access the YUV bits directly in several formats (YUY2, UYUV, YUV12).
The Bink library is about 200 KB and is completely standalone (only pthreads and glibc required).
At playback time, Bink needs two full YUV12 video frames in memory (12-bits per pixel) and a one second data rate buffer.
Can open from a filename string, a file handle, or you can completely overload all of the IO functions. By default, the Bink IO system does all reading on a low-overhead background thread.
Can completely overload the default memory functions, so that all memory management happens through user-supplied callbacks.

And in the last release notes history here: http://www.radgametools.com/bnkhist.htm

Extract web text:
Added Linux 64-bit Bink Player to distribution.
Moved to native Linux 32-bit builds (vs hybrid MSVC build).

Sorry but do not understand the justification based on the NO support from RAD. The essential piece of your game. When the reality is different, if not, there are evidence.

Thanks for answering.

Greetings,

David Gámiz Jiménez

[ChronoWolf]

As I said before, it wasn't really my department. I am just here giving and update to the best of my knowledge so that people are not left out in the dark. I actually should have been more specific rather than saying "No Linux support", where I meant no Linux support on Bink2 with Unity. Even now, there are some custom band-aids that the programmers applied to the PC and Mac versions of Bink 2 in unity to ensure it works, which do not apply to the linux version. But, as far as I am aware there is little to no interest from other developers (other than us) looking for FMV + Unity + Linux, making our case quite insignificant in the grand scheme of things (at least in the eyes of RAD). This may also indicate a gap in the skillset of the TE programmers, which I am sure is something the Linux experts here could probably help with, but that's not my call unfortunately :(