The SGX 535 in the 3GS is clocked at 200 MHz. The PSP is clocked at 167. The 3GS has a new ARM Cortex a8 CPU with a 256 kb L2 cache. PSP CPU has a higher bus, but no L2 cache and is only clocked at 333 MHz. iPhone 3GS has 256 mb RAM and PSP has 64. Both GPUs have dedicated graphics memory. The MBX in the 3G iphone had 24 mb dedicated. The 3GS has idk... On paper, the 3GS is better, but Apple does not give developers full access to the 3GS innards. The PSP GPU pushes 30 million polygons a second, even though most games barely even reach 5 mil/sec. The SGX pushes 28 mil, and the MBX pushes 1 mil. Now the PSP supports OpenGL 1.4 and the 3GS supports 2.0, and has several cores for shader processing and vertex buffer support. The 3GS has much better vertex shader drivers than the old MBX. Overall, i'd say the PSP and 3GS are about even gaming wise, but the 3GS has more overall power.
No, the "dedicated" SGX memory you're referring to is simply the amount of memory allocated from the system memory. There is only a small cache on the SGX itself for the tile being rendered but no local memory for textures and the framebuffer like on the PSP. Peak polygon rate for the chip itself means very little, the factors that influence the real-world scenario are, for example, the size of each poly on-screen, the lighting/shaders involved, texture amounts and sizes and most of all, if the device has even enough memory bandwidth to keep the render pipelines fed with the data they require. For games shaders are nice, but fill-rate is important. And in that respect the PSP has still a clear advantage.
I am not a programeur, but I ve made games for iphone and psp... datas wize it s like the opposite. the psp like to handle a lot of small texture and a LOT of small polygon<no hardware clipping>...that why most bsp engine run like shit on psp <splintercell psp?> while apple device like big polygon<but not a lot of them> and big textures the psp can also handle a lot more drawcall than the iphone... the iphone 3gs can do nice shader<not really used in game so far> my game "brotherhood of violence" use normal map rendering http://forums.toucharcade.com/showthread.php?threadid=41800 those screenshot are from the 3gs version.. running at 30fps...
I'd like to preface this by saying that I'm only continuing to compare the GS to the PSP for practical purposes, i.e., if we will see graphics like or better than the PSP in the future. I'm not looking for/trying to promote fanboyism. Why are you bashing on the iPhone so much? The XB360 uses system memory for its graphics chip too. It's actually an ADVANTAGE in a lot of ways when there's enough to go around. As far as fill-rate is concerned, the PSP has like 665 (non-pixel-shaded) mpixels/sec, the iPhone has ~400 (pixel shaded)/sec. Experience shows that 400 pixel-shaded /sec is better than 664 non, but seriously, not sure why we're even still on the "iPhone isn't a REAL console like the PSP" trail. Let's say the PSP has an edge - let's call it a 10% practical edge. That doesn't mean the iPhone isn't great, awesome, and cool, and worthy of game-playing. If the PSP had a 100% edge we wouldn't even be discussing this in the first place... You're assuming there isn't a time factor involved in a free market. Please read the thread to see the discussion on whether or not it is possible in the future, considering the generations of hardware out there, etc., and how this all plays into the GS's capabilities. Rehashing it in response to your post would really be annoying. Vague mis-rememberings of specs on a model older than the one we're discussing is rather pointless, too. #1 those aren't the specs, #2 that's not the model we're speaking of. If you want to get down to bandwidth, the PSP has 2.6GB/s of bandwidth. The SGX theoretically hits 4.6GB/sec. The SGX is a SoC with the ARM, so it's likely that the bus will support what the SGX does; that said, if it doesn't hit 4.6GB, it can still be fast. As for the fast local cache on the PSP, it has 2MB. 1MB is taken up by the double-buffered 480x272 display, another good chunk for depth and - if it supports it - stencil buffers, and then there is a VERY small bit available for textures. Interesting how small that bit is. I've heard a lot of iPhone developers saying they get big gains sorting polygons by texture and rendering ones that use the same texture in batches. Considering the size of that PSP cache I wouldn't be surprised if the PSP needed the same kind of optimization. But, that said, that's the MBX chipset, not the SGX. I'd like to point out here for no particular reason that the Open Pandora, using a Cortex A8 at 600MHz and an SGX530 at half the pipelines, manages Quake3 at 60fps with the highest details and 800x480 screen resolution. That's 2.5x the pixels as the iPhone, leaving it a theoretical Q3 benchmark of 60*2.5 = 150fps if fillrate is the only limiter. I know Quake3 is old, but it's not a pixel-shaded game. Simple pixel shaders make Quake2 look amazing. Just imagine what that means... I addressed those architecture issues. As far as compromises go, it's interesting, then, that Apple chose to put architecture that can give a PSP a run for its money in an iPod, which was going along just fine without it, thereby reducing its battery life...don't you think? Sounds like a compromise was made in the way you aren't thinking. Also, the PSP is and always has been billed as an all-around media device. Sony wants you to use it as your movie player, your MP3 player, etc. It just turns out that media playing is a *subset* of game playing...yet more interesting! Thanks a lot for that info and those screens. It makes sense that the iPhone would like few polygons but big textures/lots of pixel shading. It has a great deal of bandwidth, but not a lot of pipes to throw around. Pixel shading eats up a lot more pipe time than vertex shading. So reduce the vertex shading time as much as possible, make good use of the time you're going to spend on pixels ANYWAY by shading them better. Maybe my logic is weak but it at least makes sense on paper.
I'm not bashing on the iPhone, it's my favorite development platform. I'm discussing the compromises with the hardware that affect its real-world performance. You bring up Xbox 360 as an example of a unified memory architecture, but it's a bad example: the Xbox 360 graphics chip has 10MB of embedded memory with massive bandwidth (i.e. 256GB/sec for dedicated graphics vs. ~25GB/sec for system bus). No, let's not call it a 10% practical edge. The PowerVR chips are excellent in minimizing overdraw on opaque polygons and that's where their theoretical fill-rate is quoted from, but with partially transparent polygons the situation changes. In terms of raw fill-rate the PSP has a clear benefit. Look at it this way (as a broad sweeping statement that totally disregards the myriads of ways game contents differ): the first iPhone was barely able to run relatively simple 3D content at ~30fps. The 3GS is roughly twice as fast in real-world scenarios. So hence you get original iPhone content running at 60fps, or fancy shader stuff at ~30fps. I've already stated that hardware is largely irrelevant in the market. Better hardware is not going to make the App Store climb up from the $0.99 hole. Even the original iPhone could have supported epic, massive, console-like experiences just fine if there was a mass of customers willing to pay premium pricing. I still enjoy discussing the improvements made possible by the hardware, though. I've said the bottleneck is the system bus through which all reads and writes happen during every frame that's rendered, and you again mention on-chip values that have little relevance. There is no separate bus from graphics to memory at 4.6GB/s on the iPhone. Let's compare: iPhone 1G system bus - 32 bits at 103MHz -> ~393MB/sec (corrected) iPhone 3GS system bus - 32 bits at 150MHz -> ~572MB/sec PSP system bus - 128 bits at 166MHz -> 2.6GB/sec PSP VRAM bus - 256 bits at 166MHz -> ~5.3GB/sec (iPhone specs from here) The iPhone numbers are far from the peak data rates within the chips themselves. For fun with numbers, divide the bus bandwidth with the framerate you're aiming for to see a theoretical peak value of data you can feed to the chip per frame. This must include all geometry and textures because the MBX and SGX have no local graphics memory, only a small cache to assist with tile rendering. Hence my comparison of iPhone to a laptop with integrated graphics. The situation is similar to a graphics card accessing all its relevant data and writing to a framebuffer over the PCIe bus. This is what I'm referring to with architectural compromises. Having a tile-based renderer as the graphics chip is essential, a traditional chip would totally choke, but the PowerVR architecture still manages to get a decent performance. This supports what Bmamba said, you want to keep your textures small on the PSP. The small size of the local graphics memory on the PSP is the reason why PSP games tend to be visually bland. I guess the iPhone is better in that regard, i.e. you're bandwidth bound, not so much texture memory bound. Not at all. My comments seem to be misinterpreted as some kind of iPhone bashing, or saying it can't run games due to its architecture compromises. This is far from the truth, there are plenty of fun games on the iPhone. You could say that the iPhone (and 3GS) are intended as 30fps devices. The hardware is capable of it, even the PowerVR developer documentation encourages to target a fixed framerate, using steady 30 as an example. The benefits are obvious as there's less a load on system resources (helping with battery usage), and that leaves cpu cycles for background tasks. 60fps is possible (here's looking at you, TrueAxis), and I tip my hat at the achievement. If you understand the intended performance of the device, you can still make excellent games within those bounds, and certainly break the bounds if you're hardcore and looking for trouble. The PSP is still a console in the respect that there are very little things happening in the background when a game is running. On the iPhone, the system is still responsive to phone calls, push notifications, playing mp3 songs while a game is running etc. and these functions need their share of cpu cycles. With all the above being said, I believe it's highly unlikely that future portable devices would be similar to the PSP in architecture. Unified memory will probably be the design choice in portable games consoles, and therefore the question will be how they address bandwidth bottlenecks. If a PSP2 still aims for being a hardcore gaming console and not a casual device, it needs to address performance with either large caches or wide buses.
The question is how far can you go for 60fps and 30fps. Pretty far off what the tech specs recommend - even more if we could program the iDevices at the lowest level (which Apple will not allow). The screen shots here (just to show what is been rendered) run at 60fps on a 3GS and 30fps on the older hardware. You really need to see this all move to understand what's going on here. When I originally got Space Tripper to run on an iDevice (the older devices) some levels ran between 9fps to 12fps. And the best levels at 20fps. Pretty crap really. That was a year and a half ago - since then every thing has been optimized to hell, from the data structures, GPU and CPU. Extremely high intense work. Those 9/12fps levels run at a solid 30fps on the older hardware now, that's some pretty far out optimization. There's some more stuff I need to do for the older hardware, and now that Jet Car Stunts is out of the way with the latest update I can get back to Space Tripper on Monday. The levels with optimization can be broken down into 3 areas: 1. GPU limited. The first world of Space Tripper is GPU limited. So many alpha polygons. 2. GPU and CPU limited. Alien world fell into this group. 3. CPU limited. Aztec world fell into this. There's a crap load of baddies on the screen. I need to get some time back on the CPU for the older hardware, just so it can run smoothly. It may not be possible but it could as well. If I can pull this off then people will wonder how the hell this is all possible. If you look at the radar on some of those shots - those dots are baddies. This gives you some idea on how much processing is needed for the baddies. So in short Space Tripper will be the most optimized game ever on the iDevice. Is it justified? Only if it sells but it may just brake even. Will I ever do it again? No, that type of intense work just burns you out.
I think most of you saying how nice the idevices are , is because that msot of you are really old. You guys played SNES/NES and your comparing graphics to those...
Yes, being in my 80s with a failing eyesight, I just can't stand these small pixels on modern screens. Get off my lawn unless you played Gateway to Apshai on Commodore 64 And seriously though, what on earth would you compare the iDevices to, Xbox360? They do have the most powerful 3D graphics in a cost-effective, casual audience, broad appeal, low-power multipurpose device so far. The funniest thing is, if you watch Star Trek - The Next Generation, you'll notice that the gadgets they were envisioning for the 24th century are already outdated by Apple's UI and industrial design. Imagine that!
Old yes, but not "really old" must admit i also had a c64... that was a burner compared to the pc at that time, coz it had 16 colors compared to 4 colors (cga,ega or something like that) on the pc. Anyway, the good thing aboiut the Idevice&Gaming is, it's a "mobile device", always with me and the thing that is actually missing are the "3gs"-titles. Almost any dev is developing for 2g/3g because so many people still have this device and it's nice get any infos about the 3gs and it's graphic abilities. It seems to be powerful (for a mobile device)....well, Apple sold so many 3gs/3rd Gen Touch the past quarters that it's time to move on. 1g,2g,3g.....like Jobs recently said (regarding Flash) "it's old technology"
Thank you very much for the thoughtful reply. I've been sick with kidney stones and am feeling better now. Hurrah! Yes. So, I really don't trust that website for specs. I mean, it lists the 1g iPhone as having cache, and the 3GS as not, when in fact, we know the 3GS has more cache. On the the SGX's bandwidth. You've been assuming thus far that the SGX has no on-chip cache. The SGX specs specifically speak of 3 caches: http://www.imgtec.net/factsheets/SDK/POWERVR%20SGX.OpenGL%20ES%202.0%20Application%20Development%20Recommendations.1.1f.External.pdf The rough idea seems to be this: 1) It gets all the trianges, does all vertex processing, culling, etc., then writes compressed stream of info on them back to memory 2) the tile processor starts fetching them per-tile and rendering This seems to be inefficient from a system memory point of view, but efficient from a pipeline point of view...the USSE's can be on full vertex duty the one way, and pixel on the next. It caches instructions that it doesn't have the right data i.e. textures, etc.... Results are rendered to the on-chip tile buffer...which means that after that expensive first step, the frame and z-buffer rendering is only limited by how fast it can clear that buffer to main memory in between bouts of rendering. OK. The last thing of note that document mentions is the memory bus. It says not to do large copies or send lots of big textures all the time. Going back to sorting based by texture, it seems like this is the most important thing to pick up for optimizing any 3g/3gs game: sort your polygons by texture first, or you'll choke the already small memory bus. I'll grant you it's not likely that the SGX gets 4.6gb/s access to memory. That 572mb/sec seems actually reasonable considering the rendering architecture, though. I mean I can see how it could do really good with that. The first problem is that we're using DDR here...that Doubles the Data Rate. We're already at 1.1gb/s, about half the throughput of the PSP's GPU. This doesn't make a huge difference for random-access stuff, but for things like texture reads, it's king. It lets you burst data 2x faster. OK, we are already doing pretty good actually. I mean 1.1gb/s isn't so poor. But this is where it turns into speculation unless a hardware engineer can get back to me... PVR was around designing chips long ago, and they were being partnered with ARM long ago. The Cortex A8 has a fully cached architecture, unlike the ARM11. It is more than possible that it could actually be a 64-bit double-bandwidth bus, by the simple nature of dual-channeling the RAM. This would be a very inexpensive solution to up performance hugely. This would bump us up to 2.2gb/s minimum. Granted, it's speculation; I'm just saying, those numbers on a sheet you're looking at aren't the whole story. Now I'm a little confused by your "intended to be 30fps devices" part. 30FPS doesn't leave a big room for error - halving the framerate becomes catastrophic, and Apple's API's certainly make that easy enough. But 30FPS is "more than enough." The display doesn't even refresh at 60FPS, and the visual lag at 30FPS is null. Are you an FPS freak? Is it 60fps, gotta have the latest Radeon X9999999 or nothing? Bear in mind most XB360, PS3 games are targeted at 30 before you say it makes a significant difference. You're probably thinking of responsiveness. What makes the biggest difference with Apple far more than the framerate is the responsiveness of controls. The API is horrific, with the timers and method calls and constant interruptions. It's almost a wonder games are made at all on top of it. If you ask me, it's the software far more than the hardware that really gets in the way. What do you think, TrueAxis? If Apple provided you with a more down-to-the-metal SDK, and you got out from under the horrific development model (Apple's SDK) you're laboring under now, do you think you could've done all that optimization a lot easier? (The other question to ask is if the game is too ambitious for the platform...) I recall stories of earlier systems suffering from similar problems...and then an SDK specifically for gaming was released and changed everything...it was called DirectX. This is where my argument really starts to rest on shaky ground IMO. I believe that Apple is following their hardware push with a software one to match it. I believe there'll be an Apple DirectX coming, probably with the iPad. I hope there is! I mean anyone here can agree there's lots of potential...so will Apple act on it? @TrueAxis: what kind of GPU optimizations did you end up doing? Anything to do with sorting by texture before rendering? What did you find helpful? And I see like 100 enemies on screen...Assuming you're targeting 30fps, and you spent ALL your time working on them, that's not very much time each per frame. What are they all doing that's so complicated? Often they are optimized by doing a process similar to this: 1) Split the actions and re-actions for each enemy into seperate finite state machines 2) Group enemies into successively smaller groups of graded smarts levels; i.e., the whole enemy is "attacking," 1/3 of it is "being sneaky" while 2/3 is "going frontal," 1/8 of each of those 1/3rds is doing that in a sub-way...down to the point were individual actors really don't do anything on their own; 3) When the player produces an event they have to react to, a "reflex" is made such as "dodge left at max speed" based on their group behavior, and an input is sent into their group. This is to get 100 good enemies on the screen of a much more powerful say game console. You want 100 enemies on the iphone screen generally you gotta go the way of SI:Infinity Gene or Plants vs. Zombies and make them fixed-action. I'm so curious about what you're doing there! Are you really taking 100 intelligent actors at a time on the iphone!?
Look forward to minor vidual tweeks on the newer hardware because most people won't be retiring their 1st and 2nd gen hardware for a long, long time and developers are too smart to ignore them for the hardcore minority.
No, I've mentioned the cache before in my posts. While the exact size of the cache is unknown, its purpose is to hold data relevant to the tile being rendered (and perhaps help with some consecutive tiles). It's not a local graphics memory in the sense that it would hold entire textures. So the problem that textures bog down the memory bandwidth is still relevant. Sounds about right, although I must say I am not so familiar with the hardware to know which steps are performed at driver-level and which ones involve back-and-forth using actual computing resources on the chip itself. For example, if it's more efficient to do vertex shading on the cpu or the gpu etc. Texture fetching is still an expensive task, and happens at the last stage of rendering. While the tile cache probably helps on its own part, I believe the main reason to sort by texture is to minimize performance penalties from state changes, not so much to conserve bandwidth. Well, it does as well as we've all observed This is speculation. Using DDR doesn't necessarily mean that the memory controller supports double data rate, nor should we assume that numbers are twice that which we've calculated. For all we know the double data rate could be taken advantage of to halve the bus clockspeed. Now you're projecting your expectations on the device, hoping it's somehow more than it is. Remember, this is Apple we're talking about. Steve makes hardware as good as it needs to be, unlike Ken Kutaragi who dreamt of making hardware as good as it can be iPhone is a low-power portable device, it has enough bandwidth to perform media and browsing functions smoothly as a priority, and games "because it can". I have been involved in the development of a game for PS3 which was running at solid 60fps (Super Stardust HD), and appreciate the responsiveness it makes possible. That being said, the smaller the physical size of the screen, the less perceptible low framerates are. 20-30fps is perfectly adequate for most casual games. I would wager that for the majority of the casual gaming audience on the iDevices, even 15fps appears smooth. Heh, and for us who come from a mobile games background, the iPhone is a dream come true with no hardware fragmentation (well, before 3GS), OpenGL ES for smooth 3D graphics, and good audio capabilities.
@Writingsama What you need to remember is Space Tripper is a conversion of a PC game from around 2001. What you need to know is what worked well on the gfx cards back then is extremely bad for any iDevice GPU. GPU optimization methods. 1. Everything is sorted by texture. 2. Use the smallest packed vertex format you can get away with. 3. Make sure all vertex data is cache friendly. 4. Convert all world data to a PVS system with all the data cache friendly (waste a load of memory) 5. Render everything in the biggest batches possible. 6. Use texture atlases to help batch rendering. 7. Everything is software skinned to encourage large batches. 8. A well timed glflush will work wonders with the framerate. 9. Draw solid polys first then alpha. (Space Tripper has a shed load of alpha polygons). 10. With alpha polys after texture sort, sort by blend mode. The original source code did not do any of this. Just by doing all these things GPU rendering went from worst case 9fps to 30fps. I draw the world by texture sort in big batches. Then I draw all solid enemies from a texture atlas with one draw call. Then I draw all alpha from a texture atlas sorted by blend modes. Software skinning is far more efficient than hardware because you can create large render batches and transform the smallest amount of vertex data. You need to resort to ARM assembly language to get the best from this. By preloading cache lines, backface removal and lighting all done on the CPU you can get more vertex transformations through the hardware pipeline or basically eliminate the ones that get discarded. This helps the GPU loads. Yes you are right about the OS hampering the games framerate. And the more time the game uses the less responsive inputs go. Sound is a big issue as well. Never use OpenAl it eats so much time. I wrote my own sound mixer, using the Audio Unit and did all sound processing in the callback. Doing this eliminates some of the OS spikes most games suffer from. There's a load of other things you can do to get the OS spikes to a bare min and to make inputs responsive but I'll keep that to myself It gives True Axis a big advantage. What you say about processing baddies is true - that's what it does now but the original code did not. The biggest hit is collision detection... baddie to world, player to world, bullets to world, baddie to player, baddie to bullets, player to bullets, bullet to bullets. There's lots of tricks that can be done to get this down to bare min calculations. But barring in mind the CPU is doing a lot of glDriver overhead and the vertex processing for software skinning (needed to make the GPU more efficient)... so assembly language is needed to get some time back for logic. With assembly language and preloading cache lines you can get a 2.5 to 3 speed increase to code that was compiled by the compiler.
@Writingsama I forgot to answer one of your questions. Yes, if Apple made the OS good for games and let me program the GPU at a low level, then yes my job would of been easier The game is possible, I think, but what worked well in 2001 on the hardware at the time, is bad for the powerVR GPU's. The problem is the games data is not efficient for the iDevice - it is now. Also, it's a challenge to get this to work... If I pull it off for the older devices then True Axis will get a pretty good name for technical excellence, which we more or less did with Jet Car Stunts. All good for future business planning. If I don't pull it off then the game is fantastic on a 2nd gen iPod and up to the newer hardware. But less money to make of course.
From my point of view, the 3GS wont last long as a target for games. In fact, it currently is not a target, because the major device in the wild is the 3G. But when the 4G arrives, the contracts for the 3G fade out, so most people who want to stay on the Apple platform will switch from the 3G to the 4G and skip the 3GS. I also think, that the 4G will therefore outsale the 3GS. So the next big platform where games will be developed for will be the 4G, with 3GS and 3G being still supported, but not being a direct target. Maybe Im wrong. I dont know what will happen to the millions of 3G phones. Maybe they will get dumped, maybe they will get sold and put into the 2nd hand market.
It's a good point because here in germany you just get iphone with a 2 years contract, but in summer/spring 2009 alot of 2g & 3g devices were sold over ebay, so guess a lot made use of the "Additional Payment" to get out of the contract or purchased a device in Europe. But the biggest market is -i guess- the US for Apple and the devs, so germany itself is pretty uninteresting (sadly). Anyway, i don't think the 4g will have a better gfx-chip inside, maybe minor improvements, but nothing unexpected new, Apple wants compatibility through the devices, but there must be a cut one day (3gs/4g - 2g/3g). And with the release of 4g it may be the best time to develop for 3gs&4g devices. It really sucks to have a graphic-chip with more power, new functions, but it's rarely used.
The 3GS hardware sets the baseline for GLES 2.0 games, there's no way it will be ignored in exchange for a device that has even less market share. In fact, the 3GS may well be the most powerful GLES 2.0 device for a long time to come. If Apple follows the screen resolution race and puts a 800*480 screen on the iPhone 4G, there are no guarantees that the graphics performance will go up by a similar factor. If you look at the Nokia N900 or Nexus One, both have acceptable hardware to perform most of their duties, but fall behind in game performance due to fillrate limitations.
Extremely interesting discussion. I'm gonna get Space Tripper when it comes out just because all of the magnificent optimization work that has been done on it. Good info, thanks everybody. I'm a day-time .NET developer and have done some iPhone development, but nothing OpenGL or gaming related yet. This makes me want to get into it, just for the hell of it.
@Frand I did end up doing too much speculating. Let's return our feet to the ground. 1) The MBX Lite was still adequate for the 3GS. It is so overpowered for the iPhone OS it's a bit ridiculous. What possible motivation could Apple have had for upgrading it unless it is for high-performance applications? And what high-performance applications are there for mobile...oh yes, games... It is true that games were first "because it can" on 1st and 2nd gen devices. But then Apple started making tens to hundreds of millions on games, games, games. The top grossing game on the store since before Christmas has been COD:WAW:Zombies, only being offset a few times. This is probably the only big-name "hardcore" game the iPhone *has*, and it is a good indicator of things to come. As we know, the casual gaming crowd is a huge one, and the iPhone sells a lot of those. It should. But the hardcore crowd is good too, they're the ones that make PS3 and XB360 and Wii (yes "hardcore" gamers have Wiis too) profitable. Wait, are the PS3 or XB360 profitable yet? I haven't kept up with the console wars much. Apple is certainly very profitable. Anyway, back to the "hardcore" gaming crowd. It's there. Cod:WAW:Zombies, NOVA, and more, prove it. It's not like COD:WAW spiked briefly. It's still going strong, 3 months long, and was the highest grossing and #1 paid app over Christmas, which netted them at least $20 million over Christmas alone. It wasn't a spike by a small segment of gamers that grabbed it up. And you can't say it's not a hardcore title. The biggest obstacle to their technical feasibility - controls - has been largely solved. (And that's the biggest technical hurdle for any game on any platform, and often cripples games that would be AAA) You have to remember that people don't buy the iPhone just for games. But when hardcore gamers get it, let's say, for just a phone, they discover games like COD:WAW, and then hey, hardcore gamers are playing! As the dearth of sequels teaches us, big publishers are complacent. People are getting bored of Gameloft's reskinning of FPS's under different names (sandstorm, nova, brothers in arms...) and are begging (even in the reviews on the app store) for innovation. The kind that Thief, System Shock, Deus Ex, etc. pioneered. (Looking Glass we still miss you!) 2) A 32-bit 150MHz bus doesn't use DDR to halve the bus rate...from a hardware engineering standpoint that would be a nightmare, would choke performance, and kill the platform. The power savings would be so negligible. You wouldn't see the 40% processor speed gains when the 3GS has with a mere 17% clock rate increase. You may as well stick with DRAM at that point. It's reasonable to assume that DDR is what they used, since in mass production DDR is so cheap it's practically free; it's unreasonable to assume they down-clocked DDR to 75MHz in order to make their lives nightmares and degrade performance. It's also unreasonable to assume that the chipset can't handle it. Adding DDR to a memory controller is drop-in functionality, not special hardware design. Downclocking DDR 200MHz to 150MHz would allow them to use mass commodity parts, proven technology, good energy savings, easy engineering, and get a nice performance boost. If DDR is in the iPhone, it's running at 150MHz, period. And it's cheaper than most embedded-level RAM and has the power savings, too. The only other real alternative for Apple in their phone is 1T-SRAM type stuff. 3) You did mention the cache...but check out the architecture documents. There are separate caches for vertex, texture, tile data, and maybe another, I'm not reading through it again right now. Which makes a lot of sense, because... 4) As John Carmack himself (aka The 3D Graphics Man, if not the current one) implemented, and TrueAxis just confirmed, sorting by texture is probably the most important general performance optimization. At least for the MBX Lite; it certainly doesn't kill the SGX (despite the SGX's lower theoretical fill rate) and the architecture lends itself to a texture sort on the SGX. 5) This is a really interesting discussion, but I think we've probably about reached the end without going into pure speculation. Let's agree on a summary: -1 The 3GS *probably* has the technical capability, if PERHAPS not the current software implementation, to create at least PSP-competitive graphics, and larger more complex worlds due to its larger RAM. Only Apple's future actions, which we can't predict with accuracy, will show what they really made it capable of. Regardless, the 3rd-gen hardware is pretty future-proof, since it establishes that shader baseline. Another example of a game with improved experience that comes readily to mind is BIA 2, which doesn't play with the crisp clarity of NOVA on 1st and 2nd gen hardware. -2 The marketplace has the potential to expand towards "hardcore," even if it doesn't happen with big-name publishers very soon (though Gameloft is sure making a pretty penny exploiting that void...). The PSP and DS will be getting more big games for a while to come at least, and the iPhone is not a PSP in terms of actual "hardcore" games available. Unless you really, really like racers. Then you might want to get an iPhone. To my knowledge there are more racers you'd actually want to play on the iPhone than the PSP. LOL. -3 iPhone > DS. I mean we all knew that. Technically speaking of course. -4 The 3GS is unlikely to be exploited by developers tomorrow, unless Apple starts some kind of a drive, such as getting a real Halo, a REAL killer game, that only plays on the 3GS (Halo and superior online are basically how Microsoft broke into the console wars for real). It is possible that Apple will retain the segmentation, as the continued side-by-side 2nd gen and 3rd gen hardware sales show; those who want the higher performance can have it for a premium, and are encouraged to get it (8gb ipotch for $200 or 32 with upgrades for $300? Come on!) -5 The 3GS provides a good upgrade to the experience of those games, such as COD:WAW, or TrueAxis' upcoming games, and is worth the $100 extra investment (sell old 32gb ipotch for $200 first), since it is likely to support at least a pretty good version of games if and when more "hardcore" games come and target it. -6 If you just want to play time management games stick to your 1G device, it's fine for it. How's that sound? @TrueAxis It sucks that the SDK compiler is so poor that you're finding 3x speedups over what it produces. ARM isn't even a tough target. Who does Apple have working for them? Assembly is easy, optimizing in assembly is hard; I give you lots of props for what you've done. (Unless you just write really, really poor C code and much better assembly code...) You mentioned software skinning was a lot faster. I'm assuming you're talking about the MBX. You mentioned that what works on the MBX at 30fps (did Apple remove the 27fps cap?) works on the SGX at 60, I'm assuming you haven't bothered to poke at it and stretch its hardware skinning capabilities since it works fine and you have to work so hard for the MBX? You also mentioned doing multiple well-timed glFlush() per frame. I don't know much about actually working with PVR chips (and I didn't read any of that optimization document I linked except for the hardware overview), but I'm wondering if on the SGX that may change. Regardless, I've learned so much about the architectures from these discussions that I think I've figured out the rough timing of your glFlush() calls, but I won't share them here. Be careful what you reveal... Thanks so much for sharing your technical experiences! I own Jet Car, but I haven't gotten too into it. I have way too many more games than I can play and have a life, I am going through them two by two or so and it'll probably take a year. It is an awesome game though and I'll try your new one right away. Hey need a beta tester that can speak programming? I play on a 2nd-gen ipotch.
@Whoever mentioned the resolution rush That's so pointless...800x480 at 3.5"? Well, maybe not, but that's the limit. Really. I'd personally rather have HD video out, and x264 hardware support without re-encoding, but that's a whole other story. Apple uses pretty low-quality screens though. They use the same manufacturers as for their macbooks and they exhibit the same quality issues: poor contrast, interlacing-like artifacts on some ipods (I had to return my 2nd gen ipotch 3 times to get a good one :-( ), etc. I think the biggest barrier for Apple in this arena wouldn't be hardware specifications but rather getting manufacturers that suck less to supply parts at the prices they want to pay. I'm not one of those people who buy a macbook and expect a perfect, gleaming, amazing machine with no faults whatsoever. But seriously. The screens on modern macbooks have been really below-average at their price points for years now. You can find nicer screens on $500 PCs (albeit with lower specs, battery, etc. etc. etc.) @TrueAxis about sound: Yeah, the SDK is horrible for sound. Don't knock OpenAL, it's Apple's implementation that sucks. You're using an API to hardware and software designed for playing glorified MP3s, not designed for mixing audio channels. Audio synthesis and mixing can go from so simple to so complicated, and if you're doing simple stuff (decoding audio, mixing it, time warping, a few effects) it's almost always better to go with middleware or code your own to your specific needs, especially in these platform constraints. I would say always, but then I can't see Diner Dash needing that. But maybe it does? What do I know. *shrug* I do remember an OS update that messed up the sound for like every game though. Wait, I said if you're doing simple stuff. But if you're doing complicated stuff, wow, you REALLY want to bake your own. OK. Devs: do your own sound if you need performance. Even decoding AAC is really easy to learn and implement and won't add much to your dev time. Also, sort by texture. Also, sound is a big area I could see huge gains in optimizing in assembly. Depending on how poor the compiler is. I mean we're talking about compiling C code! It's pretty close to the hardware as it is! Is it really that bad TrueAxis? Is your compiler really that bad? REALLY? And while I'm preaching to devs, please, please, PLEASE remember you're on a portable device. Please. Don't make audio integral to the experience (unless you're making Rez). Put subtitles on speech. Few devs are making this mistake nowadays but some newcomers still do. Often when you're mobile you can't have/don't want sound. And a voice-acted cutscene with no subtitles is boring and loses the plot for you. Finally. @Doom2RPG I know you only want one save state, and that you want people to be able to go back and load if they mess up. I get it. That's why you ask people if they want to resume from where they left off. A call should not destroy 30 minutes of play, I don't care what you say.
