10 ms·

Yet phones, which only need to draw text and flat bitmaps, are laggy and stall all the time.

by jblow 10y ago

toast0 10y ago
If a game ran like our phones, it would get terrible reviews and people wouldn't buy it. If a phone ran like our games, people wouldn't buy it because it has no apps.
- lj3 10y ago
  Reductive and ridiculous. Games frequently have smaller languages (like Lua and Scheme) embedded inside them for scripting purposes. There is no shortage of game mods.
vvanders 10y ago
As someone who's lived in both spaces(GameDev and Phone UI/UX engine development) there's certainly similarities but there's also some pretty stark differences. For instance you're given no guarantees for execution time on a phone. That slice of time that Sony/MS takes for their overlay that's mandated to no less than x% of a frame? Doesn't exist on Android/iOS. The OS is welcome to wake up some background process(or another app on Android) and steal away one of your cores. From a development side you just don't have the same resources to dedicate to performance on phone development that you get in gamedev. Combined with a culture that doesn't value performance as much(hello Java) that's why you see different results. Google/Apple is targeting the guy in his garage who wants to put out something in ~3 months. Rarely do you see the development times that games have and that is where the divergence happens.
- iainmerrick 10y ago
  Another difference (when it comes to games programming) is that Android phones in particular are incredibly varied, and the GPU drivers are often really bad so moderately non-trivial code can easily crash the whole phone. The upshot is that you have to code very carefully to a small subset of OpenGL ES, which limits the clever stuff you can do do improve performance. For example, trying to share your GL context across multiple threads is a good way to crash or hang your Android app, even though in principle it's supposed to work. Windows hardware is also very varied, but it seems like desktop Direct3D drivers are relatively good compared to mobile GL drivers. (OpenGL drivers, unfortunately, are also really bad on desktop.)

Yet phones, which only need to draw text and flat bitmaps, are laggy and stall all the time.

by jblow 10y ago

Yet phones, which only need to draw text and flat bitmaps, are laggy and stall all the time.

If a game ran like our phones, it would get terrible reviews and people wouldn't buy it. If a phone ran like our games, people wouldn't buy it because it has no apps.

lj3 10y ago
Reductive and ridiculous. Games frequently have smaller languages (like Lua and Scheme) embedded inside them for scripting purposes. There is no shortage of game mods.

vvanders 10y ago

As someone who's lived in both spaces(GameDev and Phone UI/UX engine development) there's certainly similarities but there's also some pretty stark differences. For instance you're given no guarantees for execution time on a phone. That slice of time that Sony/MS takes for their overlay that's mandated to no less than x% of a frame? Doesn't exist on Android/iOS. The OS is welcome to wake up some background process(or another app on Android) and steal away one of your cores. From a development side you just don't have the same resources to dedicate to performance on phone development that you get in gamedev. Combined with a culture that doesn't value performance as much(hello Java) that's why you see different results. Google/Apple is targeting the guy in his garage who wants to put out something in ~3 months. Rarely do you see the development times that games have and that is where the divergence happens.

iainmerrick 10y ago
Another difference (when it comes to games programming) is that Android phones in particular are incredibly varied, and the GPU drivers are often really bad so moderately non-trivial code can easily crash the whole phone. The upshot is that you have to code very carefully to a small subset of OpenGL ES, which limits the clever stuff you can do do improve performance. For example, trying to share your GL context across multiple threads is a good way to crash or hang your Android app, even though in principle it's supposed to work. Windows hardware is also very varied, but it seems like desktop Direct3D drivers are relatively good compared to mobile GL drivers. (OpenGL drivers, unfortunately, are also really bad on desktop.)