jit.gl.sketch dynamic changes in cmdlist
My turn to ask a question :)
In the patch below I alter the position of 8 points of in a jit.gl.sketch. I do this using cmd_replace but this seems to be the cause of some slowing down when the changes are happening. Any hints on this ? Or is this the perfect case to start learning javascript and related jitter object...
what happens if you change from pak to pack ?
/*j
Goes much better (probably 4x as much ;) ), still the occasional
hiccup in the underlaying render but almost negligable.
I've gotten so used to almost always using pak that I completely
overlooked pack.
Though it is just meant to add "sexyness" to an interface layer, i
can do without when push comes to shove, but I'd rather not of course
since it's those little details that add a lot to the experience.
Thx Jasch.
sorry for this double post. Don't know why that happened. Brought
'puter back from sleep and mail goes off re-sending mail.
When implementing the cmdlist changes in a larger patch all worked fine.
Now, when I open the patch on a PC, instead of Mac, the patch seems to crash on this.
I have narrowed the problem down to the part where :
a counter is activated when a certain logical condition is met.
The counter runs up and changes 8 vertextpositions using the countervalue mapped onto the appropriate float values for the vertices.(using scale or zmap give the same result).
When this process is set in motion, the vertices start moving and then stall. Resulting in a full stalling of max...
Machine :
AMD sempron 2500+
1.75Ghz
512 Mb ram
XP professinal, service pack 1
NVIDIA GeForce3
I haven't got the correct java version installed, which results in some error messages when starting up max, but I presume these are unrelated. I'm in no need for javasupport anyways.
Could this be because of the nr. of cmd_replace messages sent?
rgds,
B.
Sounds like you are either backlogging the scheduler/queue (make sure
you drive with qmetro rather than metro), or you are growind your
cmd_list infinitely.
-Joshua
Alrighty.. I'll give it a go keeping that in mind.
Only strange thing that strikes me, is that this problem does not occur under OS X with the same patch...
maybe run the patch and keep it open for a long time, like a few
hours, and you can see if the patch begins to slow down, and check
the cmd_list to see if , indeed, it has grown thus fucking things up?
Might not explain the PC crash, but.. eh.. *shrug*
its brute force, but hey..
v a d e //
www.vade.info
abstrakt.vade.info
As suggested by Joshua, I've separated the cmdlist changes to be
triggered by a qmetro. I haven't been able to check what exactly the
problem was, but I suspect it was due to the fact that is was
triggered by a logical operator, which in turn was triggered by,
well, stuff happening continuously really... I guess the cmdlist
didn't know how to handle this on windows... or on mac it was a bit
more 'leeway'.