mixed feelings on this one.

first comes the "trust in microsoft" issue.
then there is the engine, lumbeyard was struggling to get users, amazon didnt made O3DE because they are an charity or anything like that, they made because they couldnt convice almost anyone to use their engine.
unity receive an massive adoption from indies, unreal had the features that AAA needed.
now unity is trying to enter the AAA space while unreal is trying to enter the indie one, while sustain their position among the big ones.

on the open source side, we have godot, that is making a lot of sucess and growing quickly but in terms of development and in terms of users, due to an excelent workflow, licence, among other things.

lumbeyard was lost without an niche to fill, it helps nothing that even installing the engine seems to be troublesome (games from scratch had a lot of issues with it)
https://www.youtube.com/watch?v=h27MOJjoApM [External Link]

now that amazon transformed lumbeyard into this thing, managed by the linux foundation, i wish then success, but at the same time, i wish they dont take too much the spotlight from the likes of godot (aka that the volunteers who contribute to godot dont change their minds for this instead)
honestly i think they might be losing time on this one, at the same time, their render probably have an better chance to compete against unreal than godot one.

View this comment - View article - View full comments

who would guess that reducing the refresh rate would be one of the most hyped features...
and that is only possible when you control the display, that sort of thing wont work on generic hardware, because some monitors may not support it, so its perfect for an handheld.

View this comment - View article - View full comments

Quoting: jp

Quoting: SchattenspiegelRemember the time basically every major application had a .deb package available and most the disk space was available for games and data and stuff, because applications where small and started nearly instantly and... actually...worked...?

I mean seriously, what is the goal of this? To accelerate climate change by being intentionally wasteful? To incite social unrest by creating an atmosphere comparable to a traffic jam whenever one opens an application?

There is no goal, it's just laziness and illiteracy of developers, who for the most part don't know how to write pure code, they have flooded Linux devcommunity.

that is like saying, rust is useless because an good programer can check the code to make sure its safe to run, sure, in an ideal world we would have perfect programers in enough quantity to make big projects without massive security holes, meanwhile in the real wolrd, we have code writen by humans, so the more you can take away their capabilities of making mistakes, the less security holes you will have.

Quoting: jpAt the same time, all these snaps/flatpaks etc (shhh, systemd) are complicated and unsafe, although it is useful for someone to have legitimate backdoors.
Welcome to World with New order created by corporations and approved by new Linux generation.

old games wont be mantained no matter how much we wish then too.
if i have an small risk of someone actually developing an malware for linux and i geting this malware, end up not being able to run my games on my computer (among other things), and i could chose to run saffer code at the cost of being 100% sure that i wont be able to play my games, then the choice is obvious.

that is like saying, give all your money to thiefs arround the world, they cant rob you if you have nothing.

View this comment - View article - View full comments

Quoting: F.Ultra

Quoting: PikoloSteam as a snap package? That is very unwelcome - I hate applications updating behind my back. Mozilla provide an official Firefox PPA, but I hope Canonical don't mess with the Steam APT package.

The Mozilla Team PPA is not by Mozilla, it's by a voluntary group inside Canonical (or at least they where some years ago). Mozilla are the ones that build the snap for Ubuntu.

what a plot twist

View this comment - View article - View full comments

sigh
by the time i get enough money for an new computer + games, i probably wont want to give those companies any cent anymore...

View this comment - View article - View full comments

Quoting: pete910

Quoting: elmapulfirst they should fix their supply issue

Not knowing how many they have made or pre orders taken you cant make that assumption.

"In the first month very quickly we'll be in the tens of thousands, by the second month we'll be in the hundreds of thousands. And beyond that it'll grow even quicker."

https://www.pcgamer.com/valve-says-steam-deck-production-will-be-in-the-hundreds-of-thousands-by-next-month/ [External Link]

havent you being following the news?

View this comment - View article - View full comments

Quoting: Termy

Quoting: elmapulmost of thos devs are indie devs, im still waiting to see if big devs will start opitimizing for the deck.

Well, Apex Legends is not something i would consider "indie" ;)
There have been several not-so-small studios that released patches to optimize for the Deck, so i wouldn't say its just the indies, albeit they surely are the majority.
Of course it would be nice to have dozens of millions of sold units to "force" the industry to finally care about linux, but i'm pretty happy with the progress we've seen in the last few months already. ^^

that is why i said "most of", now, steam deck have a good momentum, but it will have to keep it momentum in order to get support from more big publishers and will have to get this support for the long run.

nes and snes had an good momentum but that was not enough to ensure n64 would have for instance.

View this comment - View article - View full comments

Quoting: 3zekielMy thought is that the video is confusing power efficiency and performance. I will answer points by points and try to explain.

"nope, the guy really knows his stuff, he even made a video to talk about trade offs.
often you exchange processing power with energy efficiency, size, etc"
he said other examples instead of etc.
he knows that often one tech is not better than other, its just better at an specific thing.
more often than not.

View this comment - View article - View full comments

Quoting: Termy

Quoting: elmapulonce they ramp up their production capacity

I'm sure they'll change things once the production surpasses the demand - but as that seems to still not be the case for the Index, i doubt it'll be too soon.

i doubt VR will ever have the demand that deck have, playing almost any game ever launched on the go, will have a bigger demand than playing the few VR games we have, especially considering that not all games work in VR.

Quoting: TermyAnd i'm not sure if that's a bad thing.
As polished as the Deck already is, i wouldn't say it's something a completely oblivious person should just grab from the shelf of a big vendor because they like the packaging.
I'm also not sure if it really needs to compete with the number of switches shipped, at least not for "our" purpose. It "just" has to solve the chicken&egg problem - and seeing how many devs are jumping at it, it seems to be doing a pretty good job at that.

most of thos devs are indie devs, im still waiting to see if big devs will start opitimizing for the deck.
i have to agree that i dont care about marketshare so long we can play any game we want, and run any software or use case we want (use alternatives to the windows exclusive softwares with the same esential feature)
but if we can reach console level of sales (75~150 millions of units shiped) then we might as well solve the chicken and egg problem foreblem as well as optimization problem forever.

View this comment - View article - View full comments

Quoting: Guest

Quoting: elmapul

Quoting: 3zekiel

Quoting: elmapul"It's not like arm is new in gaming. Mobile phones have been doing it for a long time, the Switch uses arm cores."
speaking of it, arm processors would be much better to run emulators for portable consoles.
hell, its possible to run psp(or vita?) apps on a switch without emulators!

It's the Vita which can run without a full emulator, the PSP is using MIPS.
One problem though, at least for older portable consoles, is that they use 32 bit arm ISA, which has been dropped from newer cores. Also, emulating RISCV over modern CISC tend to work very well due to reducing the instruction cache bloat - an x64 instruction might cover 3 or more ARM instruction (think of LEA vs a multiplication a shift and an addition), keeping the generated code small. So it's not 100% sure that emulating ARM 32 over ARM 64 will be faster than emulating on top of x64.

As for emulating x64 over ARM, it is quite costly... The best way to do it is to go semi hardware like Apple did with the M1 (Implement a bunch of x64 instuctions in hw - mostly memory related -, use x64 memory ordering etc etc). Without that, I'm afraid taking a big overhead is mostly unavoidable, making recent games unplayable.

i saw an video explaining it, and it was quite the opposite!
arm is better to emulate x86 than x86 to emulate arm!
the video is in portuguese so i'm not sure its gonna be usefull here, but te explanation was something like:
you can draw an square by drawing 4 lines, but you waste a lot of processing power if you have to draw an entire window with 1px of width every time you want an vertical line, and an entire window with 1px of height every time you want an horizontal line.
x86 complex instruction set is only usefull when most of those instructions get used often, but that simply is not the case, many instructions were put there to cheat on benchmarks or because hardware patents dont last forever and intel priorities were at not being copied instead of designing an efficient chip, in fact, most x86 instructions are already "emulated" using micro architecture or something like that in plain x86 chips.
(i say x86 but i mean both x86 and x86/64, its just laziness)

i dont remember the exactly explanation on why arm was better, but it was somethng like x86 have an number of instruction that vary too much to be predictable or anything like that.
the processor spend a lot of time trying to figure out the instruction instead of executing it.
anyway, i hope someone else who work on the area can figure out what i'm talking about and and explain it in better/more precise words. =p

The designs of each have become far too complex to be summarised properly in just a short paragraph or two, but some highlights:

• arm is a design, which can be customised. Specific instructions can be added to the hardware - not all "arm" chips are equal!


• arm is risc (reduced instruction set), x86/x86_64 is cisc (complex instruction set)


• These days (well, last I checked) cisc is sort of emulated with microcode - that is, smaller instructions are used to build and run the complex ones. This is done to reduce chip size and complexity, but makes the instruction decode somewhat more entertaining from an engineering standpoint.


• Branch prediction, long pipelines, decode units, and a whole host of extras are generally somewhat more beefy on x86/64 chips to get raw performance out of it, and all of that takes up an awful lot of chip space. One of the reasons arm can go smaller, more power efficient, is by minimising or removing some of that - at the cost of performance.


• As manufacturing technologies improve, there are fewer gains to be had by x86/64, and arm can catch up in those areas, but it's still going to lack certain instructions that help make software run a lot faster (if the software uses them!).

Basically I can see arm right now being able to take over on normal desktop usage (Apple has certainly shown it's quite possible), but it's still a very, very long way away from what x86_64 can do when the thermal and power designs are more permissive. Only it's not quite so simple as that because hardware aside, there's quite a good deal of back & forth with software as well (just like with GPUs). All the fancy instructions in the world are useless if software never uses them - but x86/x86_64 has had a very long time in the spotlight, and compilers can make various assumptions about what is supported or not. Apple get away with it on the M1 because they control everything (they can add instructions and know they'll be used).

Both arm and x86_64 serve different purposes, but requirements change over time and the lines between purposes are blurring more all the time and there's space for a range of options.

this^ give that man a coockie, not only he explained 99% of what i said better than my self, but he also added some extras.

View this comment - View article - View full comments