What this feature hopes to achieve is a clearer understanding of what challenges the iPhone audio developer faces, how to overcome them, and, in fact, what game audio on the iPhone really means.
Worth a read if you are new to this.
Epic Games, the creator of the widely-used Unreal 3 game engine, is gearing up to release its Unreal Development Kit (UDK) for iOS, which will give iOS game developers unrestricted access to powerful 3D game development tools.
The UDK is Epic’s free version of the Unreal Engine, a powerful game engine that has been used to power such graphically intensive titles as Gears of War and Epic Citadel (pictured)—the latter of which has already been released for iOS as a demonstration of the Unreal Engine 3′s performance on the platform.
When it ships, the UDK iOS will include the same editors and code used to create a number of blockbuster games, and will be available to anyone wishing to publish games via the App Store. Toolsets of this quality generally cost developers anywhere from $500 to tens of thousands of dollars, so by releasing the UDK for free, Epic is drastically lowering the barrier of entry for iOS developers wishing to create graphically impressive games.
From MacWorld.
Should really turn things on its head in 2011.
Sony’s Networked Application Platform is a project designed to leverage the open source community to build and evolve the next generation application framework for consumer electronic devices.
The foundation upon which this project is base comes from the GNUstep community, whose origin dates back to the OpenStep standard developed by NeXT Computer Inc (now Apple Computer Inc.). While Apple has continued to update their specification in the form of Cocoa and Mac OS X, the GNUstep branch of the tree has diverged considerably.
Interesting choice from Sony.
Some insight into how the “streaming textures” are done in Rage…
The id Tech 5 engine uses a uniform paged virtual texture system for basically everything in the game. While the algorithm would be possible on 3GS and later devices, it has a substantial per-fragment processing cost, and updating individual pages in a physical texture is not possible with PVRTC format textures. The approach used for mobile RAGE is to do the texture streaming based on variable sized contiguous “texture islands” in the world. This is much faster, but it forces geometric subdivision of large surfaces, and must be completely predictive instead of feedback reactive. Characters, items, and UI are traditionally textured.
We build the levels and preview them in RAGE on the PC, then run a profiling / extraction tool to generate the map data for the iOS game. This tool takes the path through the game and determines which texture islands are going to be visible, and at what resolution and orientation. The pixels for the texture island are extracted from the big RAGE page file, then anisotropically filtered into as many different versions as needed, and packed into 1024×1024 textures that are PVRTC compressed for the device.
The packing into the textures has conflicting goals – to minimize total app size you want to cram texture islands in everywhere they can fit, but you also don’t want to scatter the islands needed for a given view into a hundred different textures, or radically change your working set in nearby views. As with many NP complete problems, I wound up with a greedy value metric optimizing allocation strategy.
Managing over a gig of media made dealing with flash memory IO and process memory management very important, and I did a lot of performance investigations to figure things out.
Critically, almost all of the data is static, and can be freely discarded. iOS does not have a swapfile, so if you use too much dynamic memory, the OS gives you a warning or two, then kills your process. The bane of iOS developers is that “too much” is not defined, and in fact varies based on what other apps (Safari, Mail, iPod, etc) that are in memory have done. If you read all your game data into memory, the OS can’t do anything with it, and you are in danger. However, if all of your data is in a read-only memory mapped file, the OS can throw it out at will. This will cause a game hitch when you need it next, but it beats an abrupt termination. The low memory warning does still cause the frame rate to go to hell for a couple seconds as all the other apps try to discard things, even if the game doesn’t do much.
Interestingly, you can only memory map about 700 megs of virtual address space, which is a bit surprising for a 32 bit OS. I expected at least twice that, if not close to 3 gigs. We sometimes have a decent fraction of this mapped.
A page fault to a memory mapped file takes between 1.8 ms on an iPhone 4 and 2.2 ms on an iPod 2, and brings in 32k of data. There appears to be an optimization where if you fault at the very beginning of a file, it brings in 128k instead of 32k, which has implications for file headers.
I am pleased to report that fcntl( fd, F_NOCACHE ) works exactly as desired on iOS – I always worry about behavior of historic unix flags on Apple OSs. Using this and page aligned target memory will bypass the file cache and give very repeatable performance ranging from the page fault bandwidth with 32k reads up to 30 mb/s for one meg reads (22 mb/s for the old iPod). This is fractionally faster than straight reads due to the zero copy, but the important point is that it won’t evict any other buffer data that may have better temporal locality. All the world megatexture data is managed with uncached reads, since I know what I need well ahead of time, and there is a clear case for eviction. When you are past a given area, those unique textures won’t be needed again, unlike, say monster animations and audio, which are likely to reappear later.
I pre-touch the relevant world geometry in the uncached read thread after a texture read has completed, but in hindsight I should have bundled the world geometry directly with the textures and also gotten that with uncached reads.
And OpenAL…
OpenAL appears to have a limit of 1024 sound buffers, which we bumped into. We could dynamically create and destroy the static buffer mappings without too much trouble, but that is a reasonable number for us to stay under.
Another behavior of OpenAL that surprised me was finding (by looking at the disassembly) that it touches every 4k of the buffer on a Play() command. This makes some sense, forcing it to page the entire thing into ram so you don’t get broken sound mixing, but it does unpredictably stall the thread issuing the call. I had sort of hoped that they were just eating the page faults in the mixing thread with a decent sized mix ahead buffer, but I presume that they found pathological cases of a dozen sound buffers faulting while the GPU is sucking up all the bus bandwidth or some such. I may yet queue all OpenAL commands to a separate thread, so if it has to page stuff in, the audio will just be slightly delayed instead of hitching the framerate.
I wish I could prioritize the queuing of flash reads – game thread CPU faults highest, sound samples medium, and textures lowest. I did find that breaking the big texture reads up into chunks helped with the worst case CPU stalls.
OpenGL ES 2.0 or 1.1? Particularly interesting to me as I still primarily code with OpenLG ES 1.1 in mind but support 2.0. However, I am fast moving towards a 2.x model for future projects.
There are two project technical decisions that I fretted over a lot:
Because I knew that the basic rendering technology could be expressed with fixed function rendering, the game is written to OpenGL ES 1.1, and can run on the older MBX GPU platforms. While it is nice to support older platforms, all evidence is that they are a negligible part of the market, and I did give up some optimization and feature opportunities for the decision.
It was sort of fun to dust off the old fixed function puzzle skills. For instance, getting monochrome dynamic lighting on top of the DOT3 normal mapping in a single pass involved sticking the lighting factor in the alpha channel of the texture environment color so it feeds through to the blender, where a GL_SRC_ALPHA, GL_ZERO blend mode effects the modulation on the opaque characters. This sort of fixed function trickery still makes me smile a bit, but it isn’t a relevant skill in the modern world of fragment shaders.
Some general notes…
The other big one is the codebase lineage.
My personally written set of iPhone code includes the renderer for Wolfenstein RPG, all the iPhone specific code in Wolfenstein Classic and Doom Classic, and a few one-off test applications. At this point, I feel that I have a pretty good idea of what The Right Thing To Do on the platform is, but I don’t have a mature expression of that in a full game. There is some decent code in Doom Classic, but it is all C, and I would prefer to do new game development in (restrained) C++.
What we did have was Doom Resurrection, which was developed for us by Escalation Studios, with only a few pointers here and there from me. The play style was a pretty close match (there is much more freedom to look around in RAGE), so it seemed like a sensible thing. This fits with the school of thought that says “never throw away the code” (http://www.joelonsoftware.com/articles/fog0000000069.html ). I take issue with various parts of that, and much of my success over the years has involved wadding things up and throwing it all away, but there is still some wisdom there.
I have a good idea what the codebase would look like if I wrote it from scratch. It would have under 100k of mutable CPU data, there wouldn’t be a resource related character string in sight, and it would run at 60 fps on new platforms / 30 fps on old ones. I’m sure I could do it in four months or so (but I am probably wrong). Unfortunately, I can’t put four months into an iPhone project. I’m pushing it with two months – I have the final big RAGE crunch and forward looking R&D to get back to.
So we built on the Resurrection codebase, which traded expediency for various compromise in code efficiency. It was an interesting experience for me, since almost all the code that I normally deal with has my “coding DNA” on it, because the id Software coding standards were basically “program the way John does.” The Escalation programmers come from a completely different background, and the codebase is all STL this, boost that, fill-up-the-property list, dispatch the event, and delegate that.
I had been harboring some suspicions that our big codebases might benefit from the application of some more of the various “modern” C++ design patterns, despite seeing other large game codebases suffer under them. I have since recanted that suspicion.
I whine a lot about it (occasionally on twitter), and I sometimes point out various object lessons to the other mobile programmers, but in the end, it works, and it was probably the right decision.
John Carmack
10-26-2010
Dear Unity Developers,
Our long awaited user conference, Unite’ 10, is only one day away and we hope to see you in Montreal! If you can’t make in-person, you can still be a part of the Unite experience and listen to the live keynote speech, delivered by our CEO, David Helgason. Simply go to unity3d.com on November 10 at 16:00 CET (GMT +1:00).
Some big announcements are coming, so stay tuned!
Regards,The Unity Team
Programmers have very particular font needs. A font for programming must be monospaced, extremely readable, and must sharply distinguish between similar characters, such as capital O and zero and the number 1, capital I, and lowercase L. In addition, good programming fonts allow you to view more lines of code on screen at once.
From Keith Devens.
Handy little resource.
Research In Motion (RIM) is extremely excited about the opportunities available with the new BlackBerry® Tablet OS and its corresponding application platform. Building on the incredible power of the QNX operating system that’s uniquely suited for tablet computing, the BlackBerry Tablet OS will lay the foundation for the future while preserving the key investments that have made the BlackBerry platform so successful.
Having a look at the getting started guide now. But bearing in mind that it’s just for Adobe AIR apps I might wait until they release the real SDK.
I warned Palm about this approach.
Stroustrup had been hacking away at his replacement for the C programming language at AT&T Bell labs since 1979, where he and his colleagues in the research department were given free reign to experiment with new ways of building software.
I was 10 years old. A handful of years later I would get a Commodore Vic 20, and learn BASIC. Shortly after I would jump into machine code, and never look back.
[October 14th] 1985: The first official reference guide for the C++ programming language is published.
I learned today that not only do I share my birthday with Cliff Richard, I also share it with my second language; C++. My first language being machine code.
When I was writing games for home computers, and arcade games I simply did not get what C, or C++ was all about. The transition in the games industry from machine code to C++ was like a tidal wave of terror for me. So much so that I ran from job to job where I could still craft in what I believed at the time was the one and only language I would ever use.
C++ went on to become one of the most popular programming languages ever created. It was designed to be a “general use” language: It can be run on just about any platform, and it shows up almost everywhere, especially in videogames and embedded systems.
Although I am still most at home coding in ASM, C++ has become my native language these days. The main occupant of the bag of tools I now take to work for most jobs I may encounter.
I do still have a little black wallet, lovingly wrapped in wax paper, in my tool box, tightly packed with little op codes for those special occasions. And of course a big brightly coloured plastic bag full of Objective C.
I guess if I had thought of it and had some marketing sense, every computer and just about any gadget would have had a little “C++ inside” sticker on it.
Imagine if Microsoft had got its hands on Stroustrup!
Fantastic interview with Stroustrup, from Michael Calore for Wired. Well worth a read.
..[A] simple MacOS X app takes your archived IPA file and creates the required manifest and HTML files for wireless distribution. It even zips up a copy of the app for folks on 3.x that need to install via iTunes.
Looks interesting. Ironically it’s still in Beta itself.
For the past few years, we’ve had to go through the same song and dance: gather device IDs, create ad-hoc builds and then try to explain to users how to install them via iTunes. This can be trying for even technical users and non-technical users can get totally flummoxed. Let’s not even talk about people on Windows where the files often unzip in strange ways, leaving them totally confused.
I had this exact problem yesterday with my Graphics guy and his PC.
iOS BetaBuilder is freeware and runs on MacOS 10.6 or greater. You’re welcome to use it however you’d like and feedback is encouraged but I’m not in a position to offer any support – you use at your own risk blah blah blah.
I’ll be using it this week, and will provide feedback as an update to this post.
UPDATE : Used it today to distribute a Beta build of a project I am working on. Works as advertised. Recommended.
A handy reference.