Looking Glass: Run a Windows VM on Linux in a window with native performance • Hacker News Board

Re: Looking Glass: Run a Windows VM on Linux in a window with native performance

#271

Post by KronisLV » Sun, Jul 18, 2021, 9:32 PM UTC

tester756 wrote: post #216

KronisLV wrote: post #170

Earlier quoted context omitted.

You can definitely handle some of those situations server side (the key word being "some") with enough engineering effort. In regards to player positions: check which player locations are occluded and wouldn't be visible through the geometry, then only send the valid ones for each player. Of course, doing this on high tick servers could prove to be computationally intensive. In regards to aimbots: the clients already…

>Attach some mouse movement metrics and from that you'll sometimes be able to infer the most naive aimbots instantly. see? even you do not believe that this will work

Of course I don't believe that it'll work 100% of time time, since nothing will.

Fighting against cheating in online games is going to be a constant arms race.

That's not to say that detecting most of the naive implementations isn't worthy of the effort.

It won't always work consistently but it should be pretty obvious when someone is lerping between two quaternions. Then, you can build upon that and attempt to detect small bits of random noise that'd be applied upon said interpolation and go from there.

Re: Looking Glass: Run a Windows VM on Linux in a window with native performance

#272

Post by KronisLV » Sun, Jul 18, 2021, 9:45 PM UTC

Macha wrote: post #193

KronisLV wrote: post #170

Earlier quoted context omitted.

You can definitely handle some of those situations server side (the key word being "some") with enough engineering effort. In regards to player positions: check which player locations are occluded and wouldn't be visible through the geometry, then only send the valid ones for each player. Of course, doing this on high tick servers could prove to be computationally intensive. In regards to aimbots: the clients already…

> In regards to player positions: check which player locations are occluded and wouldn't be visible through the geometry, then only send the valid ones for each player. Of course, doing this on high tick servers could prove to be computationally intensive. What's your tolerance on this? Too low and players will complain that other players pop into view and kill them in the event of latency. Too high and cheaters stil…

A few approaches to consider:

  1) be fair and decide upon some value that should cover most cases, make the outliers suck it up, like some games kick those with higher pings
  2) don't be fair and base the threshold of visibility on some predictions about the movement of the entities in the following ticks, based on their probable movement speeds, as well as the ping times of the each player; the player with the higher ping value might receive the position of the other about 10 frames earlier before they round a corner - imperfect, but should still avoid ESP across the map
  3) don't be fair, base this tolerance on hidden metrics about how trustworthy each of the players is considered, based on whatever data about them you can get, a bit like hidden ELO - you can probably game or abuse this system with enough effort, but it shouldn't make a difference in the lives of most legit players, since it shouldn't matter whether a model that you're about to see was rendered 5 or 10 frames before you actually did
  4) enforce regional matchmaking by default and only show servers with acceptable ping times for your system (if any at all)

As for RTS games, that should be even simpler - most have some sort of a fog of war mechanic. Given that, you could probably come up with some data structure to represent everything that's visible to your side (like an octree) and send all of the models within it, without worrying about checking individual positions.

As for warping: the exact same way as in any online game, probably by some interpolation. If you receive a position from the server, the entity should be visible at a certain position, if you do not, then it shouldn't be visible (or maybe send the position in which it should disappear, with an additional flag). If you don't get the data for a while, handle it however you would stale data - like ARMA 3 does with entities just standing around or other games with them running in place, which is pretty funny.

Re: Looking Glass: Run a Windows VM on Linux in a window with native performance

#273

Post by CyberDildonics » Sun, Jul 18, 2021, 9:48 PM UTC

chrisseaton wrote: post #266

CyberDildonics wrote: post #258

Earlier 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.

> 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 rendered

What does this even mean? What is "it" here and what is a "render node" ? There are hierarchies of transforms and players are going to be separate from the environment. This doesn't actually mean anything.

> it's just obscured by closer geometry. And it's how some cheats actually work - they basically turn the wireframe back on!

Yes, you are restating the context of what people are talking about, not what is actually being talked about, which is the timing of when the server should send visibility information, which is what your link is actually about.

Your link is actually directly contradicts what you are saying since it uses both an expanded bounding box based motion extrapolation and precomputed visibility, neither of which has anything to do with a z-buffer.

Re: Looking Glass: Run a Windows VM on Linux in a window with native performance

#274

Post by Cyph0n » Sun, Jul 18, 2021, 9:52 PM UTC

j1elo wrote: post #183

Cyph0n wrote: post #135

Earlier quoted context omitted.

Same setup here! I am running Proxmox on the host to streamline managing VMs and storage. Proxmox comes with a nice web GUI, which makes it very east to monitor system state. I have a Windows VM for gaming that owns the single Nvidia GPU. I also have a few Linux VMs for development (via VS Code remote) and media management. As far as storage goes, I don’t have anything too fancy. Proxmox is installed on an SSD. I hav…

Would you mind talking a bit about the small decisions you took for a Proxmox setup? I am slowly learning and planning my (very)small server setup. Things like: * Are the VM image backups you mentioned, done to your pool by means of the ZFS snapshots? Or done at the file-level with rsync or similar. * Do you make backups of the Proxmox installation? Similar as before: is Proxmox itself on a ZFS volume, so backups can…

1. In my case, VM image SSDs are formatted using LVM-Thin. Based on this, Proxmox automatically takes care of snapshotting the VM images for backups. It would work the same if you used ZFS for image storage.

2. No, I do not currently backup the Proxmox config. There is a good script here: https://github.com/DerDanilo/proxmox-stuff

3. If you install Proxmox on a "thin" filesystem (ZFS or LVM-Thin), then yes, you will get snapshot functionality for free. Note that you would have to configure this yourself - Proxmox does not expose a backup feature for its own config.

4. I have two NVMe SSDs. The first is 500GB and is split into two partitions: 100GB for the Proxmox install (LVM + ext4), and 400GB for VM images and containers (LVM-Thin). The second is 900GB and is fully used for VM images. Both are using LVM.

Re: Looking Glass: Run a Windows VM on Linux in a window with native performance

#275

Post by CyberDildonics » Sun, Jul 18, 2021, 9:54 PM UTC

chrisseaton wrote: post #267

CyberDildonics wrote: post #257

Earlier quoted context omitted.

Why would that be necessary? You realize the server already has to do a line of sight calculation to determine if a shot hits right?

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 rendering the game to do it. It is literally demonstrating that they are already doing what people were wondering about.

Re: Looking Glass: Run a Windows VM on Linux in a window with native performance

#276

Post by j1elo » Sun, Jul 18, 2021, 10:19 PM UTC

Cyph0n wrote: post #274

j1elo wrote: post #183

Earlier quoted context omitted.

Would you mind talking a bit about the small decisions you took for a Proxmox setup? I am slowly learning and planning my (very)small server setup. Things like: * Are the VM image backups you mentioned, done to your pool by means of the ZFS snapshots? Or done at the file-level with rsync or similar. * Do you make backups of the Proxmox installation? Similar as before: is Proxmox itself on a ZFS volume, so backups can…

1. In my case, VM image SSDs are formatted using LVM-Thin. Based on this, Proxmox automatically takes care of snapshotting the VM images for backups. It would work the same if you used ZFS for image storage. 2. No, I do not currently backup the Proxmox config. There is a good script here: https://github.com/DerDanilo/proxmox-stuff 3. If you install Proxmox on a "thin" filesystem (ZFS or LVM-Thin), then yes, you will…

Seeing how others have organized their systems helps me with doing my own thing. Thanks a lot for sharing!

Re: Looking Glass: Run a Windows VM on Linux in a window with native performance

#277

Post by throwaway2048 » Sun, Jul 18, 2021, 11:48 PM UTC

genewitch wrote: post #262

throwaway2048 wrote: post #104

Earlier quoted context omitted.

Not really a problem, you can unbind the VFIO driver

> linux /vmlinuz-5.10.27-gentoo root=/dev/nvme0n1p2 ro amd_iommu=on iommu=pt pcie_acs_override=downstream,multifunction pci-stub.ids=10de:1b82,10de:10f0 the host never sees the card.

thats using the pci-stub driver, not VFIO

Re: Looking Glass: Run a Windows VM on Linux in a window with native performance

#278

Post by gnif » Sun, Jul 18, 2021, 11:53 PM UTC

zbrozek wrote: post #200

lillecarl wrote: post #148

Earlier quoted context omitted.

I used to use looking glass (still sponsoring the project) but since my hardware is ancient I tried running the windows VM of a DVI to my monitor instead, and it's been so incredibly smooth along with Barrier ever since, with more horsepower I would probably go back to LG because of the convenience of being a regular window I can manage however I want.

This? https://github.com/debauchee/barrier Is the key feature clipboard sharing? Otherwise I don't know why I wouldn't redirect events with zero additional software. As-is, I press both ctrl keys and my keyboard and mouse switch to the virtual machine. The big nuisance is that I need to switch monitor inputs. That appears to be something I can automate, but simply haven't yet.

No, it's not. evdev forces you to have your keyboard/mouse either fully captured or not, which is a pain if you're just working with a productivity suite. With LG's SPICE client input is sent to the VM via the same channel that evdev does, but also gives greater control allowing us to keep the cursor in sync with the local cursor, making the VM feel as if it's just another application on your desktop.

Re: Looking Glass: Run a Windows VM on Linux in a window with native performance

#279

Post by virteverything » Mon, Jul 19, 2021, 12:29 AM UTC

aetherspawn wrote: post #155

I'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…

KVM? Virt-Manager? It might take an hour to learn virt-manager and some of its quirks, but it absolutely can do everything you request here, I do so very regularly.

If you want a low-maintenance version, you could just snag someone's NixOS config - you'd have an easy to reproduce environment that just ensures virt-manager and a really light-weight window manager are installed and then you're done.

Virt-Manager does shared directories (9p anyway; there's no UI for virtio-fs, but you can still use it by editting XML). It handles USB2 and USB3 forwarding. It does snapshots, it does clones, you can even leverage Linux filesystems to do far fancier things than possible on HyperV hosts. Etc. (Plus KVM won't trash your plain ole EXT4 partitions like countless people keep reporting under HyperV [and I've personally experienced twice]). It can even do graphics accceleration/virtualization for Linux guests.

Virt-Manager is so under-known and under-appreciated, but then again, it's got its rough-edges. With some polish there is really no reason to ever mess with VBox under Linux.

Re: Looking Glass: Run a Windows VM on Linux in a window with native performance

#280

Post by idonotknowwhy » Mon, Jul 19, 2021, 2:49 AM UTC

ac29 wrote: post #32

idonotknowwhy wrote: post #14

Earlier quoted context omitted.

Can rpcs3 do this for you?

The PS3 never supported 4K, so I dont see how its Netflix client would.

You're right. Wonder what would happen if you run it and tell rpcs3 to render in 4k