r600

A quick update to INSTALL (dependencies list) brings us up to r600. This makes about 50 commits in the past month.

... of course with the sprint ongoing we're likely to reach r750 by PySoy's Beta-2 release next week.

fresh soymilk!

While this is a blog about PySoy, a 3d engine for Python, this post is about a soy related product I recently fell in love with.

It's called the SoyQuick soymilk machine. Basically a pitcher, heating element, grinder, filter screen, and some sensors in one package.

You throw in 2/3 cup of soaked soy beans, fill water to a line in the pitcher, plug in a standard power chord (same as computers use), press the start button, and 15 minutes later fresh soymilk in the pitcher and okara in the filter basket.

This awesome machine plus an ample supply of Special Gunpowder Green Tea is what's fueling me through the PySoy Beta-2 release process.

Beta-2 task assignments

Looking at beta2 tickets there's an extremely disproportionate number of tickets being handled by yours truly.

If you can participate later this week or as part of the sprint, please take a look through what needs to be done and volunteer yourself for some of the workload. Many of these unassigned tickets almost anyone can do without previous experience with PySoy.

Sprinting to Beta-2

What a better way to kick off 2008 than with the long-awaited Beta-2 release of PySoy?

We've been lazy though, very little has been committed since Beta-1's release a few months ago. To play catchup and get us focused enough to reach this goal a sprint has been scheduled for the last weekend of 2007 (Dec 28-30).

The physical site for the sprint is in Manchester, NH. A bank of public IPs (no NAT), caffeine, desktop space, and inflatable crash mats await those able to make it. RSVP for the address.

For those working from home we'll have IRC and video conferencing throughout the weekend. If you're planning to participate join #PySoy or get your webcam working with Ekiga.

Even if you have no experience with C programming or OpenGL we need people for documentation, writing examples, and unit testing. Being inexperienced is an advantage for locating inadequately documented classes and filling in the gaps!

Every serious participant will be mailed a silk-screened "PySoy Sprint 2007" patch. Sews easily to a backpack, jacket, etc to let the world know that you helped make the PySoy revolution!

dependencies upgraded

Pyrex 0.9.6

There's a few API changes which result in warnings, we're going to keep things the way they are now until Ubuntu and a few other distributions have this version available, or 0.9.7 is released, whichever comes soonest.

---

ODE 0.9

ODE's new version comes without an updated changelog, however, a diff on the include directories shows very few API changes from 0.8.

Because Ubuntu 7.10 just came out with ODE 0.8 we're going to stick with ODE 0.8 compatibility for the time being. Those previously trying to install PySoy on Ubuntu may remember having to manually install ODE 0.8 as the last packaged version available for Ubuntu was 0.5.

---

Theora

We may need to update for libtheora beta2 since there were numerous changes since alpha7, however, beta2 is not packaged for most distros yet (ie, both Gentoo and Ubuntu only run alpha7). It would seem prudent to stick with alpha7 for now.

Server move

The server hosting *.pysoy.org has been moved from Ithaca, NY to my new home in Manchester, NH.

It's now on a much faster connection (I've clocked over 850k up) and a decent UPS to reduce downtime to near-zero. I used the switchover time to upgrade the software and tighten security a bit, too.

Sorry for the downtime, it'll be worth it in the long run.

Maintainer's Update

It's been awhile since I've posted so a quick update;

We've got two new developers, KirkMcDonald and DerekRhodes. Kirk has taken over the Win32 porting and Derek is working on materials/textures.

Toba has remained active after Summer of Code. He's also the only student to complete his SoC project and thus receive full payment.

I've been in the process of moving so my free time for PySoy has been limited. I'm generally available via IRC for questions and, now living in Manchester NH, will be able to pound out some code again once part of my studio is setup here. It's going to take me months more to move it all.

We'll have Beta-2 out by the end of the year at the current rate with Win32 compatibility, input handling, and model+texture loading/saving.

beautiful mistakes

Fullscreen and splash window (ie borderless) support is in. I ran several systems overnight with a script which flips between fullscreen and windowed every second to ensure there's no threading issues with the new code.

In the process I generated this great mistake, basically what happens when you don't clear the background while rendering the collision blocks. We're going to have to do more complicated mojo to make splash windows "transparent".

Overall work on the engine is on-track for Beta-2.

Now on to dynamic text textures

Beta-1 Success & Bugs

A mere hours after Beta-1's release bugs started getting found. This was entirely expected.

The largest problem people have had is with installing ODE 0.8 on Ubuntu. For whatever reason the last packaged version available to Ubuntu users is 5. Installing from source means editing /etc/ld.so.conf to add /usr/local/lib and running ldconfig, something a bit scary to new users.

Overall positive comments from testers though. It's great to get this sort of confirmation even with the engine so incomplete. Of course Beta-2 with input support and mesh loading will be much better.

A month off from that point, here's another screenshot.

power outage

Ack. Thanks to a long term power outage the svn + website server was down for several hours today delaying work. With luck we should have that release out tomorrow (7/10).

Three tickets remain

The last of the beta-1 tickets have been delegated. Hopefully they're easy ones.

Then we start with the final check to make sure nothing obvious segfaults.

the day before beta-1

Today we saw one of the largest recent API changes come to pass, "mesh" is now something that can be applied to a Body, not a type of Body itself.

soy.bodies.Pyramid is gone, there is now a pyramid.py in tests/ which provides it for the test scripts. I also copied over the blocks.py file from Blockdropper (one of my old Soya games) and updated it's API for our engine. That is the screenshot I included here.

There are a few tickets remaining for Beta-1, but barring some last minute critical bug discovery we should be set in the next 16 hours.

"State of the Soy" @ r400

I just committed revision 400 which sets video playback to realtime. Yes, video, we now have the ability to stream Ogg Theora as a texture onto a canvas or mesh.

Working backwards, Toba got some more shapes committed (ie, box) so collision is progressing nicely. We can now stack widgets by depth (layered), horizontally, or vertically with aspect ratios and margins. All soy.Window functions (ie position, resize, title change) are working.

We have a basic light/material model working (1 light, 1 texture), with textures being imported from PIL, and every form of 1d and 2d texture is supported including greyscale, greyscale+alpha, color, and color+alpha. These can be shown on a canvas or mesh.

Just 2 days out from Beta-1 with a handful of critical tickets remaining, I think we'll get it ready. The most exciting work is still a few weeks off, though. Stay tuned.

soy.Window ready for beta-1

About a quarter of the Beta 1 tickets were various bugs in soy.Window left behind when we migrated from GLUT.

After a day of work I'm happy to announce that they've all been fixed:

Multiple windows work, I tested a loop to create 100 of them then destroy them all in various orders.

.position and .size can be both accessed and changed from the Python side. I tested with multiple windows to ensure each had it's properties being updated in realtime. While we don't have container widgets yet each widget gets a _resize call whenever the parent window is resized.

The window's .title can be set in realtime. I spent a number of hours trying to get the window's icon setable to a 2d texture but gave up, more code is needed here than I have time for.

Dynamic camera changing for a projector is now supported as well. That was a trivial little bug..

Overall we're close to 60% finished with the weekend remaining to finish them up. I'd like to dedicate Monday to packaging it up and getting the list of dependencies together.

recent work update

We're 4 days out from beta-1 now, at this point we're starting to see all the things that won't get done in time.

Angelo got lights working, or at least one light. More work is needed before beta-1. Texturing is acting odd in that it's colors are ignored if provided from a soy.colors.Color (while they work fine without texturing). Static colors work fine. I can only guess as to the reason behind this.

Today Toba got fields to activate based on collision shapes, a huge step forward. He added a new test script to show this.

I managed to get much further with File loading; transports are now being processed by _coreLoop (through an ugly hack), codecs are identified, and Theora streams are being initiated. I hit a barrier with trying to use dicts within coreloop, so before moving forward the soy._internals.IndexTab class will need to be finished (which will provide lookup of void *'s from either int or char* key, each object having both).

Jayce dropped out of Summer of Code. His work has been pushed to beta-2 for others to finish.

Nothing from Mike recently, we still need work done for joints.

SVN now open, GPLv3 applied

I'm sitting in the FSF office in Boston as I write this:

svn.pysoy.org is now open to the public for download.

The LICENSE text for the GPLv3 has been applied, minutes after RMS's announcement and livecast.

Note that this is NOT Beta-1. We're aiming for 7/9 for the first "release". There is no guarentee that this will compile or run (but it should). Check out the tests/ directory for some cool stuff we've done for testing purposes.

... and enjoy.

subversion to open Friday

We'll be opening svn.pysoy.org to the public on Friday afternoon (June 29th) by 5pm UTC, just after the release of GPLv3. The code should not be considered usable in this state, it may not even compile depending on recent commits, and no support is offered for it as we're extremely busy getting ready for Beta-1 release.

The engine's Beta-1 will be released Sunday at earliest (July 1st) and possibly as late as Monday July 9th. At that time the ticket system will be re-opened to users and support offered. Betas should not be used to build anything "real", as API changes are still pending and several critical features are missing, but is useful for learning and helping us track down the bugs in our current code.

GPLv3 and game media licensing

Seems the GPLv3 is sufficient to ensure that entire PySoy-based games are also free. The key to this is in section 5c of the "last call" draft which specifies the "whole of the work, and all its parts, regardless of how they are packaged" as covered by the terms of the license.

Copyright law does not follow technical rules of how a work is constructed or distributed, it follows human judgment of what a "work" includes. For games this is simple; a game, including all it's parts, includes any media designed for that game. It does not include media arbitrarily loaded by the user, such as generic CD tracks the player of a game selects to be played, which contains no hooks or labels specific to the game or it's engine.

That is, a judge is likely to rule that a song created about alien invasion of length 1 minute 20 seconds, the same length as a cut-screen showing aliens invading, and which is labeled by a convention (file named cutscreen05.ogg) the game uses to determine which music to play, is a part of total work.

However arbitrary media files, such as tracks of a friend's CD, which are not designed specific to the game and which are interactively selected by the user may even be included on the same CD or tarball with the game. Such bundling is called an "aggregate", the license is explicit in permitting this sort of bundling.

I created a game licensing page on our website with more details on this and some ideas for making money using the "gaming as a service" model.

r200 status

We've reached another artificial milestone, what a better time to deliver a "State of the Soy"

First our physics model is coming together nicely; we have working joints with constraints and can connect bodies. Bodies can be removed from a scene and added to another scene retaining their parameters and state, joints not so much yet but soon. Initial work on fields has started.

Next our rendering model now includes GLEW and Vertex Array support along with a legacy fallback. To show this the "Pyramid" test class now inherits Mesh and uses it's render function. No normals or texture coordinates yet, the latter because texture support hasn't been added to this version yet.

soy.File is mostly ready though the load/save functions still need to be added to, well, everything. The basic .soy file format, now embedded in Ogg, is working. There is not yet a global _files array nor does Coreloop process File so delayed loading, especially of Vorbis/Theora, is not happening yet.

soy.colors has been populated. There's now over 100 colors available by name.

Work was started on the MacOS X version of _core, utilizing Carbon for "native" windowing support. We'll hopefully see a fully working version for that platform soon.

I've heard work on the Windows version of _core was started but nothing has been committed yet.

Overall our pace is accelerating; the more pieces become complete the easier it is to work on the remaining. Our roadmap remains unchanged for Beta-1 release July 1st.

intel's x3000 vs radeon x300

Just ran across a great review of Intel's X3000 (aka GMA 3000) chipset, for which they supply free software drivers for and work with the community to support, vs the free software Radeon drivers produced by the DRI team on the Radeon X300.

Great. Now I need to own one, another test system in the office :-)

If you're into Intel-based systems this certainly looks like a great choice, and what a better way to show Intel you appreciate and support their commitment to the values of free software (at least in regard to their hardware support)..

AMD, clueless

AMD (which recently acquired ATI) has recently made a buzz about how they are going to do better with working with the GNU/Linux community. This offer seems to be taking the form of faster release cycles for their proprietary driver for GNU/Linux, a closed & NDA'ed beta-testing program, and abandoning "older" drivers such as the r200 series that DRI supports well.

They still don't seem to understand that while the quality of the driver and it's release is of some importance, the license of that driver is the deal breaker.

Give us a poor driver with a free (as in freedom) license and the community will make it great.

Give us an excellent driver with a proprietary license and only a minority of users will use it.

Why?

Many distros, I'll use Fedora as an example since AMD spoke about this at a RedHat Summit, will not package proprietary drivers. Ubuntu, which I believe is the most popular right now, is on the fence and, at the very least, warns the user.

To add to this many free software developers ignore ATI's drivers as proprietary. As a result there is little GNU/Linux software that takes advantage of the higher end cards, the free DRI drivers on an r200/r300 card work just fine for almost everything. They certainly will for PySoy-based games.

Why would a user, then, pay $100+ for a higher-end video card when a $35 Radeon 9250 is better supported? For users it's thus a good consumer choice to stick with the cards supported by the free drivers regardless of that user's view on software freedom.

But AMD seems ignorant that GNU/Linux is about freedom, much like McDonald's board of directors meeting over poor sales in India. I imagine a meeting like this:

Sales VP: "They don't like our beef"

Marketing VP: "So we'll give them better beef, fresher!"

Technical VP: "We could slaughter the cow on site if it helps"

Sales VP: "That could be a great slogan, 'fresh from the cow'"

[cue standard nods and voicing of agreement from around the table]

r100

If you're one for artificial milestones, note that the 100'th commit was just made to Trunk.

It's great seeing all the pieces come back together the way we planned.

fixed joints are now working

Note that soy.joints must be manually imported at the moment; this way any bug in soy.joints will not interfere with testing other parts of PySoy.

import soy
import soy.joints
sce = soy.Scene()
cam = soy.bodies.Camera(sce)
cam.position = (0,0,10)
py1 = soy.bodies.Pyramid(sce)
py1.position = (-2,0,0)
py1.rotation = (0,2,0)
py2 = soy.bodies.Pyramid(sce)
py2.position = (2,0,0)
py2.rotation = (0,0,3)
scr = soy.Screen()
win = soy.Window(scr)
pro = soy.widgets.Projector(win, size=(320,240), camera=cam)

You'll should see two pyramids next to each other rotating on different axis. Now for the fun part:

jnt = soy.joints.Joint(sce, py1, py2)

Presto - they're locked together as if they were one larger object, their rotational velocities blended. You can watch their .rotation change. Now for the really fun part:

jnt = None

The invisible bond that connected them is nullified, and as such, they spin off in opposite directions with their own rotations.

This is only the beginning of course; there's 7 other joint types to be added!

IT WORKS

The final fix was just committed moving the glXMakeCurrent call to the _render() function (and, thus, the _coreloop thread). I've tested it to work on rage128, radeon, and nvidia (TNT2) cards.

Most notably we're still missing the event callback for changing the window's _width and _height when it's resized and the size __set__ code for changing the windows size from within Python. We could also use several more attributes and methods for, ie, checking and setting wether a window is minimized, to bring it to the top, to change it's title, etc.

But that's just Window()-dressing, if you'll excuse the pun. The important thing is that we once again have a PySoy which renders.

splitting classes into pyrex include files

We've reached a point where some of our .pyx files are too lengthy to be easily worked with, not just for our editing purposes but for subversion as well. To solve this I've started splitting the modules into a file for each function or class, that file named for that class.

This also has the advantage that it's easier to sort through the svn changelogs to see when a specific class was last modified.

why not soy.windows

We started down the path for a soy.windows with the goal of having many possible Window classes, ie, a fullscreen window, vs a borderless splash window, etc.

After much learning on how these are implemented it became clear that a single Window class, with these features as options, is preferable. Further, there's function/variable linking limitations that require some hacks to work around, not something we really want to be doing.

The new Screen layer is extremely decent; it solves our fullscreen issue, it allows the game to manage display on multi-headed systems, it provides a clean and simple API for obtaining screen size and other display information, and even provides a nice "hook" for input.

We also have a problem with the usleep function, more specifically, in that win32 doesn't have it (they use a "Sleep" function instead). We were going to have to have optional building for _core in any event because of this.

So to simplify the API, make things easier on us, and generally make it run more smoothly, soy.windows was folded back into _core.

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.

the acursed nvidia..

So far all dev on this version has been on ATI Radeon cards using free software drivers. Works beautifully for every feature currently supported..

... and then one of the SoC students tries to get it running using his nVidia card w/ their proprietary drivers. Black window, no pyramids, no widgets, no colors, not even the window's background color. Nothing.

I got the nVidia TNT2 ("legacy" proprietary driver) out to test it myself, same result as Angelo reported with a newer nVidia card/driver.

The black window, vs it not updating at all (ie, clear), comes from the double buffering. It's apparently the only thing working as all the actual OpenGL commands can be removed with the black window remaining.

ldd reports that the code is, indeed, linked against nVidia's OpenGL libraries on this machine. glGetError reports no errors. The window's rendering function is being called (if the glutSwapBuffers call is removed the window becomes clear). Single buffering mode is clear (ie, doing nothing) under all cases.

The next step is to write a small C program copying these functions and building it into a known-to-work GLUT tutorial until we get it to work. Time consuming, but at this point, I see no other solution. If this turns out to be a problem with FreeGLUT I swear I'm going to spend a week to finally tear it out of PySoy and replace it with our own OS-specific windowing code. It's consumed so much of my time already..

---

The good news I have tonight is the i915 DRI/Mesa drive apparently has GLSL support thanks to "brianp" on Freenode. Shocking, given the antiquated nature of the chipset, but if it can support GLSL I see no reason why the Radeon series GPUs cannot.

addressing the GPL data loophole

The GPL is a powerful tool to promote free software. In essence it's a social contract - "You may use, modify, and redistribute this software so long as you give everyone else these same rights." If a game is released under the GPL others may extend it, improve it, or change it to suit their tastes.

These changes may be accepted and adopted by the original author or the 3rd party may release it on her own provided these rights and restrictions remain. The license extends to software which uses GPL covered libraries or other software within the same executable so, for example, if someone implements a PySoy-based game that game must be under the GPL as well.

However, a loophole exists in this license: while artwork and other software data may be covered itself by the license it need not do so in order to use or be used by GPL covered software even when such data is core to that software's function. It is, thus, possible to create a modified GPL application which relies on proprietary data.

In terms of games, this makes the anti-social licensing practices of some acceptable under the GPL. This loophole could also, potentially, be exploited for any number of applications. Envision corporations such as IBM and Motorola releasing modified GPL software bundled with proprietary data blocks enabling that software to function on their devices. As long as said data does not contain clearly-defined "instructions", merely data as numbers and strings used by the GPL-covered code, this is in full compliance with the GNU GPL.

It doesn't trouble me that such loopholes exist. What does trouble me is, now in the process of drafting the GPLv3, the principal authors of this document (whom I have a great deal of respect for) fail to see this as a problem in need of addressing.

more fun with pyramids

Just goofing off, added multiple projectors to the previous example (all attached to the same camera):

pro = soy.widgets.Projector(win, size=win.size, camera=cam)
proj1 = soy.widgets.Projector(win, size=(400,300), position=( 0,0), camera=cam)
proj2 = soy.widgets.Projector(win, size=(400,300), position=(400,0), camera=cam)
proj3 = soy.widgets.Projector(win, size=(800,300), position=(0,300), camera=cam)
line1 = soy.widgets.Square( win, size=(800, 2), position=(0,300))
line2 = soy.widgets.Square( win, size=( 2,300), position=(400,0))


Great example of how elegant PySoy has become. No "multiple viewport" hack, the design just incorporates this sort of beautiful flexibility.

another Pyramid demo

I've been working to get .soy file loading up using a new Python API, will likely have it in by Sunday. Once it's finished we'll be able to use media exported from Blender and GIMP.

In the meantime please enjoy this quick but beautiful demo using the test Pyramid class (works on r34):


import soy
from time import sleep
from random import random

def rand(x) :
  return (random() * x * 2) - x

def hone(p) :
  v = [rand(5), rand(5), rand(5)]
  for i in range(3) :
    if p[i]*v[i] > 0 :
      v[i] = v[i]*-1
  return v

win = soy.Window('Pyramid Space', size=(800,600))
sce = soy.Scene()
cam = soy.bodies.Camera(sce)
pro = soy.widgets.Projector(win, size=win.size, camera=cam)
pys = []
for i in range(1000) :
  pys.append(soy.bodies.Pyramid(sce))
  pys[-1].position = (rand(50), rand(50), rand(50))
  pys[-1].rotation = (rand(3), rand(3), rand(3))
while True :
  cam.rotation = (rand(.5), rand(.5), rand(.5))
  cam.velocity = hone(cam.position)
  sleep(5)


Simulation Test (Trunk r33)

import soy
white = soy.Color('#fff')
ltgrey = soy.Color('#ccc')
win = soy.Window('Simulation Test')
sce = soy.Scene()
cam = soy.bodies.Camera(sce)
cam.position = (0.0,0.0,5.0)
s1 = soy.widgets.Square(win, position=(25,25), size=(150,150), color=white)
pro = soy.widgets.Projector(win, size=(320,240), camera=cam)
s2 = soy.widgets.Square(win, position=(100,50), size=(25,25), color=ltgrey)
pyr = soy.bodies.Pyramid(sce)
pyr.rotation = (1.0,1.0,0.0)


What this does: Three widgets are created - a white square, a projector, and a grey square. The prior can be seen behind the 3d scene and the latter in front of it. A "Pyramid" body is created, something in the code just for testing, and is given a rotational velocity around two axis. Sure enough, the pyramid rotates before the camera.

When run from an interactive shell the .position .rotation and .velocity can be modified for either cam or pyr as the simulation runs. Unlike other Python-based engines Python does not need to be in some "loop" for the simulator to do it's job.

r28 test code

import soy
w = soy.Window()
s = soy.Scene()
c = soy.bodies.Camera(s)
c.position = (0.0,0.0,5.0)
p = soy.widgets.Projector(w, size=(320,240), camera=c)


r20 bug fixed (and more)

Piet came through again with another great patch. The bug was in setup.py, apparently something was being reused which shouldn't have been. He fixed this and did a big cleanup as well.

He suggested moving to using properties instead of using __getattr__ and __setattr__, this looks like a good idea since it makes the code a bit cleaner and allows us to add docs to the properties easily.

pyrex compile bug #21

For some reason, __pyx_n_type and a whole array of other Pyrex-provided variables for type(), len(), the types for tuple and list, AttributeError, etc work fine in _core but not in bodies. I've spent the last 2 hours trying to figure out why without success.

I've seen this sort of bug before but don't know the solution to it. It seems to pop up almost randomly and disappear just as mysteriously when non-related changes to the code are made. Hopefully the Pyrex guys can solve this.

In related news - I'm giving Piet (and prehaps other Pyrex devs) read access to our repository, sending tarballs is taking too long.

Getting on the same page

I've been in the middle of enough debates over the "right way" to do something over the last week to justify another IRC meeting to resolve this stuff. At present it looks like next Friday (21st) at 22:00 GMT is best for everyone (6pm EDT).

In other news I spent the day doing non-tech stuff, namely, sowing seeds in paper cups for a garden in a few weeks. It's been a good change of pace.

not a bug, a documented feature..

So I was pointed to the Pyrex docs covering "special methods". Apparently the behavior causing the segfault is intentional, and yes, the __new__ of the base type is automatically called (so it's extending rather than replacing).

Now I need to start defining superclass __new__ as:
def __new__(self, parent, *extra, **extranamed) :

In other news, Zach has had me focusing on soy.Window rather than continuing with the camera/bodies/etc. It's working nicer now, with a background and keeping the aspect it was created with. There's a ton more surface things that can be done with it but I think this is enough for now.

holy colored triangle, batman!

Another day, another apparent Pyrex. This time it seems subclasses must have the same number of arguments as their superclass or the compiled code will segfault.
I wonder, can this really be the first time someone has tried using a different number of arguments in __new__ with class inheritance? *grumble*

This explains why the Projector subclass I was working on kept segfaulting on creation.

I boiled the problem down to render a single static triangle, worked fine, added a 2nd argument for an object of type soy.Color and, after finally (2 days) figuring out where the problem was and throwing in a hack to fix it, we got a color-able triangle.

Changes to the color object, surprise surprise, change the triangle's color in realtime. I can run this in a loop to rotate it's color and watch the results, more evidence the coreloop is working properly.

This PySoy code for this is in SVN. The Python code for this demo is:
>>> import soy
>>> red = soy.Color('#f02')
>>> red
<Color #00ff0022>
>>> win = soy.Window('Triangle Test')
>>> tri = soy.widgets.Triangle(win, red)
>>>

Summer of Code 2007 students

The results are in. PySoy got 3 student slots this year:

• PySoy: Rigid transformation blending by Jayce Kazuto Doose
• Adding fields and waves to PySoy by Eric Stein
• Integrating multi-texturing [...] in PySoy by Angelo Theodorou

This is no surprise, all three students were "accepted" almost a week ago, just now it's been confirmed. Good job guys!

anyone have a can of Raid?

22:48 < pjd_> you seem to have a talent for exposing strange and interesting bugs :)

Yes, that's right. Another Pyrex bug, and another awesome fix from Piet. It's good that the Pyrex guys are getting a chance to find some of these problems, just wish I didn't keep hitting them. To be honest, Pyrex is well used by lots of projects, I just seem to be using the newer language features.

Working to resolve a render bug with widgets now. I'm coding very slowly, using printf everywhere, every function seems to bring two or three new bugs that need to be resolved.

it's ALIVE!

After much debugging coreloop, now set to operate in it's own thread without having to obtain the Python GIL.

It's working and appears to be stable outside of FreeGLUT-related bugs. This can be demonstrated in windows refreshing after their size is changed or uncovered.

At this point the code has all been moved to Pyrex, even the coreloop thread. The latter took two days resolving a bug that turned out to be from Pyrex 0.9.4, we require Pyrex 0.9.5.1a (the latest release) which supports multiple cimport commands for parts of the same package.

Many thanks to Piet Delport for his help in resolving this!

So PySoy compiles beautifully now. Now to get widgets rendering again, specifically soy.widgets.Projector ;-)

pysoy roadmap

Since it's been requested, here's the timeline for PySoy 1.0. Note that hit some of these dates far earlier than projected.

Friday, April 13th: API overhaul (mostly) complete, pushed to SVN and "unfrozen" for continued development

As the new maintainer, in an effort to bring order to chaos, I've frozen development while I restructure the API (and thus the code). On April 13th, if not before, a major SVN commit will be made with these changes. Any bugs I find but cannot fix along the way are being entered into the ticket system for dealing with later, my focus is overall structure and getting coreloop working well under the structure we previously conceived.

Between 4/13 and 5/28, our Summer of Code students will be getting up to speed on what we're doing and our development practices.

Monday, May 28th: Our Summer of Code students begin work.

Since they are working full-time, the three of them together represent a majority of the work being done over the Summer. This is not to say the rest of the development team isn't working as well, but most of what we'll be doing is re-implementing the code we've already done into the new API and debugging/optimizing it. By contrast, the students will be adding new code we have not worked on before so their jobs are significantly more time consuming.

Friday, June 29th: First "beta" release, SVN read access open to public

By the end of June we'll release the codebase as we have it for public viewing. There will be no guarantee that the API will remain the same between this and 1.0 but changes, if any, will be minor. The primary reason for doing this is to get sample games ready before 1.0 release and get input from the larger community on ways it could be further polished.

Summer of Code work will not even be to midterms at this point, but some preliminary student work should be available by this point. There may also be additional "beta" releases between this and the final release.

Friday, August 18th: Release Candidate 1

At least one release candidate will be made prior to 1.0, each with a 48 hour window to find any remaining bugs or issues (ie, a missing file or #ifdef for a platform). Any change represents a new RC with new 48 hour window.

Friday, August 24th: 1.0 Release

We want to hit the "end of summer" deadline and have 1.0 released with the SoC students work included. This leaves enough time for potentially three or four release candidates prior to final release.

1.0 represents a stable API which can be safely developed for.

Thereafter: 1.1 and beyond

Further development remains backwards compatible to code designed for 1.0 while adding new features, optimizing it's speed, or fixing a few fringe-case bugs we missed.

of children and parents..

More of the old Python-side API getting moved over to cdefs, today is the "Children" type 'list' becoming a C array w/ mutex locking and position shifting. I decided to do something a bit more by making this a cdef class:

cdef public class Children [object soyChildren, type soyChildrenType]:
  '''PySoy Children

     This is a thread-safe C array of Python objects for "Parent" classes.
     It's append, index, and remove methods are identical to Python lists.
     The up, down, top, bottom, and move methods move an object in the array.
     The lock and unlock methods control the mutex.
  '''
  cdef int size
  cdef int current
  cdef void **list
  cdef PyThread_type_lock lock

  def void __new__(self)
  cdef void lock(self)
  cdef void unlock(self)
  cdef void append(self, void *child)
  cdef int index(self, void *child)
  cdef void swap(self, int first, int second)
  cdef void up(self, void *child)
  cdef void down(self, void *child)
  cdef void top(self, void *child)
  cdef void bottom(self, void *child)
  cdef void remove(self, void *child)
  def __dealloc__(self)

Instances of this class must be locked/unlocked externally. When the coreloop traverses the various trees it'll lock/unlock thus blocking Python's execution only if Python is trying to modify the children while it's being processed. Much better than using the GIL.

This is in a soy._imports module to keep it out of the way and attached as a cdef attribute to any "parent" class. A similar Child class will reference these methods and can be inherited by the base types which need to attach to a parent.

learning to trust pyrex

I've had a frustrating interesting night with Pyrex, 6 lines of code being written, rewritten, repeatedly, in both C and Pyrex trying to get a simple struct array to work properly.

With some spectacular help from pjd it was finally resolved, and Coreloop is running again, but this spawned a discussion about trusting Pyrex and I've come to realize that - no - I don't trust it. I was coding 6502 assembly in middle school, I started coding C over a decade ago, I don't even use an IDE because it seems to get in the way more than it helps, and here I am trusting this "Pyrex" thing to chew up my code in it's own language, regurgitate it as C, and possibly not give me access to certain things that I need?

However, PySoy is too big to write in C alone, I've been down that road with much smaller modules and it's not fun. I'm going to have to learn to trust the 'rex and start thinking of it as a language of it's own.

In other news, I'm feeling more confident about our SoC students. Hopefully PSF gets enough student slots for us to end up with at least 2 of our applicants.

synergy restored my sanity

So I have a lab setup with multiple testing systems, each with a different kind of video card, and a cluttered desk of keyboards, mice, game controllers and joysticks. There's a mass of braided/tangled/ratnested cables from all these peripherals leading to the computers behind my desk.

By the advice of some X.org devs I installed Synergy and set every test system on a loop. Each continues to have it's own GPU+Monitor, their own GNU/Linux distro for packaging, but I only need one keyboard and one mouse to move between them.

Kudos guys, what's left of my sanity thanks you!

new maintainer

I've resumed my role as pysoy maintainer due to Zach's other committments not leaving enough time for him to continue the position. Zach will remain on as the distribution director and windows packaging lead.

Now that I've had time to review the work that's been done I've started work on an inter-component API and roadmap to move forward. Look for these on the wiki, and yes, they're open for discussion. The role of maintainer is to facilitate and mediate, not dictate.

After this is done we'll begin getting the codebase back into SVN. I feel it's important, especially given new developers joining us, that this be done in the next two weeks. Part of this process will include pruning developers who are no longer active by who works toward this goal.

Summer of Code 2007

PySoy will once again participate in Google's Summer of Code under the Python Software Foundation.

We've had several decent proposals from students and will have a tough time choosing between them. It's always one of the things I have a tough time with, myself. Announcements for which students were accepted will be made April 11th.

a Moment of Nostalgia

Damned. I missed the international C64 convention last month.

Let's see what's new in C64-land.. Ethernet controllers, online games, and apparently plans for a MMORPG. Oh, look, you can even download GEOS at no cost now!

I keep reminding myself it runs at 1mhz, my PDA is more powerful, but it's still nice to think about MMORP'ing on my old commie.