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.
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.