PyGLy steps into the future

I’ve been working quite heavily on PyGLy for the last few weeks and I’m incredibly pleased to announce that PyGLy is now OpenGL 3 clean!

It took more work than I hoped. Not because of PyGLy (it was already pretty good), but Pyglet’s OpenGL Core (3+) support on OS-X, is well… broken.
I had to integrate a patch written by someone else and patch out 2 of the window event handlers.
The main reason for this is that OpenGL Core on OS-X is limited to 3.2, and is Core only (no legacy compatibility).
These changes can be found in my Github repository.

Pyglet isn’t without it’s problems. It is quite heavy weight in places. There is no support for float or 1D textures.
Other problems are it’s usage of legacy calls. These are scattered throughout the code base and prevent me from using even the Label or VertexList classes.
I would LOVE to help with the development of Pyglet… but I find the code… very confusing.
It’s got a fair amount of abstraction. Tracing even a vertex buffer blows my mind.

Regardless, I hope these issues will be fixed soon.

Initial release of PyGLy

It’s a pretty big day for us, as I’m pushing my labor of love, PyGLy, to GitHub.

PyGLy is a 3D framework developed in pure python.

I’ve been dismayed at the state of game frameworks on Python.

There are a large number of quality 3D engines and frameworks out there. However, there are serious problems with the ‘engines’ out there that have Python bindings.

• Not truly cross-platform (this is Python FFS!).
• Not free.
• Not maintained.
• No documentation (the worst culprit).
• Bindings are 2nd class citizens and you still need to code C/C++/Whatever.
• Don’t work with latest versions of code.

Most engines have bindings created by the community. The problem is these are quickly dumped when the person moves on.

Python only 3D engines seem… well… stagnant.

• PySoya and PySoy seem to be seething at each other but not really producing much.
• PyGame is just SDL in disguise.
• The rest… well they all 404 now.

For the most part, 3D game development on Python is dead.

So, behind the scenes, I’ve been writing my own 3D framework for Python, PyGLy.

“Framework” is an important word there. PyGLy does not force any one methodology on you. PyGLy simply provides functionality to wrap common functionality. Windows, Viewports, Scene Graph Nodes, Cameras. It’s up to you to put them together how you want.

Obviously some things are going to be coupled together. But for the most part, PyGLy just gets out of the way.

At the moment PyGLy is quite small, but it is in active development and already has features that may interest some.

I think the best case for it at the moment is for people wanting to rapidly prototype in 3D but not be abstracted from the rendering process. PyGLy lets you forget about the scene graph and just concentrate on rendering your objects. Rendering is performed via callbacks. You can make any OpenGL call you want in these callbacks.

PyGLy is the foundation of our Python 3D work, so expect it to be actively developed going forward.

The following are some of the things that we’re wanting to add in the future:

• Shadowing.
• Scene management (Octree, etc).
• Cocos2D integration (CCLayer).
• Separate OpenGL 3+ path.

As we’ve said before, Twisted Pair are true believers of Open Source, so you can find PyGLy on our GitHub repository under a very liberal license.

Pyglet mouse events and rendering

The Problem

I added mouse event handlers to my Pyglet application recently. I found when I moved the mouse over the window, my rendering started to create “ghost” images.

I finally found the solution hidden in the docs.

The pyglet application event loop dispatches window events (such as for mouse and keyboard input) as they occur and dispatches the on_draw event to each window after every iteration through the loop.

So every mouse move (or any other event) triggers Pyglet to call “on_draw”.

But because I’m controlling my own render loop at 60Hz, I didn’t see a need to hook into this event. So I assume Pyglet is attempting to render the scene itself, and it’s failing miserably.

This is really bad design! What if I have lots of events that are seperate? Looks like Pyglet is going to hammer the “on_draw” event.

The Solution?

Well the basic solution is to ensure you’ve hooked into the “on_draw” event and just connect it to your render call. Don’t connect it to your game update logic or you will end up updating everything.

But…

This means your frame rate will vary depending on user input, and may even end up running balls out. Which could turn a simple game into a system hog. My basic application goes from 1% (of 2 cores on a dual core system), to 20% with the mouse moving.

It also means that you need to decouple the rendering from the system update, as each event you have scheduled will trigger an “on_draw” event. If you don’t decouple them, you will render each frame twice!

The Proper Solution?

We need to over-ride the “EventLoop.idle” method as mentioned in the docs.

The code without “on_draw” looks like this:

def idle( self ):
    """An alternate idle loop than Pyglet's default.

    By default, pyglet calls on_draw after EVERY batch of events
    which without hooking into, causes ghosting
    and if we do hook into it, it means we render after every event
    which is REALLY REALLY BAD
    http://www.pyglet.org/doc/programming_guide/the_application_event_loop.html
    """
    pyglet.clock.tick( poll = True )
    # don't call on_draw
    return pyglet.clock.get_sleep_time( sleep_idle = True )

def patch_idle_loop():
    """Replaces the default Pyglet idle look with the :py:func:`idle` function in this module.
    """
    # check that the event loop has been over-ridden
    if pyglet.app.EventLoop.idle != idle:
        # over-ride the default event loop
        pyglet.app.EventLoop.idle = idle

The “on_draw” function also calls pyglet.window.flip() for us, so now we need to do that after our rendering. So add the following (obviously you need to change the window variable depending on what you’ve called it):

# switch out the default idle function for ours
patch_idle_loop()

def render( self ):
    # do render here
    # flip the buffers
    self.window.flip()

And we’re done! No more superfluous “on_draw” events and my simple application no longer spikes the CPU usage when the mouse is moved!

Registering Event Handlers in Pyglet

The Problem and Pyglet’s own solutions

Pyglet’s documentation suggests a number of methods to receive events.

The recommended method of using @ decorators works for global methods where the event object is known. But if its for a class method or the event object is passed in later, this will not work.

The alternative is to simply over-write the existing handler with something like

window.on_resize = self.on_resize

Unfortunately most of them end up with the following error:

window.set_handler( window.on_key_release, self.on_key_release )
AttributeError: 'Win32Window' object has no attribute 'on_key_release'

This discussion on the developer list explains it. This method only works when the platform’s window class has an existing method to handle the event. And not all events are handled by default, so when you come across this, BOOM!

Even then, when it works this is also a double edged sword. The existing handlers are there for a reason! For example, if you over-write the on_resize method of Window your application will no longer draw (took me a while to figure this out).

So yes, Pyglet’s documentation is really, REALLY, asking for trouble.

The Proper Solution?

Use the “push_handlers” method.

Pyglet automatically detects a method with the event’s name and dispatches the event.
So we can just add methods to our class and we’ll automatically receive the events.

class Test:
  def attachToWindow( self, window ):
    window.push_handlers( self )

  def on_key_press( self, symbol, modifiers ):
    # method name matches the 'on_key_press' event!
    print "Keypress"

Or we can manually specify which events we care about.
If we do this, we must specify the actual function that receives the event.

class Test:
  def attachToWindow( self, window ):
    window.push_handlers( on_key_press = self.on_key_press )

  def on_key_press( self, symbol, modifiers ):
    # method name matches the 'on_key_press' event!
    print "Keypress"

Creating Voxel Volumes Quicky in Python Part 2

So we created a volume pretty quickly Part 1, we also implemented basic RLE and Position Aware RLE (PARLE).

Read on for a few minor improvements we can make with little effort.

Game mechanics: Waterloo

I hadn’t heard of this game before. Waterloo has some interesting game mechanics.

About the game:

• RTS
• Play from the point of view of a commander on the battlefield (literally).
• Move your HQ to get to a better position.
• Orders are dispatched by messengers in the form of written notes (literally! It has a text interface!).
• Messengers take time to arrive and can even be killed en-route.

Four words: HOLY SHIT THATS AWESOME.

A good case for mandatory castration

Murtle76 not only hates a game he didn’t bother to play, but insists that he isn’t insulting or annoying anyone…

Steam region pricing is getting rediculous

This discussion regarding Borderlands pricing differences, although not a big deal this time, is the latest in a long line of regional pricing FUBARs.

I saw that Borderlands standalone (US$7.49) and Borderlands GOTY edition (US$7.50) were both on the “Top Sellers” list.

I thought perhaps people were boycotting the DRM encumbered DLC for the game (included in the GOTY edition), which made me happy!

Then I checked the forums and realised I was wrong. Different regions, again, have vastly different prices:

US pricing:
Borderlands GOTY = $7.50

Borderlands = $4.99

DLC = $7.49

Borderlands + DLC = $12.48 (greater than GOTY by $4.98)

AU:

Borderlands GOTY = $7.50

Borderlands = $7.49

DLC = $7.49

Borderlands + DLC = $14.98 (greater than GOTY by $7.48)

UK:

Borderlands GOTY = £7.50

Borderlands = £4.99

DLC = £4.74

Borderlands + DLC = £9.73 (greater than GOTY by £2.23)

Euro:

Borderlands GOTY = €12.50

Borderlands = €4.99

DLC = €5.99

Borderlands + DLC = €10.98 (less than GOTY by €1.52)

As you can see, this pricing is literally schizophenic.

I don’t believe this is Valve (although their Steamworks page does say that they will suggest pricing for games), I think this is the publishers stepping up pressure on Valve to fall into line. And unfortunately it’s working.

I made a comment that perhaps we should all band together to make a “Steam Gifting Co-operative”. Thing is, I was serious.

Many deals in Europe or the AU are far inferior to the US pricing. The region banning is stupid. This usually isn’t Steam but government ratings forcing publishers to offer modified versions (eg. L4D2 with fading out corpses instead of normal version). Grand Theft Auto: Vice City is still NOT on steam in Australia (thanks guys, you forced me to pirate it) although GTA3 and GTA:SA finally are.

Gifting gets us around this. It can also get us around the price issues. The only problem I can see is something like this happening if the “giftor”s bank account goes into the negative. Which is pretty horrific.

People would be re-imbursed for gifts (this isn’t a charity!). The only problem is ensuring that the “giftee” pays the “giftor”. Most bank transfers take a day and by then most deals would be over. I believe PayPal transactions are instantaneous, but I’m not sure. If it is, this would negate this issue.

I think a gifting co-operative is a very realistic and simple way of negating some of the publisher’s influence on Steam.

There are a few forum threads doing exactly this (NeoGaf, Awkward Zombie), but we need to make it more formal and easier to use.

There needs to be a way to:

• Request a gift from a specified region (“giftee”).
• Notify of our intention to fulfill a request (“giftor”).
• Select a “giftor”.
• Notify of payment sent, gift sent, gift received.
• Comment and add to user’s reputation (ala Amazon) for both “giftee” and “giftor”.
• Cancel a gift request.
• Quickly view current gift requests with filters for region, age and user rating.

How many times do we have to say it?

DRM doesn’t fucking work!

Absolute power corrupts

I love Steam. Having a social gaming network with constant access to a game market place where the prices are truly fluid is brilliant. But the thought of something like this happening is always in the back of my mind, and it scares the shit out of me.

I’ve seen posts before of people having an account for each game they have. That way if an account is banned or VAC banned, their other games aren’t affected.

You also get around VAC banning you from all games that use that engine. Ie. a VAC ban in HL2 will ban you from all games that use the Source engine: L4D, CS:S, etc.

 

Also, PayPal sucks. Please avoid using it where possible.

Back in my day Sonny…

I really miss games like this. This walk through brings back so many memories. It also shows how many things I missed even though I didn’t finish it. Brilliant game, brilliant story. God damnit… I want to play it now!

Musings on piracy

Once again a short rant (not a proper post) I posted on Steam that describes my thoughts on piracy.

Post also copied below.

The truth of DRM

I just posted this on Steam, it’s a rant but I think it expressed my feelings on DRM quite well.

Post below in-case you’re scared of the Steam forums (don’t blame you).

Telstra BigPond Thompson Modem and Killing Floor

The Thompson modem used by Telstra (and On2 and BT) creates a unique issue with Killing Floor. I documented this on the Steam forums but it doesn’t appear to have gotten much attention so I thought I would reproduce it below.

Edit: There is now an “official” fix on the Steam forums, but I cannot verify if it resolves these issues.

First Milestone

Over the last week I’ve written and re-written my Python framework about 6 times. Yesterday and today I re-wrote the core messaging framework again and I’ve just gotten to what I would consider the first milestone! Very exciting.

And so it begins…

Well, I resigned from my job last friday to focus full time on Twisted Pair.

The way I see it, if I fail at getting this off the ground, I can just consider the time spent as a big holiday with my family. So either way, everyone wins… apart from my bank account =P.

I’m taking some time to relax but will pick up development after my last day (three weeks from now). I’ve been thinking a lot about Shock and I’ve solved a number of things in my head so it will be full steam ahead once development starts. I’m really looking forward to seeing some milestones.

Progress, Decisions and Optimism

Work on Shock has been slow but good. I’m developing the engine toward an actual game, rather than hammering out a perfect framework first. Just to be clear, I am writing good code that will be in the engine for a long time. What I’m not doing is writing code that I don’t need yet. A mistake I made with my last game framework (unreleased). I’m currently scavenging code and ideas from it for Shock, which is far superior.

It’s incredibly exciting to see all of these concepts, ideas and designs come to life. I’ve had the Shock engine in my head for over 5 years now and I’ve been constantly refining it as I learn more and more about better programming practice and new programming methodologies. Shock isn’t really anything new, it’s more that it is a single implementation of the best ideas I’ve come across in that time.

From the ashes…

Twisted Pair is alive and well. Work has been continuing despite the lack of updates.

After much flip-flopping with game ideas, we have finally settled on our next game and are incredibly excited about the possibility this will bring (thats not corporate speak… I’m actually fricking excited!).