Sprinting toward Beta-3

We've made some massive headway in the last two weeks;

First, we have physics processing back. We're using ODE for now just to get us through the next release cycle or two, but we've modified its headers (ABI-compatible) to work better with libsoy. Done are the days when we stress over API compatibility, since we've decided to write our own fully integrated (and scaled down) physics processing with Orc we have a certain freedom to throw their conventions to the wind.

How this is going to play out is a slow migration of values to arrays. Body data, for example, will be stored an array inside a scene so SIMD processing can be used more efficiently. The Soy Body class will represent a pointer to that array and include properties and methods for working with its data. The actual storage of that data will be governed by the Scene, giving it the freedom to sort bodies per "island" (groups of bodies connected by group). This is similar to how ODE processes bodies already and we'll be likely using their code as a starting place.

Second, we have the basic types for rendering. At the moment this is just a rotating cube, but that involved roughly 6 classes operating in both GObject and Python domains. The next step is soy.models.Mesh for rendering more complex shapes.

Third and most exciting, our humble game engine can now run as a Firefox plugin! There's some bugs to be worked out still, but "embedded" support has been added to our soy.widgets.Window class that allows it to run inside virtually any application.

With luck and determination we'll have the next release out by the end of the month. I've dialed back our goals considerably given that its a rewrite from our last beta release but our release cycle will be much shorter now that the rewrite is finishing up.

New import (and export) mechanism

I've started writing a new import mechanism for .soy files, replacing the old soy.transports module with a importer that allows .soy files to be loaded as modules with the standard Python import command.

With the old method, "transport" objects acted as dicts of objects in the .soy files and could be loaded and saved as such. The resulting code looked like this:
import soy
MyGame = soy.transports.File('data/MyGame.soy')
window = MyGame['window']
redblock = MyGame['redblock']
(etc)

Now, the new .soy importer is added to sys.path_hooks when PySoy is first initialized and applys to any directory added after. When finished, the above code could be rewritten as:
import soy
sys.path.append('data/')
import MyGame


No "etc" needed because in that one import command data/MyGame.soy is loaded and made available directly in a module called MyGame. Much more pythonic, IMHO.

A separate class will be written next called soy.Exporter which PySoy objects can be added and removed from, then saved to a file such as this example which modifies the previously imported MyGame module:
archive = soy.Exporter(MyGame)
archive.grasstex = grass_texture
del(archive.bricktex)
archive('data/MyGame2.soy')


Similarly, two archives could be combined like this:
archive = soy.Exporter(MyGame)
archive2 = soy.Exporter(CharacterFoo)
archive += archive2
archive('data/MyGame3.soy')


The reasoning behind this is in most cases .soy files will be written by GIMP or Blender, so the most common use case for the soy.Exporter class is for combining and pruning the .soy files created by these tools.

As always, constructive/critical feedback welcome and appreciated.

libsoy migration milestone

After a great deal of time (I'd rather not admit how long) we've finally managed to link the new libsoy code in with Python.

This afternoon (around 4:30) the following code opened a PySoy window on the screen:

arc@khonsu ~/work/pysoy $ python3
Python 3.1.3 (r313:86834, Dec  5 2010, 09:55:24) 
[GCC 4.5.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import soy.widgets
>>> w = soy.widgets.Window()
>>> 
(soy:16042): Gdk-CRITICAL **: IA__gdk_window_set_title: assertion `title != NULL' failed
IRQ's not enabled, falling back to busy waits: 2 0
OpenGL version 2.1 Mesa 7.10
GL_ARB_vertex_buffer_object: Yes

While incomplete and, well, its only a window, this is the first time we've gotten the two pieces to work together. David Czech and I have spent the rest of the evening fixing both build systems (libsoy and PySoy) and getting ready to copy the window binding code for the rest of the engine.

Our largest failure in this has been diverting so much energy into GObject Introspection. While its a really great idea and I'd love to see it evolve, its still so deep alpha that I can't imagine anyone but Gnome developers getting much practical use out of it. I would like to finish up GTypes at some point, but either the XML format for .gir or any level of documentation on typelib needs to be written first. I've wasted far too much time already trying to reverse engineer these from examples and their source that should have been put into my own projects.