As a long-time user, I didn't like my first impression of iOS 7 beta, got used to it after about a day, and would not now go back. I actively recommend that people I know upgrade, unless they have an older device (never install a new iOS on a 3+ year old device; it never ends well.)
So, you haven't met me "in real life", but there are plenty of people who like iOS 7.
If we went on "met in real life" figures, then I'd have to say that nearly everybody uses an iPhone and very few use Android. Because that's what I saw on my recent holiday. Obviously not a fair comment, but maybe it goes to show that people with a similar viewpoint often end up in the same place.
The reason is that it can perform global optimizations, in-lining aggressively.
So can all semi-modern C++ compilers. This is a compiler technology, not a language concern.
Modern generational garbage collectors are also faster than malloc/free, and do not suffer fragmentation.
Perhaps true, but this ignores the fact that C++ can effectively bypass heap allocation completely for programmer-defined hot spots. Sure, this pushes the optimisation work on to the programmer rather than the compiler, but it still means a significant performance win. Java can't do this to anything like the same degree.
I think he's referring to signed integer overflow conditions, which don't behave as most people would probably expect and aren't trivial to handle correctly.
Yes and no. Applications can't typically "put things into the cache", but algorithms can (and often are, when it comes to image processing) tuned to suit a particular cache size. Processing the image in an appropriate order, breaking the image into cache-sized chunks, and so on can all be effective strategies which pay off big-time in terms of performance.
Apple does this with all their old hardware. They either declare your hardware obsolete
I'm fine with this. Hardware keeps improving. Software changes to take advantage of this. Sooner or later, I'll want to upgrade.
or make the OS perform so badly on it that you declare it obsolete on your own.
There really needs to be consumer protection against this kind of thing. Apple has made a habit of pushing upgrades to devices that really can't handle it. Explaining to people why they shouldn't tap "Yes" when the phone repeatedly wants to upgrade, because it will permanently break their device, is not a battle that you can win. Not until it's too late, anyway.
From what I've heard (and it seems to match my experience, though it's difficult to be sure with a hidden filesystem) the latest update will even background-download itself onto your device without asking, using your bandwidth and device storage- which you can't get back, even if you don't wish to upgrade.
To be fair, Apple devices (at least, first and second gen iPads) have similar screen burn-in problems. Run the device with the same app too frequently and you will start to see minor but permanent panel degradation.
Major problems can be found after the ramping-up stage that you mention. The team decides that they can fix the problem, but only by changing some fundamental assumption upon which the whole game is based. This causes a lot of rework and can blow budgeting and scheduling out of the water. Worse, gp is fairly correct about a practical life cycle for a game engine- so if you bump the schedule like this a few times, you may need to start making "upgrades" to your underlying tech before you've even released the product. That can be a vicious cycle (see DNF.)
"Data storage / retrieval, mechanics" are often the smallest part of a game. What's really expensive is often the art assets, sound, levels, and polish. And a change to any of these can mean updating everything else to suit (oh, we're going with an egyptian theme now?)
We've "burned" an image into several iPad2 LCD screen quite effectively. It's not horribly noticeable while the tablet is in use, but display a uniform dark/black image and it's clear that there is permanent damage. We've since started using a screensaver for that application to prevent the issue from worsening, but the damage was permanent.
It may not be the same mechanism, but the end-user result is the same.
I'm sure an actual judge can come up with a much better and more inclusive way than I could come up in the minute or so it took me to write that comment.
Better, more inclusive- probably. Perfect- no. And if you're going to come up with a single statement that defines business pracitces for all time, you'd better be sure that it is perfect and without any loopholes.
A good starting point would be to kill off software and business method patents
That would surely just lead to a world where software companies can't compete with hardware companies, since one side has protection and the other does not. (hypothetical: Hardware-heavy companies including Apple and Samsung would have patents which could be used software-heavy companies such as Microsoft or Google. But if Microsoft wanted to enter the tablet market, they would have nothing to protect them from the hardware patents.)
Which basically means "you can't make something that looks exactly like my product", which is totally sensible, as there is no good reason why Samsung should be allowed to sell a phone that looks exactly like the iPhone (which is way more than just "rectangle with rounded corners").
Absolutely, but where do you drawn the line? A lot of the complaints about Apple here stem from the fact that Apple deliberately use a minimalist design, which can be hard to avoid without adding user-unfriendly gimmicks to the product for the pure reason of dodging patents. Should something similar to the FRAND concept exist here, identifying "essential" patents and preventing abuse?
I don't get it either. 100k Apps seems adequate to me -- especially for a new platform.
A small number of quality apps is enough to suit most users, most of the time. The difference is the lack of all those niche apps which are only needed by a few people, only some of the time. Need a security-camera app to check on your business when the alarm goes off at 3am, for whatever el-cheapo camera brand you thought was a good idea at the time? This is where a more mature app library can be noticeable.
It's the whole 1990s Windows vs Mac thing over again, but this time in reverse. If you're in love with the minority platform, the lack of apps probably won't make you change. But for someone who cares less about the platform, it's hard to give up access to those niche apps for questionable benefit.
Works fine for me and mine. I'm not saying that your experience is invalid, but it certainly isn't true for everybody.
The worst iOS update in my experience was 4.0, which turned my iPhone3G from a slightly outdated phone into an unusably sluggish phone with no real way to go back to the old performance. The OS itself was fine (and was a great improvement when used on the iPad, iPhone4, etc.) but it should never have been released as iPhone3G compatible.
* Developing the first part of the game is often the bulk of the cost. Let's say that it's 70% of the work, as compared to doing a monolithic game. Since you're expecting to sell it at $2-$5 rather than $50+, you're causing a pretty hefty loss of income with quite a small loss of expense. You'd better be sure to sell lots of episodes.
* "Sequels" don't sell well. You'd need to be very well loved to bring income that compares to a monolithic game. If you're that well loved, you would have made this money by selling at the higher price anyway.
Not saying it can't ever work, but this model adds a lot of risk in a business that's already overly risky.
on the other hand, it's pretty well known that issueing unecessary state changes to 3d apis is bad and can be costly. So even if they didn't know the extent of the problems it caused on that particular card, enabling and disabling something for no good reason a hundred time per frame is bad.
Agreed- however in the (distant) past we've had to do exactly this because of bugs in the driver state caching. I've also seen Cg hitting state changes fairly hard on some platforms- there was an optimisation to prevent this but it used to cause memory leaks. It can be difficult to know exactly what's going on under the hood there and you can't really blame the application developers for this without knowing the specific circumstances.
One thing worth noting is that a change that makes no difference on the card you're testing with may make the difference between the game being playable or a slideshow on a different card.
Absolutely true. My anecdotes above were in regards to very specific hardware so this comment doesn't really change what I'm saying, but it's an important thing to understand in a general sense.
One particularly amusing issue I remember was with a new feature in Direct3D where I believe we were the only people who supported it in hardware at that time and everyone else emulated it in software; we got a new game from big name game developer X and it ran vastly slower on our card than on much less powerful systems. The idea was that you'd enable this feature once and then keep using it, but they were turning it on and off hundreds of times in a frame and each time that caused a major pipeline stall in our hardware. So once we figured that out we just detected the game and dropped back to software emulation like everyone else, but if they'd known what they were doing the game would have worked fine on all cards and been faster on ours because they'd actually have been using the hardware instead of the CPU.
To be fair, you're accusing the dev in question of not optimising for your card when you admit that the card in question was unusual and probably released after the game in question was developed- otherwise you probably would have worked with them to improve their software? It's all well and good to say "they should have known better" (and I've used that line before, so I know how you feel) but if you're the odd man out, it's hard to really blame the dev for not being able to predict how performance would change in the future. Especially if the dev is using some kind of third-party engine or graphics library (eg. Cg) where they don't necessarily have fine control over state changes.
I don't know the details of your case so I won't comment further, but it's worth remembering that there are two sides to every story.
One thing I learned from writing video games is that driver developers often don't know much about real-world performance.;-) Much of the performance advice we have seen given by GPU teams in the past had zero benefit to game performance and took weeks of developer time to implement and maintain. On the other hand, sometimes you come across a real gem.
Short version: good programmers good, bad programmers bad. Sometimes what is good for one case is not good for another case.
I found SimCity on the iPad to be pretty good actually. Not perfect- it could do with a few minor fixes- but well worth the money and one of the bigger time-wasters for me.
I would think that most C++ programmers consider the lack of GC to be a feature, not a limitation. Speaking for myself, that's one of the major reasons why I prefer C++ over other 'more modern' languages- GC introduces a whole class of potential bugs and limitations that don't exist without it, and encourages the programmer to ignore object life cycle. I'm not saying that GC is all bad, but neither is it clearly better than the alternative for complex programs.
Regarding multithreading, program architecture is far more important than your choice of language. If you design a sensible flow of information through your program, you'll end up with an efficient and (relatively) bug-free result. If you have poor flow, you'll end up with horrible performance and deadlocks. A 'safe' programming language like Java/C# doesn't protect you from this.
You're right that C++ lacks standardised cross-platform libraries; the situation is improving, but slowly. It's not a deal-breaker in many cases but it is a cost that needs to be considered. The same is actually true of the other languages you name to greater or lesser degrees- C# really isn't practically cross-platform in many cases, despite Mono. Java is known for having poor cross-platform UI support. At least they get the lower-level primitives right though.
Acceleration starts at a specific point and "pushes" its way through the object at the speed of sound in the material of the object. If you had a 10 mile long metal bar and were strong enough to shove one end, the other end wouldn't move instantly.
A quick question about this- what happens if you continuously push the end of the bar at the speed of sound in the material? Obviously you can't get a situation where the bar collapses to zero length, but that is the "obvious" outcome from what you describe.
I've always wondered about that one and never bothered to learn.
Slashdot Mirror
As a long-time user, I didn't like my first impression of iOS 7 beta, got used to it after about a day, and would not now go back. I actively recommend that people I know upgrade, unless they have an older device (never install a new iOS on a 3+ year old device; it never ends well.)
So, you haven't met me "in real life", but there are plenty of people who like iOS 7.
If we went on "met in real life" figures, then I'd have to say that nearly everybody uses an iPhone and very few use Android. Because that's what I saw on my recent holiday. Obviously not a fair comment, but maybe it goes to show that people with a similar viewpoint often end up in the same place.
You make some good points, however:
The reason is that it can perform global optimizations, in-lining aggressively.
So can all semi-modern C++ compilers. This is a compiler technology, not a language concern.
Modern generational garbage collectors are also faster than malloc/free, and do not suffer fragmentation.
Perhaps true, but this ignores the fact that C++ can effectively bypass heap allocation completely for programmer-defined hot spots. Sure, this pushes the optimisation work on to the programmer rather than the compiler, but it still means a significant performance win. Java can't do this to anything like the same degree.
I think he's referring to signed integer overflow conditions, which don't behave as most people would probably expect and aren't trivial to handle correctly.
Yes and no. Applications can't typically "put things into the cache", but algorithms can (and often are, when it comes to image processing) tuned to suit a particular cache size. Processing the image in an appropriate order, breaking the image into cache-sized chunks, and so on can all be effective strategies which pay off big-time in terms of performance.
Apple does this with all their old hardware. They either declare your hardware obsolete
I'm fine with this. Hardware keeps improving. Software changes to take advantage of this. Sooner or later, I'll want to upgrade.
or make the OS perform so badly on it that you declare it obsolete on your own.
There really needs to be consumer protection against this kind of thing. Apple has made a habit of pushing upgrades to devices that really can't handle it. Explaining to people why they shouldn't tap "Yes" when the phone repeatedly wants to upgrade, because it will permanently break their device, is not a battle that you can win. Not until it's too late, anyway.
From what I've heard (and it seems to match my experience, though it's difficult to be sure with a hidden filesystem) the latest update will even background-download itself onto your device without asking, using your bandwidth and device storage- which you can't get back, even if you don't wish to upgrade.
To be fair, Apple devices (at least, first and second gen iPads) have similar screen burn-in problems. Run the device with the same app too frequently and you will start to see minor but permanent panel degradation.
Major problems can be found after the ramping-up stage that you mention. The team decides that they can fix the problem, but only by changing some fundamental assumption upon which the whole game is based. This causes a lot of rework and can blow budgeting and scheduling out of the water. Worse, gp is fairly correct about a practical life cycle for a game engine- so if you bump the schedule like this a few times, you may need to start making "upgrades" to your underlying tech before you've even released the product. That can be a vicious cycle (see DNF.)
"Data storage / retrieval, mechanics" are often the smallest part of a game. What's really expensive is often the art assets, sound, levels, and polish. And a change to any of these can mean updating everything else to suit (oh, we're going with an egyptian theme now?)
We've "burned" an image into several iPad2 LCD screen quite effectively. It's not horribly noticeable while the tablet is in use, but display a uniform dark/black image and it's clear that there is permanent damage. We've since started using a screensaver for that application to prevent the issue from worsening, but the damage was permanent.
It may not be the same mechanism, but the end-user result is the same.
I'm sure an actual judge can come up with a much better and more inclusive way than I could come up in the minute or so it took me to write that comment.
Better, more inclusive- probably. Perfect- no. And if you're going to come up with a single statement that defines business pracitces for all time, you'd better be sure that it is perfect and without any loopholes.
A good starting point would be to kill off software and business method patents
That would surely just lead to a world where software companies can't compete with hardware companies, since one side has protection and the other does not. (hypothetical: Hardware-heavy companies including Apple and Samsung would have patents which could be used software-heavy companies such as Microsoft or Google. But if Microsoft wanted to enter the tablet market, they would have nothing to protect them from the hardware patents.)
Which basically means "you can't make something that looks exactly like my product", which is totally sensible, as there is no good reason why Samsung should be allowed to sell a phone that looks exactly like the iPhone (which is way more than just "rectangle with rounded corners").
Absolutely, but where do you drawn the line? A lot of the complaints about Apple here stem from the fact that Apple deliberately use a minimalist design, which can be hard to avoid without adding user-unfriendly gimmicks to the product for the pure reason of dodging patents. Should something similar to the FRAND concept exist here, identifying "essential" patents and preventing abuse?
Not a smaller cut. No cut whatsoever.
I don't get it either. 100k Apps seems adequate to me -- especially for a new platform.
A small number of quality apps is enough to suit most users, most of the time. The difference is the lack of all those niche apps which are only needed by a few people, only some of the time. Need a security-camera app to check on your business when the alarm goes off at 3am, for whatever el-cheapo camera brand you thought was a good idea at the time? This is where a more mature app library can be noticeable.
It's the whole 1990s Windows vs Mac thing over again, but this time in reverse. If you're in love with the minority platform, the lack of apps probably won't make you change. But for someone who cares less about the platform, it's hard to give up access to those niche apps for questionable benefit.
Brighter than the sun. I wish you could turn them down without ruining the contrast.
Works fine for me and mine. I'm not saying that your experience is invalid, but it certainly isn't true for everybody.
The worst iOS update in my experience was 4.0, which turned my iPhone3G from a slightly outdated phone into an unusably sluggish phone with no real way to go back to the old performance. The OS itself was fine (and was a great improvement when used on the iPad, iPhone4, etc.) but it should never have been released as iPhone3G compatible.
Yam.
I also thought that at first, but on a second glance.. skew per clock cycle is increasing exponentially. Which is probably what they care about here?
There are two problems with this:
* Developing the first part of the game is often the bulk of the cost. Let's say that it's 70% of the work, as compared to doing a monolithic game. Since you're expecting to sell it at $2-$5 rather than $50+, you're causing a pretty hefty loss of income with quite a small loss of expense. You'd better be sure to sell lots of episodes.
* "Sequels" don't sell well. You'd need to be very well loved to bring income that compares to a monolithic game. If you're that well loved, you would have made this money by selling at the higher price anyway.
Not saying it can't ever work, but this model adds a lot of risk in a business that's already overly risky.
on the other hand, it's pretty well known that issueing unecessary state changes to 3d apis is bad and can be costly. So even if they didn't know the extent of the problems it caused on that particular card, enabling and disabling something for no good reason a hundred time per frame is bad.
Agreed- however in the (distant) past we've had to do exactly this because of bugs in the driver state caching. I've also seen Cg hitting state changes fairly hard on some platforms- there was an optimisation to prevent this but it used to cause memory leaks. It can be difficult to know exactly what's going on under the hood there and you can't really blame the application developers for this without knowing the specific circumstances.
One thing worth noting is that a change that makes no difference on the card you're testing with may make the difference between the game being playable or a slideshow on a different card.
Absolutely true. My anecdotes above were in regards to very specific hardware so this comment doesn't really change what I'm saying, but it's an important thing to understand in a general sense.
One particularly amusing issue I remember was with a new feature in Direct3D where I believe we were the only people who supported it in hardware at that time and everyone else emulated it in software; we got a new game from big name game developer X and it ran vastly slower on our card than on much less powerful systems. The idea was that you'd enable this feature once and then keep using it, but they were turning it on and off hundreds of times in a frame and each time that caused a major pipeline stall in our hardware. So once we figured that out we just detected the game and dropped back to software emulation like everyone else, but if they'd known what they were doing the game would have worked fine on all cards and been faster on ours because they'd actually have been using the hardware instead of the CPU.
To be fair, you're accusing the dev in question of not optimising for your card when you admit that the card in question was unusual and probably released after the game in question was developed- otherwise you probably would have worked with them to improve their software? It's all well and good to say "they should have known better" (and I've used that line before, so I know how you feel) but if you're the odd man out, it's hard to really blame the dev for not being able to predict how performance would change in the future. Especially if the dev is using some kind of third-party engine or graphics library (eg. Cg) where they don't necessarily have fine control over state changes.
I don't know the details of your case so I won't comment further, but it's worth remembering that there are two sides to every story.
One thing I learned from writing video games is that driver developers often don't know much about real-world performance. ;-) Much of the performance advice we have seen given by GPU teams in the past had zero benefit to game performance and took weeks of developer time to implement and maintain. On the other hand, sometimes you come across a real gem.
Short version: good programmers good, bad programmers bad. Sometimes what is good for one case is not good for another case.
I found SimCity on the iPad to be pretty good actually. Not perfect- it could do with a few minor fixes- but well worth the money and one of the bigger time-wasters for me.
I would think that most C++ programmers consider the lack of GC to be a feature, not a limitation. Speaking for myself, that's one of the major reasons why I prefer C++ over other 'more modern' languages- GC introduces a whole class of potential bugs and limitations that don't exist without it, and encourages the programmer to ignore object life cycle. I'm not saying that GC is all bad, but neither is it clearly better than the alternative for complex programs.
Regarding multithreading, program architecture is far more important than your choice of language. If you design a sensible flow of information through your program, you'll end up with an efficient and (relatively) bug-free result. If you have poor flow, you'll end up with horrible performance and deadlocks. A 'safe' programming language like Java/C# doesn't protect you from this.
You're right that C++ lacks standardised cross-platform libraries; the situation is improving, but slowly. It's not a deal-breaker in many cases but it is a cost that needs to be considered. The same is actually true of the other languages you name to greater or lesser degrees- C# really isn't practically cross-platform in many cases, despite Mono. Java is known for having poor cross-platform UI support. At least they get the lower-level primitives right though.
At the point of download, you have the choice of:
* Downloading it to your photo roll.
* Copying it to the clipboard.
* Emailing it.
http://en.wikipedia.org/wiki/Embarrassingly_parallel
Acceleration starts at a specific point and "pushes" its way through the object at the speed of sound in the material of the object. If you had a 10 mile long metal bar and were strong enough to shove one end, the other end wouldn't move instantly.
A quick question about this- what happens if you continuously push the end of the bar at the speed of sound in the material? Obviously you can't get a situation where the bar collapses to zero length, but that is the "obvious" outcome from what you describe.
I've always wondered about that one and never bothered to learn.
100 devices per developer, not per app.