tequila bomb

Here’s How It Works

As a developer/creator of a project you can create a project here at 8-Bit Funding. Doing so will allow our users to fund your project in return for perks that you assign. These perks can range from a special thank you in the credits of a video game, to a pre-order, to a lifelong pass at “PWN Cafe” should that be the name of your cafe.

As a funder of a project you can comb through our various gaming related projects, find which ones interest you and then fund the necessary amount in order to acquire a perk. Perks are various rewards set by the project starter to reward you for helping complete their project.

Each project is funded via PayPal making this transaction easy and simple to use for almost anybody in the world, no matter if you’re a funder or a project starter.

We need more of this kind of thing.

Although it should be noted that “Upon completion of your project, we will release funds”. Which means that if you’re working on a longer project and do get funded you still won’t have any money until you have a complete project to sell.

“Apple didn’t have an in-house game designer before me so I think it was pretty unique,” Devine told Kotaku. “Game technologies touch everything from the graphics stack to touch latency to push notifications. No other app type covers so many technologies and having someone there to validate and help shape that was basically my day job. It was pretty kick ass.”

Overall I think Devine certainly made his mark on iOS. A lot of the graphic stack is certainly better put together (now) than anything on OS X – in terms of respective modern gaming support on the two quite different hardware platforms. It would be nice to think that he had some input there. I wonder how many frustrations he faced also with some obviously bad decisions at times.

“I don’t think a lot of people are really thinking yet what games mean on these touch platforms, the joystick is gone, there is no proxy in between you and the screen anymore,” he said. “I am not a fan of virtual d-pads, pointers, or other crutches, we have an opportunity on these devices to let players hold, move, touch, and feel the game in front of them and I intend to focus on that.”

Devine certainly gets the unique problems, and the unique opportunities of iOS hardware for gaming.

Despite his departure, Devine insisted that Apple’s commitment to iOS gaming wasn’t diminished. “I can’t comment on what’s next inside Apple, but I can tell you, they really do ‘get’ gaming,” he said.

Good to know. Let’s hope they don’t fall back into bad habits without his input.

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

Some real gems in here that anyone in the process of bringing games with more complexity than the likes of Angry Birds to any mobile platform should consider carefully…

Carmack says there is a sizable market of gamers who would like that FPS experience, and “want their iPhone to replace the PSP and the DS as a serious gaming machine. But they do not dominate the market.”

[But those kinds of games are not ] “as large of a success as Angry Birds.”

The market is there. But you need to produce something to the kind of quality that a significant, but specialised niche demographic will inevitably want from their entertainment.

We’re number 1 with the HD version, and the SD version is down like in the 30s or something,” said Carmack. “This is going to influence our thinking going forward — if it’s that big of a difference, we probably won’t offer the low-end, standard def version.”

Again, those with an interest in a high profile product like Rage on iOS, expect the best quality version possible. And it to be as immersive as possible.

That last point is partly why there is a bit of a backalsh in the more hardcore iOS gaming community about Rage simply being an on-rails shooter. Rage looks great, and plays great, but in the end I might as well be playing any aim and fire iPhone shooting gallery game.

My favorite part of the interview was at the beginning where Carmack echoed my own feelings about iOS development.

“Being able to work on a more constrained project now and then is rewarding in a lot of ways, and of the available small platforms, I think that the iOS platform is clearly the best.”

Like coding back in the good old days.

Benjamin Morrise got tired of waiting and began seeking assistance from various capable types to form a production team to build the iPhone controller accessory we’ve all (well, some of us anyway) been waiting for. The team he hopes to assemble consists of an Industrial Designer, a Mechanical Engineer, an Electrical Engineer, and a Software Engineer. The hope is for them to come together and build a controller for the gaming masses.

A much better design than the current front runner, which I think is fugly.

Benjamin, and his team, have some design headaches to overcome if they plan to support more than one model of iPhone or iPod Touch.

Morisse hopes to secure funding through Kickstarter.com…

But, I would buy one of these. I may even throw some help their way via KickStarter.

And any future games I do will support it, if it exists. I have one very special one in mind right now.

It’s no wonder that many of us often find solace in the high-concept games of the classical arcade era, that beautiful time in the 1980s when Pac-Man was god and Defender was thought to be too damn confusing. There is one game that towers above even those in my—admittedly minority—opinion: Robotron 2084.

Great article.

Robotron and Defender are still my all time favorite games.

Nothing has ever touched them.

Eugene Jarvis is also one of my all time heroes.

Bliss is finding an arcade with a well-maintained machine that still runs on a single quarter. If the time comes when I can’t find one, I’ll buy one for our basement and teach my sons to play properly. Robotron 2084, in some ways, teaches you to be a gentleman. Albeit a slightly brutal one.

Which is exactly why I do own a Defender and a Stargate arcade original.

I also have a set of Robotron boards, and the control panel.

They are among some of my most prized possessions. If my house was burning down I’d carry them out with me, along with the dog and right now my iPhone 4!

Apple has introduced a new iTunes feature spotlighting underrated gems, cult hits, and forgotten favorites in the App Store’s Games category.

Surprisingly, much of the list skews toward the hardcore end of the gaming spectrum, featuring lesser-known but excellent offerings like Cave’s bullet-hell shooter Espgaluda II, Square Enix’s real-time strategy title Hills and Rivers Remain, and indie standouts Eliss and Orbital.

Cool. This is a nice new feature for the App Store.

It may go some way towards mitigating some of the true gems that seem to sink into App Store oblivion that I touched on in the piece I discussed here.

The Macintosh platform is renowned for being a graphical powerhouse, but this refers to professional/prosumer photography and the like. For gaming, Apple has been slow to include support for new hardware and new driver features (they are just now OpenGL 3.0 compliant) and overall their drivers are more conservative when it comes to performance. Portal is going to be slower, the question is by how much.

…

Portal – like all Source engine games – is CPU limited when given a powerful enough GPU, and even with just a GTX 285 we can approach that under Windows. Under Mac OS X however, we look to be GPU limited at all times.

…

Ultimately having the Source engine ported to Mac OS X is going to remove the technical need to use Bootcamp to run Windows for games, but based on Portal it doesn’t remove the need to boot Windows for performance reasons. For long-time Mac users none of this should be surprising, but it means that we shouldn’t expect the Mac OS X version of the Source engine to be revolutionary.

Let’s hope that both Apple and Valve work to further embrace gaming on the Mac moving forward.

So far I’ve found the Steam experience to be enjoyable. The idea that once I’ve bought a game I can use it on any platform, and any machine is revolutionary. It shouldn’t be, but it is.

It would be a shame to have that spoiled by Apple’s lagging OpenGL gaming support, and Valve simply porting titles – as opposed to putting some effort into specialising Mac versions for OS X and its quirks.