Quoting: gustavoyaraujo

Quoting: KohriasMight help these console amateurs to get a bit better :) Does not even come close to keyboard + mouse.

You are wrong. I played a lot of ranked games in Dota 2 before and a lot of other players recognized me as a good player.

Well to be honest that only tells that you are good, not that this is actually better than keyboard+mouse. We could put sandals on Zlatan Ibrahimovic and he would still run rings around most football players.

View this comment - View article - View full comments

Back when it was in a Humble Bundle I created a Swedish translation for it: https://drive.google.com/file/d/0BwqAKhyY0V1OX25XQk1mUVZaRnM/view?usp=sharing [External Link] if anyone would be interested :)

View this comment - View article - View full comments

Quoting: ArehandoroFrom a very ignorant point of view. Why start VKD3D-Proton instead of expanding VXDK to use D12 too? Is the difference in APIs between D11 and D12 so big that a different project needs to implemented?

Don't quote me on this but AFAIK the difference between DX11 and DX12 is akin to the difference between OpenGL and Vulkan.

View this comment - View article - View full comments

Quoting: gustavoyaraujo

Quoting: F.Ultra

Quoting: gustavoyaraujoWhy don't do something like anticheat-dkms and live it open source to talk to the EAC and other softwares like that?

Well, I'm not an expert, but this makes sense.

They don't want to show people what and how they are looking at so they cannot go the open-source kernal module route. In reality there is no way that they can hide this anyway in their current Windows version but they like to pretend that they do (lot's of enterprises likes to pretend that their closed source nature hides things, which it doesn't).

I see, but what I mean is just some kind of opensource middleware to be implemented in the kernel as a module to let them use their anticheat solution.

Then you have a module that just gives any software on your machine root-kil level access to the inner works of your kernel and also honestly it IMHO doesn't matter if that module is open or closed since "whatever EAC will do in your kernel" is closed source anyway.

They could of course make it open source dkms just to be able to build it for a wide variety of kernels of course if that was the problem to solve (just realised that perhaps that was what you meant).

View this comment - View article - View full comments

Quoting: gustavoyaraujoWhy don't do something like anticheat-dkms and live it open source to talk to the EAC and other softwares like that?

Well, I'm not an expert, but this makes sense.

They don't want to show people what and how they are looking at so they cannot go the open-source kernal module route. In reality there is no way that they can hide this anyway in their current Windows version but they like to pretend that they do (lot's of enterprises likes to pretend that their closed source nature hides things, which it doesn't).

View this comment - View article - View full comments

Quoting: TheSHEEEP

Quoting: g000hDon't think your point holds weight *because* cheating is easy on Windows. Almost all the cheating tools are built to work on Windows. It would be harder for me as a Linux gamer to find cheats to use on Linux. Sure, someone could make Linux better for cheating, but the status is that it isn't a great cheating platform unless you build the cheats yourself rather than take advantage of all the cheats already built for Windows.

You are confusing cause and effect.
That you can find more cheats and tools for Windows is exclusively down to the fact that 99% of gamers are on Windows. Writing some tools to edit hex values while a game is in RAM isn't easier on Windows, it's the same on pretty much any platform.
Same with editing game-specific dynamic libraries, inspecting/inserting network packages, and all the other ways to cheat.

It just wouldn't make sense to write some cheating tool for Linux as it wouldn't really be used by anyone. There already aren't too many gamers on Linux, and (potential) cheaters are an even smaller subset of that.

The same logic adheres to WINE, WINE is not doing magic so whatever WINE can do to bypass EAC on Linux, the cheaters can already do to bypass EAC on Windows.

Also AFAIK this is just WINE enabling the Windows version of EAC to work on WINE, what are the evidence that this will allow Linux gamers to bypass EAC (and bypass it easier than Windows gamers already can)?

View this comment - View article - View full comments

Quoting: Eike

Quoting: ShabbyX

Quoting: x_wing$ man poll
$ man select
```
That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

And more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.

I guess that somewhat answers the question I would have asked:
Poll and select seem to be all about files, while...

The WaitForMultipleObjects function can specify handles of any of the following object types in the lpHandles array:

Change notification
Console input
Event
Memory resource notification
Mutex
Process
Semaphore
Thread
Waitable timer

This still sounds useful to me.

And out of that list it's mostly mutexes and semaphores where Linux is lacking (most of the others on that list have an equivalent and thus can be used with epoll). And being able to wait for a mutex or a semaphore with epoll would have been a very nice addition, BSD have kqueue where you can wait for both fd:s, signals and mutex/semaphores with the same function and it existed before epoll so quite a large number of people are upset that Linux went with their own API that had less functionality (that said I do prefer the API of epoll over kqueue, just the functionality that is lacking).

In the end it just means that you as a Linux developer write your application in a different way than what you would have done on Windows or BSD so the major problem comes with things like WINE since they have to support the WIN32 interface.

edit: It also have to be said that this patch does not solve the "listen to both fd:s and other stuff with the same interface" since it just implements a way to listen to several FUTEX:es at the same time.

View this comment - View article - View full comments

Quoting: Code ArtisanWhen i wanted to implement my own threading API on linux a few years ago, i found out that there were no system procedure to pause or resume a thread from another thread unlike Windows. You had to use signals for that and it was really messy.

Suspending threads comes with so many caveats that on platforms there they do exits (i.e Windows) they are marked as not to be used by anything other than debuggers really, and you are instead referred to use the same kinds of thread to thread syncronization that you have on i.e Linux such as e.g condition variables.

View this comment - View article - View full comments

Quoting: Zlopez

Quoting: CatKiller

Quoting: ZlopezSo if I am white heterosexual I can celebrate the pride month?

Why wouldn't you?

Because I didn't saw anyone in the LGBT... happy, if I say I'm proud white heterosexual. For them I'm racist embracing the culture of enslavers, or at least this is what I see in most media today. People being banned or have to resign from organizations if they take this stance.

But I don't need any special month to be proud about myself. For me it's funny that somebody even needs this :-)

Please link to some of these news items of today where a person have been forced to resign from an organisation due to "being proud of being a white heterosexual".

View this comment - View article - View full comments

Quoting: CatKiller

Quoting: F.UltraJust guessing here since I'm #1 not a Windows dev and #2 not a Game dev, but this could be due to some high hopes optimizing since the library calls perform some sanity checks and massaging of the data that you send in so a direct syscall is some ns faster.

Me either, but historically there have been some really elaborate things done with games because you really need the performance - timing your game output by where the CRT electron beam is, for example - and you're optimising for that rather than maintainability. On a console it's probably (relatively) legit (and probably took quite a lot of work), since you've got limited hardware configurations and a fixed software environment, any changes to your assumptions come with a whole other console, and if the performance isn't quite there you can't tell your customers to simply buy a better computer. It's not legit when you don't know the hardware, you don't know the software, and all your assumptions can be completely ruined by an OS update, or driver update, or any number of other things that can happen without warning and completely out of your control.

Oh yes, timing to CRT electron beam is something that I did extensively do in the 80:ies and 90:ies but I don't think that even is a thing with consoles released in the last decade. Regardless it does fit as an example anyway, I did write that they where "crazy" :-)

View this comment - View article - View full comments