cyhawk on 2010/08/29 18:51:

The screenshot looks fascinating!
 
To nitpick: it would be good manners to name your directory "cubemaze" or something (not "pyweek11"). It helps when I'm extracting a bunch of games in the same directory. It's also nice that most games name the main Python file run_game.py, following this also helps judging a bit. (You could check out the skellington for the recommended format.)

I don't mind these nearly as much as this stack trace upon startup though:


Traceback (most recent call last):
  File "run.py", line 8, in <module>
    main()
  File "/Users/darabos/Downloads/PyWeek-11/pyweek11/source/main.py", line 19, in main
    run_game()
  File "/Users/darabos/Downloads/PyWeek-11/pyweek11/source/main.py", line 12, in run_game
    gameloop.prepare(options)
  File "/Users/darabos/Downloads/PyWeek-11/pyweek11/source/controller/gameloop.py", line 44, in prepare
    self.update(1/60)
  File "/Users/darabos/Downloads/PyWeek-11/pyweek11/source/controller/gameloop.py", line 70, in update
    item.update(item, dt, self.time)
  File "/Users/darabos/Downloads/PyWeek-11/pyweek11/source/model/cameraman.py", line 16, in __call__
    if item.position != self.last_position:
  File "source/lib/euclid.py", line 328, in __ne__
    return not self.__eq__(other)
  File "source/lib/euclid.py", line 322, in __eq__
    assert hasattr(other, '__len__') and len(other) == 3
AssertionError

tartley on 2010/08/30 22:31:

Ohno! Thanks for the feedback cyhawn, and for supplying a timely workaround claxo!

I didn't use the skellington this time around - and you're right, that caused me to unhelpfully stray from some pyweek conventions. I'll add this to my personal 'to remember for next time' notes.

Now that I come to investigate, I see that stacktrace generated on Python26. I was developing on 2.7, I forgot to re-test on 2.6 before I uploaded. Ooops!

I've adopted the fix, I presume it's too late to upload a bugfix version now? Ohdeary.

tartley on 2010/09/02 08:39:

Thanks for the bug report Cosmologicon, much appreciated.

As you can see from the traceback, it's happening while compiling OpenGL shaders. I'm afraid I don't know enough about opengl drivers to know why this might happen on your hardware but not on mine. I presume your opengl drivers are not very old? If someone else does understand this, I'd appreciate any edification.

I guess you can run without the shaders, by commenting out lines 49-51 of source\view\render.py:

        shader = ShaderProgram(vs, fs)
        shader.compile()
        shader.use()

This will make all the game very flat shaded, which will make it a bit ugly and harder to see what's going on. Level 3, in particular, was always a bit tricky to see what was happening - this might tip it over the edge of impossibility.

Oh! You could fix the flat shading, by adding a quick hack at line 90 of source\model\shape.py: (at the end of Shape.__init__)

        for face in self.faces:
            light_angle = face.normal.dot(Vector3(1.0, -3.0, 2.0).normalized())
            light_angle = (light_angle + 1) / 2
            face.color = face.color.tinted(Color(0,0,0,255), light_angle)

RB[0] on 2010/09/02 17:01:

Shaders are a *big* problem in OpenGL - unless you use a library where someone has taken the time to make a nice wrapper for all that stuff...

I have tried them a few times, as has my friend, and stuff that works on his Python/Pyopengl/etc. doesn't work on mine.
But worse, what works on his nVidia doesn't work on my ATI, and vice-versa.

tartley on 2010/09/02 23:15:

Ah, the other thing I should probably have pointed out is that there isn't much game there. It's just three mazes, and not particularly good ones, at that. :-(