Sweet zombie Jesus, what a stupid dialog box.

Eclipse Software Updates dialog

It seems Apple have reinvented the job-system method for parallelizing tasks across multiprocessors.

I’m amused, because this has been a hot topic in games programming since the introduction of processors like the Playstation3’s CELL CPU, and has probably been around for even longer, but I’m too lazy to google any references.

Key findings from “Interactive Australia 2009” research, published by Bond University.

• 88% of homes have a device for playing computer or video games.

•  68% of Australians play computer or video games.

• 46% of gamers are female.

• The average age of an Australian gamer is 30 years.

•  84% of Australians aged 16-25 compared with those 50+ play computer and video games.

•  The average adult gamer has been playing for 11 years.

•  Half of all gamers play daily or every other day, a quarter play once a week.

•  The average game play session is one hour.

•  Computer and video games compete with other media leisure time, not with outdoor activities.

•  70% of parents in game households play computer and video games, 80% of these parents play them with their children.

•  78% of parents say an adult is present when games are purchased for their children,

• 92% of parents say they are aware of the games played in their homes.

•  75% of all computer and video games classified in Australia are G or PG (Classification Board).

•  63% of adults do not know that Australia has no R18+ for computer and video games.

•  91% of adults (including gamers and non-gamers) say Australia should have an R18+ classification for games.

What say you now, game-haters?

Well, using Xcode to build iPhone ready resources is a lot easier than I thought it would be.

I once had the misfortune of working with The Worst Resource Builder in the World.  It would take hours and hours, and then crash or simply lie about having completed. Most of the developer’s time was spent trying to figure out what data they need to jiggle, just to be able to run a build. What was even more painful was that it was completely re-written to be distributed, without improving the reliability. The main change was that now you needed to walk around to random machines in the office and restart each offending builder.

Anyway, as I mentioned in a previous post, I’d like to be able to transform COLLADA files into my own model format, in a reliable and easy method as possible.

Doing the exact opposite of my previous experience seemed to be the logical start – make it simple. The simplest thing I could think of was to use make. And then an even simpler idea was to use Xcode, which would use make for me. It turned out to be correct.

So I had DAE (COLLADA model) files, my “convert_dae” program which generates LXTM files (Luxatron model file), and my Xcode project. Here’s what to do.

1. Right click on the target for the project, and go to the ‘Rules’ tab.
2. Add a rule of type “Source files with names matching”.  For the match field, I put “*.dae”.
3. For the Using option choose “Custom script”.
4. For the script I entered:
   “/Users/Justin/Projects/msg/src/tools/convert_dae/build/Debug/convert_dae ${INPUT_FILE_PATH} ${TARGET_BUILD_DIR}/../..”, which simply uses the Xcode environment variables to call “convert_dae” with two arguments – the input file and an output directory.
5. For output files I entered:
   “${TARGET_BUILD_DIR}/../../${INPUT_FILE_BASE}.lxtm” which tells Xcode where the output will be and what they are named.
6. Then I added the DAE files required by my project into the “Resources” folder.

Thats it. From now on editing the DAE files means they get automatically converted from wherever they are and correctly added to the project’s resource bundle. Win.

This resource was pretty useful, and Apple have some good documentation on their developer site.

This is why programming in a language that hides the hardware from me makes me scared. Note the order of severity below – its not what most people would choose, but its correct:

Data alignment: Straighten up and fly right.

“If you don’t understand and address alignment issues in your software, the following scenarios, in increasing order of severity, are all possible:

• Your software will run slower.
• Your application will lock up.
• Your operating system will crash.
• Your software will silently fail, yielding incorrect results.”

Well written article, worth a refresher if you’ve forgotten why you should care about alignment.

First big COLLADA mesh converted and loaded – over four thousand triangles of ducky goodness.

Sony Duck

There’s still lots of work to be done in the converter:

1. The converter is currently outputting four floats for RGBA color per vertex, it really only needs a single byte for each channel, reducing the size from 16  to 4 bytes.
2. Each vertex is treated as unique, so there is massive duplication of vertex information. Essentially the indexes are a range from 0 to 4211. This is because the COLLADA description of streams is is very flexible and allows vertex attributes like normals, colours etc to be at a different frequency, something that OpenGL ES 1.1 does not allow. So essentially I take the easy way out and make every vertex unique, duplicating the attributes, without checking for which vertices are *really* unique and adjusting the indexes.
3. Textures are ignored, as are complex models with sub-meshes.
4. At the moment I have to remember to manually run “convert_dae duck.dae” and then copy the output “duck.lxtm” directly to the projects resources folder, when either the DAE file changes or the .lxtm model format changes. This should be an extra ‘Build’ step in Xcode.
5. No attempt at mesh optimization or triangle reduction is made. I probably won’t get around to this for the first release. Although its a fascinating Phd worthy topic, its too easy just to make the (human) modeller responsible right now.

I have now have

• a mesh class with batches per material,
• a simple scene graph (eg a linked list),
• quaternion/matrix conversion code.

There is a simple model class that contains a tree of “meshes”.

However at this point I really need to be able to load some interesting data. Spinny cubes don’t cut it anymore.

COLLADA is an text format for interchange between 3D programs (like Max, Maya) and your engine code. Until the creation of COLLADA, there was simply no common way to share 3D information.

However, for me (and every other game developer), the problem is that I really don’t want to be loading and parsing DAE files (XML) which describe several thousand polygons each. COLLADA has a concept of ‘conditioners’ and ‘refineries’ which are really just fancy names for old-school game “data converters” or “data packers”.

So my next bit of work is to look at creating a build step with an offline tool hosted on my mac. The build step will simply “make” (in the makefile sense) my nice binary data from source COLLADA files (.DAE).

Oh and for what its worth, the “engine” or framework I am developing (as a base for the actual game) has a name: LUXATRON or LXT for short. And I already have the domain name.

I’d love to see “Powered by LUXATRON” on the splash screens of some cool iPhone games in a years time. And my Ferrari will be red. The only colour they should be.

Here’s a screeny of the customary rotating square demo:

Spinny!

Features at play here:

1. A simple OpenGL ES renderer with a nice vertex declaration interface – currently supporting lit, textured and vertex coloured triangles (or any combination thereof). There’s also a handy wrapper around VBOs that I’ll go into in the future.
2. Texture loading (currently only 32bit PNG files, massive overkill for the LCD screen).
3. Texture based font rendering – two fonts are visible here, my personal favourite “Georgia” for the text and “Arial” for the frame timer. The font class uses the output generated by the excellent “bmfont” tool available free at www.angelcode.com .
4. A slightly inaccurate frame timer

Confession – I actually got started a couple of months ago, but didn’t think of writing about it until just recently.  Unfortunately, progress is pretty slow, as this isn’t my full time project. However, the good news is that I have a bunch of stuff almost ready to post.

Pardon me while I wrestle with the formatting – this is my first time using WordPress on a non-default format. Small children or those with a weak constitution should avert their eyes for a few days…

I’ve compiled a list of things you need to get started:

1. Become a registered iPhone developer for free here: http://developer.apple.com/iphone/
   This gives you access to the all the online/offline documents and tools. You don’t need anything for this except an email account.
2. Get an Intel Mac. A new Mac mini will cost around AU$849. http://www.apple.com/au/macmini/
   You can now install the tool, build code and run the iPhone simulator. Theoretically this should be all you ever need to learn to program for the iPhone – but to run on actual hardware you need the next step.
3. Join the iPhone Developer Program for AU$129. http://developer.apple.com/iphone/program/
   Unfortunately theres a delay here of a a few weeks while they process your application. You pay once you’ve been accepted, and now that iPhone OS 2.0 is public the approval time should be picking up.
   You need this to be able to sign and execute code on a iPhone or iPod Touch.
4. Get some test hardware – a new 8GB iPod Touch from eBay is around AU$300.
5. Once you have hardware and dev program access, you can then follow an incredibly baroque process of certificate generation via the developer site. Once done, you’re now ready to have your own gravity sensing teapot application.

Total cost (if you don’t have a Mac or an iPod) = approx. AU$1278.

1. The iPhone/iPod Touch is a sweet machine: with a kick-ass CPU, and a kick-ass GPU.

2. The development environment is free(-ish) if you already own an Intel Mac. (More about this next time)

3. You can develop in a real compiled language in the C family – C/C++/Objective C. Inline assembly works. No JIT compilation, no virtual machines, just you and the code you wrote.

4. Personally, its a new thing to make my brain hurt while I learn, and thats when I’m happiest.