Quoting: LordpkappaWe'll see an upgrade to the actual games that use Unity like Cities Skylines?

They're pretty fast upgrading the eninge for their game. Two days ago (29th of November) they released on Unity 5.4 which was released on 10th of August, so it took them only close to two month. So I'd guess with the next bigger content they release we'll see Unity 5.5 support.

View this comment - View article - View full comments

Would be interesting what kind of issues they experience with the port in a bit more detail. Seriously, with all the issues even really experienced porting studios as Feral describe, it's not unexpected with lesser experienced porters to find cases they can't solve. With our graphics stack still lacking (and we KNOW it) we can't even complain if some find it too-much-effort ...

Though, I can't say I'm personally sad, because I never understood this kind of games / they never were fun to me, but it's sad for one more title not releasing on linux which may have brought joy to a lot of linux gamers.

View this comment - View article - View full comments

Quoting: MyeulC

Quoting: STiATHmh, I don't really get the point in the project except if it is for academic purpose (which is perfectly fine, don't get me wrong there!). Providing a d3d9->vulkan mapping for systems which ship with d3d9? In the end, 2020 we'll rather see Vulkan/DX12 things popping out than having D3D9 or even 11 being used, since most engines will be there by then.

But yet, for Wine which already does all this (basically, providing a WINAPI, HRESULT, IDirect3D9* stuff and windows event handler / STDMETHODCALLTYPE etc.), it may be a good starting point if they wanted to do a d3d9 to vulkan mapping.

Let me disagree with your last point. To concentrate on this translation layer, I believe it is just easier to work on... Windows, which already supports both APIs, and as such, is just one DLL remplacement away, not involving wine.

That's interesting, but I wonder if there isn't reusable things in gallium nine, which does the same, albeit a bit higher level.
It also has its use cases where G9 isn't available, too.

It does not just source one DLL. It sources a lot of Windows native DLLs by sourcing windows.h. Anyway, it uses the MEAN_AND_LEAN macro, so you probably could provide this functionality as well. But that's basically a smaller port of Wines WinAPI implementation, but ye - it could be included into projects natively. But that's a chunk of work.

View this comment - View article - View full comments

Hmh, I don't really get the point in the project except if it is for academic purpose (which is perfectly fine, don't get me wrong there!). Providing a d3d9->vulkan mapping for systems which ship with d3d9? In the end, 2020 we'll rather see Vulkan/DX12 things popping out than having D3D9 or even 11 being used, since most engines will be there by then.

But yet, for Wine which already does all this (basically, providing a WINAPI, HRESULT, IDirect3D9* stuff and windows event handler / STDMETHODCALLTYPE etc.), it may be a good starting point if they wanted to do a d3d9 to vulkan mapping.

View this comment - View article - View full comments

I'm hoping it will release on Linux :-) ... that's another game I'm really looking forward to.

View this comment - View article - View full comments

Yeah, a starcraft clone more or less :-) ... I think I would love that one.

And on greenlight it says it comes with a campaign :-) .. that's a must-buy if they don't mess it up completely.

View this comment - View article - View full comments

Quoting: PixelPiBethesda supports with Vulkan Windows 7 and Windows 8 users. I think this is the main reason why we will see a lot of Vulkan developments in the near future. But unfortunately this does not mean automatically Linux ports.

Agreed. Blizzard will do the same for the next iteration for their engine. The good part about this is, that for Wine it's quite straight forward then, so we can expect better performance and less issues with wine ports in future. Of course we want native ports, but hey - let's stay realistic, it would be nice already if we don't have to fiddle around for every game to get it working well and after that still suffering performance issues.

View this comment - View article - View full comments

Quoting: GuestHave to agree that something natively developed from the start is what we should be pushing for. Almost all the people who have so far touted the performance gains from Vulkan have had engines designed with DX11 in mind and tried previously to kludge OpenGL into it.

Actually, that's what engine devs are doing right now with Vulkan as well. They're developing Vulkan below a DX11ish API.

So basically, all engines - and I mean all, being Serious Engine, UE4, Unity etc. are using a DX11 "look-alike" interface, having an implementation in Vulkan below the hood.

I think what we'll see is very much what has been missing the past decade. Engines will build their own graphics API to be developed/scripted from the game development studios, mapping that internally to what ever export target we see out there, providing the maximum performance they can deliver on a certain API / Platform. And we'll see this API to be very DX11ish in the end anyway. Why? Because the game development studios are used to DXish APIs.

Vulkan / DX12 are basically for engine devs to push the performance to the limit. Game development studios will expect something more high level to use.

View this comment - View article - View full comments

Nice great step forward. Not an AMD user, but hey- that would be just great. Just for the reason that Mesa has been moving [very] fast (maybe due to all the game developers) recently.

View this comment - View article - View full comments

I'm pretty sure anyway it will become an official offering at some point. They just don't want to announce something yet.

View this comment - View article - View full comments