![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
silveradept[This is part of a series on video games, their tropes, stories of playing games, and other related topics. If you have suggestions about where to take the series, please do say so in the comments. We have a lot of spaces to fill for this month.]
Apropos of doing a lot of fiddling tonight in trying to get one of my Raspberry Pis to do Steam game streaming and to get one of my old Dualshock 3 controllers hooked up properly to it (in which I managed to crack the casing of a Bluetooth dongle, but the hardware inside is still fine, thankfully), I am reminded significantly of the fact that gaming experiences have always been uneven, depending on the platform in use. Consoles, of course, generally skirt this problem, as they have a fixed configuration of hardware that can be developed for and exploited to its very limits. There are stories, I'm sure, about developing for consoles and finding all sorts of ways to get that hardware to do things that it wasn't actually meant to do, much less do extraordinarily well. On the computer side, though, any given game could be developing for one or more operating systems, a myriad of hardware configurations, and people who want to game in very specific ways, with the peripherals of their choice. The usual solution to this predicament is through the use of hardware abstraction. So long as the game itself only responds to input signals, it doesn't really matter what hardware is generating those signals, and so people can use whatever peripherals they want, assuming it has enough buttons to achieve the stated goal. For things that don't, however, there's usually an attempt to detect what's being used to play the game, so that alternate methods, like radial wheels, can be implemented so that the input device currently in use isn't disadvantaged or have gameplay features and shortcuts blocked or locked out. In many a genre of game, not having access to the full suite of possibilities at gameplay speed is a severe handicap for a player.
Output can be similarly abstracted, such that the game might only care about making sure that objects are called into existence in the right places using a particular shared language or set of protocols, like DirectX and OpenGL, rather than having to painstakingly figure out what hardware is going on and tailor the drawing decisions to that hardware. Much more likely, there's a query about "what feature sets do you support?" and the game makes deicisions about what to include and what won't be understood based on the reply to that query about what features are available.
However, hardware abstraction only gets you so far. On Windows systems, it's almost a guarantee that proprietary drivers will be in use for the hardware subsystems, ensuring a significant amount of compatibility and correct implementation of features according to their specifications. Non-Windows systems may also have proprietary drivers for them, and many do, but they're not necessarily going to be as well-documented, well-supported, or well-updated, because the amount of people who are running desktop systems that aren't Windows is still pretty small. For the Linux crowd, while there are proprietary drivers for just about everything, people who are on Linux because they want nothing to do with anything that is closed-source aren't going to choose those drivers, and will instead stick with the open-source drivers, which are often good for many things, but not necessarily for gaming. Coupled with the fact that OpenGL is, well, open, and DirectX isn't, Mac and Linux users are at a a disadvantage for playing games, as so many of them use the Microsoft-proprietary DirectX for their acceleration, and thus lock themselves into Windows as the only place where their game can be enjoyed. There's a little bit more cross-compatibility with independent games, as they tend to use toolkits like Unity that produce games that can be played on any platform or easily compiled for each of the major ones (which is itself helped somewhat significantly by the fact that Apple's machines are using x86 / x86_64 instruction sets with compatible chips, rather than ones with a completely different instruction set that made compatibility a problem).
Further complicating things are the mobile operating systems, using the ARM instruction set, and that have significantly different interfaces than the ones available to the x86_64-type machines. Again, depending on the language for scripting and the toolkits in use, it's still possilbe to create games that can run on desktops and mobile devices alike, but for the most part, throughout the history of gaming, there have been fault lines depending on consoles versus computers, and operating systems versus each other. Now we have to add the "desktop/mobile" line as another place where people are divided. There are some crossover spots, of course, because once you abstract enough, it becomes a matter of whether or not there's an interpreter for what the game was made in. (Which, as we recall from emulation, is usually easier if it's an earlier generation of technology.)
Raspberry Pi and other single-board computers become interesting things, then, because they are necessarily systems-on-a-chip, and the entities manufacturing those are usually doing so for mobile phones and other devices, so they run ARM rather than x86, but they are intended, for most purposes, to replicate a desktop environment and effect, when they're not being transformed into other, more focused-purpose things like media players and retro gaming machines. Also, those single-board machines are a damn sight cheaper than a lot of other things around. Where the issue, such that it is, comes into play is that because they're cheap, they aren't necessarily as full of raw power as other processors as might be found in mobile phones, and so while they can do things like play movies and digital files really well, they're not so good at the games department. Pair them with a server on the other end, however, and a decent enough local network connection, though, and they're suddenly really good at playing games wherever you want to play games. To the point where Steam basically released programs that would allow a sufficiently new Raspberry Pi to function essentially the same as the Steam Link device, which was meant to allow a central Steam computer to be played on any client where a television and inputs could be hooked up (so long as the network infrastructure was solid, of course). And some of the earlier models can still be used for this purpose as well. As I was doing for much of today.
Funnily enough, Linux is way better at being able to hook up the Dualshocks from my PS3, which is really rather nice and allows them to continue to live on as controllers for classic gaming and for streaming gaming and for playing videos being streamed over the network. Although I spent a lot of time banging my head trying to make something work correctly, and it refused to. So I switched drivers and software bits, and suddenly all was well and working quite nicely, thank you. Which is a lot of what gaming on Linux has been, and was what trying to use Linux was like when I first thought about it at university. The community has come a long way toward making an experience that is usable and doesn't require constant trips to the console to fix things, and the World Wide Web makes it easier to crib off someone else's work to fix similar problems. And WINE is a lot better now than it was before, so much so that it has forks that can run a pretty impressive set of otherwise Windows-only games.
I'm not sure that Linux will ever achieve parity with Windows in how many games will run on it, but it's certainly doing a lot better all around than it was before. With Steam leading the charge of offering its launcher on Windows, OSX, and Linux, hopefully jmore and more developers will stik to tools and frameworks that can work everywhere.
So yeah, I tried to learn Linux to play games, and I succeeded, a little, but instead it turns out that Linux works really well for other purposes than gaming, so long as those purposes don't include the need for DRM.
Apropos of doing a lot of fiddling tonight in trying to get one of my Raspberry Pis to do Steam game streaming and to get one of my old Dualshock 3 controllers hooked up properly to it (in which I managed to crack the casing of a Bluetooth dongle, but the hardware inside is still fine, thankfully), I am reminded significantly of the fact that gaming experiences have always been uneven, depending on the platform in use. Consoles, of course, generally skirt this problem, as they have a fixed configuration of hardware that can be developed for and exploited to its very limits. There are stories, I'm sure, about developing for consoles and finding all sorts of ways to get that hardware to do things that it wasn't actually meant to do, much less do extraordinarily well. On the computer side, though, any given game could be developing for one or more operating systems, a myriad of hardware configurations, and people who want to game in very specific ways, with the peripherals of their choice. The usual solution to this predicament is through the use of hardware abstraction. So long as the game itself only responds to input signals, it doesn't really matter what hardware is generating those signals, and so people can use whatever peripherals they want, assuming it has enough buttons to achieve the stated goal. For things that don't, however, there's usually an attempt to detect what's being used to play the game, so that alternate methods, like radial wheels, can be implemented so that the input device currently in use isn't disadvantaged or have gameplay features and shortcuts blocked or locked out. In many a genre of game, not having access to the full suite of possibilities at gameplay speed is a severe handicap for a player.
Output can be similarly abstracted, such that the game might only care about making sure that objects are called into existence in the right places using a particular shared language or set of protocols, like DirectX and OpenGL, rather than having to painstakingly figure out what hardware is going on and tailor the drawing decisions to that hardware. Much more likely, there's a query about "what feature sets do you support?" and the game makes deicisions about what to include and what won't be understood based on the reply to that query about what features are available.
However, hardware abstraction only gets you so far. On Windows systems, it's almost a guarantee that proprietary drivers will be in use for the hardware subsystems, ensuring a significant amount of compatibility and correct implementation of features according to their specifications. Non-Windows systems may also have proprietary drivers for them, and many do, but they're not necessarily going to be as well-documented, well-supported, or well-updated, because the amount of people who are running desktop systems that aren't Windows is still pretty small. For the Linux crowd, while there are proprietary drivers for just about everything, people who are on Linux because they want nothing to do with anything that is closed-source aren't going to choose those drivers, and will instead stick with the open-source drivers, which are often good for many things, but not necessarily for gaming. Coupled with the fact that OpenGL is, well, open, and DirectX isn't, Mac and Linux users are at a a disadvantage for playing games, as so many of them use the Microsoft-proprietary DirectX for their acceleration, and thus lock themselves into Windows as the only place where their game can be enjoyed. There's a little bit more cross-compatibility with independent games, as they tend to use toolkits like Unity that produce games that can be played on any platform or easily compiled for each of the major ones (which is itself helped somewhat significantly by the fact that Apple's machines are using x86 / x86_64 instruction sets with compatible chips, rather than ones with a completely different instruction set that made compatibility a problem).
Further complicating things are the mobile operating systems, using the ARM instruction set, and that have significantly different interfaces than the ones available to the x86_64-type machines. Again, depending on the language for scripting and the toolkits in use, it's still possilbe to create games that can run on desktops and mobile devices alike, but for the most part, throughout the history of gaming, there have been fault lines depending on consoles versus computers, and operating systems versus each other. Now we have to add the "desktop/mobile" line as another place where people are divided. There are some crossover spots, of course, because once you abstract enough, it becomes a matter of whether or not there's an interpreter for what the game was made in. (Which, as we recall from emulation, is usually easier if it's an earlier generation of technology.)
Raspberry Pi and other single-board computers become interesting things, then, because they are necessarily systems-on-a-chip, and the entities manufacturing those are usually doing so for mobile phones and other devices, so they run ARM rather than x86, but they are intended, for most purposes, to replicate a desktop environment and effect, when they're not being transformed into other, more focused-purpose things like media players and retro gaming machines. Also, those single-board machines are a damn sight cheaper than a lot of other things around. Where the issue, such that it is, comes into play is that because they're cheap, they aren't necessarily as full of raw power as other processors as might be found in mobile phones, and so while they can do things like play movies and digital files really well, they're not so good at the games department. Pair them with a server on the other end, however, and a decent enough local network connection, though, and they're suddenly really good at playing games wherever you want to play games. To the point where Steam basically released programs that would allow a sufficiently new Raspberry Pi to function essentially the same as the Steam Link device, which was meant to allow a central Steam computer to be played on any client where a television and inputs could be hooked up (so long as the network infrastructure was solid, of course). And some of the earlier models can still be used for this purpose as well. As I was doing for much of today.
Funnily enough, Linux is way better at being able to hook up the Dualshocks from my PS3, which is really rather nice and allows them to continue to live on as controllers for classic gaming and for streaming gaming and for playing videos being streamed over the network. Although I spent a lot of time banging my head trying to make something work correctly, and it refused to. So I switched drivers and software bits, and suddenly all was well and working quite nicely, thank you. Which is a lot of what gaming on Linux has been, and was what trying to use Linux was like when I first thought about it at university. The community has come a long way toward making an experience that is usable and doesn't require constant trips to the console to fix things, and the World Wide Web makes it easier to crib off someone else's work to fix similar problems. And WINE is a lot better now than it was before, so much so that it has forks that can run a pretty impressive set of otherwise Windows-only games.
I'm not sure that Linux will ever achieve parity with Windows in how many games will run on it, but it's certainly doing a lot better all around than it was before. With Steam leading the charge of offering its launcher on Windows, OSX, and Linux, hopefully jmore and more developers will stik to tools and frameworks that can work everywhere.
So yeah, I tried to learn Linux to play games, and I succeeded, a little, but instead it turns out that Linux works really well for other purposes than gaming, so long as those purposes don't include the need for DRM.
