says “true variable refresh rate” support, is not true variable refresh rate support…
Well thats click bait and a half
says “true variable refresh rate” support, is not true variable refresh rate support…
Well thats click bait and a half
specific parts. you need metal to withstand the pressures of the actual bullet to get a somewhat degree of reliability, so any pressure bearing part needs to be metal, everything else can be plastic, but the more metal the better. Now you can get some more basic designs with parts that you could fabricate at home, but a lot of the higher end designs require off the shelf gun parts.
The “leading design” right now is the FGC-9 which is actually seeing a degree of use in myanmar(??). The design requires metal parts that could be feasible to fabricate at home. However it is shockingly easy, even in heavily restricted countries, to be able to order the metal parts.
we already have them. It’s not hard to make a firearm, and the 3d printed weapons scene has taken off quite well. all of the good ones still need metal parts ofc, but they are pretty easy to get your hands on in many cases.
I like both, airsoft does happen to be a whole lot cheaper though
Edit: Accidentally thought it was a Glock at first, my bad.
Sig boys are seething
not enough guns, needs a rifle and a shotgun at least.
Yes, there are open source firearms. there is even 3d printed designs for an MP5 the youtube channel Print shoot repeat showcases a lot of them.
Yep, I would say it’s the best we got. I have a 4K monitor at a 20% scale and it works great.
It’s not really hacky as far as I know, it’s just the old status quo. On X applications could scale themselves if they have high DPI support, and that’s what KDE is allowing. And it works great. The vast majority of apps I use support high DPI on X, and they work perfectly fine on xwayland.
It is legitimately a great experience using xwayland like this. A lot of apps I use, they look perfectly fine, they perform perfectly fine, and they’re not broken, which is a massive plus.
Of course, this probably does break one or two apps out there. I’m not saying it’s a perfect solution. It’s far from it. But honestly, I think it’s a really good solution. It allows developers the ease and flexibility of developing for X11 if you don’t need Wayland’s features.
Of course, you are still losing out. Having proper touch support is such an amazing feature with Wheland. Don’t get me wrong. I love a lot about Wheland. It’s just a pain in the ass to develop for. It is nowhere near as flexible as X11.
I haven’t had any stuttering issues myself, so I cant comment on that outside of “works for me”
This is understandable, and honestly xwayland is great, even with fractional scaling now, at the very least on KDE. I think simply relying on xwayland is a very viable solution now for a lot of apps. and it helps work around a lot of issues so that’s always a major plus
Ill say promising. Mesa recently landed sparse support so that should make a lot more games playable now, perf is decent but there are for sure still bugs, for instance for me and a couple others, gamescope doesn’t work right
i wish they had some kind of hotkey for it instead.
tried it, sadly it seems to rarely actually pop up, most sites I tried just didnt do anything
for anyone trying on a similar setup, Feel free to reach out on the bliss and waydroid matrix/telegram channels if you would like some more help. Blue archive JP seems to work fine under waydroid as a couple users report. and as for bliss, ping me (@Quackdoctech) in the telegram chat and we can work on trying to get nvidia to work. it seems hit or miss and we really need more nvidia users to help debug issues.
as for waydroid issues, It might be best to wait to see if the work on A13 will remedy the situation, but we shall see.
PS. I am the one who wrote qemu docs for bliss. also I highly recommend using the new bliss images, the Android 12L ones. not sure if OP is author, but if not feel free to try and forward it to them
This is not traditional VRR how we think of it. VRR how we think of it is changing the “frame rate” of the monitor to better suit the frame pacing of the received frames, this is not whats happening here. This is how things like freesync works. It takes your device framerate, say 60fps, and slows it down to better match the frame pacing of the content, say 48fps. Now the monitor doesn’t physically change states or anything, it just allows flexible updating to match the frame pacing.
You don;t get this with this adaptive refresh rate method
Here you are effectively getting a noop every refresh cycle it doesn’t need. It’s still good, but not as good as what most people think of as VRR (Freesync/vesa adaptivesync, gsync etc.). You are limited to the steps your display can output. For this to be useful you require a high refreshrate display like 120hz because each application needs to align with a frame refresh.
IE. say you have a 24fps video, the display won’t change it’s frame pacing, but rather you get a noop every 4 frames and a refresh, (24 * 5). Now assume you have a 90hz display, 24fps has no solid divisor in 90fps, so you have to either wait for sync, or get tearing. The first one leads to judder (which can probably be mitigated using offset sync waits?) the second one is well, tearing.