SVN now open, GPLv3 applied

I'm sitting in the FSF office in Boston as I write this:

svn.pysoy.org is now open to the public for download.

The LICENSE text for the GPLv3 has been applied, minutes after RMS's announcement and livecast.

Note that this is NOT Beta-1. We're aiming for 7/9 for the first "release". There is no guarentee that this will compile or run (but it should). Check out the tests/ directory for some cool stuff we've done for testing purposes.

... and enjoy.

subversion to open Friday

We'll be opening svn.pysoy.org to the public on Friday afternoon (June 29th) by 5pm UTC, just after the release of GPLv3. The code should not be considered usable in this state, it may not even compile depending on recent commits, and no support is offered for it as we're extremely busy getting ready for Beta-1 release.

The engine's Beta-1 will be released Sunday at earliest (July 1st) and possibly as late as Monday July 9th. At that time the ticket system will be re-opened to users and support offered. Betas should not be used to build anything "real", as API changes are still pending and several critical features are missing, but is useful for learning and helping us track down the bugs in our current code.

GPLv3 and game media licensing

Seems the GPLv3 is sufficient to ensure that entire PySoy-based games are also free. The key to this is in section 5c of the "last call" draft which specifies the "whole of the work, and all its parts, regardless of how they are packaged" as covered by the terms of the license.

Copyright law does not follow technical rules of how a work is constructed or distributed, it follows human judgment of what a "work" includes. For games this is simple; a game, including all it's parts, includes any media designed for that game. It does not include media arbitrarily loaded by the user, such as generic CD tracks the player of a game selects to be played, which contains no hooks or labels specific to the game or it's engine.

That is, a judge is likely to rule that a song created about alien invasion of length 1 minute 20 seconds, the same length as a cut-screen showing aliens invading, and which is labeled by a convention (file named cutscreen05.ogg) the game uses to determine which music to play, is a part of total work.

However arbitrary media files, such as tracks of a friend's CD, which are not designed specific to the game and which are interactively selected by the user may even be included on the same CD or tarball with the game. Such bundling is called an "aggregate", the license is explicit in permitting this sort of bundling.

I created a game licensing page on our website with more details on this and some ideas for making money using the "gaming as a service" model.

r200 status

We've reached another artificial milestone, what a better time to deliver a "State of the Soy"

First our physics model is coming together nicely; we have working joints with constraints and can connect bodies. Bodies can be removed from a scene and added to another scene retaining their parameters and state, joints not so much yet but soon. Initial work on fields has started.

Next our rendering model now includes GLEW and Vertex Array support along with a legacy fallback. To show this the "Pyramid" test class now inherits Mesh and uses it's render function. No normals or texture coordinates yet, the latter because texture support hasn't been added to this version yet.

soy.File is mostly ready though the load/save functions still need to be added to, well, everything. The basic .soy file format, now embedded in Ogg, is working. There is not yet a global _files array nor does Coreloop process File so delayed loading, especially of Vorbis/Theora, is not happening yet.

soy.colors has been populated. There's now over 100 colors available by name.

Work was started on the MacOS X version of _core, utilizing Carbon for "native" windowing support. We'll hopefully see a fully working version for that platform soon.

I've heard work on the Windows version of _core was started but nothing has been committed yet.

Overall our pace is accelerating; the more pieces become complete the easier it is to work on the remaining. Our roadmap remains unchanged for Beta-1 release July 1st.

intel's x3000 vs radeon x300

Just ran across a great review of Intel's X3000 (aka GMA 3000) chipset, for which they supply free software drivers for and work with the community to support, vs the free software Radeon drivers produced by the DRI team on the Radeon X300.

Great. Now I need to own one, another test system in the office :-)

If you're into Intel-based systems this certainly looks like a great choice, and what a better way to show Intel you appreciate and support their commitment to the values of free software (at least in regard to their hardware support)..

AMD, clueless

AMD (which recently acquired ATI) has recently made a buzz about how they are going to do better with working with the GNU/Linux community. This offer seems to be taking the form of faster release cycles for their proprietary driver for GNU/Linux, a closed & NDA'ed beta-testing program, and abandoning "older" drivers such as the r200 series that DRI supports well.

They still don't seem to understand that while the quality of the driver and it's release is of some importance, the license of that driver is the deal breaker.

Give us a poor driver with a free (as in freedom) license and the community will make it great.

Give us an excellent driver with a proprietary license and only a minority of users will use it.

Why?

Many distros, I'll use Fedora as an example since AMD spoke about this at a RedHat Summit, will not package proprietary drivers. Ubuntu, which I believe is the most popular right now, is on the fence and, at the very least, warns the user.

To add to this many free software developers ignore ATI's drivers as proprietary. As a result there is little GNU/Linux software that takes advantage of the higher end cards, the free DRI drivers on an r200/r300 card work just fine for almost everything. They certainly will for PySoy-based games.

Why would a user, then, pay $100+ for a higher-end video card when a $35 Radeon 9250 is better supported? For users it's thus a good consumer choice to stick with the cards supported by the free drivers regardless of that user's view on software freedom.

But AMD seems ignorant that GNU/Linux is about freedom, much like McDonald's board of directors meeting over poor sales in India. I imagine a meeting like this:

Sales VP: "They don't like our beef"

Marketing VP: "So we'll give them better beef, fresher!"

Technical VP: "We could slaughter the cow on site if it helps"

Sales VP: "That could be a great slogan, 'fresh from the cow'"

[cue standard nods and voicing of agreement from around the table]

r100

If you're one for artificial milestones, note that the 100'th commit was just made to Trunk.

It's great seeing all the pieces come back together the way we planned.

fixed joints are now working

Note that soy.joints must be manually imported at the moment; this way any bug in soy.joints will not interfere with testing other parts of PySoy.

import soy
import soy.joints
sce = soy.Scene()
cam = soy.bodies.Camera(sce)
cam.position = (0,0,10)
py1 = soy.bodies.Pyramid(sce)
py1.position = (-2,0,0)
py1.rotation = (0,2,0)
py2 = soy.bodies.Pyramid(sce)
py2.position = (2,0,0)
py2.rotation = (0,0,3)
scr = soy.Screen()
win = soy.Window(scr)
pro = soy.widgets.Projector(win, size=(320,240), camera=cam)

You'll should see two pyramids next to each other rotating on different axis. Now for the fun part:

jnt = soy.joints.Joint(sce, py1, py2)

Presto - they're locked together as if they were one larger object, their rotational velocities blended. You can watch their .rotation change. Now for the really fun part:

jnt = None

The invisible bond that connected them is nullified, and as such, they spin off in opposite directions with their own rotations.

This is only the beginning of course; there's 7 other joint types to be added!

IT WORKS

The final fix was just committed moving the glXMakeCurrent call to the _render() function (and, thus, the _coreloop thread). I've tested it to work on rage128, radeon, and nvidia (TNT2) cards.

Most notably we're still missing the event callback for changing the window's _width and _height when it's resized and the size __set__ code for changing the windows size from within Python. We could also use several more attributes and methods for, ie, checking and setting wether a window is minimized, to bring it to the top, to change it's title, etc.

But that's just Window()-dressing, if you'll excuse the pun. The important thing is that we once again have a PySoy which renders.

splitting classes into pyrex include files

We've reached a point where some of our .pyx files are too lengthy to be easily worked with, not just for our editing purposes but for subversion as well. To solve this I've started splitting the modules into a file for each function or class, that file named for that class.

This also has the advantage that it's easier to sort through the svn changelogs to see when a specific class was last modified.

why not soy.windows

We started down the path for a soy.windows with the goal of having many possible Window classes, ie, a fullscreen window, vs a borderless splash window, etc.

After much learning on how these are implemented it became clear that a single Window class, with these features as options, is preferable. Further, there's function/variable linking limitations that require some hacks to work around, not something we really want to be doing.

The new Screen layer is extremely decent; it solves our fullscreen issue, it allows the game to manage display on multi-headed systems, it provides a clean and simple API for obtaining screen size and other display information, and even provides a nice "hook" for input.

We also have a problem with the usleep function, more specifically, in that win32 doesn't have it (they use a "Sleep" function instead). We were going to have to have optional building for _core in any event because of this.

So to simplify the API, make things easier on us, and generally make it run more smoothly, soy.windows was folded back into _core.