Arm Accuracy Super Resolution
community.arm.com
community.arm.com
Predictably many of the high quality games in that category are ones which started their life on PC or consoles and were ported to mobile later. Mobile-first game development is rotten to the core.
How did this happen? I get that the average cell phone user is relatively easy to bilk, but it seems that the oasis's of honest fair games are incredibly sparse.
This is the issue that drove the rise of the mobile games as they are today.
Android users in particular were extremely reluctant to pay for games up-front.
> Last week I found myself in one of those "good news, bad news" situations. The good was that more than 100,000 people were enjoying the new Android version of our game. The bad news was that only about 10 percent of them paid for it
I am mystified. Why does the game install not include the current skins?
If you have to serve asset downloads yourself as a post install, making the total download smaller both improves UX and also saves you money on CDN costs.
To be fair they are limited to iPhone 15 Pro and M1 iPad or above which narrows the market a lot for now, but it still seems like a hard sell to developers and users without something changing. Controls and storage space alone are huge issues for users, Each of those three games take up more than half of a base 15 Pro on their own. For the price of a controller and 512GB iPhone you might as well buy an iPhone 15 Pro AND a Switch or Steam Deck which will have vastly more games and expandable storage to boot.
https://www.notebookcheck.net/Disappointing-AAA-game-sales-o...
For example, Tiny Wings was the number one iOS game in 2011 and cost two bucks.
In 2010, Plants vs. Zombies was a pay up-front iOS game that cost three dollars.
Today, PvZ is cross platform and free, but filled with Skinner Box nonsense.
(Yes, that's the actual design principle.)
Now instead, you find a way to get the amount of dollars a person can pay extracting cents from the people who used to pirate a game, and hundreds from those who have money.
It’s bad for the game, but great for the developers’ pocket.
EDIT: for example, Nintendo made 3.7B in 2023, King made 2.7B or so it seems. Nintendo is one of a kind, companies like King are a dime a dozen.
Meanwhile consider other consoles. Games are all the same price around $60. The cheap/simple games are like $15. The pricing supports different business models although certainly in recent years the $60 releases are falling prey to gambling mechanics and other dystopian decisions.
I also start to wonder if all that can still be called "entertainment" and "downtime", or if that becomes less and less the case. After all, they do fulfill a certain purpose for humans, and if that is not the case anymore it will have an impact on other parts of our lives.
They decided to commoditise their complement - why muck about with business partnerships and curation to produce a hundred $50-$70 games and lock out homebrew developers, when opening the floodgates lets you give your customers a wider selection and lower prices?
Hell, they probably imagined market forces or something would allow quality mobile games to sell for $50 via the app store, and that they were doing small developers a favour by not locking them out of the platform.
I doubt they knew, at the time, that they were going to be buried in micropayment casino mechanics and free-to-play, pay-to-win dross.
Is the outcome crap? Yes, 100%. But I can see how back in 2008 when Steam was in its infancy, PC game piracy was rampant, consoles locked out homebrew games and every PC software producer needed had to roll their own sales/payments/distribution/updates infrastructure if they wanted to get paid, they thought the design improved on the status quo.
Of course, that won't help with the control issues which I completely agree with.
I play "Doug Dug" almost every day. I played Pixa (same devs). I thought they did a great job of coming up with a way to make the game fun on touch. "Skiing Yeti Mountain" was great. "Planet Quest", "Severed", "Sword & Sworcery EP", many more.
https://www.notebookcheck.net/Apple-s-Metal-FX-upscaling-is-...
* Spatial - Inferring data from nearby pixels in a single frame (?) * Temporal - Inferring data from a point on previous and next frames
I guess this is super resolution in the statistical sense, rather than "AI super resolution" which would infer data from similar data in other photos/videos.
I'm surprised, I thought this was a dead area for research and AI super resolution had fully supplanted it. Are there any open source implementations of this, ex: for photography? I was digging into this a few years ago and all I could find was the commercial "PhotoAcute" which is basically dead but I somehow managed to get a key for and it... barely works.
So there's no way the technique or similar techniques can be used to upscale a single photo in isolation. However, conceptually it's similar to capturing a long exposure image of dark scene, like the night sky, to get a low-noise, brighter photo. Temporal super resolution accumulates information from rendered pixels over time, while a long exposure photo accumulates information from captured photons over time.
The larger problem to solve with these upscalers are temporal artifacts when using the above information. This lead to a number of heuristics, but if you train a neural network to do the work, it tends to perform better than the heuristics. There's still a ton of research going into non-ML solutions however, because the current console generation doesn't have AI-acceleration available, nor does a lot of hardware out there. So there's some longevity to be had by doing a good job for all that hardware out there.
There is no open source solution of the AI variant. There are currently only DLSS (Nvidia) and XeSS (Intel), and both are proprietary. The one open source solution is AMD's FSR (MIT license), which doesn't use machine learning. So naturally Arm and Apple build on FSR for their products instead of developing an AI solution from scratch.
Render resolution has been less tightly linked to display resolution for a long time, and some games have done that on different elements in a scene for a long time (I remember seeing it in Psychonauts from 2005). Variable Rate Shading is another tool developers have to pull resources away from areas it's not going to be noticed. What I've been wondering about for a while is what's the furthest a developer could push it to smartly spend performance instead of doing it on the full frame, how much effort does it take to hint to these systems that different elements are more or less important, and then compose them together in a way that doesn't have obvious flaws.
In other words—if GPUs were powerful enough to just push more pixels to the screen, then we would still use these upsampling techniques anyway, save a bunch of computational power, and then spend that computational power improving the graphics in other ways.
60fps on non-SD8 SoCs is going to sell more Play Store cards, and also co-incidentally more ARM licenses. Maybe it could also preemptively save Google Tensor before its public reputation points run out. Game players also gets better experience, but that's maybe entirely coincidental.
DLSS/XeSS allow dropping the pixel count and then reconstructing a satisfactory image, which means you can either cut power draw for near-equivalent quality, or use the newly available headroom to improve quality-per-pixel further or deliver higher framerates.
One dirty secret when it comes to mobile phones and tablets is that games were already rendering below native resolution - Apple basically told developers to do this in the early Retina era, since it wasn't feasible to render at native with good framerates - since it saves power and the screens are so high-res that most users won't be able to tell the difference.
I can't remember the last time I launched a game on my phone and it was actually rendering at native resolution. So in that context, techniques like FSR or this new upscaler are just replacing the existing bilinear/bicubic upscale filter.
We literally generate 30-60 pictures every single second. Every picture has information in it which combined gives you more unfaked information.
Your viewpoint doesn't change it's content every single frame. This only happens when you rotate super fast 180degree or warp through a portal or whatever.
We take the information from the previous frame and now have more information than before as long as it's the same object we render
That would have been worth first checking with a native English speaker.
We should probably worry why ARM feels it has to. If this was a great idea, game and game engine devs would have done it already.
"We are very proud of the results of this work and want to share it"
They want to share the work, not the results (otherwise the sentence would be "we want to share THEM").
As far as I'm concerned, on the end of a game developer, that should be a single checkbox in the project options, or something similarly easy to choosing between 2X and 4X AA, both on the desktop and mobile, where supported by the hardware (or simpler generic upscaling, if nothing else suffices).
The performance gains (at the expense of graphical fidelity, which may or may not be acceptable) would be staggering - you could quite literally squeeze out just enough performance to enjoy a game or an application even from older generation hardware for more modern titles.
All those options are also going to need time allocated for a graphics developer to tune to suit your game if the out-of-the-box defaults aren't great, and as it's an area still in progress upgrading APIs and revalidating for your game on a range of hardware. If you're doing multiplatform with consoles/mobile that's even more in the mix, and you need to consider what will reward the time spent on it.
Yes. You'd be horrified if you saw how many game-specific hacks each GPU driver had. Patching their horrors in drivers. So sad.
Built-in Render Pipeline: no DLSS, no FSR, no XeSS
URP: no DLSS, FSR 1.0, no XeSS
HDRP: DLSS, FSR 1.0, no XeSS
Unity 2023.2 (latest released version, not LTS): https://docs.unity3d.com/2023.2/Documentation/Manual/render-... same as above
Unity 6 (upcoming release, preview): https://docs.unity3d.com/6000.0/Documentation/Manual/render-... Built-in Render Pipeline: no DLSS, no FSR, no XeSS
URP: no DLSS, FSR 1.0, no XeSS
HDRP: DLSS, FSR 1.0, FSR 2.0, no XeSS
There are also other methods supported by that engine, but we're not at a point where we'd have all-encompassing support, at least not yet. Maybe in a few years.