Epic Games has acquired RAD Game Tools so they now own Bink video and more

QuoteThe good news is that Epic will not be locking it down to their systems

for now.*

I don't think Bink has bright future. Open codecs will eventually replace it, especially with increased effort to support AV1 by all hardware makers.


Last edited by Shmerl on 8 January 2021 at 9:56 am UTC

Quoting: Breizh

QuoteThe good news is that Epic will not be locking it down to their systems

for now.*

Why would they? If EAC and other acquisitions are to go by, they have no interest in locking SDK's and services pertinent to other game engines to their platform because if anything, it helps them. They indirectly benefit from contracts made by RAD and others.

Quoting: Breizh

QuoteThe good news is that Epic will not be locking it down to their systems

for now.*

Yes clearly. Just see what they did with Rocket League : first they dropped Linux support, and then removed the game from Steam...

What I wanted to ask for decades now: Why are game makers using Bink video that much, instead of say MPEG-2 (or whatever was/is available at the respective time)?


Last edited by Eike on 8 January 2021 at 5:40 pm UTC

Quoting: Breizh

QuoteThe good news is that Epic will not be locking it down to their systems

for now.*

I'll give it 6 months. That's how long it took Epic to murder Rocket League IIRC.


Last edited by ElectricPrism on 8 January 2021 at 11:04 am UTC

Quoting: EikeWhy are game makers using Bink video that much, instead of say MPEG-23 (or whatever was/is available at the respective time)?

There's two things that make Bink a prime candidate for video games:

1) The API reportedly very easy and comfortable to use for games. It is, after all, specifically written for games. That alone is already a very good selling point. If you can just drop the library in and hook it up to your rendering code without having to rewrite your own engine, that kind of friction-less support is worth a lot

2) Bink (*) has several optimizations and block types to specifically support videos found in video games. Namely, hard edges you'll find in animated or 3D-rendered graphics. Other general video formats are tuned for real life video captured by a camera, where hard edges and wide stretches of the exact same color are scarce, but gradients and noise that needs to be filtered are frequent

To elaborate point two a bit, you might be familiar with how screenshots, webcomics, etc. shouldn't be saved as JPEGs. The hard edges, also around text, produce artifacts, weird block-like things. That's because JPEG is meant for photographs, not drawings. The same is true for most general video codecs, including the MPEG families.

Of course, newer codecs are more complex with more features, so this isn't that pronounced anymore, but with Bink, drawn and rendered sequences are a main focus, not a distant consideration.


(*) At least Bink 1, which I have read the RE'd ffmpeg sources for. Bink 2 isn't yet in ffmpeg, but it has been RE'd, however I haven't looked at that yet. Too much to do, too little time. But I do expect this point is also true for Bink 2


EDIT: To make it clear, I don't work for RAD nor is this supposed to be an advertisment for them, and they don't pay me. :P


Last edited by DrMcCoy on 8 January 2021 at 11:21 am UTC

So they are building up a monopoly.

Everyone knows what companies like this do, when they have enough power/marketshare. They lock up things to erase competition.

So I consider this bad new not only for Linux gamers.

But in fact it will harm us the most. Openess and freedom are the first things to go down the drain.

Quoting: Dribbleondo

Quoting: Breizh

QuoteThe good news is that Epic will not be locking it down to their systems

for now.*

Why would they? If EAC and other acquisitions are to go by, they have no interest in locking SDK's and services pertinent to other game engines to their platform because if anything, it helps them. They indirectly benefit from contracts made by RAD and others.

It looks to me like they are building up an ecosystem, to then lock it down:

1. All tools/assets needed to develop games with big market share are being bought. Or at least influenced as much as possible.

2. Include them in an ecosystem (Unreal Engine as base)

3. Lock it down to Epic Games Store or at least make it hard and expensive to publish somewhere else.

Linux gamers will of course only be collateral damage.

Quoting: einherjar

Quoting: Dribbleondo

Quoting: Breizh

QuoteThe good news is that Epic will not be locking it down to their systems

for now.*

Why would they? If EAC and other acquisitions are to go by, they have no interest in locking SDK's and services pertinent to other game engines to their platform because if anything, it helps them. They indirectly benefit from contracts made by RAD and others.

It looks to me like they are building up an ecosystem, to then lock it down:

1. All tools/assets needed to develop games with big market share are being bought. Or at least influenced as much as possible.

2. Include them in an ecosystem (Unreal Engine as base)

3. Lock it down to Epic Games Store or at least make it hard and expensive to publish somewhere else.

Linux gamers will of course only be collateral damage.

How would Linux games be collateral, exactly? EAC was (and still does) work on Linux, and there's nothing to suggest otherwise; meanwhile EGS isn't Linux native anyway, so no collateral there either. If anything, they've given Lutris grants to support EGS via their frontend. And Bink Video is so widespread that it'd be financial suicide to keep it locked onto one ecosystem; something they are actively against doing anyway (see their ongoing lawsuit with apple to free up the apple ecosystem). Even Unreal Engine 4/5 is freely useable between launchers, because if it weren't, developers would riot and it would tank the one bit of reputation they seem to care for; their ability to make a good game engine.

Basically, it's not their style to hoard and lockdown developer tools.


Last edited by Dribbleondo on 8 January 2021 at 11:53 am UTC