0.678 was released earlier this month. Folks who like the significance of numbers will note that such an interesting version number won't occur for another 111 releases. At the current speed of release, this will take just over four and a half years. The big changes in this version all came under the hood and related to the new modular ApeScript and a new threading model I would like to explore in later versions of the Simulation. The Apple threading model related to splitting the code associated with the cognitive simulation on two new threads which also tied in with their vector mathematics implementation of the cognitive simulation.

The new threading model identifies that much of the graphics rendering, weather simulation as well as the cognitive simulation and potentially ApeScript are all thread ready. Whilst there is some order in some components of the Simulation, in general there are a number of sections that can be calculated concurrent with other sections.

As my recent migrant status continues, I don't have access to any machine - including a P4 - that would benefit from any thread implementation of the Simulation. Whilst I have tried to push my P3 laptop into hyper threading, the software emulation doesn't provide the speed improvements. Looking at the most cost effective methods in actively testing threaded versions of the Simulation a number of ideas come to mind. Some easy ideas - consider buying a Noble Ape tshirt or ask if rabbits fall in love this Valentine's Day with a copy of the Original Manuals.

But seriously, the threading model can be tested relatively effectively through a console compilation of the Simulation run under Cygwin or any similar UNIX emulator.

On this point, I recently dusted off NobleMake and will be using it actively in creating a command line version of the Simulation for regular testing. NobleMake is one of my favourite Noble Ape byproducts and it has the benefit of working on Windows, Linux, Mac OS X even Mac Classic circa 1987. Nothing like a truly platform independent compilation assistant.


Historically any major changes in the Noble Ape Simulation development were written about in documents and then referenced in the mailout. As the Mailout is now being referenced as a primary source for changes to the Simulation, on Wikipedia amongst other sites, I wanted to try something new and launch a new development project through the mailout. The worst that can happen is I have to write an introductory document later on.

For the past year I have been evaluating graphics technologies - language to hardware APIs like OpenGL, ActiveX, and middle layers like, Ogre - to see if there is a viable mainstream graphics method that could provide a rich 3d graphical environment. A dream, that I am code naming ''True3D''.

Imagine if you ran the Simulation as a full screen 3d environment where you could watch a series of Noble Apes or actively select a particular Noble Ape. Each Noble Ape would be fully graphically rendered showing their age, size and sex as well as their genetic markings through their fur colour and patterning. The Apes would inhabit an accurate 3d representation of their environment including the biologically simulated plants, animals and insects that the Simulation currently simulates. In addition the cognitive simulations would actively be drawn as rotating cubes above each Noble Ape's head. You can move through this environment through a full six degrees of freedom (movement through space and any camera angle).

In terms of development time, there are a number of considerations with the True3D development. Some background history, in 2002 I experimented with mirroring the Simulation at the time through an OpenGL interface. This produced a very jerky and generally disenchanting version of something that was visually similar to the subsequent Ocelot interface. In short, it was better to develop Ocelot than tinker indefinitely trying to improve a limited OpenGL implementation.

I have explained this candidly to a number of OpenGL and polygonal graphics evangelists over the past four years. Their general pitch relates to the latest top-of-the-line graphics technology which doesn't lend itself to the average Noble Ape user. Contemporary computer games, for example, still provide a very limited environmental subset compared to a truly random Noble Ape Simulation environment with completely free camera locations and angles. So following the True3D through a contemporary graphics language route, does have some development pitfalls. The aim is to get to a point where I can establish could the Noble Ape Simulation environment be simulated with contemporary graphic cards without too many hardware requirements.

What is the other option?

Moving Ocelot to a graphics method with five degrees of freedom shouldn't be too difficult. In fact, moving Ocelot to a graphics method that allows 45 degrees to top down (rotating the z axis) with a floating height away from the ground and the usual x-y movement and rotation would be very easy and eliminate the need for the Map window entirely. I have looked at this problem before and considered it too confusing an interface - although it lends itself to Noble Warfare. This still is quite a distance from the kind of graphical interface I am describing for True3D. It also continues to link the Simulation's graphics environment to software rendered graphics. With threading this can be split to a second processor, but it would be nice to utilise a GPU too.


For the past four years I have been corresponding with fellow ALife developer, Dave Kerr. Dave produced the highly successful Windows ALife simulation, AIPlanet, and is working on a new graphics engine for ALife and other applications currently codenamed, AIR. Chatting to Dave this week, he noted that a DLL of the Noble Ape Simulation would be extremely useful to his development of AIR as it would provide him with a stable ALife project though a unified API. Dave currently develops in Delphi, for the computer linguists on the mailout, they will appreciate the differences between Delphi and, the language most of Noble Ape is developed in, C.

With a number of relatively autonomous modules, the creation of a DLL version of the Simulation begs the question - what should go in the DLL?

I have a number of ideas about this. The Simulation Core could be included on it's own without too much work. Memory management APIs would need to be added, but that lends itself to a hyper-object oriented skin to the various simulation core APIs which should work without too much effort. In addition, ApeScript would be quite useful in a DLL form, particularly with the ongoing discussion of modularising ApeScript into something that is meaningful. A DLL would make it meaningful. In addition, I could easily provide a full memory managed DLL version of the Simulation to maximise the black box nature of addressing the Simulation.

All this is yet to be discussed with Dave - but it is an interesting development I wanted to put out to the mailing list for feedback.


The success of the Noble Ape Simulation example movies has made me think about using other media types to get the ongoing narrative of developing the Noble Ape Simulation out to the masses through any media necessary. An interesting fact, the BBC Radio 4 interview on Noble Ape and simulating life is the third most popular file on the Noble Ape site. So clearly, there is already a group of interested ears waiting to hear more about the Simulation and related development.

I have done four test records on various topics and with various audio recorders to try to get the format right. 15 minutes per segment seems ideal. Each available for download - about 1.5Mb per segment.

I'm hoping to have more information online in the next couple of weeks - check the Noble Ape site for update information. The next mailout should provide a lot more information.

Hope all is well with you all,

Tom Barbalet, 26 January 2006.

Noble Ape - Mailout Archive