I remember playing a free-to-play antigrav racing game when I was a kid (around 2006-2007). This one reminds me a lot of it.

View this comment - View article - View full comments

Quoting: GuestI used this kind of tricks to play Rise of the tomb raider at 48hz, but the input latency was so bad that i opted for 75hz instead.
Can't even imagine the feeling with a FPS.

BTW, since the deck uses Wayland, things are not so easy like with xorg and a custom EDID has to be crafted and loaded at boot by modifying the kernel command line.
https://github.com/kevinlekiller/linux_intel_display_overclocking [External Link]
(skip the xrandr part ofc)

I didn't know the Steam Deck's display could be overclocked. It's an interesting avenue for those retro games running at 35 or 70 FPS (and without source ports that support arbitrary framerates).

View this comment - View article - View full comments

By the way, I had the opportunity to interview the studio about Lumencraft's development with Godot: https://godotengine.org/article/godot-showcase-2dynamic-games-lumencraft [External Link]

View this comment - View article - View full comments

Quoting: elmapulcan this trick be used to apply FSR on one viewport (the 3D one) while ignore it on the other?
[edit]
actually you just said its possible, but have you tried?

This is already how it works – the `scaling_3d_scale` property will never affect 2D rendering, as its name implies.

View this comment - View article - View full comments

Quoting: elmapul

Quoting: somebody1121I hope they release the source code soon so godot 4 can add this (Although it need some TAA implementation first for the motion vectors)

i dont think they have enough man power for that, it would only delay vulkan, i think they will focus on deliver vulkan on 4.0, bring back openGL at 4.1, and those extra features either will go at =>4.2x or 5.0x.

TAA is being implemented in Godot 4.0 as we speak! There's not much to show yet, but this means motion vectors will be available for FSR 2.0 to use (and/or XeSS, depending on whether it goes open source in a timely fashion). These motion vectors will also be useful for a motion blur implementation in the long run.

MSAA and FXAA will remain available, with SMAA potentially being implemented in the future for high-quality post-processing spatial antialiasing.

Quoting: elmapulone thing i think they could implement though, that shouldnt require too much effort to add is some form of rendering the text in a different render contex so FSR 1.0 could work on everything else from the game, then you render the text as the last step in an higher resolution instead of upscaling it.
(something like an text overlay on top of the game render.)

This is indeed what Godot 4.0 does if you reduce the `scaling_3d_scale` project setting/Viewport property below 1.0 :)
It can also be set above 1.0 for supersampling if you have the GPU power to spare.

This can be done in Godot 3.x too with a two-Viewport setup: https://github.com/godotengine/godot-demo-projects/tree/master/viewport/3d_scaling [External Link]

View this comment - View article - View full comments

Quoting: HythlodaeusThis game is good, but I feel the devs are torturing themselves at this point by continuing to use the doom engine. There's so much impractical hacking to make this thing work it would be much much simpler at this point to switch to a proper open source 3d engine like Darkplaces or even Q3. For instance, the game still doesn't have working loops because the engine's (lack of) physics do not support them at all. It's also permanently capped on 35 FPS because of similar reasons.

Doom source ports generally have more complete modding documentation than Quake source ports do.

Also, uncapping the framerate would be possible if Doom Legacy supported physics step interpolation (like GZDoom and PrBoom+ do).

View this comment - View article - View full comments

After testing various launchers and games that use extra screens, Gamescope that handles the display of windows gets confused and madly flicks between them.

This seems to be a widespread problem with games/apps that use some kind of launcher or multi-window functionality in general. Godot suffers from the same problem when running a project from the editor too, since a separate process (and window) is spawned for that purpose. I wonder if Valve could do anything about it, but it might not be possible without lowering performance (since I assume the Steam Deck's single-window paradigm is here for a reason).

View this comment - View article - View full comments

Cube recently celebrated its 20th anniversary! Someone made a page that hosts the very first version available (no Linux binary, but runs well in WINE): http://cubeengine.com/forum.php?action=display_thread&thread_id=2763 [External Link]
I only played the last Cube release (20050829) before trying out the first version, so it's interesting to see how it evolved over time. It's interesting to note that the old shotgun sound is very similar to the super shotgun sound currently used in Freedoom: Phase 2.

Fun fact: In February 2022, the game's source code was relicensed to Zlib [External Link] (after using a modified Zlib license that made it GPL-incompatible.

View this comment - View article - View full comments

Judging by the article name, I thought it was going to be about the first-person shooter SiN. :P

View this comment - View article - View full comments

Quoting: BogomipsJust tested it for 5 minutes, still stuttering for me. I think less than before with a good FPS gain but still not acceptable in competitive.

Getting rid of stutters typically requires playing a full game on all maps, ideally against human players who use agent skins (instead of bots which never use them).

View this comment - View article - View full comments