Marketing wise, is it wise to release a game you developed in house, for a hostile platform, and only then release it for "steam", OS? I mean I understand that they have no faith in other publishers. But WTF? Valve? It's your OS. If you want for it to make sense for people to install it, add some incentive!

View this comment - View article - View full comments

Dead Space. The first two games aged really well, and there’s still some achievements that I’d like to have. Thirdway through DS2 on Hardcore. The exploding necromorphs usually kill me out of the blue.

View this comment - View article - View full comments

Doesn't matter if it's good now. As long as it keeps getting better.

View this comment - View article - View full comments

AMD isn't perfectly secure. It's more secure. If there are fewer researchers for the platform because of obscurity, then there's going to be fewer people knowing about the exploit. That said, AMD should release the source for the PSP.

if you want more security than AMD, use something like RISC V, or Power. Sure finding binary blobs that work for them would be difficult, but in my view, you shouldn't be running software that you didn't personally compile on a compiler of your choosing if you are concerned with security to this level.

View this comment - View article - View full comments

Quoting: Guest

Quoting: Shmerl

Quoting: GuestThere's actually quite a lot of a video card that isn't used at any given time, so while adding some dedicated raytracing pathways may reduce area dedicated to other features, I don't think the impact is of the magnitude that you might be thinking.

If general GPU compute units can handle ray tracing - then fine, but apparently they aren't good enough for it (yet).

Indeed, and different vendor approaches to their compute units will definitely be worth keeping an eye on.

I'm of the opinion myself that despite nvidia pushing their own rtx extensions, eventually it will all collapse back into generic compute units in the end - maybe some differences to current designs to make them more efficient for raytracing type work, but compute units nonetheless.
That will make raytracing just be another software package, like Radeon Rays.

Another possibility is that the tensor cores become the new CUDA cores.

View this comment - View article - View full comments

Quoting: Liam Dawe

Quoting: appetrosyanDon't quite get what they gain from this. Still, this means that we could (in theory) have RTX accelerated Quake 2 on Linux.

We already do. That's the point. Quake II RTX is out and supports Linux.

Thanks! I hand idea. I would like to say that I'd give it a try, but I have an old rx 480.

View this comment - View article - View full comments

Quoting: vipor29

Quoting: appetrosyan

Quoting: vipor29im gonna be getting ahold of a rtx 2070 super,coming from a vega 56.plus upgrading to a 1440p display so this should be quite interesting testing this out.

Just out of curiosity, what made you go to 2070 over 5700XT?

how is the 5700xt in linux

Fine AFAIK.

Might not be perfect on Ubuntu, but even on an LTS installing a new kernel seldom presented problems.

The only edge I can think of that 2070 has over 5700xt would be Raytracing, but that doesn't work on Linux, and the fact that RTX 2070 was out far earlier than the AMD counterpart.

You do answer my question: launch day support seems to be more important than I thought...

View this comment - View article - View full comments

Don't quite get what they gain from this. Still, this means that we could (in theory) have RTX accelerated Quake 2 on Linux.

View this comment - View article - View full comments

Quoting: vipor29im gonna be getting ahold of a rtx 2070 super,coming from a vega 56.plus upgrading to a 1440p display so this should be quite interesting testing this out.

Just out of curiosity, what made you go to 2070 over 5700XT?

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: appetrosyan

Quoting: antisol

Quoting: scainethink about the end-game, which is perfect, seamless support for all Windows games, on Linux.

Firstly, that's not my end-game. I'm not particularly interested in running windows games on Linux. I'd rather have Linux games.

Secondly, the idea of having perfect, seamless support for all Windows games is a pipe dream that will never happen unless Microsoft opens up the relevant tech (directx, win32 api or whatever the modern equivalent is), which they will absolutely never do. Even if they did you're only going to get up tp ~95% compatibility. Without the specs (at least) for these techs being open it's always going to be a reverse-engineering effort where you're playing whack-a-mole with new versions of APIs. If you think that this is a reasonable goal you're just setting yourself up for disappointment.

You're not going to get perfect support for all windows games under wine. Not ever. This is the nature of emulation. 100% is not achievable, even with open specs and non-moving targets. Attempting it with windows is bold and commendable but ultimately futile and laughable. Wine can't even run the ~20 year old stuff that I want to run.

This comment highlights a common misconception that plagues all of these discussions.. For the LAST TIME, WINE = WINE IS NOT an EMULATOR.

Reverse engineering, can and often does work better than having access to the source code, provided enough dedication and good enough platforms: nblood vs blood fresh supply is a good example of a reverse engineered lovingly crafted engine doing better than a commercial port.

Wine can't run things that are 20years old, may be up to the projects themselves, and it's highly likely that windows 10 can't either. At this stage the only thing that does actually make more sense to do is to think of the distant future. Apple just deprecated 90% of all games that have a Mac version, because of stubbornly removing 32-bit libraries. A similar thing can and might very well happen on Windows, and on Linux, we have averted the catastrophe once, we can avert it again. I'm positive that at some point, the libraries will be deprecated so badly that we'll simply be bundling them as part of retro gaming, much like we do now for the 8/16 bit stuff. This, you will never be able to do, if you've never ventured into emulation.

A pipe dream it might be, but I'm happy with the vertical slice of games that can reliably be played through wine. I'm also a bit unhappy with the state of "native" games with proprietary licenses.

Actually wine can and does run 20 year old games better than Windows 10 can. Because in wine you can actually set the version of Windows you wish to pretend to be (also known as emulation, but I know it isn't emulation, it is a compatibility wrapper, much like Glide is a wrapper for the 3Dfx API into OpenGL.)
Wine, the great Pretender!

Quoting: slaapliedje

Quoting: appetrosyan

Quoting: antisol

Quoting: scainethink about the end-game, which is perfect, seamless support for all Windows games, on Linux.

Firstly, that's not my end-game. I'm not particularly interested in running windows games on Linux. I'd rather have Linux games.

Secondly, the idea of having perfect, seamless support for all Windows games is a pipe dream that will never happen unless Microsoft opens up the relevant tech (directx, win32 api or whatever the modern equivalent is), which they will absolutely never do. Even if they did you're only going to get up tp ~95% compatibility. Without the specs (at least) for these techs being open it's always going to be a reverse-engineering effort where you're playing whack-a-mole with new versions of APIs. If you think that this is a reasonable goal you're just setting yourself up for disappointment.

You're not going to get perfect support for all windows games under wine. Not ever. This is the nature of emulation. 100% is not achievable, even with open specs and non-moving targets. Attempting it with windows is bold and commendable but ultimately futile and laughable. Wine can't even run the ~20 year old stuff that I want to run.

This comment highlights a common misconception that plagues all of these discussions.. For the LAST TIME, WINE = WINE IS NOT an EMULATOR.

Reverse engineering, can and often does work better than having access to the source code, provided enough dedication and good enough platforms: nblood vs blood fresh supply is a good example of a reverse engineered lovingly crafted engine doing better than a commercial port.

Wine can't run things that are 20years old, may be up to the projects themselves, and it's highly likely that windows 10 can't either. At this stage the only thing that does actually make more sense to do is to think of the distant future. Apple just deprecated 90% of all games that have a Mac version, because of stubbornly removing 32-bit libraries. A similar thing can and might very well happen on Windows, and on Linux, we have averted the catastrophe once, we can avert it again. I'm positive that at some point, the libraries will be deprecated so badly that we'll simply be bundling them as part of retro gaming, much like we do now for the 8/16 bit stuff. This, you will never be able to do, if you've never ventured into emulation.

A pipe dream it might be, but I'm happy with the vertical slice of games that can reliably be played through wine. I'm also a bit unhappy with the state of "native" games with proprietary licenses.

Actually wine can and does run 20 year old games better than Windows 10 can. Because in wine you can actually set the version of Windows you wish to pretend to be (also known as emulation, but I know it isn't emulation, it is a compatibility wrapper, much like Glide is a wrapper for the 3Dfx API into OpenGL.)
Wine, the great Pretender!

While that is mostly true there are some exceptions. My point was that even conceding that Wine cannot do more than Windows, then it is still a valuable asset!

View this comment - View article - View full comments