it compiles (again)

Noteworthy only because its been a few weeks, PySoy is compiling once again.

Also took care of those ugly warnings on soy.bodies, a result of ODE using const and Pyrex not. The solution was listed in the Pyrex docs, just a matter of finding it and plugging in the explicit typecast.

More work is needed on the Screen and Window classes before it can display anything. The freeglut->glx transition process is wrapping up but isn't finished yet.

adding "screens" to API

We hit a problem while implementing the new soy.windows.Window; when a window is created it must add itself to a global list of windows, formerly soy._core._windows (of type soy._imports.Children) in order for the coreloop to render it.

The problem is that with Pyrex, and I believe this limitation stems from the C/Python API, you cannot share variables and functions between modules unless they are in a class. So if the _windows list is moved to soy.windows coreloop would no longer be able to access it, nor call a soy.windows.render(), nor any other technique we've thought of.

Widgets must add themselves to a list of widgets in their parent window upon creation, and this works, because the parent window is passed as an argument to the constructor. We have no such mechanism for Window objects.

So after some brainstorming, and looking at various workarounds, I started thinking in the direction of a parent class to Window called Screen. This objects of this class would not be generated by the user, but rather created as part of PySoy's init and placed in a soy.screens variable (which acts like a tuple).

Thus, you would say mywindow = soy.windows.Window(soy.screens[0], 'My Window', size=(500,250)) or, should you wish, any other available screen. You could also look up or even change aspects of a screen through it's attributes. IE:

>>> soy.screens[0].depth
16
>>> soy.screens[0].size
(1024,768)
>>> mywindow.size
(500,250)
>>> soy.screens[0].fullscreen
None
>>> soy.screens[0].fullscreen = mywindow
>>> mywindow.size
(1024,768)

We'll need to do more research as far as cross-platform support goes before being able to change resolution/depth, ie I believe with X11 we'll need to provide a list of available modes to select from, whereas on Windows we may be able to attempt any resolution/depth (I may be wrong?). Perhaps the .size could be __set__'able but only to valid modes?

Being as we need this before PySoy can compile w/o freeglut I think it's best we move forward with this and work out the wrinkles as we go along.

soy.Window -> soy.windows.Window

After some discussion this morning it was decided that the best way to implement different platforms (and different Window types, ie, splash windows, dialog, etc) was to make it a submodule.

In Trunk, as of r39, src/windows-glx/ contains the code for GNU/Linux, src/windows-wgl/ will contain the code for win32, and src/windows-agl/ will contain the code for OSX. Each have their own .pxd file making it easy to pull in platform-specific libraries.

We still need to implement a platform-independent sleep function; usleep on GNU/Linux and OSX, Sleep on Windows. Since we need an elapsed time function as well this can be implemented in a few different ways.

freeglut's last straw

The nvidia bug has been found, though not explained; it disappears when coreloop is run as a function in the main thread (vs spawning it as it's own thread).

I have a difficult time believing that nvidia's drivers are thread-unsafe, so I must assume we've found a fringe-bug in freeglut that only appears when you thread using the nvidia drivers.

I've started ripping freeglut out replacing it with GLX/AGL/WGL code.

chimera genetics

I've flipped to my AI project for a bit after being frustrated by the nvidia bug. Yes, it's been a week with no progress on it.

Chimera, for those who haven't seen this working name before, is a PySoy extension module for "pet" AI which can be used in any game supporting the module (so your same pet can be in any game supporting Chimera).

It started over a year ago for Soya and, like PySoy, has been rewritten several times over. Originally it was to be akin to Pokemon, except open, so you could have virtually anything you could imagine. This had two main drawbacks; lack of "breed-ability" and extremely complex cerebellum AI required to "learn" how to move and effect it's environment.

The latter real-world animals have as instinct. Baby horses are walking within hours of birth, baby birds try to fly as soon as their bodies are able, baby mammals feed from mother's teat without external prompting, and despite language barriers all us humans use the same emotional expressions to communicate ideas (smiling, laughter, etc). In order to give this leg-up Chimera need to be based on the same base model; ie, all bipedal or quadrupedal, same senses, etc.

So the new goal is for Chimera to be of the same species and a sort of "genetic code", not DNA but an array of floats which can be mixed for offspring and random mutations allowing for surprising outcomes. Since some instinct (ie, how to walk) should fit the breed this becomes genetic as well, the parameters for how to walk being an example of behavior passed parent to child. Genetics only provide the base for behavior, each individual chimera will develop based on their own experiences. In real world biology this is called it's phenotype.

Using the walking example again, this means a baby chimera will get a small advantage from walking parameters combined with their leg parameters. It won't be perfect, but they'll likely be able to stand on their own and improve over time. The "play" associated with improving will likely be entertaining for players as well.

The current model includes 5 body-type morphs for running, climbing, flying, digging, and swimming, all quadruped (the flying type is more akin to a flying squirrel). It's best described as a squirrel or cat, small and able to sit on a shoulder. I hope to have procedurally created textures based on the genetic code for different patterned coats, each unique.