next »

[DiscordGames]

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).

Code:

        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.

[joedev]

Wow! Thanks for going into so much detail. Super cool effect and not all that difficult to implement.

[beetleking22]

Damn slym you are hell of  a great artist.. It's great to see you persevere and improve at such a fast pace, how inspiring   but I hope this game is going to be as good as Super metroid, Metroid Fusion and Castlevania symphony of the night. Also kudos for all developers of this game.

[DiscordGames]

Alright, so today was pretty productive! Pretty much spent the whole thing optimizing the sprite slicing and pixel particle systems. Tony worked on more animations for the player and redid my temporary art enemies. Behold!

[happymonster]

Looks great! I definataly hope to see more info from Tony about the art.

The only thing I'd suggest is to change the damage number font and effect a bit. I'd make it jump up rather than float up (fastest at the start, then slowing till the top), and perhaps have it fade away, or shrink to nothing vertically.

Oh, if the orange things are coins, perhaps they would look better as circles? I keep seeing some kind of eye!

[Bandreus]

Loving it. I think the particles (the pixel ones, not the chunks) might be affected by gravity a bit too much, but then this is getting a bit too picky I think 

Great job guys, on both the art and programming side. This project looks very promising

[Cranky]

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 don't know anything about xna, but guessing that it is based on direct3d, I would guess that you can use texture coordinates when rendering. So when doing slicing, you don't even need to generate extra textures or raw pixel data to render portions (slices) of your base texture.
You shouldn't have to ever look into the pixel data when doing slicing in fact, you should only work with shapes (that's how you get reusable code and it works with any resolution). So when working with shapes, you can generate (convex) polygons for your slices, then generate texture coordinates for every vertex in the polygon. After that you can render polygons easily as a triangle fan (link1 link2).
This way you use the base texture for every slice. If you ever need to do anything on the pixel level, use pixelshaders instead (except when applying stuff that you only have to do once, like upon loading the texture itself). Also if you are trying to minimize texture swapping, you should look into using a texture atlas.
Don't misunderstand me, I'm not trying to tell you how to do your game ^^ just things I learned myself the hard way.

[Joshua]

Both of you guys are knocking this out of the park! Keep up the good work! 

[Linkshot]

Loving it. I think the particles (the pixel ones, not the chunks) might be affected by gravity a bit too much

I don't, just to counterbalance that. However, down the road, an ambitious endeavour would be each pixel having its own gravity. Then it calculates the average of the chunk and sets fall speed that way.

[DiscordGames]

Loving it. I think the particles (the pixel ones, not the chunks) might be affected by gravity a bit too much, but then this is getting a bit too picky I think 

Great job guys, on both the art and programming side. This project looks very promising

Thanks! It's actually kind of weird looking because the GIF is at half the framerate of the actual game (30 fps instead 60 fps). I promise it looks MUCH better in game. We're shooting to record a new development video in the next week, so I'll let you know when it's up.

[Friend]

That art... amazing! I wish I could pixel that well. Also, nice choice on the passive blue colors. Are there gona be lava and grassy levels?

[tred]

That art... amazing! I wish I could pixel that well. Also, nice choice on the passive blue colors. Are there gona be lava and grassy levels?

Thanks! We're not sure about grassy (I'd love to), but there certainly will be lava and quite a few other environments.

[elisee]

This is looking real good and great fun. Keep it up!

[happymonster]

Hope to see some grassy environments too.

[DiscordGames]

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 don't know anything about xna, but guessing that it is based on direct3d, I would guess that you can use texture coordinates when rendering. So when doing slicing, you don't even need to generate extra textures or raw pixel data to render portions (slices) of your base texture.
You shouldn't have to ever look into the pixel data when doing slicing in fact, you should only work with shapes (that's how you get reusable code and it works with any resolution). So when working with shapes, you can generate (convex) polygons for your slices, then generate texture coordinates for every vertex in the polygon. After that you can render polygons easily as a triangle fan (link1 link2).
This way you use the base texture for every slice. If you ever need to do anything on the pixel level, use pixelshaders instead (except when applying stuff that you only have to do once, like upon loading the texture itself). Also if you are trying to minimize texture swapping, you should look into using a texture atlas.
Don't misunderstand me, I'm not trying to tell you how to do your game ^^ just things I learned myself the hard way.

I thought about this, but the reason I chose to go the other way is that I don't think the polygons have any respect to the pixels. IE. if you slice the quad diagonolly, some pixels will be "cut in half" so to speak.

I tested this method on Xbox 360 last night and it was silky smooth, so I'm considering it "good enough" for now. :D

[Worthless_Bums]

Alright, so today was pretty productive! Pretty much spent the whole thing optimizing the sprite slicing and pixel particle systems. Tony worked on more animations for the player and redid my temporary art enemies. Behold!

That looks amazing. I find a lot of pixel art these days is a little too bright and eye burning but the blues you picked are great.

[DiscordGames]

I've just been working on boring stuff today, so I won't bother detracting from the awesome background Tony is working on for the Mines.

[DustyDrake]

Please tell me that if there's blunt weapons, they won't slice.

[Bandreus]

Please tell me that if there's blunt weapons, they won't slice.

I can easily see enemy sprites exploding in big chunks when killed with blunt weapons.

[ANtY]

subscribing to this thread cuz 2 awesum