api style document 1

from the recent dialog on the dev list i see its time to put this together. while Arc is the maintainer the rewrite thats underway (the third by my count) should learn from our history lest we repeat past mistakes.

• always group dimensions/channels/aspects in one attribute
  
  
  • something.position=(x,y,z) not something.x something.y something.z
  
  
  • something.color=(r,g,b) not something.red something.green something.blue
  
  
  • something.volume=(l,r) not something.leftvolume something.rightvolume
  
  
  • something.size=(w,h) not something.width something.height


• combine aspects of one thing in one class
  
  
  • entity.mesh entity.shape entity.mass
  
  
  • scene == audio field + visible scene + ode world + ode space


• inherit often + group in same submodule
  
  
  • every widget should inherit same base class in soy.widgets
  
  
  • every entity should inherit base entity class in soy.entities
  
  
  • every camera should inherit base camera class in soy.cameras


• init should be implicit
  
  
  • opengl, openal, ode should all init when first used


• there should never be only one possible of any thing
  
  
  • multiple windows
  
  
  • multiple background music
  
  
  • multiple controllers
  
  
  • multiple game servers


• idiotproof without treating users as idiots
  
  
  • allow users to do stupid things that dont crash pysoy
  
  
  • agressive type checking to ensure pysoy wont crash
  
  
  • out of bounds arguments should silently change to nearest inbound value
  
  
  • let user create large scenes that drop fpu very low, good for learning
  
  
  • when possible let same thing be used for multiple other things:
    
    
    • allow video as texture on widget and mesh
    
    
    • allow sound to attach to widget or entity
    
    
    • abstract api on these things to make this simple


• when in doubt consider the following (in order)
  
  
  1. which solution is most intuitive
  
  
  2. which solution would produce the smallest api
  
  
  3. which solution requires the least user-side code to use
  
  
  4. which solution offers most flexibility
  
  
  5. which solution leads to higher fps

Seasons Greetings

Here's wishing everyone a great holiday and new year!

Just don't forget the deadline for thread-safe submodule state is January 1st!

struct org();

Workin` out the details of a "Rank" structure for pySoy. It resembles the Meritocracy structure many other free software projects rely on.

Just a draft for now but we really need to get something in place soon to deal with growth. I'm getting burned out and we don't even have a release out yet.

It's on the wiki for feedback, so if you have a concern or complaint, please feed back.

magic music machine

I've had some trouble with the OpenAL bindings for PySoy.

The goal is to match the direction and velocity from physics space into audio space whenever audio is bound to a 3d object. Unbound audio (such as background music) plays without doppler effects.

It's working on Windows but not Linux or OSX right now, my guess is an inconsistancy in Seth's ODE bindings it the cause as unbound audio is working everywhere.

The audio decode functions I'm leaving to Arc since he has more experience with this. At present only .wav is supported through the Python wave module.

Started work on my M³ Media Player (M³ = "Magic Music Machine") as a demonstration of PySoy's audio support and a cool Ogg Vorbis/Flac player.

web-o-matic

Spent an hour tonight working to update pysoy.org. Much more remains to be done. Here's a summary:

1. cal3d related tickets closed as "wontfix" (we're not using cal3d anymore)


2. edited and closed some of PalleRaabjerg's export/input tickets


3. deleted all Summer of Code milestones from the roadmap


4. set the 1.0 milestone target-date for November 1st


5. cleaned up many tags

Also, I shortened and toned down the text on soya3d.org.

Hope I didn't step on anyone's toes.

Clawe'ing it's way out

I posted the first draft of the new Layers Document for public comment.

For those who may be wondering, yes, much of the Clawe PyREX code will be used for the Avatar mode. By the time we're done getting PySoy 3D out as a full release Clawe will have almost no code left. This only means that it will be easier to add new features!

I'm in front!

Now it's official, I'm the lead developer for PySoy 3D.

Hey, you slaves, stop reading my blog and get back to work!