Quoting: Guest

Quoting: tuubiI don't know if this makes a difference, but HL2, the episodes and at least the first portal are actually DRM-free [External Link]. You need a steam account to download them, but they'll happily run without Steam.

Yes, I actually know (there's this list of DRM-free stuff on Steam).
Unfortunately I'm too consistent (stubborn?) in my No-Steam policy.... But HL2 is one of the titles really testing me on this :D

I don't think anyone really likes DRM; even the companies that use it would probably prefer not to waste time and effort on it. Unfortunately, as digital content is so easy to pirate on both a personal and commercial basis, without DRM a lot of companies would not ba able to produce the games they do. If, say, DRM were outlawed, you would probably find that many games would switch to something like a free-to-play model with an awful experience unless you shell out for bucket-loads of micro-transactions.

Prior to Valve announcing their Linux client, the only reason I had a Steam account was to activate Civ V, and I had a very negative view of digital distribution because of the possibility of losing all access to the games you have paid-for. But since valve started supporting Linux, I was willing to give them a chance, and now I get my games on Steam as a matter of preference. Valve/Steam are by no means perfect, but I have found that download/update ( for me ) are much more convenient that physical, I personally have experienced almost no Steam issues, and although I know there is usually some DRM there, I find it non-intrusive compared to the horrible DRM that used to be inflicted with physical media.

I admire your principled stance, but I haven't been able to envision, nor have I seen any credible suggestion for, a DRM-free model that would satisfy everyone's needs; so I guess we are each stuck with accepting what we personally consider the least bad option.

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: KimyrielleI rarely look at performance numbers and benchmarks, as I am happy when game runs with enough FPS for me to be able to play it. I would however be curious if there are OTHER components holding back Linux performance other than OpenGL. In other words, if a game uses Vulkan on both Windows and Linux, would it perform exactly the same on both Linux and Windows? Or would Linux still be worse?

OK, disclaimer, I'm no developer and I can't back this up.
But the general zeitgeist I have from following vaguely this sort of thing for years comes down to: Aside from OpenGL problems, up to now graphics card drivers for Linux have tended to be slower, although that situation too has been improving and the nature of Vulkan seems to be such that it probably won't be nearly as much an issue for Vulkan stuff. But OS to OS, Linux itself is probably faster than Windows, and certainly lighter, so it wouldn't hog as much CPU or memory for itself, leaving more for the game. The "lighter" part of course depends on specifics like, KDE or XFCE or what? As I say, this is my general impression which I cannot cite any sources to defend, so take it for what it's worth.

All modern OS are comparable in performance ( i.e. no big advantages ). They have differing design philosophies which can have an impact, and as you point out the quality of drivers and other code libraries can also affect performance. My cross-platform Linux/Windows code tends to run a little faster in Linux, but as it is developed using Linux-based libraries ported through MinGW to Windows, that is probably to be expected.

It is honestly very difficult to properly compare APIs or compare OS performance without actually viewing the source to verify that what you are comparing is reasonable. For example, the croteam OpenGL implementation may just not be as "good" in terms of best practice and optimization as their Vulkan implementation. All good developers learn constantly, but it doesn't mean you have the time or inclination to go back and improve older stuff once you realize it sucks :-)

I'm more with Kimyrielle, in that I don't care how many FPS, as long as it's good for my personal perception, which typically means consistency and responsiveness over pure frame-rate.

View this comment - View article - View full comments

Quoting: liamdaweThe way the story is presented is brilliant too. You’re not repeatedly given cut-scenes, as the story unfolds literally as you’re playing and makes the action and the story blend seamlessly together in a way not many developers are able to achieve.

Totally agree. This is the sort of thing that is the essence of good game design, but unfortunately seems to take a back seat in many games. HL2 is, fundamentally, trekking through a long and winding sausage, shooting things, but it doesn't usually feel that way. I have nothing against cut-scenes intrinsically, as they can help flesh out stories and ensure the gamer has important information, but many games use them in a way that completely breaks the immersion or game experience. Even worse, some games are beginning to resemble interactive movies, where you only occasionally have any form of control ( can I please take out a contract on the individual that invented Quick-Time Events? ).

Quoting: liamdaweLike a lot of games, the ending battle was a bit of a letdown.

I'm not really a fan of boss battles. They have been around since the likes of early CRPGs and Wolfenstein and have mostly become boring at best. Even in a shooter, it shouldn't be a requirement if the game is well structured for the ending to involve working out the arcane loophole that allows the boss to be invincible or a bullet-sponge; IIRC I died 4 times playing Mass Effect 2 before I could stop laughing at the giant baby cadaver that constituted the boss ending, and felt no sense of achievement in killing it.

Hmm, maybe I need to go play Episode 1 and 2 now...

View this comment - View article - View full comments

Quoting: webcreatureI think you refer to D3D11on12. That is primarily made for porting purposos, or reuse D2D, text and UI. It is by no means easy to use or in any way recommendable. And it is definately not wise (or simply impossible) to mix a D3D11 and D3D12 in the renderpipeline.
For me the 3d portability initiative is a way for every parttaking company to tell Microsoft and Apple: "We want open cross platform APIs".
We'll see how much members the initiative will have.

Yes, D3D11on12 which does automatic D3D11 to D3D12 conversion at the driver level ( i.e. you don't actually mix D3D11 and D3D12 ). It's downsides are some CPU overhead and significant CPU-side memory overhead, since it is keeping both D3D11 and D3D12 copies of data and synchronizing them at the driver level. This may not be good for everything, as there are some parts of D3D11 that are not supported, but it still allows gradual migration of code that is likely to be more appealing to some than trying to shoehorn an entirely new and alien API ( not C++, not COM ) into code that they may not want to re-architect. Even if the render functions are converted to Vulkan, the rest of the code is likely tied to Visual C++ and DirectX/COM. At least in the short term, I think you will see many existing Windows games companies ( that are not engine vendors or users ) move to D3D12 first before adding Vulkan, if they do at all.

View this comment - View article - View full comments

Quoting: Guppy

Quoting: Guest[...]
They use the exclusive standards.

Why?

I have no fucking idea.

[...]

Because it's the safe logical progression DX12 might be 99% different to DX11, but being used to DX they will take that 1% familiarity over something the is 100% unknown.

From the viewpoint of a D3D developer, it's actually a lot better than that; Microsoft have a "merged" D3D11/D3D12 mode that gets you many of the benefits of D3D12 API while keeping most of the D3D11 calls the same. There is really no reason to change to Vulkan unless a developer wants to target additional platforms.

The reasoning behind this announcement/initiative is probably a pragmatic acknowledgement that the world will not become Vulkan overnight, and possibly not at all. For a general cross-platform application that wants to have some 3D capability, and for WebGL client implementations, having such a compatibility layer may help ( they are inviting input, so we don't know how such a layer would work ).

For games and other performance-sensitive applications, maybe it is not such a good idea, as there would probably not be as much opportunity to optimize with either a source-level code generator or binary-level translator.

As something of an aside, there seems to be an assumption by many people that adoption of Vulkan by developers is both an obvious step and a trivial task. For some developers one or both of these are true, but for many they are not.

What if you have a game or other application written in C++/COM on Windows, with all the appropriate development and content tools a practices? Are you going to adopt a new C API and development model for a few percent extra sales, or use the safe option of an updated familiar friend?

Vulkan is the "natural" 3D API for Android/Linux ARM devices and GNU/Linux x86 devices ( as well as potentially other Linux, BSD and SysV derivatives ), so anyone that has an interest in targeting these platforms, such as game engine developers, have been quick to adopt Vulkan. But I think it is the support in Android that is the more important driver for adoption than any support in Windows.

View this comment - View article - View full comments

Quoting: SchattenspiegelGuess I will have to reward the port by buying TWWarhammer if Feral does a Shogun 2 port. Already have later from from my Windows days, I fear.

@Feral:
Concerning interest: I would like to suggest looking into the IL-2 Sturmovik: Battle of Stalingrad/Moscow/xxx series of games - well technically it's one game, I guess. Admittedly not that many potential players/buyers but it would be the only current game of it's kind on Linux and it has a lot of desirable dlc options and will probably get more (buyable) content for quite a while yet.

Seconded. I enjoyed the first 4 IL2 games, but didn't get the Cliffs of Dover/Battle for Staligrad because I stopped buying Windows games. I would certainly buy Linux versions.

View this comment - View article - View full comments

Quoting: Whitewolfe80

Quoting: Mountain ManI have Empire: Total War and Total Warhammer. That's more then enough Total War games for me at the moment, so I won't be getting Shogun.

Fair enough but it is the best one out of them all of them the units are balanced there are more options other than the limited options in warhammer or rome 2/attlia but i get what you mean I personally own all of them except Napoleon.

Shogun II was the first TW game after I stopped buying Windows games, and so , the first one I did not buy. As I also bought Rome II/Attila to support the CA Linux pledge, this is the only TW game In the back catalog I don't have, so I will certainly buy it.

On the other hand, I'm not sure I'll ever get TW Warhammer. I never really liked the Warhammer/WH 40,000 universes, as they always seemed limited and visually unappealing to my senses. But I guess CA have run out of popular historical periods without a recent game :-)

View this comment - View article - View full comments

Quoting: Shmerl

Actual submission of commands to the GPU is still done sequentially, in a single thread, however there’s very little overhead; all error checking has been done

Is that true? From what I've read, modern GPUs support multiple queues for input (some for graphics, some for compute). I'm not sure what GPU is supposed to do with multiple queues for graphics for example, since in the end, rendered image is a single frame, but if they exist, it means it should be possible to feed them from multiple threads (one thread per GPU input queue). And Vulkan should support that.

Also, it's possible to have multiple GPUs working in parallel (Vulkan aims to support that), to increase computational power. You for sure don't want to have one thread feeding such hardware setup - it's going to be underutilized.

Yes, Vulkan uses a single thread for GPU submission. AFAIK, in hardware terms, the most common case where a single thread may cause throttling would be for an extremely powerful GPU with a relatively weak CPU. In such a case, you would be using a dedicated PCIe card for the GPU, and the need to use PCIe would enforce single-thread synchronization in the driver regardless of what you do higher up the software stack.

AMD's APUs and Intel integrated graphics are different in that they are monolithic silicon, and therefore might be expected to benefit from multi-threading; but as the GPU elements are relatively weak, it is probably not the case.

Either way, an application design is probably more robust if it explicitly synchronizes submission order through a single thread. Responsibility for explicit synchronization is the trade-off developers accept for the benefits of using Vulkan.

Multiple independently operating GPUs ( say, one for compute and another for graphics ) could clearly benefit from a submission thread per GPU, but if they are co-operating on the same tasks, you still need to synchronize submissions, so you would probably still want a single thread to do that work.

View this comment - View article - View full comments

Quoting: Kimyrielle

Quoting: PhiladelphusInteresting that a mere two years ago, at the end of 2015, [Steam only had 2,964 games altogether](https://twitter.com/Steam_Spy/status/804072335997358084?ref_src=twsrc%5Etfw), and now here we have 3,000 on Linux. :)

Though the flip side is, simply having more games doesn't necessarily mean more games I want to play, nor does it include some games I do want to play. But hey, as long as they're making someone happy, that's fine with me. :)

Unfortunately, that's true. Of the 3,000 games, roughly 2,500 suck very extremely hard. Indie development has brought us gems like Prison Architect and Stardew Valley. But also a lot of people who can barely code Hello World suddenly thought they could be the next game development star and published their drivel on Steam because nobody stopped them. That's actually a huge problem these days, because it's getting harder and harder to find the few good games in the mountain of drivel.

Yep. Steam is a microcosm of the Internet at large. Anyone can say anything ( much of it wrong or, at least, highly opinionated ), publish their music, videos, and selfies, and, of course, turn "Hello World" into an underwhelming game.

Just wait until the other 6.5bn of the global population join in.... :)

View this comment - View article - View full comments

Quoting: CreakI know that I won't change the mind of all the users in this forum, but if I can convince you @liamdawe that GL threaded is good, but not "that good", and that the game engines can be multi-threaded even without the GL threaded feature. Then maybe you would post new articles that won't get the hopes too high for your users.

As a developer in the game industry for 11 years now, I have some knowledge. I completely understand that you don't have to trust me on what I'm saying, but you have access to people that you trust more (Valve, Feral, Aspyr, ...). Ask them your questions like: "is it possible to do some multi-threading in a game engine even though there is no threaded GL?" or "What kind of algorithms can be multi-threaded in an engine apart from the 3D part?"

On my side, I won't say more about this, because I can feel that I'm getting angry at fighting against hopes and beliefs, and that can be very frustrating.

Completely agree :)

The IT world in general is far too much about marketing BS, and the gaming world is sometimes part of that. The fact the Mantle/Vulkan/D3D12 exist is testament to the fact that there are issues to be resolved, but there are generally no silver bullets in coding. Threading APIs may be a convenience for developers, but the underlying implementation then has to do GENERIC work to deal with the threading in place of the developer doing SPECIFIC work for their threading needs; it will not always be a good idea.

View this comment - View article - View full comments