Pixel Destruction - Per pixel 2d destruction with unity

NEW INFO: no longer an open source project, now I am beginning work on creating an android game with the framework! Thanks for all those who helped get the bugs worked out early on!

Original Post:

Hey guys, I found this cool Java/Processing project, which uses a destructible pixel terrain. I decided to take a shot at converting to Unity's C# and here are my efforts so far...



Link to original (Java/Processing) source:
http://gamedev.tutsplus.com/tutorials/implementation/coding-destructible-pixel-terrain/

So here is the deal, since I am porting it from an open source project (errr... tutorial) in Java/Processing, I say it could be an open source project for unity... If I can get the help I need to get it up and running, then we share the whole project with the community (asset store free section perhaps?) and everyone could make some cool stuff out of it. Think of all the interesting "cortex command" and "clonk" clones haha.

So I ask you fellow forum members, help me in my goal, and lets make something I have never seen in Unity... Download, disect, come back with answers/improvements to its problems... simple as that.

see further post for more info

 

Very awesome to see this actually happening. I saw your original question about it and wondered if this would actually progress. Hopefully we can all come together to make something magical happen!

 

That's my hopes, I will still be grinding away at this the next few days, and hopefully I get some good feedback here in this thread, and get the ball rolling.

see further posts for more info

 

Tried to fix some,

Renderer.cs

original:

Code (csharp):

1. for (RenderObj obj : objects)
2.   obj.draw();

replace with:

Code (csharp):

1. foreach (RenderObj obj in objects)
2.   obj.draw();

and added public.. to these (in Bullet.cs)

Code (csharp):

1.     // methods implemented as a PhysicsObj
2.     public float getX() { return x; }
3.     public float getY() { return y; }
4.     public float getVX() { return velX; }
5.     public float getVY() { return velY; }
6.     public void setX(float pX) { x = pX; }
7.     public void setY(float pY) { y = pY; }
8.     public void setVX(float vX) { velX = vX; }
9.     public void setVY(float vY) { velY = vY; }

ArrayList can be most likely replaced with List.

One problem is the millis()
http://processing.org/reference/millis_.html

 

Ok making changes to the upload to reflect these changes mgear, thank you.

see further posts for more info

 

Made one test from the original sources,
it can at least draw the terrain with transparent bg..
but nothing happens since those update/draw() functions are not done..(not sure if it would work anyways : )

Code (csharp):

1.   public void draw() {
2.     //fill(col);
3.     //noStroke();
4.     //rect(x,y, size, size);
5.   }

Download current source package:
http://www.mediafire.com/download/bjxdmk8kwtunv9s/pixelterrain_test1.unitypackage

For milliseconds, can use:

Code (csharp):

1. private System.Diagnostics.Stopwatch  stopwatch;
2. stopwatch = new System.Diagnostics.Stopwatch();
3. stopwatch.Start();
4. ..
5. stopwatch.ElapsedMilliseconds; // returns ms

 

awesome, sounds promising, I will compare our work and see what I can do with it... I'll check back when I've gotten anywhere...

see latest posts for more info

 

Spent the day working away at it, I completely started over from the Java source, then came up with a much cleaner, better formatted, better commented, still-not-working version of the same thing... which is available still from the first post.

I got through some errors, changing java/processing conventions over to C#, naming all the scripts with conflicting (unity built-in) names to CustomWhatever... I did a lot of testing but was not able to properly draw anything to screen... this is proving to be much more difficult than I had thought! I'll check back tomorrow, hopefully someone else can have a look through it and figure something out.

see latest post for more info

 

Didnt check the latest package yet,
but in previous version you didnt have img.Apply(); after img.SetPixels(..)
http://docs.unity3d.com/Documentation/ScriptReference/Texture2D.SetPixels.html

I also had problems with graphics.drawtexture, it doesnt start from upper left corner when given 0,0..

 

Yes I think I fixed the img.apply part in this new package... but yes drawtexture doesnt work like I expected it to, maybe some unity 2D guru could give us a push in the right direction with that. I might even post a unity answers question with that particular code if I cant get it figured out today.

Edit - doh! I was trying to call Graphics.DrawTexture where I couldnt, it must be in OnPostRender, or OnGUI..(perhaps others as well, but not normal methods/update...)

 

Now it can:
-draw the terrain
-find every purple pixel
-replace every purple pixel with transparent pixel
-redraw the terrain
-spawn player

took hours of hacking at it to get it that far - but now we are really getting somewhere, and I'm learning a good bit of useless Java information... - although I owe much of this new update to mgear - for helping sort out a few big ones in his source that I picked through, or atleast pushing me in the right direction.

New info:
I made a webplayer to test out the current version (its broken right now, no shooting, no character controls)

In this webplayer you can see the glitch I am having problems with right now is that the player (just a green and black cube) starts floating upwards like gravity is reversed.

I tried just using negative value as gravity, only slows down the upwards movement, which led me to think it must be somewhere else effecting it. Anyway you can try it here:

see first post for links

and same old link for the source of it to maybe... help me out? haha

 

Nice work!

In customphysics modified this part, now it falls better (although still upwards),
see original code, that closingbracket/else position:

Code (csharp):

1.             if(obj.GetType() == typeof(Player))
2.                 {
3.                     if (!(((Player)obj).onGround  velY > 0))
4.                         obj.setY (obj.getY () + velY * fixedDeltaTimeSeconds);  
5.                 }
6.                 else
7.                     obj.setY (obj.getY () + velY * fixedDeltaTimeSeconds);

hmm that didnt do much even if disabled,
its getting moved up in here:

player.cs (~line 225)

Code (csharp):

1. y = yCheck - playerHeight / 2;

 

It's hard getting to the bottom of this physics bug, disabling gravity from the customphysics.cs or inverting it (whatever it was * -1) doesnt bring him down (or leave him floating still) like expected. So I am really scratching my head on this one - but in other news lol, I managed to sorta figure out getting the sky to not be black, but transparent, but then as soon as I got it working I managed to screw it up again - go figure. Anyway those are the two issues im working on right now - the players bad gravity effect (im thinking its isPixelSolid() related by the way...read bottom part) and the non-transparent (yet 0 alpha) "sky" which only comes up black for now? I'll report back if I get anything working today.


Oh and also... you can comment out a few sections of player.cs and the gravity will drop him to the bottom of the screen properly, it just wont have him stop on terrain, goes allll the way down to the bottom of the screen... so I am almost certain something is wrong with the player constraints coding... perhaps also again, isPixelSolid from CustomTerrain could be doing it.


EDIT: oh right good eye on that bracket thing! I'm changing it now. and yes noticed that that line seems to effect it too, I'll see what I can figure out with it.

Oh another thing, isPixelSolid has debug stuff showing (atleast in mine, not sure if I uploaded it like that) and it seems to always report alpha of 1 no matter what pixel is tested... as if the part that assigns 0 alpha to certain pixels is not having an effect.... hmmm... makes no sense because like, the sky is either becoming clear (seems like first run does this... and then black thereafter) and that means that it applied those effects to the image... maybe when I am running the isPixelSolid its only checking the source image? I had tried using a dummy version of Color[] to hold ONLY the alpha, so all 0, 0, 0, (1 or 0) once it was set was what I expected, but even running ispixelsolid on that STILL returns a 1 - no matter what???



Okay breakthrough on that part - its feeding bad pixel coordinates... I decided to try coloring the pixels ran through ispixelsolid with a green color, and bam at runtime I see this:



and so I am gonna have some work to figure this out.... is unity reading from bottom left corner? hmmm

somebody answer if they have insight

 

in customTerrain.cs

find:

Code (csharp):

1. return img.GetPixel(x,y) != Color.clear;
2.  

replace with:

Code (csharp):

1. return img.GetPixel(x,y) == Color.clear?true:false;

Now its bouncing..

*edit: actually it should be opposite..since the original code is !=

 

oh sweet haha, be back in a few

yes this definitely fixes that part! okay, now I have updated this question here to get help with this aspect:

http://answers.unity3d.com/questions/534239/getting-certain-pixels-from-texture2d.html has been answered

 

ok it seems the whole image is upside down somehow,
because if you do this SetPixel() in CustomTerrain, inside isPixelSolid()
it draws inside the terrain (not where the player is)

Code (csharp):

1.             img.SetPixel(x,y,Color.red);
2.             img.Apply(false);
3.             return img.GetPixel(x,y) != Color.clear?true:false;

*oh you had the same note in previous post

 

New, much improved, almost as good as that java webplayer version. Now destruction is visible, you can destroy and add pixels to the terrain with left and right click.

see the first post for a screenshot

You still cant see all the dynamic pixels properly (ones being blown up and spewed out with right click) until they land and become static pixels.... but hey, I'm bustin my butt here people! lol

see further post for more info

 

Man I am losing steam pretty bad on this project. I am needing some assistance for sure, as the problems I am facing now are pretty difficult to overcome - first major issue is the hanging of the editor and webplayer - its doing this all the time, every time. I don't use pro, and haven't got a good way to profile whats causing this... and commenting out random bits of code here and there is proving difficult to narrow down the cause.

Another big issue I am dealing with, is getting off OnGUI() and trying to draw to a quad in front of the camera (which I got a prototype going) because it seems quicker (better FPS anyway, until you start clicking) but it still suffers from hangs every 5-10 mouse clicks... so its hard to gauge how much of a difference it makes...

Now don't take me wrong, I am far from giving up on this project, but my free time is limited, and my 2D (expecially Texture2D) knowledge is limited... if I could get some people (like some 2D experts) to jump on board and start trying to fix some of these issues we could really polish this up nicely, and maybe get that performance you see in the java webplayer which seems to not even be phased by thousands of pixels all over the place...

Anyway, if I come up with any major changes I'll be sure to upload what I have... but for now I am pretty much stuck in researching better ways to handle this stuff. My theory for now might be to try switching to setpixels32 instead of setpixels... word on the street is that its much faster.

 

I was also thinking it could be easier just to start from scratch..
just take exploded (moving pixels) into array, calculate physics, update them to Color[] array, then Apply()..repeat.

here's profiler image from that last package:

 

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:

Code (csharp):

1. // create the dynamic pixel
2. //                              DynamicPixel pixel = new DynamicPixel (terrain.getColor (solidX, solidY), x, y, velX, velY, terrain.destructionRes);
3. //                              pixel.stickiness = 800;
4. //                              physics.add (pixel);
5. //                              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):

Code (csharp):

1. for (int i = 0; i < size; i++)
2.             {
3.                 for (int j = 0; j < size; j++)
4.                 {
5.                     terrain.addPixel (col, thisX + i, thisY + j);
6.                     //DynamicPixelGraphic.AddPixel(col, thisX + i, thisY + j);
7.                 }  
8.             }
9.             // remove this dynamic pixel
10.             renderer.remove (this);
11.             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?

 

Bump - I have been working hard still on this destructible terrain plan of mine, haven't got anything new to upload based on the stuff in my current package - but I am working on re-writing the whole project to be more suited to unity, which also means it won't really be the same project at all - but instead a whole new branch based on the bits and pieces I got working here on this project with mgear's help.

 

Ive nothing technical to share,
however if I was you, I would definitly dig deeper into it, and to keep motivation up just try to bring this to a releaseable state and sell it via Asset Store.

This way we all can benefit from it (maybe keep the price low like 25 bucks or something ), but getting money for it in the end could justify the efforts you have been putting in it so far (as I saw from your posts and questions) and perhaps motivate you to make it smooth

 

Thanks for the motivational post, I have been pushing pretty hard to get this project further along in performance, and although I'm not sure unity is right for this type of game framework, I'll be sure to figure out as much as I can and either post to asset store if it's good, probably super cheap like five, maybe ten bucks, and if when I've finished it, it stinks in performance, I'll upload source to at least show why it fails to do it this way.

PS I don't recommend using this current (available to download) build in any hopes to get something working, I've discovered countless flaws in how I ported it, and if you have interest in this, hang in there until next release, which is ongui free, and much more stable.

 

Since we are talking about it, here is some info about what the little demo I have going is like:

 

I just came across this thread and have to say I'm really excited to see your continuing developments. This sort of functionality would make a really swell addition to my Unity toolbox. Will be keeping an eye out!

 

Big Update:

See first post for latest version

This is officially version 2, cuz I say so.

Check it out guys! It's better, less buggy, but still capable of crashing your unity!



I would love some collaboration on this if anyone is trying to dig in and wants to push it further. I will be probably working on it some in the coming weeks and might upload more updates depending how much free time I have.

EDIT: Now I have updated the webplayer, so you can try it out online!

Webplayer:
https://dl.dropboxusercontent.com/u/76853021/DestructiblePixelTerrainWebPlayer/WebPlayer.html link down

 

Hey guys, small update with a fix for the primary fire not working sometimes. Should work well now, also got rid of right click context menu popping up:

Pixel Destruction Version 3 Unity Package link down

Same link to the webplayer, so check it out! Improve it!

 

Whats up guys, so I been spending a few minutes revisiting this package, and remembering where I am getting hung up. See right now the problem is when the player shoots near the boundaries of the map (bottom, left and right side being shot at the edges) it causes the editor or player to crash. I expect this has to do with either the rendering or physics checking something out of the edges of the screen, causing some unhandled exception or infinite loop or whatever. Problem is I am having a hard time hunting down this bug - as the editor log file has no useful info, ending with:

which these areas of the code show no signs of having a problem, and those are debug logs I was testing with to improve the problems with shooting not working consistently when the player clicks (in version 3 I addressed that problem) but truly these log messages have nothing to do with this problem. It seems the editor completely hangs (doesn't give error report, just freezes indefinitely) and doesn't log anything past the moment where my problem occurs so I get no useful information after the crash, and don't know for sure what could be the culprit.

Anybody got pro who could do a profiler check and see if they notice an unusual bump in performance of any certain method when the player shoots the edges of the map terrain (which will eventually crash the editor)? Perhaps this would help me get to the bottom of this freeze annoyance, and try a few new ideas I had in mind for this package

 

here's profiler screenshot (digging the terrain).

maybe using queue instead list could work?
(at least it was much faster when i tried it with a simple floodfill, compared to list remove)

 

Hmm queue instead of list... Better get my Google going, never heard of it, could you describe how that works? Thanks for the quick response mgear, hope your doing well!

 

this floodfill here is using List:
http://unitycoder.com/blog/2012/10/10/flood-fill-algorithm/

replaced the list with http://www.dotnetperls.com/queue , it was 10 times faster..
but not sure if its suitable here (didnt check your latest sources yet).

 

Well I'll read into it and see what works best. At this point I'm thinking of using an int array for every pixels solid, air, or unique properties, to increase read speed for collisions and such. But maybe this could optimize things enough to stop this repeat crash I get when destroying the ground near edges. I'll post back tomorrow sometime if I get any results.

 

Ok well I did some digging, and read about all the different generic collections... and I am drawing a blank!

I see that in some cases a queue is the right thing to do, but I also notice that queue items are handled in order, which for the purpose of random read/write to any one of the items in the queue might be a problem... or will it?

And I see dictionaries are supposed to be fast in some circumstances, but how would I even apply a dictionary to this type of situation? I might need to read into these further to understand the usefulness.

I also seem to understand after reading all these performance related discussions (about generic collections vs arrays) that a built in array can actually be much faster than all these generic collections if they are used properly... right? I mean like I suppose not having dynamic size would be a problem... unless... I keep an array of every single pixel (in the current version what... 512 x 512 pixels then?) that would be in the image of the terrain (including empty ones!) and that way I wouldn't necessarily need to resize the array ever, and only edit the certain pixels to be either active or inactive at certain locations???..... errr wait... yeah? no? I remember originally avoid built in arrays in favor of dynamic list add and remove functions... but, its killing the performance? Maybe having the whole "is solid" "is air" data stored in an array would help stop all the dynamic removing and adding to the list, but still I have the heavy Apply() happening very frequently...

I am trying to wrap my mind around it all and figure what is best to replace these lists, because the slowdown of dynamically removing items from the list seems to be what kills performance (quite possibly killing unity or the player along with it half the time) according to that profiler screenshot.

Anybody have any input on whether or not a built in array (or probably several, for terrain, as well as dynamic pixels) could replace these list in the way I am using them? Remember, anybody can download the source and eyeball the code to try and decide if I am taking the wrong approach to this! Perhaps I need to direct my attention to creating a shader to handle the rendering, and avoid having Texture2D.Apply() used at all!

 

In the update loop there seems to be two setpixel for each loops,
that will be slow, just assign the colors into array (then assign the whole array into texture).

And instead of adding into list, maybe could have fixed size array, then just keep counter value for what is the length..(so there is no need to clear/reset/resize the list)

also using LoadRawTextureData() will make it ~10 times faster rightaway.

 

Hmm interesting ideas, I'll start working on it and see what I can do. So LoadRawTextureData() could be a faster alternative to getpixels32 you mean? I'll read on the docs I suppose to find out what is going on with that. Hope that's true, but I suppose the Apply() is still required to do my rendering, man I sure wish I could find some info about a shader that could do some pixel crunching magic faster than editing a texture with stuff, then doing Apply(). I've been thinking hard about trying integer arrays, avoiding those lists, and have a couple ideas to test, but I imagine it'll take me some time to cook something up that's functional. Thanks for digging in there mgear!

EDIT:
@mgear
I have a problem when it comes to keeping track of the objects added to a PhysicsObject array. See the old way is I just stick the physics object into a list, and then remove said object from the list. I don't have to pick them out of a stack you know? But when I try to change it over to an array, I realize I must track each physics object somehow with an ID or something, because when it becomes time to remove the physics object, I need an index of that particular one in the array. Only way I can imagine is just having a var kept on any new physics objects (ID) that makes it match its index in the array, so that when objects come into collisions before others spawned before it, I don't remove it from the array in the wrong position. So even if I do an ID per each physics object, and hand it off to be removed from the list in its particular position (as pixels never end up dying in a perfect order that they spawned in) I still have to consider where is "available" in the pool (i am presizing the array at 250 physics objects to see if that threshold is passed in testing or not) to stick future new physics objects in at right?

Like what I am saying is that wouldn't I then need some kind of bool[] array to match my physics object array, saying where is occupied, and where is not, so that when the player quickly fires two times, causing two separate spawning events of many physics objects, which will certainly have all kinds of different positions in the array after several adds and removes from it... well yeah that would mean I need to know which "slots" are open to be added to the ID numbers and positions in the PhysicsObjects[] array right?

I'm tired... lol... maybe tomorrow I might take a shot at this probably slow plan of comparing bools and looping through arrays, only to find out it goes slower than the list<> did! ha.

Edit 2:
I did some experimenting and got rid of the list<> for physics objects, replacing with two arrays, one for physics objects themselves, and a bool array to say which slots in the index are active. I had to add some iteration through those arrays to get the right index matched up, but without replacing the other list within the terrain script, performance gains were significant. Like actually so big, the player moves too fast! I think this could be the breakthrough this project needed. I'll work more today and post back a comparison of performance, as well as whether or not the crash is eliminated afterwards. Wish me luck.

 

Ok here to report my progress again. I uploaded an "experimental" version, I am calling this version 3.5, and this is intended to show only the removal of list<> from CustomPhysics.cs, and use of a fixed size array. It is quite a mess really, because everything is not commented, and some stuff... well it is just plain experimental and may not even work properly! STILL CAPABLE OF CRASHING EDITOR/PLAYER. But The performance seems steady, although I don't notice an increase in FPS yet, consider that there are still two very busy generic list<> in the primary script for the terrain (PixelDestruction.cs), which I have yet to "phase out" because I have to be sure this is gonna have better first within CustomPhysics.cs before I am ready to implement in PixelDestruction.cs.

Anyway @mgear (or other willing participant!) if you have a moment, check it again with profiler and see if there are smaller spikes, and if the Array changeover has caused less slowdown while digging the terrain, and I'd really appreciate it. I will continue experimenting and perhaps switch out PixelDestruction.cs tonight if I can manage before I am exhausted and burnt out on coding!

And here is the link to download the experimental (3.5) version:
see first post for link to newer version

Things to note about this:
- does not properly keep track of the physics objects, as somehow the total count (activePhysicsObjects) will eventually be greater than 1 even when no moving pixels or bullets are on screen (which the player is a physics object, and there should always be atleast 1, the player). Another problem with this is it might cause the activePhysicsObjects count to go negative... causing no calculations to take place, so you can't fire until restarting. Bummer I know. This means somehow I screwed up that whole ID part, and assignedIDs must be screwed up somewhere... I'll work on this, but wouldn't mind if someone with fresh eyes points out a problem... infact I wouldn't mind if someone pointed out ANY problems, because I am sure there are plenty!

 

Hi, heres new profile stats.

Could cache those texture.width & .height values also.

(click to view)

 

Ok cool, I see much less of the slowness showing up caused by the CustomPhysics list! I went ahead and made a cached width and height var so I don't have to check texture2d each time in those methods. One thing I have noticed with the new array setup for physics objects is that I can max out the current fixed amount of active physics objects by spraying pixels straight upwards, so I'll have to increase from 1000 max to maybe 2000 max. I doubt this will impact performance really since it is fixed size though, and probably wouldn't hit the max of 2k in this world size with this destruction resolution. I added a bunch of Error and Warning logs for certain events, but a couple could be cut (like the one warning you when a pixel leaves the edges of the screen which is pretty frequent). All and all performance during destruction should be faster now, but I still cannot get to the bottom of the crash when shooting near borders of screen. It has been bugging me a bunch, so I'll keep trying to get that sorted out, so I can get into testing larger worlds, and higher destruction resolution.

Newest version with several small fixes (version 4) is here:

see first/last post for newer download links!

 

Bump. Temporary fix for the crashing, which is to make the border solid. Now pixels can get stuck to the top of the texture, and sides... however the game won't crash anymore!

Get version 4.6 with several improvements, increased physics object limit and more!

https://www.dropbox.com/s/6vhngdxlhb8rgtt/Pixel Destruction V 4.6.unitypackage?dl=0

EDIT oh ps, used a cortex command level for testing, its "rich lands" if you have ever played CC! I used a chunk of the level thats 2048x1024 in size, more than double the previous size in testing!

 

Hey what's up guys. I was just testing this new build in android (galaxy exhibit, semi slow phone) it can handle it roughly 5 or 10 fps:



So yeah, not too bad, but I've got a good bit of optimization before it's a playable demo really. Not bad for this projects first build to android though! Definitely exceeded my expectations, I thought for sure it would be unplayable completely. Anyway I'll report back anything cool I might make happen!

 

I've added an animated character (pixel miner) and tested the last test level on mobile with my galaxy exhibit with joystick movement. Runs much better than the large cortex command level did, but still some stutters when shooting. I'll be trying some new optimization experiments with breaking up the large levels into many small tiles, and do only small local texture editing and Apply() calls for active cells in the level. I am optimistic for now that this would improve performance greatly but can't say for sure yet. I'll be back eventually to like quadrupal post.

 

Looks very cool, im going to play a bit with this and see if i can help or contribute in any way.

 

Can you give an overview of how it works? From just a few minutes playing with it, it looks like the "flying" pixels are using particles, but then when the land, you make them part of a mesh?

Is the mesh using a quad (pair of triangles) for each pixel, or are you dynamically building a texture and displaying it as one giant quad?

Is there a custom shader involved?

I think I can think of some approaches to this that should perform pretty well, but some of them would require Unity Pro...

Anyway, it's a very interesting topic. Thanks for doing it!

 

I appreciate the interest guys. As far as an overview of how it works here's a basic breakdown:

First, there are no particles or meshes. It's entirely based on getpixel, setpixel drawing to textures in quads. In the last version I released, there's two quads, one for terrain, one for dynamic pixels. The gravity and physics are all driven by code not unity's physics, and depends on some fairly simple collision detection that calculates normals based on certain pixels being "solid" or "air" if there is alpha set on a pixel. The most intensive parts are the generic lists that dynamic pixels depend on, and the apply() of the textures being updated.

I've tried to keep comments pretty detailed but there are areas which you might have to just read through that I haven't gotten around to commenting.

I'll post back after with with more info tonight. Good luck, and be sure to let me know if you find any errors, or it crashes on you, or if you improve any of the methods!

 

Instead of having one huge texture for the static pixels, have you considered tiling it into (say) 16 or 32 smaller ones? Since most of the pixels aren't changing most of the time, I would expect this to greatly reduce the apply() time. (There are other benefits too that would kick in for really big worlds — any tile that was a solid color, you could avoid having a texture for that at all.)

But now you've got me wondering how it would perform if each pixel were a little quad itself. Probably not all that well — a VGA screen has 307,200 pixels, which is a lot of quads even by modern standards. But again there may be tricks you could do to greatly reduce this.

Or, probably better still, use a custom shader that reads directly out of an indexed-color buffer. Indexed color is fun too because you can do things like color table animation (often used back in the day for water and fire).

Dangit, now you've got me thinking about this too much... but I already have too many projects!

 

Yes, in fact the next version I'm working on is broken down to much smaller quads, and it's not finished yet, but I foresee improved performance.

Yes I tried many single pixel objects before, didn't work out well. So instead this time I'm doing like 256 x 128 chunks.

Well hey, I've read just minor things about that, but my shader knowledge is little to none. If you have suggestions for an example of a shader like that I'll go to town trying to implement it. I'd considered that but had a hard time finding any good info on it.

Edit oh and please take a little break from your projects and dedicate many hours to this one lol! No but seriously if you can spare any time to trying to improve performance, or hell, animate some characters or something for it, I'd be mighty appreciative! So far only mgear and a couple others have helped me out, and I'm always in need of someone to push me in the right direction!

 

Hey guys, just another android testing screenshot, which works surprisingly well on my beat up exhibit:

 

Hi there,

thanks for your effort in researching how to do this in Unity! I was just starting out in Unity and your tutorial/sample was very helpful in getting the hang of its basic interface and pipeline. Since I want to eventually target Android as well, I've added a few performance optimizations to the sample and they are actually along the lines of what JoeStrout was suggesting: rendering into smaller texture tiles and composing the terrain out of them (editing the 2048x1024 did seem to leech a lot of engine's speed), storing the world data outside the texture so it does not get queried too often (I expect an overhead here) and finally rendering the dynamic overlay without the use of an extra texture.
Now it does seem to run in a satisfactory speed on my phone

In case you or anyone is interested in further development of this small sample, please find my modified sources here: https://dl.dropboxusercontent.com/u/13160266/PixelBurst2.zip and feel free to use them for anything you like. The original ones helped me a lot. I will also be doing further development on this so drop me a line if you're interested in cooperating.

 

Well thanks! I have actually taken the project available here and basically overhauled the entire thing to create a working android version. I am actually pretty close to having a good bit of a functional game, and in about six months to a year I'll be releasing on google play! I will certainly check out the changes you have made, and perhaps there is something that will help me in that pursuit.

Here is a teaser of what I am making out of this project:



Don't mind how I am murdering the FPS in that test on android haha, things have improved a good bit since this screenshot!

EDIT: oh and yeah I would love some cooperation in this effort, maybe get ahold of me through PM and we could figure out a way to collaborate on the project!

EDIT 2:

Ok took a few moments to look into how your handling the large world, and good work! I didn't think of working on multiple split textures then applying to a single quad/gameobject - instead my version uses many separate sprites, each with a separate texture, material... and so on.

I notice your using the 2048x1024 level, which while large - I was able to go up to a 4096x4096 sized texture by using the split gameobjects/textures, and I did that because some androids only support up to 2048x2048 max size, and I hope to push it to the upwards of 8k x 8k sized worlds, and since there are no androids (that I am aware of) that can take larger than 4096x4096 textures, I chose to use relatively small ones, for now I use 512x512 "cells" that handle all the changes in a square of the world. This required the creation of an editor script that can take four textures (up to 4096x4096 in size) and splits them up into the 512x512 cells, and assigns all the variables to pixeldestruction.cs, later allowing decent FPS on mobile.

One thing I see though is yours has a more stable framerate than my version, which might be in part due to the smaller level, and in part to the additional weapons, textures, and such that my version has. I haven't gone public with that version (open sourcing it) because I plan to use it in my own game - and maybe down the road I might make it available after some time - because that way I won't have to worry about a flood of competitor apps being released around the same time as my own! But if you think you could dedicate some time to it, I would be happy to share some insights on pushing your version further so we can see if it handles larger worlds as well (if not better) than the version I use. I didn't do anything like world.cs (I don't totally understand its purpose but I guess it handles the creation of a single mesh from all the textures?) and instead just use some math to decide which "cell" to edit at runtime.

 

Hi again, I will certainly try to play with larger sizes now. First I wanted to do a 1:1 remake of the original sources so they can be used to further inspire some optimizations. So far I mostly abstracted the world data from its textures (that's the purpose of World.cs - to provide an interface to edit the world and queue those edits to be picked up and processed by the renderer), now I'll try to finally profile its performance and see where most of the CPU cycles reside. I'll let you know how that works out and if I can get my code to scale well up to 8Kx8K world

I totally understand wanting to work on a closed-source game on your own - in time, I want make one well, one that would be based a lot on, ...suprise..., terrain destruction! But if interested, we can certainly share our engines and insights on how to do optimize them - I will be definitely trying to keep the engine and gameplay parts as separate as possible and going also to research whether it can be done similarly in UE4.