That slicing looks awesome. How were you able to do that in XNA? From thinking about it I guess you would have to get the Color array from the texture and pull out the colors for each individual chunk. At that point do you create a new texture for each chunk using the color information? I guess you could draw a bunch of single pixels to build the chunk, but that would be a lot of draw calls.
I use XNA a lot and I'm just curious how you did it, it's a very cool effect. If you could give a few details into how it is done that would be awesome.
Yea sure!
When the game first starts, each entity reads a frame from it's texture into a static Color[,] (so it only needs to be stored once per type of entity).
public static Color[,] texture_data;
//later, in ctor...
if (texture_data == null)
{
Color[] colors1D = new Color[texture.Width * texture.Height];
texture.GetData<Color>(colors1D);
texture_data = new Color[frameSize.X, frameSize.Y];
for (int px = 0; px < frameSize.X; px++)
for (int py = 0; py < frameSize.Y; py++)
texture_data[px, py] = colors1D[px + py * texture.Width];
}
Now, when you're ready to split something, that Color[,] is sent over to the splitter. I'm using the Voronoi method to split up the sprite, which is actually pretty simple:
1) Decide how many sgements you want to split a sprite into
2) For each segment, give it an ID and choose a random position within the bounds of the Color[,]
3) Make a int[,] map same size as the texture that will store the segment id each pixel belongs to
4) For each pixel in the texture, calculate distance to every random segment position you generated, and store segment id with the shortest distance in your int[,] map
OK so from there, I just have a pool of objects with their own Color[,] that the segments are read out into. Right now, it's drawing each color individually as its own pixel. It sounds crazy but it's not that bad since there's no texture swapping or anything going on.
I'm about to try though making my pool objects have a Texture2D instead of Color[,] and running texture.SetData<>, then its only one Draw call per shard. The only penalty is pushing data over to graphics card, but I think that will be faster than thousands of Draw calls :D
I'll let you know what I find.
Developer
