Croteam say Vulkan 'is the way forward', Serious Sam HD: The First Encounter due in 'weeks' with Vulkan

Quoting: ShmerlNice, but when are they going to release their games on GOG? They aren't some legacy publisher, so what's stopping them?

This.

And, are we going to get these improvements to TFE and TSE at GOG?

Quoting: ShmerlNice, but when are they going to release their games on GOG? They aren't some legacy publisher, so what's stopping them?

A lot of the time it's a case of finances, time and GOG apparently not having very good tools for uploads, versioning and so on.

Note: I'm generalising here, not specific to Croteam.

Finances: They split their possible purchases across more stores, if they don't hit the payout threshold on GOG they won't get paid, but if they stick to one store they are more likely to get their money.

Time: They have to do support across another place, think what you want, but that alone will suck up a fair amount of time.

GOG tools: I've heard from a number of people that GOG's upload tools aren't great and they don't allow different versions like Steam do. There is a reason so many actively choose to use Steam for their builds as it's easy to manage lots of different versions, especially when in development or generally updating titles.

Quoting: liamdaweFinances: They split their possible purchases across more stores, if they don't hit the payout threshold on GOG they won't get paid, but if they stick to one store they are more likely to get their money.

Are you saying that GOG have a threshold of sales they require, before starting paying anything to developers? That's the first time I hear such thing. I thought they simply pay percentage of every sale. On the other hand, I don't think games of Croteam are in danger of underselling. They are quite good and popular in general. Way less known studios and games are selling through GOG, and apparently have no such issue.

Quoting: liamdaweTime: They have to do support across another place, think what you want, but that alone will suck up a fair amount of time.

That's probably related to the above, but again, GOG isn't tiny, so they can compensate their support efforts with more profits. And again, less known games and smaller studios do it apparently successfully.

Quoting: liamdaweGOG tools: I've heard from a number of people that GOG's upload tools aren't great and they don't allow different versions like Steam do. There is a reason so many actively choose to use Steam for their builds as it's easy to manage lots of different versions, especially when in development or generally updating titles.

I'm not sure about different versions (I suppose GOG only offer the latest one, or some version + patches to latest one in some cases), but I don't really understand the trouble with upload. GOG accept some tarball from developers, and they themselves (i.e. GOG) already package and put it out. What's hard with having some rsync set up between GOG servers and developers? It should be a no brainer, there are tons of solid and production proven upload / sync tools out there. I'd like some comments from GOG about why this can be a sore point.


Last edited by Shmerl on 10 February 2017 at 8:39 pm UTC

Quoting: Shmerl

Quoting: liamdaweFinances: They split their possible purchases across more stores, if they don't hit the payout threshold on GOG they won't get paid, but if they stick to one store they are more likely to get their money.

Are you saying that GOG have a threshold of sales they require, before starting paying anything to developers? That's the first time I hear such thing. I thought they simply pay percentage of every sale. On the other hand, I don't think games of Croteam are in danger of underselling. They are quite good and popular in general. Way less known studios and games are selling through GOG, and apparently have no such issue.

Yes, GOG and Steam both do, I'm sure itch.io does as well.

QuoteThat's probably related to the above, but again, GOG isn't tiny, so they can compensate their support efforts with more profits. And again, less known games and smaller studios do it apparently successfully.

I've spoken to developers (who will remain anonymous) giving me low figures from GOG. GOG is, sadly, just not big enough for some developers to consider it. I think it's fair enough, they aren't a charity, their time has to be financially worth it.

QuoteI'm not sure about different versions (I suppose GOG only offer the latest one, or some version + patches to latest one in some cases), but I don't really understand the trouble with upload. GOG accept some tarball from developers, and they themselves (i.e. GOG) already package and put it out. What's hard with having some rsync set up between GOG servers and developers? It should be a no brainer, there are tons of solid and production proven upload / sync tools out there. I'd like some comments from GOG about why this can be a sore point.

There's a fair bit more involved than simply uploading a tar for developers, especially when it comes to rolling patches. The guys at itch.io even did a big blog post on their work to make uploading and patching easier for developers. There's a surprising amount of back-end work involved in this sort of thing.

And all this is without even getting into online support. That splits development time and support yet again to support more for less gain on an additional service.

This is why it slightly frustrates me every time people moan about no GOG support, GOG just don't offer what some developers require. Still, I don't expect everyone to just know this sort of stuff which is why I try to explain it calmly :)


Last edited by Liam Dawe on 10 February 2017 at 9:10 pm UTC

Well, there are good binary patching tools as well, I think one of the inXile Linux developers event wrote an interesting overview of this topic. So it's not like GOG or anyone else need to reinvent the wheel. They just need to iron out the expected way for developers to do it. Kind of strange that this is so hard.


Last edited by Shmerl on 10 February 2017 at 9:14 pm UTC

Quoting: GuestI think you misunderstand the purpose of SPIR-V.

I don’t, I believe I know fairly well what an intermediate representation is.

Quoting: GuestIt's an intermediate representation, nothing more. The reference compiler just converts from GLSL to SPIR-V representation, and does some basic sanity checks along the way (correct syntax for example). There is no real attempt at optimisation - and nor is there meant to be one.

Well, I was mistaken that there is an attempt in the glslang itself, there is however (WIP) optimizer in the SPIR-V Tools with issues such as Exhaustive inlining, Promote memory to registers or Aggresive dead code elimination.

Quoting: GuestIt's actually the GPU driver which does the optimisation part. Mesa uses LLVM (or parts of it) as a backend for that. It has to be done this way, because different GPUs require different optimisations, and support different instructions, which is something that simply can't be done at the SPIR-V level.

Perhaps just think of SPIR-V as the lexical analysis output, but not a whole lot more.

And that should not (in my imagination, at least) be the case. Most of more obvious optimizations are doable in a high-level language (GLSL, C, Rust, Python, Java) – things like function inlining, static constant expressions evaluation, loop unrolling, eliminating some unnecessary bounds-checks and other dead code.

Some optimizations are not possible to be expressed in higher-level languages – like eliminating unnecessary jmps/gotos when jumping out of nested if-else statements (but C can express them – with goto statement) – but those are expressible in an assembly-like IR (like LLVM-IR or SPIR-V).

And there are very machine-dependent optimizations – vectorization, choosing proper registers, choosing the most performant instruction from instruction set for the job – for those you need to know what your hardware is capable of and its own language. Those should definitely be done by the GPU driver’s shader compiler. But for the more general optimizations – I believe one should not be forced to rely on driver doing all that (even if they do, because they do it anyway for GLSL in OpenGL…), and instead should be able to ship optimized intermediate representation of shaders.

LLVM, by the way, does most of its optimizations on LLVM-IR – its own intermediate representation (and not on any real machine code) – so that those optimizations are reusable between all its backends (so people porting LLVM to another CPU architecture do not need to worry about them and reinvent them). Rust compiler even tries to go one step further – and introduces its own mid-level intermediate representation (MIR), on which it wants to do some of those optimizations even before it’s translated to LLVM-IR. And, BTW, using LLVM gives Mesa most of those optimizations for free – but again, I believe a programmer should not need to rely on the driver optimizing shaders shipped as binary IR.

And that also makes the LunarGLASS-based (where LunarGLASS, as far as I understand it, is also basically a set of GLSL and SPIR-V frontends and GLSL backend for LLVM) approach to optimization of compiling-with-optimizations SPIR-V (LLVM-IR-like) into optimized GLSL (C-like) and again compiling it into SPIR-V – because most of those optimizations are expressible at C or GLSL level.


Last edited by silmeth on 11 February 2017 at 12:30 am UTC

I have a simple question: can Vulkan breath new life into an old GPU? My Radeon 7850 can last one or two more years thanks to Vulkan? Or games will be even more resource hungry?