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

Wonder what the fix for Splinter Cell Blacklist is, cannot find any closed bugs for it on their github.

View this comment - View article - View full comments

Quoting: CatKillerI'm not sure why this didn't occur to me before.

Using system calls directly seems like a very silly thing to do with a Windows game, but that's not necessarily as true for an Xbox game. I think the developers that have done this will still get bitten by the support costs caused by the fragility of their chewing-gum-and-string coding method, but it might not be as insane as it might first appear.

So perhaps Quantic Dream have an Xbox version that they haven't released yet, or they found it easier to go PlayStation -> Xbox -> Windows for some reason.

Just 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. And there exists lots of projects like this one: https://github.com/JustasMasiulis/inline_syscall [External Link] that provides easy access to the direct syscalls under Windows.

I guess that based on how "crazy" some of the game devs can by sometimes when they read on some webpage that "do X for performance" then they just do it without thought. One such example was the guy that where porting some game to Stadia and complained about his spinlock behaviour on Linux: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723 [External Link] when the real and obvious answer was "don't use spinlocks in userspace, ever", but the dev had used them "for performance" when in the end it turned out that using the proper locks the performance was actually much better :)

View this comment - View article - View full comments

Quoting: scaine

Quoting: F.Ultra

Quoting: CatKiller

Quoting: elmapul"sidestepping the actual Windows API. "
how is that even possible?

So, again, just as I understand it from reading bug reports about a game I'm vaguely interested in rather than from any in-depth knowledge, most programs will use some kind of library when they need to make some system calls to make something happen - libc or ntdll.dll, say - but it's also possible to just make system calls directly: libc and ntdll.dll need to be able to make their own system calls, too, of course. Windows and Linux both use the same mechanism for this (I think it's a processor instruction and registers?) but they use different numbers in the registers: that is, they'll both have a system call number 12, but there's no reason for it to necessarily do the same thing. In fact, which thing gets done by each number changes between versions of Windows, so the developers doing this need to check the version of Windows and use a look-up table to generate their numbers.

Exactly this! on i386 you put the syscall number in the eax register and some other data in other registers depending on the syscall and then you raise the $80 interrupt. On x86_64 they implemented a pure syscall instruction on the CPU.

Here is an old "Hello World" example that calls the sys_write syscall (syscall 4) to write the "hello world" string to stdout and then it calls exit (syscall 1) to let the kernel terminate the "application" with a proper exit code.
 
.data
    s:
        .ascii "hello world\n"
        len = . - s
.text
    .global _start
    _start:

        movl $4, %eax   /* write system call number */
        movl $1, %ebx   /* stdout */
        movl $s, %ecx   /* the data to print */
        movl $len, %edx /* length of the buffer */
        int $0x80

        movl $1, %eax   /* exit system call number */
        movl $0, %ebx   /* exit status */
        int $0x80

Jesus, I'm getting wild, unwelcome flashbacks to the mid-80's and trying to learn 68020 assembler to get a simple text message scrolling smoothly across the screen! I got there, but I paid for that in blood and almost literal tears. Never again!

68020 assembler is a league of beauty and non-complexiness above i386 so you should actually feel lucky ;). I have a few hundred floppys with 68000 assembler code in the basement, don't know if they still are readable though...

View this comment - View article - View full comments

Quoting: CatKiller

Quoting: elmapul"sidestepping the actual Windows API. "
how is that even possible?

So, again, just as I understand it from reading bug reports about a game I'm vaguely interested in rather than from any in-depth knowledge, most programs will use some kind of library when they need to make some system calls to make something happen - libc or ntdll.dll, say - but it's also possible to just make system calls directly: libc and ntdll.dll need to be able to make their own system calls, too, of course. Windows and Linux both use the same mechanism for this (I think it's a processor instruction and registers?) but they use different numbers in the registers: that is, they'll both have a system call number 12, but there's no reason for it to necessarily do the same thing. In fact, which thing gets done by each number changes between versions of Windows, so the developers doing this need to check the version of Windows and use a look-up table to generate their numbers.

Exactly this! on i386 you put the syscall number in the eax register and some other data in other registers depending on the syscall and then you raise the $80 interrupt. On x86_64 they implemented a pure syscall instruction on the CPU.

Here is an old "Hello World" example that calls the sys_write syscall (syscall 4) to write the "hello world" string to stdout and then it calls exit (syscall 1) to let the kernel terminate the "application" with a proper exit code.
 
.data
    s:
        .ascii "hello world\n"
        len = . - s
.text
    .global _start
    _start:

        movl $4, %eax   /* write system call number */
        movl $1, %ebx   /* stdout */
        movl $s, %ecx   /* the data to print */
        movl $len, %edx /* length of the buffer */
        int $0x80

        movl $1, %eax   /* exit system call number */
        movl $0, %ebx   /* exit status */
        int $0x80

View this comment - View article - View full comments

Quoting: VundultDoes anyone know if this will work with non-steam games added to your library?

I have a hard time believing that they even could make that work.

View this comment - View article - View full comments