Zach/etc Read over http://www.pysoy.org/wiki/PySoy/Layers - makes sense on a conceptual level, but how does this effect the API or class heirarchy?
As I understood it, the top-level object was going to be a soy.Window, widgets inside the window, root node (scene) inside the camera(s), 3d objects and other nodes inside the root node.. I don't see how "modes" are going to be implemented in the above system, or for that matter, how the second layer input handling will be implemented either given that the soy.Window was going to serve for event input. Recommend a top-level soy.Audio, ala soy.Window, for a single audio i/o device and some method to find available audio devices. That way, the "usb sound card in a game controller" setup could be used to give multiple players their own audio or for multi-head/multi-audio setups. I'd still like to see the module's top-level to be as clean as possible such that it contains only a handful of classes (soy.Window) and further submodules for everything else. Modes, for example, could be in a soy.Mode submodule. How you're going to fit modes into the model w/o allowing multiple modes to apply to the same root node/camera/window/etc I can't see. _______________________________________________ PySoy-Dev mailing list [email protected] http://www.pysoy.org/mailman/listinfo/pysoy-dev
