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

Quoting: natewardawgOne is using a few 100% native calls, but using non-native names in the code, the other is translating non native calls for an entire OS at runtime, it's a huge difference.

Not huge, because another is not translating the entire OS unlike what you say. Wrappers like Wine don't emulate the whole Windows kernel for instance. They simply translate a given list of calls into ones that provide similar functionality through native means. It's far from providing entire OS at runtime. That's why for instance Wine won't work for Windows hardware drivers as far as I know.

So the difference between static and dynamic translation is purely nominal. The result is simply a chain of calls into native functions. Wine naturally should implement Windows calling mechanism I suppose, to actually be able to translate Windows binary calls. Source wrappers don't need that.

What you are describing on the other hand, is already something like ReactOS which indeed provides a whole Windows like operating system. Wine is nowhere aiming at such functionality.

View this comment - View article - View full comments

Quoting: natewardawgSo when the game goes to render DX11 stuff, your "DX11" code actually makes OpenGL calls.

This is obviously a simplified version, but should hopefully get the point across. :)

Same thing happens dynamically, except calls are translated at runtime. Even at source level, the wrapper needs to retrofit completely foreign API into another one that is native. It's a hack, not a proper software design to begin with. But as long as it produces a working result cheaper, some don't care if it's a hack.

View this comment - View article - View full comments