I just hope for visible coats and cloaks.

View this comment - View article - View full comments

You asked why not every developer switches. Some of them are paid to create games on Win10 + Xbone, eg. because Microsoft pays them for exclusives to make their platform more attractive.

Some of them are paid to create PS exclusives.

Some of them are concerned about interoperability and thus need a macOS API…

Some of them just do not need all the control Vulkan gives them.

The real question is ‘why won’t all those platform providers just adopt Vulkan as their API and get rid of those Metals, D3Ds, and NDA-guarded secret APIs?’, and unfortunately the answer is ‘because they are used to the practice of having everything possible as proprietary as possible’. And it will take a lot of time before it changes (hopefully the existence of Vulkan, some actual openess from Microsoft – they at least opened they shader language and work for SPIR-V compiler for it, Linux-based Ataribox, Vulkan adoption in Nintendo Switch etc. will force them to change their attitude eventually).

View this comment - View article - View full comments

Quoting: GuestIt has 1) the best performance and 2) the best compatibility. So why isn't every developer making a switch to Vulkan?

1. Not every platform supports Vulkan (even though Linux and Windows do) – if a studio makes a game for XOne and Win10, DX12 is the reasonable choice because of MS policy (of cource, releasing a game only for XO and W10 does not need to be a reasonable choice).
2. Not every platform supports Vulkan #2 – if someone targets all major general PC operating systems – Windows, macOS and Linux – they need to use OpenGL or write renderer backend in two APIs (Vulkan and Metal) – hopefully that will change thanks to the Vulkan Portability Initiative.
3. Vulkan is low level and not for everyone. If someone creates an engine for games with simple graphics and has limited resources, OpenGL is a better choice for that person – it’s supported on Windowses, Linux, macOS (although only up to OGL 4.1), even on some BSDs with some hardware (and if they intend to release only for Windows, unfortunately D3D11 is a better choice, as Windows OpenGL drivers happen to be less optimized, worse, not standard-compliant…).
4. If someone writes games for Sony or Nintendo consoles, they are forced to use yet another API, and they need to sign an NDA disallowing them to publish any information about the API itself, because console manufacturers are bullies who live in their closed walled garden and they strongly “protect” their “intellectual property” – although, since as the rumour says those APIs are rather low-level, Vulkan might be a good choice when porting their games to PCs, Android devices, more open consoles, etc.

So, as I share the sentiment that most games needing high-performance low-overhead graphics engine should use Vulkan with SDL2 (and, if needed for macOS or Xbone, port it later to Metal/D3D12), there are some valid cases when using OpenGL is a better choice, and, well, there are many developers who (at least currently) do not give a shit about Linux (or even about PCs), and, sadly, for them Vulkan is not a win.

View this comment - View article - View full comments

Well, it should be possible to implement D3D11 using Vulkan with good performance, as Vulkan is much lower-level. So hypothetically a good implementation should not give too much performance penalty, and a port to Vulkan with comparable performance should be possible.

But Feral is only one company, porting (probably in a hurry) the whole games, and not just 3D APIs – so I don’t think they have enough resources to keep up in their D3D11-subset implementation on Vulkan with the level of optimizations GPU driver maintainers make in the Windows drivers.

And Vulkan is still one layer above the hardware, so the drivers authors, working directly on HW, have a bit more freedom to optimize. And there’s also the fact that Vulkan is still somewhat young API and its own implementations in drivers is not as optimized as they could be, giving still a bit more penalty.

So I believe they did a very good job overall. :)

View this comment - View article - View full comments

Quotein addition to taking a look at working with Vulcan in the future.

It’d be nice if they considered doing something with current modern APIs, like Vulkan for example, instead of waiting for help from fictional alien species in the future. ;-)

View this comment - View article - View full comments

Quoting: TcheyWell, it seems to me they never intended to port to Linux, only said it in marketing because why not, but now they see there may be interest so they ask around to see if it's worthy or not. 

To me it looks more like they might actually have an honest intention of doing Linux version, but somebody higher (investor?) makes problems with that and stops them from doing it, so they need arguments that it is feasible to be able to take that direction. But, anyway, without further information we can only speculate, and they do not seem to be too open in their communication…

View this comment - View article - View full comments

Quoting: liamdaweHaving it fully advertised, with thousands of people buying it can overwhelm a developer with feedback, especially with a small team.

And, to add to that, especially when the developers themselves are aware that their game has annoying problems (and from the article I gather it had before this update) – that’s cool they want first to do their own QA and eliminate the bugs they are aware of before advertising to the wider public.

View this comment - View article - View full comments

Quoting: truckerpunkLooks like a digital adaptation of the board game "Scythe" - and that's not a bad thing, if you ask me :D

See what I mean? (Link to an article about Scythe) :
https://arstechnica.com/gaming/2016/07/scythe-the-most-hyped-board-game-of-2016-delivers/

Both games are based on the same art collection by the same guy. Google for "1920+" by Różalski. ;-)

View this comment - View article - View full comments

Quoting: GuestThis is not a language problem, it is a GCC problem. Microsoft's compilers manage it, and Apple's builds of clang manage it.

Right, I should have written that C++ has no standard ABI, and while a lot of compilers (msvc and clang among them) keep their stable, others (like gcc) use the freedom to change it between versions for optimizations.

Maybe gaming distros should switch to stable-ABI compilers for C++? But they’d need to roll their own repositories then for everything instead of building on top of Debian.

And there are other compiled languages with no guarantees about ABI – there are games written in Rust appearing.

The easiest solution to the changing ABIs problem would be using dynamic libraries providing semantically versioned C API (eg. through open-source wrappers, or wrapping them in-house) and all others link statically to your binary (the problem then arises what to do, when the license does not allow you to link statically…).

Quoting: GuestFurthermore it would help if the ELF format had a versioning system which helped. Mach-O format on OS X has a pair of version numbers expressly to deal with this, and it works pretty well. It'd be pretty simple to add it to ELF, but I suspect requests to do so would fall on deaf ears.

That does not sound bad – having binary say explicitly which version of the library it needs, and which version of the ABI it’s compatible with would make at least debugging more easily. But, you are right – it helps only the software that’s not provided in the official repositories, so the wider community might be reluctant to consider such a thing.

View this comment - View article - View full comments

Quoting: F.UltraIf only writers of shared libraries would think more about backwards compatibility...

It would suffice if they followed semantic versioning with regard to their libraries’ APIs – one would know which shared versions are compatible. Some libs would have a few hundred new major versions every year – but at least it’d be obvious that every game needs its own separate copy of it in its own version.

At least until we dive into compiled C++ libraries where the version of the compiler that compiled the library and a game binary matters, as C++ has no stable ABI (so library compiled with newer gcc might, and probably will, stop working with old executable).

View this comment - View article - View full comments