Quoting: tmtvlMicrosoft have proven themselves to be rather decent towards Linux as of late.

Not towards Vulkan though, which reflects the sick lock-in mindset of their gaming branch.

Quoting: tmtvlThey also haven't blocked Minecraft from opposing platforms, so I don't think there's much to worry about no matter who they decide to buy out.

The only reason Minecraft wasn't borked is the fact that it already worked for Linux, so they didn't want to make their reputation even worse than it is now by axing it.

View this comment - View article - View full comments

Quoting: GustyGhostAnd not just that, but outside of the gaming industry the concept is completely preposterous. Just imagine: "Daewoo signs exclusive contract with Lionsgate Films for timed exclusive movie releases only to compatible™ Daewoo DVD players."

I wouldn't say so. Unfortunately this sick idea can be found in various markets. Consider the fact that Disney pulled their films from Netflix (or planned to pull? I'm not using either, I've seen something about it). Same goes for Netflix themselves, they make films that are exclusively available through their store only. That's not a healthy situation at all.

View this comment - View article - View full comments

Nightdive is a great studio and they support Linux in general.

View this comment - View article - View full comments

The last thing we need is MS monster messing up Linux gaming. About EA? Not sure if it would make it any worse than it already is.

And regarding exclusive releases - this dumb and insulting approach should die out already. Normal game creators should strive to increase their reach, not to insult users by excluding them.

View this comment - View article - View full comments

Quoting: Purple Library GuySo then if you have a game whose graphics are simplified with mostly static environments, in short a game whose look could have been readily produced 15+ years ago with the computing resources available then, why does it not imply using less computing resources? It's distinctly counterintuitive.

The reason old games could use less resources is that their engines were carefully crafted to use less to achieve more. I.e. they used every trick they could to make things look better within limitations of available hardware. That required quite a lot of effort and ingenuity.

Today developers use common bloated engines that do nothing of the sort. So unless they design their engine from scratch to be actually minimalistic, don't expect their games to be less demanding. There are exceptions of course. Such as Pico-8, or LÖVE which are made to be minimalistic to begin with: https://love2d.org [External Link]

View this comment - View article - View full comments

I don't focus just on the binary, but on the source level as well. That's the difference in how I view non native result. In the end, you get a binary that runs on Linux either way, because we aren't talking about VMs here.

So in this sense, Feral's ports aren't native either, because they wrap foreign API in their code into native one.

View this comment - View article - View full comments

Quoting: GuestI'm actually curious about why it seems to matter. What does "fully native" give that a source or runtime based wrapper does not? I think performance is not really that much of a problem; while a "fully native" game would likely have better performance, that only comes from inclusion during game development and engine design rather than any compiler magic.

If performance isn't a problem, then it doens't matter much, except from design cleanness perspective. But performance isn't always an easy target. Consider for example performance hit that The Witcher 3 gets in Wine, because of translation of D3D11 into OpenGL 4.x.

I.e. it's still pretty playable, but there is a performance hit that you need to take in account for given hardware.

That's what translation here is. It's not just simply taking shaders and translating them. It's trying to map completely different API with its own logic, into another one with its own restrictions. That's a logical translation. It's probably easier to make it efficient if you are translating it into low level Vulkan.

View this comment - View article - View full comments

Quoting: natewardawgBy your own definition of what translation is, there's no such thing

It's not a new thing translating one API into anther. You can say "there is no such thing", but it's not really uncommon.

Quoting: natewardawgIf you disagree, I have one simple question: How much non native game design and/or code can be present in order to call it a "Native Port"?

To make it native, it should be designed with native API as a target. And not retrofitted post factum by wrapping foreign API into native one (no matter on what level). That's about it. And as above, I have no problem with non native ports.

View this comment - View article - View full comments

Quoting: natewardawgI've written wrappers before, calling them translating is a huge misstatement.

It is normally called static translation on the source level, or compile time translation. The main point why it's not native is not the formality of names, but the fact that you take one API with its own design, and fit it into another API with a different design. The mere fact of doing that is a translation. You can debate the benefits or downsides of static translation vs dynamic one, but they both remain non native approaches.

View this comment - View article - View full comments

Quoting: natewardawgNote that a wrapper isn't "translating", it's putting actual native code into non natively "named" function calls

That is translation already. Not translating means you call right functions to begin with, using the design of the native API, instead of hacking around one API into completely different one.

Quoting: natewardawgOne is native, the other is non-native.

Sorry, but source translation is nowhere a native approach. It's a translation hack. Which is a great shortcut of course, but it's not what you'd call a proper software design from the ground up.

View this comment - View article - View full comments