Aren't we all _fans_ of gaming on Linux? :-)

Jokes aside, good job Liam & co.!

View this comment - View article - View full comments

Superhot is worthy though - paid my fair share :-)

View this comment - View article - View full comments

Quoting: Guest

Quoting: EmazzaIs cross platform online multiplayer supported?

With matching versions yes

So are now the latest versions matching?

View this comment - View article - View full comments

Is cross platform online multiplayer supported?

View this comment - View article - View full comments

Fek!

I think I made a mistake having a balcony on the 3rd floor with a wooden locked door... shh11111ttttttt

View this comment - View article - View full comments

Has there been a wipe?
Because I woke up and all my items in my "house" were gone (apart my map and some bottles of water). The house is still intact and there isn't any sign of damage.
Was the server hacked with wallhack? Can someone explain?

View this comment - View article - View full comments

Quoting: liamdawe

Quoting: EmazzaDamn, it's down now....

It does reboot once every 24 hours i believe to keep it running smoothly.

Thanks! For a jiffy got scared we would have been wiped out... :-)

View this comment - View article - View full comments

Damn, it's down now....

View this comment - View article - View full comments

Hi,

I'm sorry to post this, but I've read many imprecisions (a.k.a. bullshit) in defining what is an eOn/wine port vs a native port. Please look at the below points:

• eOn/Wine wrapper --> launches x86 code --> strips/replace external entry points APIs with calls to wrappers --> instructions are executed by OS and when program runs eventually calls back eOn/wine entry points --> these will redirect D3D calls to OpenGL/vulkan equivalent (if the game runs originally OpenGL/vulkan is a 1:1 call, this is why DooM runs so smoothly)


• native code (a.k.a native port) --> launches x86 code --> instructions are executed by OS and when program runs --> calls are made directly to OpenGL/vulkan

Does this mean that technically eOn/wine ports may be suffering by more overhead due to translations of instructions? Technically yes - but given that modern CPUs are not the bottleneck for games execution, you end up with smooth experiences.
In the past there's been native games (ports) which sometimes were slower than the same OpenGL game running on wine...

Keep in mind the following: porting a game with eOn/wine is probably harder to maintain over time, given that the translation layer has to guess and replace native windows instructions/references with compatible Linux ones.
A native game is instead compiled with target Linux/Mac directly, hence it takes probably much more effort to make it run initially, but then I would imagine that it may play more nicely even after 5+ years when underlying Linux libraries get updated (it is also worth mentioning that if the eOn/wine translation is done extremely well and without hacks also this is applicable).

Why do wine games are slower then running native on windows with same hardware? wine presents a logical translation layer from D3D to OpenGL which has to pass conformance tests and it's very hard to optimize, because the APIs are not a 1:1.
Furthermore OpenGL has a limitation that instructions are executed from a single thread, it needs to keep texture in RAM - so even if you have a dedicated OpenGL render thread as latest versions of wine, there is so much you can do (in fact you have to keep live/copy loads of memory buffers).
Of course if a game is OpenGL native, there is no logical translation and commands are executed 1:1 (I remember in 2009 WoW was faster in OpenGL on Linux/wine than windows). The same applies to vulkan (see DooM) and when you use gallium D3D drivers: in this case the D3D9 API is exposed natively from Linux, so no expensive conversion layer!

As a metaphor, for people who can speak more than one language, the wine D3D to OpenGL port is a bit like translating a language; simple sentences can be translated very quickly and without errors (famous "the cat is on the table" ) but many other more complex, can't simply be translated that easily, and if you want to be extremely specific in not losing any subtlety you have to spend more time translating it properly and ensuring it holds true.

EOn ports, on the other hand have the bonus that have to work specifically for the given title, so if there is a translation layer, they can take many shortcuts to ensure that the final effects are correct but performance is also preserved. They can afford to remove some checks/waits/spins/... as long as that game runs fine. How will this play in the long run? It may be ok, it may be not, especially if the game itself will get patched and gets other shortcuts which would require re-work from eOn. This is why I mentioned that eOn/wine is probably harder to maintain over time.

Using above language analogy, VP are working with the subset of "language" that the particular game uses, so they can analyse and replace the complex sentences with pre made correct ones quite swiftly. Of course this is far from generic but works quite well for the given specific game.
Of course if the game creators suddenly slightly change the sentences, then VP might be in for a rough ride having to re-translate once more those phrases.

A native port instead relies on the ability of the porter to translate the language not at run time, but way before, during development (yes porting is technically development) and/or compile time.

Now, if Micro-machines is a Unity game and VP have decided to use eOn instead of exporting native, this means that the Unity Linux native exporter is perhaps really bad or they ported for Linux and Mac with similar wrapper, so they focused on one piece of software (the wrapper itself) to get two birds...

Hope this helps everyone.

Cheers,
E

View this comment - View article - View full comments

YouTube video link?

View this comment - View article - View full comments