Tested the new update as well. The performance is higher and now there is an option to turn on SSAO. Unfortunately with SSAO the framerate takes a hit.

View this comment - View article - View full comments

Quoting: GuestWhile I'm not sure of the spatial coherence of indexed vertex buffers, they are at least using instanced rendering where possible it would seem. Though I agree - there might be cases where they could batch meshes together for more cache-friendly rendering. I haven't looked in depth enough to know that for certain.
Not using VAOs is also inflating their API call count by quite a lot. Basic guesstimates in my head mean that 100k API call count could be reduced to between 15k and 20k. Fix up the texture generation at the start of each frame, and it should do wonders for performance - and that's just the low hanging fruit.

To be honest I am not sure about nVidia's or AMD's drivers but traditionally the most expensive calls are the drawcalls. For some drivers the drawcalls are expensive since this is the point where they check which part of the state have changed or do shader re-compilations or set dependencies or refcount objects and many more.

I have a question though since you looked at the game's behaviour. Do you know if it's CPU or GPU limited? It will be CPU limited if at least one CPU core is maxed out.

View this comment - View article - View full comments

Quoting: GuestWhat's worse, is that some of the object rendering setup is done the "GL2.x way". This introduces some overhead and internal driver checks on a per-frame basis that could otherwise be optimised using the "GL3.2 way" (basically, vertex attributes should be packed in a special object, a Vertex Array Object, or VAO, which reduces validation checks to the creation time instead of every time things are rendered). This kind of thing I'm hopeful they'll be able to easily fix - it should improve certain parts a lot.

While VAOs will remove some internal checks they have another problem. Being a separate object means that the app will have to access (most of the time) one before every drawcall. Accessing a different part of the memory will result in cache misses. On the other hand, by touching a single VAO (or the default VAO in GL ES) you ensure that everything will be in the cache.

Cache misses are a huge performance problem that people often forget. One of the great things about OpenGL is that it's very cache friendly. Many operations touch only the context and for the most part the context is in the cache.

View this comment - View article - View full comments

Great news!! Already bought 100+ euros worth of Linux games :)

View this comment - View article - View full comments

Valve has some very interesting things to show. Just to mention that they will present GL-next with some other high profile developers.

View this comment - View article - View full comments

Quoting: MajorLunaCSo, if it were just Valve and Epic Games, I would have said "Yeah, sounds good!" BUT, with this motley crew of sadists and mostly idiots, I'd say it's VERY BAD NEWS! No way in hell it's gonna be able to replace anything Linux or high-performance! If anything, they're scheming to force this OpenGL replacement onto everyone, deliberately making it as crappy as possible so people will stop using Linux, otherwise known as sabotage. With Microsoft's and EA's records, it perfectly reasonable to assume this.

How can someone take these conspiracy theories seriously? Sabotage? Really?

View this comment - View article - View full comments

Bought it and tried it for 10' on a nVidia 560ti. The performance is not great but that is somewhat understandable, 560ti is a 3+ years old mid-range GPU. The game looks quite good though.

Thought it was better to support the developers now even if the current state of the game is not optimal. Hope they will sort these problems out.

View this comment - View article - View full comments

I couldn't resist and finished it some months ago in windows. It's a very very entertaining game.

View this comment - View article - View full comments

The motivation for GLnext's IR:
- Bugs (or spec misinterpretations) in driver compilers. This is a huge pain for developers.
- Nobody targets GLSL. Big engine developers write their shaders in HLSL and then compile the source to IR's for DX and consoles (and some of them to GLSL, Unity)
- Obfuscate the shader source (Nobody admits it but many want it)

What GLnext's IR is not:
- Compile times won't be significantly faster
- It will not perform any heavy-weight optimizations. This is up to the driver's compiler because the driver compiler knows better

View this comment - View article - View full comments

Works flawlessly on Lubuntu 14.04 and nVidia. Some occasional stuttering but apart from that it seems like a perfect port.

View this comment - View article - View full comments