On Thu, 3 Feb 2011, Ed Kelly wrote:
I suppose that's good, but I'm anxious now to sort out a 2D engine for PD.
A 3D engine is a 2D engine as long as you don't use the z-axis.
That's also why there is glVertex2 in addition to glVertex3, for example.
I'm using an industrial digger with GEM, when I should be using a spade!
Why should you ? If the industrial digger does the job... well, is this a
satisfying metaphor ?
I'm not really a graphics programmer, (in fact I have no training as a
programmer) so this is quite a challenge for me.
I suggested [gf/gl] to you because it can make a lot of GL programming
easier. Especially the part where you have to plug too many wires in too
many inlets of too many objects when it would be much easier if each GL
command could be done as a message in a messagebox. Well, [gf/gl] is what
enables you to work with few messageboxes instead of many objectboxes.
But that doesn't solve geometry questions for you. It just frees a lot
more of your mind for working on the geometry questions instead of the
wire jungle.
PD was telling me that the CPU load was about 112% just for the score on
my 2.2GHz dual core.
ah... does it make a difference to use GL's displaylists ?
what is taking so much cpu ?
Or perhaps there's something out there that could be ported.
PS - I'm over it. If I wanted to be the first I should have learned how to
program in 1997, not 2005!
The advantage of Pd is that, if you cut your project nicely into
abstractions, you can rearrange pieces of the puzzle to make something at
once very familiar and very unfamiliar, in ways that you might not be
able to do easily in Inscore. But it always depends on how each programme
is written like, and your degree of familiarity with it.
_______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
