Chard on 2009/04/11 13:49:

Firstly do you definitely mean soya3d (http://home.gna.org/oomadness/en/soya3d/) and not pysoy (http://www.pysoy.org/)?

I note that neither library is available compiled nor compiles cleanly on OS X, so likely you won't target Mac users if you use either of these libraries. I also note that pysoy employs a GPLv3 like license which has crazy licensing implications on anything you write using it.

There was a system capabilities poll for PyWeek 5. From it I estimate at least 10% of PyWeek entrants use OS X. See: http://www.pyweek.org/p/8/

Martin on 2009/04/11 15:39:

While I would imagine that quite a few of the OS X users would have a second machine and thus be able to run your game with Soya3d, I would guess that very few of them will do so. During Pyweek judging there are usually fifty or so games to try, and anything that makes your game harder to try out will likely mean that it won't get played. I've come across judges who flat out refuse to install any kind of library beyond Pygame. As best as I can tell, installing Soya3d on anything but Linux requires compiling from source, which most people just aren't going to do. Is there a modern Windows binary? The only version I can find is for Python 2.4, which is getting a little outdated by now.

For my own part, I do genuinely make an effort to play every game. However, when I make my first pass through the games list, anything that doesn't run immediately, whether because of dependencies or bugs, gets put to one side, while I play all the games that work first time. I always intend to go back and try to make the others work, but my own laziness often triumphs, I'm afraid.

As for the number of OS X users, I'd imagine it's a lot more than 10%. It was 7/56 (12.5%) during Pyweek 5, and OS X use has increased quite a bit in the last few years, particularly for game dev. As a single data point, during Pyweek 5 I was the only Super Effective team member using OS X, but now Chard, Adam and Garath all have MacBooks as development machines.

RB[0] on 2009/04/11 22:15:

If you going to do 3d at all OSX will probably be an issue. I don't know what it is, but we ran into it with PYGGEL a while back - basically pyopengl (and maybe pyglet - but I don't really know) don't work well on OSX - at least the new 3.x versions of PyOpenGL - which is why (I think) Soya doesn't work, that and it has a bunch of a dependencies I thought, maybe not...

Akake on 2009/04/12 09:46:

I could use Pyglet, yeah... :-)

I'd need to write a .OBJ parser, though, but it could work. I just might have to twiddle with Blender's OBJ exporter.

I've been meaning to learn Pyglet for a while now anyway. I'll have to consider it for my next practice game and see how it goes.

By the way, Linux and FreeBSD drivers act squirrely because they're designed for Real Programmers ;-)

Martin on 2009/04/12 13:49:

There are OBJ parsers for Pyglet out there, although not part of the main library. Still, it shouldn't be too hard to use OBJ files in a Pyglet-based game - I've done it myself in a couple of small unfinished projects.

Akake on 2009/04/12 16:20:

I'll admit, I was reading through the beginning of the Pyglet tutorial when I posted the above, and I just got to the section about OpenGL.

I'm starting to reconsider this as an idea for the compo. (I actually feel kind of woozy looking at the syntax for dealing with OpenGL. I don't want to sound whiny, but I'm really humbled by it. I have no idea where to go when it comes to that, and can't fully grasp even how the code was constructed. I guess I'm not quite the hotshot I thought I was ^^;)

Still, any advice or pointers to documentation are welcome and appreciated :-P

RB[0] on 2009/04/12 19:05:

If I may suggest (plug though it may be) PYGGEL. I created it specifically for this purpose, making 3d game creation simpler/understandable to get into for people who haven't done it before, but also allowing you to do it quickly enough for competition use.
My team will be using it this compo, and it is already being used for a few other games as well.

The only possible problem I can tell you is the PyOpenGL on OSX one, but if nothing else perhaps you can look at the code for it to get started and use it as a starting point for pyglet, it is documented fairly well, or where it's not it is generally pretty obvious what it does...

http://pygame.org/project/968/?release_id=1945
HTH :)

RB[0] on 2009/04/13 20:55:

How did you substitute pyglet? Several things won't work correct, primary being that you need to use ctypes arrays (I think) instead of lists/etc. or numpy arrays.

PYGGEL should *not* require Pygame 2.6 - until very recently I was using the previous version for dev.

In regards to the OSX problems, I asked some friends about it, and none of them say they have ever run into problems with OSX compatibility with PyOpenGL, so it is kind of a phantom issue, I dunno.

If anyone is interested, I will try and see what it will take to swap in pyglet, and make a new release or something that doesn't break backwards compatibility, etc....

Good luck either way, Akake, any/most 3d games haven't fared really well, so whatever you use, make sure you are familiar with it before the competition :)

Akake on 2009/04/15 10:03:

/me nods

I'm not sure how I'd package it, though, because it's so C-heavy. I'd like some direction for that. ^^;

I'm not necessarily off the bandwagon, just reconsidering using it for the compo :-)

Chard on 2009/04/15 14:21:

Compiled Python modules are very much platform specific. Personally I'm very keen on pure Python libraries, like Pyglet. It makes packaging so much easier. The issue is always what to do when you need to call foreign functions. Either you have to write a compiled library (which then links the foreign library dynamically at runtime) or you stick with pure Python and use the ctypes FFI. The latter option is better for distribution but it means you have to use ctypes... Libraries can then abstract away all the ctypes magic and you can end up with a very snazzy interface to C functions loaded from elsewhere at runtime.

Anyway, some libraries go one way, some the other. As far as I know there isn't a decent set of pure Python 3d space/rendering/collision abstractions so distribution will always be tricky if you use such abstractions. It's perfectly possible to write a pure Python 3d framework on top of pyglet, distributing the pair of them. Pyglet, already being pure Python and achieving quite commendable cross-platform compatibility, is a dream for distribution. Its only snag there is its (granted optional and quite understandable) dependence on AVBin for compressed audio and video formats.