Looking Glass: Run a Windows VM on Linux in a window with native performance
281–290 of 312 posts
Re: Looking Glass: Run a Windows VM on Linux in a window with native performance
#282Earlier quoted context omitted.
The anti-cheat systems end up really just being more menance than use. Tons of money burned on something that cheaters will get around anyways.
It's one of those 'keeping honest people honest' things, of it were even easier I think even more people would do it?
The problem is that developers treat PC like a locked console. This is just a completely fruitless uphill battle. PC gives power to its users, while consoles give power to the developers. PCs are designed to not sandbox or lock you, you can do anything with them without having to break its sandbox first. The mindset with the developers that deploy intrusive anti-cheat is to have the users locked in so they can ship their centralized server model and hope they can deal with the hopefully lesser amount of cheaters themselves, instead of giving the moderation power to the users themselves.
Re: Looking Glass: Run a Windows VM on Linux in a window with native performance
#283Earlier quoted context omitted.
Flipping between OS wasn't how I used VFIO. I had two different OS running on two monitors and both having access to underlying Linux shell. Basically it's not worth setting up VFIO just for gaming, but if you already on top of that mountain, then use whatever. I stopped using VFIO a while back and just bought a laptop that runs Linux without any issues. I don't really have time for games now, but if I wanted to play…
I would argue it's very much worth it just for gaming, now I get to everyday run an os I like and spin the windows vm up whenever I wanna play overwatch. Now that I'm on NixOS it was literally just a couple Nix lines and it's configured forever. (if on NixOS stable it doesn't break all the time, but you also have 6m+ old packages)
Re: Looking Glass: Run a Windows VM on Linux in a window with native performance
#284I'm an engineering software contractor and every client has a whole bucket load of outdated IDEs and random USB interface drivers they want me to install on my machine. Often this stuff has weird specific version dependencies, kernel level drivers that cause weird things to happen (like the computer to BSOD if you boot it up with other USB devices attached), random system level crashes, and when you go to the driver…
why don't you require clients to provide a lab machine for all their requirements?
I just build the price of the hardware into my hourly rate (which ends up being not very much .. $2 per hour), AU law instant write-off the cost of the machine as tax, tell them they don't need to buy a machine (which they are very happy about), and then everyone is surprised at how fast I can get the job done compared to the in-house teams which have their hands tied.
Re: Looking Glass: Run a Windows VM on Linux in a window with native performance
#285Earlier quoted context omitted.
The blurb at the top says "allows the use of a KVM [...] without an attached physical monitor, keyboard or mouse." Is that not correct?
I mean it behaves like a software KVM, at which point you can use a hardware KVM without the added latency penalty due to memory copy....
In nutshell, KVMs aren't worth their money because they have to re-implementing a lot of hardware already found in your PC.
Re: Looking Glass: Run a Windows VM on Linux in a window with native performance
#286Earlier quoted context omitted.
> Why do you think that? The server needs to at the very least trace a line for a shot. There is nothing difficult or slow about that. Before you say that it is done with a z-buffer or something similar, think about third person camera angles or how older games did the same thing. You might want to pull back on being so certain if you don't have experience with game engines or graphics. But... it is done with a z-buf…
You are conflating needing information about player position with visibility of individual polygons. Also you are forgetting that you just said that line of sight was done in hardware and you didn't explain how that would work for a server testing if shots actually hit. > You can see this for yourself if you look at a game being run with wireframe rendering. You'll see it's in the same render node so it's still rende…
Can you see how the red outline of the opponent appears while they're obscured behind the pillar?
When that red outline appears it's showing that the opponent is now being rendered, and that the z-buffer is being used to obscure them from behind the pillar.
This discussion is about how to make the red outline not appear until the opponent is actually visible.
The article goes into lots of ways to make the red outline appear later, but it still appears before the opponent is actually visible on screen.
That's the issue that people want to solve.
Consider an example of an opponent with just one pixel of their gun visible around a corner. How do you send that information to the client without telling them there's an opponent there, so that the user has to actually see the pixel? You'd have to just send that one pixel, right? Now we're talking about rendering server-side!
Re: Looking Glass: Run a Windows VM on Linux in a window with native performance
#287Earlier quoted context omitted.
Think about many times a second you have to trace a shot. Now think about how many times a second you'd need to trace from every pixel on the screen to every part of the geometry on every opponent in order to check if it was visible or not to see if a player was legitimately able to view any part of their opponent. For example read this article someone else linked https://technology.riotgames.com/news/demolishing-wal…
If you actually understood your own link you would see that there is no reason to trace every pixel on the screen when you can make a bounding box that covers motion and trace the vertices. Anyone familiar with game engine programming would never consider what you are saying. That link is a more in depth version of what I just said, ray casts are being done on the server for visibility and have nothing to do with ren…
Using an over-approximation causes the opponent's location to be revealed to the client even when the opponent isn't quite on screen yet, requiring the client to be trusted to not show this information early, which is what people in this thread want to avoid.
That's the whole point of the discussion.
This is what the article is showing - can you see how the red outline of opponents appears early, and how the client is being relied upon to hide them until they're actually visible? That's what people don't want.
Re: Looking Glass: Run a Windows VM on Linux in a window with native performance
#288Earlier quoted context omitted.
I would argue it's very much worth it just for gaming, now I get to everyday run an os I like and spin the windows vm up whenever I wanna play overwatch. Now that I'm on NixOS it was literally just a couple Nix lines and it's configured forever. (if on NixOS stable it doesn't break all the time, but you also have 6m+ old packages)
Litmus test for these kinds of things is - would you set this up for a family member in another part of town? I wouldn't. And I used Nixos too.
Re: Looking Glass: Run a Windows VM on Linux in a window with native performance
#289Re: Looking Glass: Run a Windows VM on Linux in a window with native performance
#290Earlier quoted context omitted.
Yes, I am :)
Also thanks for opening an account outside your community (here) just to help people. Also, didn't know that any 4 letter usernames were available here on HN anymore :)