Quantum of Phallus posted:

Google are killing Stadia on Jan 18 if anyone was using that

GreenBuckanneer posted:

Got my deck

I want to sniff but I'm in a meeting

GreenBuckanneer posted:

Got my deck

I want to sniff but I'm in a meeting

fit em all up in there posted:

My steamdeck has been delivered

Heroic Yoshimitsu posted:

I put in my reservation for the Deck last week, and I got my purchase email today! Really quick turn around

Tweak posted:

my expected delivery has switched to PENDING and my deck has now exited my state

(pretty sure it's on a train)

GreenBuckanneer posted:

My vent doesn't make a smell 🙄

Anyways, how big is the initial update? Kind of dumb I can't use the deck without an internet connection to start

GreenBuckanneer posted:

My vent doesn't make a smell 🙄

Marx Headroom posted:

Antigravitas posted:

Guess you got a unit that was returned. You should RMA to get one with smell.

Super No Vacancy posted:

your thinking was it should produce a smell all the time and also let you download your steam games without internet?

Harlock posted:

Call of Juarez Gunslinger is pretty fun, glad I'm able to get back into it

eddiewalker posted:

Is the wifi on this thing just bad? I’ve got 3 unifi APs on the same SSID in the house, but the deck keeps trying and failing to connect to the one way down in the basement.

Detective No. 27 posted:

I found an old Windows laptop and got Wii U working.

I love emulation but I’ve become less inclined to pirate emulate a game if there’s a currently legal accessible version out there (or if there’s a huge benefit to playing an older version), so looking through the Wii U list, I’m shocked at how small the library really was. So far the only things I’m up for putting on Steam Deck are the three Zelda games (60fps for BoTW, right?), Xenoblase Chronicles X, and …Devil’s Third.

I also got Prime Hack working last night and that’s amazing. Legitimately Nintendo quality work there.

Detective No. 27 posted:

I found an old Windows laptop and got Wii U working.

I love emulation but I’ve become less inclined to pirate emulate a game if there’s a currently legal accessible version out there (or if there’s a huge benefit to playing an older version), so looking through the Wii U list, I’m shocked at how small the library really was. So far the only things I’m up for putting on Steam Deck are the three Zelda games (60fps for BoTW, right?), Xenoblase Chronicles X, and …Devil’s Third.

I also got Prime Hack working last night and that’s amazing. Legitimately Nintendo quality work there.

Opopanax posted:

Good news, Deck Heads, Vampire Survivors officially comes out next month

https://www.youtube.com/watch?v=07kmq5ULuOM

Opopanax posted:

Good news, Deck Heads, Vampire Survivors officially comes out next month

https://www.youtube.com/watch?v=07kmq5ULuOM

FishMcCool posted:

That looks fun. Has it been long in early access? Surely we'd have heard about it by now.

ExcessBLarg! posted:

I'm sure this information is useful to no one, but I was digging around the Gamescope source code trying to understand how vsync, frame limiting, and screen tearing all work on the Deck since it's a bit of a mystery. This is in part due to regular reports of input lag when using the frame limiter--not that I personally can tell the difference--and also claims that the frame limiter screws with emulators. So here's what I've figured out:

The Performance overlay enables the frame limiter in gamescope by setting the GAMESCOPE_FPS_LIMIT xprop (on the root window of xwayland display :0). For 60 Hz refresh, the possible values are 0 (off), 15, 30, or 60. The gamescope frame limiter used to be a fancy thing that would withhold buffers to minimize latency, but apparently xwayland caused problems with this and it got nuked. The new frame limiter does a simpler thing whereby it sends a (wayland) frame callback either every vblank (limiter set to either 0 or 60), or every other vblank (30), or every fourth (15). Note that the behavior of gamescope with regard to sending callbacks is the same whether the limiter is disabled or if it's set to the refresh rate (60). Also, this only works when games use vsync (a FIFO presentation mode in Vulkan, or a swap interval of 1 in OpenGL), which leads to:

When gamescope detects a change to the GAMESCOPE_FPS_LIMIT xprop, it writes out a value to a /tmp/gamescope-limiter.XXXXXXXXX file (set by the GAMESCOPE_LIMITER_FILE environment variable). The value is 0x00000000 if the frame limiter is disabled (GAMESCOPE_FPS_LIMIT=0) only, otherwise it is set to 0x00000001. Apparently, the Deck also ships with modified version of Mesa that effectively forces vsync when this value is 1, i.e., when the frame limiter is set at all even to the refresh rate, which makes sense since that's the only way this frame limiter implementation would work. As far as I can tell, the modified version of Mesa isn't open source? At least, I couldn't find the sources for it (not here or here). I'd assume this is an oversight? I mean, there's no reason gamescope has to be open-source either.

So, to summarize: frame limiter off" and in-game vsync off results in an uncapped frame rate. Turning the frame limiter on forces in-game vsync. Now, if you enable vsync in game, it shouldn't matter if the frame limiter is off or set to the refresh rate (60), everything else should behave the same.

How does this effect input latency? In Vulkan, "vsync" means to use a FIFO presentation mode and there's a queue (swapchain) of render buffers used for this. I didn't look too deeply at this, but the RADV driver might require a minimum of four buffers which would easily explain the increased latency over running uncapped (mailbox presentation mode--grab the latest rendered frame before scanout). One thing I've seen is the claim that using in-game vsync results in lower input latency than using the 60 Hz frame limiter, but the behavior of gamescope doesn't support this--they should be identical. That said, if the game has an internal frame limiter, turning that on, vsync off, and Performance-overlay frame limiter off, should have lower input latency.

What about screen tearing? The other main reason for turning vsync on in games (in Windows I guess) is to avoid screen tearing. Right now, the way gamescope commits frames to the kernel they won't tear regardless of vsync/frame limiting/running uncapped, etc. Recently, support was added to gamescope for asynchronous flips which could result in screen tearing as a trade for low latency, but this requires setting a GAMESCOPE_ALLOW_TEARING xprop and hasn't even hit the stable/beta branches yet. I assume if Valve decides to enable support for this it will be a toggle on the Performance overlay.

So one other thing: I started looking into this after reading claims that the frame limiter causes issues with emulators, specifically Dolphin. Normally I run emulators with vsync off since they're going to be frame capped to the emulated GPU/PPU rate anyways, but I don't think the frame limiter even works on Dolphin unless you enable vsync in the emulator. Again, without the Mesa code I can't confirm, but I think the patch to force vsync is only applied to render surfaces in the "main" window of the game, and Dolphin uses a secondary window for this. If you turn vsync off in Dolphin, you'll see that the frame limiter doesn't do anyhting.