that big spike must be a heavy Apply(), or wait is it an explosion? hmm, anyway I’ll think about that today, might try something like that.
I have tried using Color32 and SetColor32 / GetColor32 - but for some reason it only draws… nothing… hmm gonna work on dynamic pixels some more
and yaknow I was thinking, that in the java webplayer it didnt draw dynamic pixels to the terrain until they became static pixels, it just did Rect’s I think, but they worked different than unity, obviously they didnt require OnGUI calls, and they were 1x1 pixels in size I think… so if we try and draw those pixels to the terrain, it would cause collision problems and stuff, and make everything really heavy on the physics engine, but maybe it would be ok to make another quad (in my latest version I depend on a quad instead of Graphics.DrawTexture() ) on top of the first one, which is specifically for drawing dynamic pixels, so they dont interfere with the collision physics and such… hmm.
and also… I been tinkering towards an array of dynamic pixels, and color[ ] of them, but I keep running into a problem with keeping track of who is who… which pixels to draw, which pixels to destroy… hmm
I havent uploaded the quad drawing version because, well its more experimental than the Graphics.DrawTexture way… but its fairly simple to switch them out really if anyone wanted to try that vs doing drawtexture
EDIT: ok that hanging, its the dynamic pixels. I edited this out of Explode.cs:
// create the dynamic pixel
// DynamicPixel pixel = new DynamicPixel (terrain.getColor (solidX, solidY), x, y, velX, velY, terrain.destructionRes);
// pixel.stickiness = 800;
// physics.add (pixel);
// renderer.add (pixel);
and suddenly, less hanging, so then I commented the parts of dynamic pixel that “bounce” the pixel around (and uncommented the part in explode ofcourse)… NO MORE HANGING! Here is what collide() does in DynamixPixel now (ps this is old code, been replaced in latest updates):
for (int i = 0; i < size; i++)
{
for (int j = 0; j < size; j++)
{
terrain.addPixel (col, thisX + i, thisY + j);
//DynamicPixelGraphic.AddPixel(col, thisX + i, thisY + j);
}
}
// remove this dynamic pixel
renderer.remove (this);
physics.remove (this);
and thats it, no more bouncing for right now… but that hang had to go, was wrecking my webplayer and test runs in editor, now I can focus on drawing the dynamic pixels in the first place…
thanks mgear for pushing me in the right direction. again. 
New Info:
Ok figured out a way to draw those dang dynamic pixels… so check out the new (crash free hopefully) webplayer for an “interesting” solution haha. re-uploaded source with new somewhat janky method for drawing onto quads… but its faster… this way does makes some strange artifacts where pixels “used to be” so it has its drawbacks to drawing those dynamic pixels this way, but a step in the right direction. On another note, I think that its something about getting the normals of the terrain that is really causing the hang (if nobody gets this I mean its freezing the game permanently or at least for way too long to be acceptable - just occurred to me that its a vague description of what happens)
What do you guys think so far? Can unity reach the performance of that java webplayer? It still gets lag when it gets intense, but much better than Graphics.DrawTexture() did. And stopping the dynamic pixel bounce saves some FPS for sure, and so does only updating the images once per frame (OnGUI did it much more probably). Any ideas for further performance increases? Any ideas for getting that normal calculation (I think anyway) to stop freezing everything up?
