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.