NOBLE APE MAIL OUT - NOVEMBER 2002
Welcome to the November Noble Ape Mailout. This month has focused on three developments. The Noble Ape Simulation code continued to develop and methods of documentation continued to be discussed through the Project's log;
NOBLE APE 0.658 - work in progress
The development this month has been concerned with making the Simulation core object-based. To-date the Noble Ape Simulation defined the size of ape population and island fundamentals before the software is compiled. Whilst there were random islands and apes, the number of apes and fundamentally the number of islands were preset. This has changed in the past month.
The original decision to make large components of the Noble Ape Simulation pre-defined came from the introduction of the Noble Ape Project on the 68000 processor. The need for optimum speed on the 68000 required very specific code. Components such as the Simulation's cognitive modelling were designed to use memory as efficiently as possible. This required a degree of control which didn't allow for a random number of apes or apes leaving or entering the island environment in a haphazard/on-the-fly way.
The development of Planet Noble Ape required a lot of dynamic memory use and thus it was only a matter of time before dynamic memory handling filtered through to the Simulation core. Aside from the dynamic nature of object based simulation, the graphics and interface code has been streamlined considerably through the introduction of object based code.
The Mailout has a very broad readership, some may not be familiar with the distinctions of dynamic memory. The new object based method treats each ape and island with a defined block of memory which can be added or removed on the fly. This grouping of memory with specific components of the simulation is described as being object based. Prior to this development, the Noble Ape Simulation grouped all the apes and the island definition in distinct but clumped memory which was defined when the software was compiled. This non-object based approach had some benefit on older processors (like the 68000).
The object based changes promote productive rework in other aspects of the Noble Ape Simulation development - in particular with Ocelot and the Generic Platform Interface. The GPI/Windows development has taken priority this month. Thus the redevelopment and implementation of a version-independent Ocelot should occur next month. The timeframe for the Ocelot development is still a good couple of versions away.
This year has been the most productive in terms of version releases and development of the Noble Ape Simulation ever! Six version releases already this year and the Simulation itself has distinctly improved. Another note-worthy edition this month has been a correct Save/Save As/Close interface. The dream within the next 12 months should be a version of the Noble Ape Simulation which can simulate multiple environments simultaneously - multiple Planet Noble Apes or a combination of the Planet and the Island.
PLANET NOBLE APE
The Planet Noble Ape development has been heavily intertwined with the Generic Platform Interface (GPI). Early this month, Planet Noble Ape was the first Noble Ape Project software to run on Windows for at least three years. Aside from this development, Planet Noble Ape continues to be defined both through the Noble Ape Project website and also through my offline testing and development. One such offline development has produced great results with the cube-sphere approximation. This is rendered at a much higher resolution than the development code on the site.
The new Planet Noble Ape resolution should be around 512 x 512 points per surface (six surfaces per planet) with higher resolution interpolation available. The final format may include some of the more traditional Noble Ape Simulation land generation, but the current refining 32-bit 8x4 spread method works very well.
The current movement method based on surface direction, rotation and moving forward/back is compatible with the existing Noble Ape Simulation movement. It feels very natural on the Planet surface.
The aim of the Planet Noble Ape development is to provide the Planet as a functioning module of the Noble Ape Simulation. This requires integration from both the Noble Ape Simulation and Planet Noble Ape. The early development in this direction has been completed with the object based simulation and removing the biology elements to a separate section of the core simulation. This new code references biology only through land-surface values, not island generation primitives.
GENERIC PLATFORM INTERFACE
I began describing the GPI last month. The development has continued to be driven both by research interest and also practical purpose. In short, the development is concerned with finding the minimalist, simplest interface to port all Noble Ape Project software through. The principle is - write a GPI for a platform and you inherit all the Noble Ape Project software in one form or another.
The current GPI development is concerned with the minimal number of functions and data transfer. Whilst the Noble Ape Simulation is partially ready for the GPI, the current application used for developing the GPI is Planet Noble Ape.
In recent days I have reworked components of the Noble Ape Simulation to allow a transparent GPI port. This strips some of the functionality currently - it returns the Simulation to a single window interface and requires additional development to support the full menu interface of the Noble Ape Simulation. The integration of the Simulation into the GPI represents the next level of developmental testing, after the Planet Noble Ape/GPI integration.
Planet Noble Ape was ported to Windows early this month. The development has been partially maintained but through the GPI almost all the Noble Ape Project applications will be available on Windows in the near future. Maintaining active Windows development as well as Macintosh and providing the tools for Windows programmers to compile and contribute to the Noble Ape Project is central. The GPI development as a porting tool in itself may encourage other developers to use this technology to port their code to a diversity of platforms.
Following the Windows GPI development, I plan on implementing a Palm GPI. Palm provides a couple of challenges for GPI implementation namely screen size and keyboard input. The event structure is also more fundamental than Windows or Macintosh. Another port-platform could be Motif/X-Windows/Linux. I haven't planned on this development in the next six months although something may come of this within the next year or so.
The diversity of visitors to the Noble Ape Project website continues to grow. On average twenty more unique visitors look at the site per day than two months ago, raising the average to roughly 80 unique visitors per day. Whilst there are a combination of factors that produced this increase, the evolving site layout and regular updates both automated and manual have assisted. The site has been listed on a Mac OS X application development site. The next step is active publicity. More on that in the new year.
Hope all is well with you all,
Tom Barbalet, 29 November 2002.