Quoting: slaapliedje

Quoting: Nevertheless

Quoting: scaine

Quoting: slaapliedje

Quoting: GuestHesitating... Should I try to complete Dungeon Master on my Amiga (MiSTer FPGA) or this one or the former then the latter ?

Ha, so I actually started playing Dungeon Master on my Amiga (A4000 w/68060) quite some time ago, I need to finish it off (re-installed the 3.1.4 over the weekend, now just need to get WHDload set up).

While I beat DM on my Atari ST back in the day, I never did complete Chaos Strikes Back. So my plan is to complete DM again, and then import my characters into Chaos Strikes Back.

I loved Dungeon Master. I completed it. Completed it again. Completed it with 3 characters. Completed with 2 characters (oh my, they become godlike by the end) then finally gave up while trying to beat it with one character. The spell cooldowns were too difficult to manage in certain fights and you just don't put out enough sword damage as a single character.

Bloodwych was another favourite - I played that split-screen with a friend on his Atari ST. Two, four-character parties rocking around a massive dungeon. Awesome.

Finally, if you like this genre and have three (very) close friends, the Amiga version of Hired Guns was sublime because you each played one character in a party of four, quad-screen. Two characters played on mouse (the Amiga could handle two mice plugged in) and two on keyboard. Amazing. Great music too!

Aww great! Now theres the idea to play Dungeonmaster back again, because of you both! ;-)

Do it! Truly a classic! It's amazing that FTL never ported Sundog to anything. So you still have to play it on the ST. That's another fantastic game I'd love to get back to to play.

I didn't even know that one! Never had an Atari ST. Looks interesting!

View this comment - View article - View full comments

Quoting: scaine

Quoting: slaapliedje

Quoting: GuestHesitating... Should I try to complete Dungeon Master on my Amiga (MiSTer FPGA) or this one or the former then the latter ?

Ha, so I actually started playing Dungeon Master on my Amiga (A4000 w/68060) quite some time ago, I need to finish it off (re-installed the 3.1.4 over the weekend, now just need to get WHDload set up).

While I beat DM on my Atari ST back in the day, I never did complete Chaos Strikes Back. So my plan is to complete DM again, and then import my characters into Chaos Strikes Back.

I loved Dungeon Master. I completed it. Completed it again. Completed it with 3 characters. Completed with 2 characters (oh my, they become godlike by the end) then finally gave up while trying to beat it with one character. The spell cooldowns were too difficult to manage in certain fights and you just don't put out enough sword damage as a single character.

Bloodwych was another favourite - I played that split-screen with a friend on his Atari ST. Two, four-character parties rocking around a massive dungeon. Awesome.

Finally, if you like this genre and have three (very) close friends, the Amiga version of Hired Guns was sublime because you each played one character in a party of four, quad-screen. Two characters played on mouse (the Amiga could handle two mice plugged in) and two on keyboard. Amazing. Great music too!

Aww great! Now theres the idea to play Dungeonmaster back again, because of you both! ;-)

View this comment - View article - View full comments

No use to think about future implications. I think they will faithfully release Bards Tale 4 and Wasteland 3 for Linux and on Steam/GOG, and then do UWP Apps on the Microsoft store alongside Obsidian.

View this comment - View article - View full comments

Quoting: TcheyI'd probably love to love this game, but the real time killed my will. I disliked the Grimrocks for the same reason. For me, this kind of games (RPG grid based crawlers) "must" be turn based. The last one to actually pleased me was Starcrawlers, who did many things "well" (but failed to provide a "less combat, more xp" option).

Funny, the realtime aspect is something I really enjoy! I think it enriches gameplay with the possibility to outmaneuver your enemies or lure them to dangerous places like trap doors or steam vents, etc..

View this comment - View article - View full comments

I finished Vaporum some time ago. I really loved it, and I'm looking very much forward to the prequel they are developing right now (which will also have Linux support by the way).

https://twitter.com/VaporumGame/status/1080793529805361152 [External Link]

View this comment - View article - View full comments

Quoting: Guest

Quoting: GuestVery detailed and well written article, thank you. But... I just can't see how having a (near) perfect translation layer between DX12 and Vulkan is supposed to bring more developers to adopt Vulkan over DX12, and in the long run start developing games for our OS. I mean, the whole point of Proton, from a developer point of view, is "don't worry about nothing, don't change your practices, keep using what you are using right now (most often DX11/DX12) because Proton will take care of everything". Why should any developer move away from DX12 if they can reach the Linux and MacOS (using MoltenVK I guess) markets with their DX12 games?

DX12 is a different case to DX11 here, because DX12 is (in my mind) classed as a new API architecture. I'll confess that my knowledge of DX12 is limited - I use GNU/Linux exclusively on the desktop now, and so have little interest in developing for DX12, but it's still an important API to consider.

Short version though is that it's not really known if DX12 will completely take off, or Vulkan, or something else. It also depends on how much mobile influence there is - Vulkan is pretty much the only option going forward with Android, and of course there's Metal for iOS. Khronos themselves recognise this and so started the portability initiative - write in portable Vulkan, and it will just run on top of DX12, Metal, or Vulkan - whatever the underlying OS (desktop or mobile) supports. Oh, and web browsers should be considered too, which has Vulkan work starting as well (ok, a web browser doesn't affect a AAA game much, but it adds weight to general developer experience, and that might well creep into all graphics areas).

So how that all plays out remains to be seen. There's little bearing in that on why DXVK outperforms some (many!) native ports for GNU/Linux though, so I didn't really touch on it much in the article.

Great! Let's collect the best arguments to use Vulkan in favor of anything else. Here are my ideas:

-unlike DX availlable to any platform that wants to support it
-multithreading support to avoid CPU limitations
-performance on par with DX12. Only custom APIs for special hardware could reach higher efficieny
-more future proof than easier to use older APIs
-multi GPU support
-has tools to convert Vulkan code to DX12 and Metal
-the enormous flexibility of Vulkan that DXVK is a bright showcase for

View this comment - View article - View full comments

Quoting: Guest

Quoting: NeverthelessI guess with more freedom and responsibilities you can easily do things not exactly right.. I suppose it's not DX12 or Vulkan to blame.

Oddly enough, I think more people are doing it "right" with Vulkan than with OpenGL. Developers need help: documentation, debugging tools, stable drivers, examples, all that kind of thing. Khronos have put just as much effort into developer help as they have with the API, so as I see it Vulkan even wins out against OpenGL in that regard!
There's a tweet somewhere from someone who developed entirely on nVidia, and then with almost no changes it ran perfect on AMD hardware (the one change was a different bit of hardware support that should have been properly queried, and was actually caught by the validation layers and reported to the developer). That's something that was actually difficult to say for OpenGL.

...but yes, a developer can still bugger up if they ignore all that help. Last I heard, Unreal Engine has a load of validation errors with Vulkan, and I'm not sure on the state of Unity3D and Vulkan right now. Not enough free time to play around that much. And if Vulkan crashes out, it's usually a bit more spectacular than OpenGL crashing out.

(damn I gotta stop blabbing on, it's just an area that I'm passionate about)

No, don't stop your passions! You wrote a great article and I love learning more and completing my picture about the topic!
If I am informed correctly programming OpenGL was is a bit like programming a black box. I suppose laboriously programming Vulkan is much more predictable (if you know what you're doing) than guessing what the OGL black box needs.

View this comment - View article - View full comments

Quoting: Guest

Quoting: GuestAn awful lot of modern ports (eg Feral, VP etc) use translation layers like DXVK anyway - it's not like porting houses are writing whole new renderers for AAA titles - that'd be cost and time prohibitive.

So really, we're comparing "porting house X's DXVK equivalent" (for Feral, IndirectX? for VP, eON) - some using OGL, some using Vulkan - to DXVK, not "native opengl" to DXVK.

Yes, the bulk of the work is some kind of translation layer, but there are additional changes around that that are sometimes made. So it's not a "pure" translation in all cases. Even VP can actually recompile the original game to work better with eON, if they have source code access.
Even within that, shaders contribute a lot to performance, and if a porting company can modify those to work better with Vulkan, then it _can_ make quite a big difference.
Still, the bulk of performance improvements come by just using Vulkan instead of OpenGL, no matter which way it's done. Vulkan is just better for modern systems - and it's DXVK, Feral, Croteam, Valve, etc (as far as GNU/Linux is concerned) who have shown just why there's been so much excitement over it. Hopefully we'll see less games using DX11 going forward, and more using Vulkan directly (or DX12 I suppose, but fingers crossed for Vulkan instead!).

I guess with more freedom and responsibilities you can easily do things not exactly right.. I suppose it's not DX12 or Vulkan to blame.

View this comment - View article - View full comments

Quoting: YoRHa-2B

Quoting: NeverthelessSo even single threaded Vulkan is much more efficient than OpenGL. I guess DX11 performance might come single threaded Vulkan close.

Vulkan draw calls and friends are, for the most part, dirt cheap. There's very little (but still some) state tracking going on in the driver, and you as an engine developer can build thin abstractions that fit your needs, again with minimal state tracking, rather than using an overly generic abstraction that ends up doing way more than you actually need, and doesn't necessarily do it well, both in terms of CPU and GPU performance.

Unfortunately, the latter still seems to be a common pitfall, and we end up with games that run significantly worse on D3D12 than they do with D3D11, even when CPU limited. Latest prominent example of that being Resident Evil 2, which runs faster with D3D11->Vulkan translation than it does with their native D3D12 renderer on Windows. And that just shouldn't happen.

I must say I'm somewhat glad it's not (only) Vulkan that has such problems...
And do you change the CPU limitation with DXVK, or is it even possible without generating lots of errors?

View this comment - View article - View full comments

Reading this I just remembered something that I think fits the article.

Two years ago I asked the Croteam devs in the Steam forums if they could tell me why I could see only one CPU core going up to 100% and all the others staying at 25% ( https://steamcommunity.com/app/257510/discussions/0/135509024341635313/?ctp=2#c135509823661294050 [External Link] ), while I was playing the Vulkan version of The Talos Principle, but still the performance was way better than the OpenGL version. I got answer:

"AlenL [developer] 23 Feb, 2017 @ 7:23pm
You are getting 100% CPU load because the CPU is not stalling and waiting for GPU. But you are getting better performance because it uses less cycles to generate rendering commands on Vulkan. That's completely logical.
You are not seeing additional core performance because we haven't implemented native multithreading on Vulkan in that build yet. We have that in the works, but it is not yet ready for release. So your Vulkan and OpenGL are running same threading engines for now."

and

"But nowadays, most games are more limited by CPU overhead. Hence Vulkan."

So even single threaded Vulkan is much more efficient than OpenGL. I guess DX11 performance might come single threaded Vulkan close.

View this comment - View article - View full comments