Programmer and sysadmin (DevOps?), wannabe polymath in tech, science and the mind. Neurodivergent, disabled, burned out, and close to throwing in the towel, but still liking ponies 🦄 and sometimes willing to discuss stuff.

  • 0 Posts
  • 119 Comments
Joined 2 years ago
cake
Cake day: June 26th, 2023

help-circle





  • game without [being exhausted of the] screen

    There is your answer: if screens exhaust you, do something without screens.

    Games are supposed to give you a good time, reinvigorate you, and prepare for your “real life”. If you’re sick of screens, then pick up pottery, or squash, or hiking, or skydiving, or cooking, or… thousands of activities out there to have a good time without a screen.

    having a huge backlog

    That’s work. Just don’t. Do stuff that makes you feel better, not just tick a box in a backlog so you feel slightly less bad.





  • What are you looking for?

    RTX 50 just dropped in, they’re in the “beta early adopter” phase, AKA expensive for people with more dough than smarts. They’re the same TSMC 4N process as the RTX 40, and unless you have a PCIe 5.0 motherboard, the RTX 50 makes little sense. No need to go to used market, but I’d personally stick to the 4060/4070 for the time being, or the Radeon RX 7600/7700.

    If you need some serious AI oomph… then go to the pro line, there are some nice RTX Ada for less than $10k, or rent some cloud H100s.


  • Yes… it will kind of depend on which layer of compatibility will a game require. Debian is Linux + GNU, which is what most people identify as “a Linux system”. Android uses Linux without GNU, but starting with Android 15 it will come with a VM (container?) system to run a GNU userland. Android can already run Linux distros via Termux, which can be set up to run a desktop, but having it by default will mean apps will be able to use it directly. I’ve just tested RetroArch on Android, with DosBox to run Windows 98… but that’s kind of a mindfuck of its own 😂. macOS is BSD, which shares the POSIX interface with Linux, but it does some things in a different way, however there is a GNU userland for BSD, so games using only that, can run on it already. WSL 2.0 is a full first-class VM with full Linux + GNU and a desktop interface that can coexist with Windows… since Windows 10/11 itself runs by default in a Hyper-V VM (the bootloader is Hyper-V).



  • The nice thing about Steam, is that it’s “too big to clamp down”:

    • People used to 🏴‍☠️ on the high seas, for many reasons.
    • Steam came up as a “single point of sale”, at the same time as Netflix was doing the same for movies and series.
    • Over time, companies tried to carve out chunks of the pie, restoring some of the original fragmentation…
    • …but while Netflix has been torn to shreds of its former glory, Steam is still the main “single point” for games…
    • …with a “single point” DRM

    Steam’s DRM only exists because game updates keep coming out with constantly updating DRM versions. The moment Steam tried to act against its clients, and they decided to leave Steam, every Steam game copy at that moment, would get cracked all at once.

    Maybe EA, MS, Nintendo, Sony, etc. don’t see that as a great thing… and that’s why they’ve been setting up their own stores… but I think it’s AWESOME! 😁




  • Because traditionally there were few Linux devices.

    Android 15 is going to change that: it comes with a virtual machine API and a Linux Terminal running Debian for ChromeOS compatibility.

    Soon, the most popular consumer OS in the world will be Linux:

    • 3.3 billion: Android / Linux
    • 2.2 billion: Apple iOS/macOS *NIX
    • 1.6 billion: Windows
    • 400 million: Windows 11 + WSL 2.0
    • 250 million: gaming consoles
    • “millions”: SteamOS Linux

    Wine might still make sense to keep things standardized for some time, and as a compatibility layer for older games, but native Linux games will also work on the Linux solutions for Android, Apple, and Windows.



  • Hm… good point… but… let’s see, assuming full parallel processing:

    • […]
    • Frame -2 ready
    • Frame -1 ready
      • Show frame -2
      • Start interpolating -2|-1 (should take less than 16ms)
      • Start rendering Frame 0 (will take 33ms)
      • User input 0 (will be received in 20ms if wired)
    • Wait 16ms
      • Frame -2|-1 ready
    • Show Frame -2|-1
    • Wait 4ms
      • Process User input 0 (max 12ms to get into next frame)
      • User input 1 (will be received in 20ms if wired)
    • Wait 12ms
    • Frame 0 ready
      • Show Frame -1
      • Start interpolating -1|0 (should take less than 16ms)
      • Start rendering Frame 1 {includes User input 0} (will take 33ms)
    • Wait 8ms
      • Process User input 1 (…won’t make it into a frame before User input 2 is received)
      • User input 2 (will be received in 20ms if wired)
    • Wait 8ms
      • Frame -1|0 ready
    • Show Frame -1|0
    • Wait 12ms
      • Process User Input 1+2 (…will it take less than 4ms?)
    • Wait 4ms
    • Frame 1 ready {includes user input 0}
      • Show Frame 0
      • Start interpolating 0|1 (should take less than 16ms)
      • Start rendering Frame 2 {includes user input 1+2… maybe} (will take 33ms)
    • Wait 16ms
      • Frame 0|1 ready {includes partial user input 0}
    • Show Frame 0|1 {includes partial user input 0}
    • Wait 16ms
    • Frame 2 ready {…hopefully includes user input 1+2}
      • Show Frame 1 {includes user input 0}
    • […]

    So…

    • From user input to partial display: 66ms
    • From user input to full display: 83ms
    • Some user inputs will be bundled up
    • Some user inputs will take some extra 33ms to get displayed

    Effectively, an input-to-render equivalent of between a blurry 15fps, and an abysmal 8.6fps.

    Could be interesting to run a simulation and see how many user inputs get bundled or “lost”, and what the maximum latency would be.

    Still, at a fixed 30fps, the latency would be:

    • 20ms best case
    • 53ms worst case (missed frame)

  • Motion smoothing means that instead of showing:

    • Frame 1
    • 33ms rendering
    • Frame 2

    …you would get:

    • Frame 1
    • 33ms rendering
    • #ms interpolating Frames 1 and 2
    • Interpolated Frame 1.5
    • 16ms wait
    • Frame 2

    It might be fine for non-interactive stuff where you can get all the frames in advance, like cutscenes. For anything interactive though, it just increases latency while adding imprecise partial frames.

    It will never turn 30fps into true 60fps like:

    • Frame 1
    • 16ms rendering
    • Frame 2
    • 16ms rendering
    • Frame 3