Shadows in QGL

Shadows help ground models in a scene and assist with depth perception. QGL really needs shadows.

Current best practice revolves around using the stencil buffer and projecting a flattened model onto surrounding geometry, creating the illusion of a shadow. The technique often referred to as a shadow volume algorithm.

A different algorithm, with different tradeoffs, is the shadow mapping algorithm. There is even hardware support available for implementing this technique.

I'd like to implement shadow mapping in QGL, as it is likely to be much faster than a shadow volume technique. To do this, I need to get a hold of the ARB_shadow extension, which PyOpenGL doesn't (yet?) provide. I'll probably have to use ctypes, and talk to the libGL dll directly.

QGL-9 Released, with a Shiny New Particle Emitter!

I've just released a new version of QGL. New features are:

* A ParticleEmitter lead node.
* All leaf nodes moved into qgl.scene.state namespace.

The particle emitter leaf node generates a bunch of particles within an arc and with a velocity range. You then call the .tick method of the ParticleEmitter, which animates the particles. It uses numpy, so it's reasonably fast. It could use a few more features, but I'll need to use it for a while to find out what they might be. :-)

Concurrency without Threads

I'm still investigating options for implementing concurrent solutions in game-like applications. I haven't found many high level languages which provide options for using real threads. Ruby, Chicken-Sceme, Bigloo Scheme, Ruby, Erlang. None of these provide real threading.

I think it's time I stopped thinking about threads, and started thinking about concurrency.

One idea I'm considering is the use of a Linda style system which is designed to provide a tuple-space on a local machine only. For performance reasons, access to the tuple-space would need to be implemented via some kind of shared memory facility.

The tuple-space approach could be ideal for game development processes. For example, the main process could push scene information into the tuple-space, where it is read by a second process which performs culling operations on the scene, and pushes the viewable set of scene nodes back into the tuple space. Meanwhile, the main process could be running the physics simulation, processing sound etc. This approach would require writing a separate program which works cooperatively and concurrently with the main program. No forking, and no threading.

If I had a Concurrent Python, what would I do with it?

Something like this:

CORE_COUNT = 2 #This is how many CPUs or cores we have to play with.
def xmap(fn, seq):
  """
  Run a function over a sequence, and return the results.
  The workload is split over multiple threads.
  """
  class Mapper(Thread):
      def __init__(self, fn, seq):
          Thread.__init__(self, target=self.map, args=(fn,seq))
          self.start()
        
      def map(self, fn, seq):
          self.results = map(fn, seq)

  newseq = []
  n = len(seq) / CORE_COUNT
  r = len(seq) % CORE_COUNT
  b,e = 0, n + min(1, r)
  for i in xrange(CORE_COUNT):
      newseq.append(seq[b:e])
      r = max(0, r-1)
      b,e = e, e + n + min(1, r)

  results = []
  for thread in [Mapper(fn,s) for s in newseq]:
      thread.join()
      results.extend(thread.results)
  return results

This function takes care of starting, joining and collecting results from threads. It lets the programmer map a function over a sequence, and have the work done in parallel. Of course, this won't work in CPython, but it might prove useful in PyPy, or IronPython. Parallel processing in this style would be very useful for applications that work with large data sets, ie Games!

A game could be written to take advantage of the xmap function whenever possible. It would only make sense to use it when iterating over large data sets or using long running functions.

Concurrent Python on Win32? No Such Animal.

I want a cross platform, concurrent Python. It seems, I can't have it. I really am astounded by the fact that there is no way I can implement concurrent programs in Python on Win32, without resorting to socket communications between two different programs. A heinous kludge, from my perspective.

The second core on my new notebook will not be available for my Python games. Python used to be my secret weapon, when it came to game development.

I don't want to get left behind in the coming multi-core revolution. Maybe it's time to move on.

QGL-8 Available: Shaders, Materials and Much More...

I've just uploaded QGL-8 to the python cheeseshop. This version contains the new shader funtionality, plus a very useful Static Node, which compiles all it's children into a single display list. The attached screenshot shows the new Material leaf class being used in a neat particle demo (contributed).

My Pyweek effort is over.

Unfortunately, Real Life issues have torpedoed my Pyweek efforts. I just cannot focus on game development right now. Too many disruptive, disturbing thoughts running around my head. Owell.

Perhaps next time.