Quoting: Guest

Quoting: CybolicFor comparison, that's more than were ever released for the N64 (~300) and the Nintendo Wii U (~150) put together. Pretty nice launch already! :D

You've undershot a bit there, I could have sworn the Wii U had around 800 games :grin:

Anyways, I would expect this list to increase massively soon with WMA codec being worked on, exciting times ahead!

Yeah, it might be a bit undershot; I went by largest amount per region (JP/US/EU) to not count games released in all regions twice/thrice.

EDIT: Since we're all doing it:

VERIFIED:      94 games (4.97%)
PLAYABLE:      63 games (3.33%)
UNSUPPORTED:   14 games (0.74%)
UNKNOWN:     1719 games (90.95%)

Not a great ratio for me but I know most of the unknowns work on desktop so I'm not too concerned.

View this comment - View article - View full comments

For comparison, that's more than were ever released for the N64 (~300) and the Nintendo Wii U (~150) put together. Pretty nice launch already! :D

View this comment - View article - View full comments

Quoting: mmstickWhat ananicy does is only a fraction of what system76-scheduler is doing.

Quoting: Cybolic

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

Doesn't appear to be applying the background process priority to all background processes, or matching all descendants of a PPID and their descendants, descendants. It'd be easier to simply do

 
dbus-send --system --dest=com.system76.Scheduler \
    /com/system76/Scheduler \
    com.system76.Scheduler.SetForegroundProcess \
    uint32:${PID}

I added support for using the System76 Scheduler in my little script [External Link] now. Honestly, I don't see any difference in how it handles process groups in my limited testing, but it is a bit faster at changing the niceness levels.
Best of both worlds now :)

View this comment - View article - View full comments

Quoting: mmstickWhat ananicy does is only a fraction of what system76-scheduler is doing.

Quoting: Cybolic

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

Doesn't appear to be applying the background process priority to all background processes, or matching all descendants of a PPID and their descendants, descendants. It'd be easier to simply do

 
dbus-send --system --dest=com.system76.Scheduler \
    /com/system76/Scheduler \
    com.system76.Scheduler.SetForegroundProcess \
    uint32:${PID}

I've updated it [External Link] to better handle children of PPID and PID. I'm not aiming to handle the entire system with this, just the basic userspace processes to the extent that bash scripting allows without too much slow code. As for general background processes, that's what the limits.conf edit is for.

View this comment - View article - View full comments

Quoting: mmstickWhat ananicy does is only a fraction of what system76-scheduler is doing.

Quoting: Cybolic

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

Doesn't appear to be applying the background process priority to all background processes, or matching all descendants of a PPID and their descendants, descendants. It'd be easier to simply do

 
dbus-send --system --dest=com.system76.Scheduler \
    /com/system76/Scheduler \
    com.system76.Scheduler.SetForegroundProcess \
    uint32:${PID}

That would certainly be easier, yes :)

View this comment - View article - View full comments

Quoting: DebianUser

Quoting: Cybolic

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

Thanks, seems interesting.
I see it uses bspc command, does it require bspwm ? or it will work under mutter with bscp command installed ?

It very much depends on bspwm. If there's another tool that continuously prints out the WID when the focused window changes, it could be adapted, but I don't know of any.

View this comment - View article - View full comments

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

View this comment - View article - View full comments

This sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

EDIT: Seems that they're just giving a -5 nice value to the pid of the focused window and its parent processes, keeping track of those changes and setting them back to 5 when the foreground pid changes. This should be doable with a shell script :)

View this comment - View article - View full comments

Quoting: Solitary

Quoting: CybolicWhile I haven't had any use for FSR on my desktop, I can definitely see it being useful on a 7-inch screen with limited battery life! It wouldn't surprise me if some games even look better than native with a bit of that sharpening on the small screen.

Seriously doubt that with such a low resolution you will ever get better looking result, because the source resolution will have to be even lower and there just might not be enough information to upscale in the first place, definitely not with reasonable quality. With FSR being applied fullscreen you will also get all texts and HUD scaled, and just that will be noticable on its own (it is noticable when you apply FSR on 1440p using ultra quality preset => which effectively scales 1108p to 1440p). This will most likely be utilized for external monitors and some heavy games where people will accept the quality loss.
I can also imagine it being used in simple games where the scaling might not affect the quality much (some simple 2D games?) where it could possibly improve battery life.

I don't think you need to lower the game resolution in order to use the RCAS sharpening part of FSR.

View this comment - View article - View full comments

While I haven't had any use for FSR on my desktop, I can definitely see it being useful on a 7-inch screen with limited battery life! It wouldn't surprise me if some games even look better than native with a bit of that sharpening on the small screen.

View this comment - View article - View full comments