chris clepper wrote:
Hi
1a) "SIMD":
In my experience MMX is so poor that it's not even worth the effort. Not only
you couldn't have told me earlier ;-) (i even guess, you did!)
code will come close or match it with a decent compiler. SSE has C intrinsics much like Altivec which would greatly speed development and aid readibility about 1 billion percent - I know that VC++ and ICC work with them, but check GCC as well. Unless you can really tweak the hell out of the asm, it's better to use the intrinsics anyway as the compiler will do a lot of the little nicities for you. It's pretty easy to write very bad assembly.
actually there are intrinsics for MMX, SSE and SSE2, supported by icc, gcc and vc7 (and vc6 if you have the "processor pack"); i really did write the code for gcc (and was surprised that it worked so well under windows then) and indeed: i don't think that i would *ever* have written any line of assembler for MMX.
1b) "multiple_window": (there is also a TAG with this name, so beware!) this separates the functionality of [gemwin] (which has vanished) into 2 objects [gemcontrol] and [gemwindow], where [gemcontrol] is the interface to the rendering-engine (GemMan) and [gemwindow] handles the window-management.
This is a pretty huge change, and it should be a working branch or the objects should be built as entirely separate objects. It does break every patch and version of GEM currently out there, which is a problem.
i thought it would be possible to stay compatible with older patches. the magic is in the abstractions folder that provides a [gemwin]-abstraction holding [gemcontrol] and [gemwindow].
Overall, this is a good idea and the functionality is a welcome advancement, but the direction of development needs some discussion. I would suggest keeping the gemwin object and just adding some arguments to it to create multiple windows ([gemwin window1] to make a window called 'window1' or something).
indeed this would have been another good idea too. the problem that i see is, that you would have a rendering-engine (the current GemMan) for each window. one of the problems arising here, is that auto-updating objects (like pix_film or particles) will have serious problems to stay "in time". the current solution in the multiple_window branch is to control the frame-rate centrally (this is: each window renders at the same rate, which might be a problem) and the use of display-lists sharing, which calls the render-object of each [object] exactly once per rendering cycle (but of course, display-list sharing might not really work everywhere).
[gemcontrol] isn't as bad idea, but it could be potentially confusing if one object manages many windows at once.
the idea is, to use pd's messaging system for controlling. imagine a patch with 3 [gemwindow] objects, 2 of which are connected to the sole [gemcontrol]. you create 3 windows by sending a "create"-message to the [gemwindow]s and turn rendering on by sending "1" to [gemcontrol]. 2 of the windows will render the scene, the 3rd (which is not connected) will stay blank.
i guess this is more like pd's concept of sources and sinks (you could compare [gemwindow] to [dac~])
all the [gemcontrol]s will control the same rendering-engine (if you turn one gemcontrol "on", you turn all of them on)
i even think it would be clearer than it used to be, as now you can have multiple [gemwin]s and send concurring messages to each of them which all take effect on the same window (e.g: multiple objects managing a single window)
the only problem that could arise is indeed, if one has multiple [gemwin]s in their patch. this will eventually produce multiple windows (which is a minor issue) but if you were using one [gemwin] to create/destroy and another one to set the fog-density this will really break the patch.
and thanks for being not grumpy ;-)
mfg.s.f.as IOhannes