More technical info about the incident (what kind of data leaked, what numbers, how and why, and how the issue was resolved and in which timeframe) can also be seen on the Google’s Project Zero issue about it.

Seems there is a chance it hasn’t been exploited yet, but as the data leaked to web crawlers, people do have leaked data cached (and may not even realize it yet), and that cached data may be used later.

View this comment - View article - View full comments

I’ve already voted yesterday. :)

It’s a very fun game, especially with the ‘football’ game mode (though certainly it’s not Rocket League. Yet. ;-)), and multicontroller support with splitscreen. The networking multiplayer is in my opinion the only major feature lacking. The graphics also is pretty decent and not really worse than some (especially older) AAA kart games.

I don’t understand why people criticize it so much on the net, as in 2017 it is really enjoyable open-source game. One of the best probably, along Battle for Wesnoth, 0AD, The Dark Mod and a couple of others.

View this comment - View article - View full comments

Quoting: liamdaweGood point, but in future we do have the spelling and grammar corrections feature for a reason :)

Fair point, I honestly missed it, saw just now, when you pointed out it exists. My bad. :)

View this comment - View article - View full comments

I know you just copy-pasted their changelog, so it’s rather their fault, not yours, but anyway – It’s Polish language, not “Polish” language. You know, it doesn’t pretend to be Polish while not really being, nor is it a title that needs quotation marks. Like, you know, English language, and not “English” one. ;-)

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

I wonder what they use for optimizing their SPIR-V shaders. As the reference Vulkan shader compiler (glslang) does not do things like inlining, dead code removal, promoting memory to registers (they are still work-in-progress, and I am not sure if glslang even does loop unrolling), so that means it emits pretty suboptimal code for shaders.

It's possible that GPU drivers do those optimizations (but with SPIR-V intermediate language they shouldn’t have to) – but does Croteam rely on it? And do the drivers actually do it?

It’s also possible they use third-party optimizer like LunarGLASS (but, as it emits high-level glsl code, that seems cumbersome, although apparently works). Or that they have their own optimizer.

And it’s possible they do the optimizations by hand (which would be very time-consuming, error-prone and generally not that great).

So it’s interesting what do people actually earning money using Vulkan in production, use right now – I believe for some time the lack of optimizations in the compiler was a blocker for some game studios (Inovae wrote about it AFAIR).

View this comment - View article - View full comments

Quoting: XpanderCroteam FTW! They were the firs to start testing Vulkan in their game also and its now pretty solid and i'm getting huge performance gains with vulkan in Talos, almost 2x perf vs opengl

Similar here, but I get some random crashes on Vulkan while reading messages in terminals. I wonder if it’s nVidia driver’s fault or Talos Vulkan bug – because of that I play mostly on OpenGL.

Still, they do a very great job.

View this comment - View article - View full comments

Quoting: sn0rlaxTheir site says Java is included. No need to install or update.

Nope, their site says “Java 1.6 or later (64 bit recommended, included within Windows version of the game)”, so they do pack it with the game on Wins (and that’s good, as managing JVM on Windows is a nightmare), but they do not say they ship it with their game on other platforms – so it seems you need to install Java Runtime on Linuxes and Macs (and that would be openjdk-8-jre package on Debian/*buntu).

View this comment - View article - View full comments

Looks pretty similar to the Sierra games (Caesar 3, Zeus, Pharaoh, Emperor), at least the non-military part of game.

View this comment - View article - View full comments

QuoteThe only thing that I can explicitly say I found annoying is the fact that you can't skip the dialogue by clicking the mouse;

I work with a guy who wrote the game, he’s sitting next to me right now, and he’s saying you can – but you need to use the right mouse button. ;-)

View this comment - View article - View full comments