[FILLED] Looking for artist(s) to develop new style for A Valley Without Wind.

[Coppermantis]

Totally agreed. I may be in the minority in that I enjoy the current graphics, but I do and would like to keep them unless the new style is breathtakingly amazing.

[Wanderer]

1) Bitmaps aren't animated by nature. A spritesheet is a texture, not an animation - the coding for reading animation frames is usually handled externally within the game code itself as a result.

Ah!  That's why I couldn't find some kind of definition file to tell it the animation order.  For note, I was debating on seeing if I could lower the # of images in the run animation and not have it look moronic.  I suppose I could really just do that via an animated gif and muck with the layering.

2) You could technically do all your work in GIMP. GIMP is a very powerful tool - however (and this is personal opinion) it manages to be even more counter-intuitive than Photoshop and is generally a crappy program to draw or do animations in - it's like trying to slice a cake with a chainsaw. I find it best for the 2D equivalent of "post processing".

Well, not having sprung for Photoshop ages ago Gimp and I are very old friends, so that's probably more a matter of convenience.

3) Although it's much more difficult to actually alter animation data (short of decompiling the program, you'd need help from the coders themselves), it's easy to alter the sprites themselves

Yeah, I really wanted to goof with the number of layers really.  Alright, I've got a few ideas on that, thanks for the brief intro to sprite animation.

[Bluddy]

I still think there's a lot of potential in reducing RAM usage by reducing the size of the PNGs (and corresponding textures). Too much space is wasted on blank backgrounds because square polygons (really 2 triangles) are used to display the images. Back in the old days, you'd use palettized textures which use up 1/4 of the space. Nowadays graphic cards don't support that anymore. But you can probably reduce texture size by about 1/5 if you take every image in the dictionary and squeeze it in right next to another image, then create polygons that are much more fine grained to display each image.

[Nanashi]

I still think there's a lot of potential in reducing RAM usage by reducing the size of the PNGs (and corresponding textures). Too much space is wasted on blank backgrounds because square polygons (really 2 triangles) are used to display the images. Back in the old days, you'd use palettized textures which use up 1/4 of the space. Nowadays graphic cards don't support that anymore. But you can probably reduce texture size by about 1/5 if you take every image in the dictionary and squeeze it in right next to another image, then create polygons that are much more fine grained to display each image.

In my opinion, that'd just create more issues, especially for modding. I like squares.

Palettes still exist - they were never really much of a graphics card optimisation. This actually has a little to do with one thing I mentioned in my obsessive ravings about how AVWW was poorly optimised - Most of the PNGs in the game are actually unnecessarily large, but when I saw that the total filesize for an entire run animation was running only about 250ish KB, I kind of figured it wasn't worth mentioning. Just as an example though, this is the running spritesheet for the character I'm using - Dave2. The original file is 220 Kb.

I've uploaded a properly optimised and indexed version of the exact same file (this takes literally 3 seconds to do!) - it's 68Kb. Feel free to compare it, I doubt you'll see any difference at all between the two. This means the image is at the very least 66% larger than it absolutely needs to be.

But I'm also of the opinion that if you're playing any 2d game long enough to cause RAM problems, you should probably take a break before you turn into yet another horrible news story on how gaming kills people.

[eRe4s3r]

I compared it and you removed all smooth edge transparency from the file, which is generally what happens when you set an actual perfect transparency inside a PNG image to index with black matte Which results in very non-smooth blending or put different, pixelation at the borders.

I would bet that in game you would see the difference instantly given white or bright BG

[Nanashi]

@eRe4s3r:

I didn't do anything to it except index the colour - and this is a series of animated frames, making it even less relevant.

If you're referring to smooth edges, the word you're looking for is antialiasing. Antialiasing is a low return process with regard to sprites, especially with regard to animation (still sprites can be kept antialiased), and should generally be kept to a minimum if you're trying to keep file sizes low. The original image used 7912 colours. The indexed one uses 256. Most of that (over seven thousand) is wasted on antialiasing. If you're that convinced it matters, here's a simple test:

The following picture has some a mix of indexed and non-indexed character pngs in it. This screencap is non-lossy, so what you see, is basically what you get. Your task is to tell me exactly which images are the indexed ones. (Note this is easier than it sounds - but if you took more than 5 seconds to do this, it's not noticable ingame.)

You can actually even do minor antialiasing with indexed files while still retaining file compaction - and I can prove it. It just takes slightly longer than 3 seconds. -_-

[Bluddy]

I still think there's a lot of potential in reducing RAM usage by reducing the size of the PNGs (and corresponding textures). Too much space is wasted on blank backgrounds because square polygons (really 2 triangles) are used to display the images. Back in the old days, you'd use palettized textures which use up 1/4 of the space. Nowadays graphic cards don't support that anymore. But you can probably reduce texture size by about 1/5 if you take every image in the dictionary and squeeze it in right next to another image, then create polygons that are much more fine grained to display each image.

In my opinion, that'd just create more issues, especially for modding. I like squares.

Palettes still exist - they were never really much of a graphics card optimisation. This actually has a little to do with one thing I mentioned in my obsessive ravings about how AVWW was poorly optimised - Most of the PNGs in the game are actually unnecessarily large, but when I saw that the total filesize for an entire run animation was running only about 250ish KB, I kind of figured it wasn't worth mentioning. Just as an example though, this is the running spritesheet for the character I'm using - Dave2. The original file is 220 Kb.

I've uploaded a properly optimised and indexed version of the exact same file (this takes literally 3 seconds to do!) - it's 68Kb. Feel free to compare it, I doubt you'll see any difference at all between the two. This means the image is at the very least 66% larger than it absolutely needs to be.

But I'm also of the opinion that if you're playing any 2d game long enough to cause RAM problems, you should probably take a break before you turn into yet another horrible news story on how gaming kills people.

All graphics cards are dropping support/have dropped support for palettized (indexed) textures. It's no longer a technique that can be used. While you can do in inside the PNG file, as soon as you convert the image to a texture, the background will have to be filled in with full, non-indexed colors.

One option is to pre-compress the textures. I know Arcen said in recent patch notes that texture compression was added, but I think it needs to be done on the bundled images themselves to be effective -- it takes a long time to compress textures, and would take way too long to do each time you load the game. It also introduces artifacts which can stand out in 2d games sometimes.

While squares are nice and clean, they're very wasteful for animations. If you look at textures for 3d games, they pack in as much as they can into one 512x512 texture. There's no reason this can't be done for 2d animations. You simply create a different polygon for each frame, with an offset to know how to center said polygon, and then you take turns making each polygon non-transparent. As I said, the hard part is getting this stuff to be done automatically ie. transforming square images to 'compressed' polygon images.

[Nanashi]

All graphics cards are dropping support/have dropped support for palettized (indexed) textures. It's no longer a technique that can be used. While you can do in inside the PNG file, as soon as you convert the image to a texture, the background will have to be filled in with full, non-indexed colors.

If your program doesn't have 16-24 bit image support, the problem is in the coding/settings. It has little, if anything, to do with your video card. Having a limited palette will save RAM simply because you require fewer bits to represent the same amount of data. That's why many doujin games either force your display into limited colour modes or ask you on startup if you want 16 or 32 bit colour.

Secondly, triangles for animation simply is not practical from a design standpoint. You're thinking like an engineer, not an artist. A 2D texture is not a 3D texture - the reason images are compacted is simply because you're dealing with 2D textures mapped onto 3D surfaces and it's an efficient use of space as the actual order of the 2D image is irrelevant. You can't do morphing, nor mapping with a 2D image, and it'd be absolute hell to align properly.

It doesn't even save much space because of the nature of 2D images. Imagine animating a square. For you to represent a square in a triangle, you need to use a triangle with double the area of the square (don't argue with math). This loss is identical to that of trying to represent a triangle in a square. Unfortunately, animations are NOT STATIC. Mathematically, we can approximate the area needed with a circle (i.e. all directions of expansion are equally likely!) and superimposing a circle within a triangle causes quite a lot more wasted space than a circle in a square. Anything more complicated than a square, and it ceases to tessellate properly, good luck coding a viewer for that (not to mention most if not ALL animation viewers do not support triangles).

With 3D models, this is not an issue because you are just mapping onto a model. Irregular shapes are fine. You can't really use 3D theory in 2 dimensions because simply specifying the limits of each separate irregular polygon would take FAR more memory than anything you'd ever save.

Edit: Before you reply with "Hexagons tessellate and are more space saving compared to squares!" I'd like you to consider 2 things.

1) Why is the majority of our media in rectangular shapes? (hint: X and Y axis make it easy to isolate coordinates)
2) What is the simplest mathematical formula to describe a hexagon?

[Bluddy]

If your program doesn't have 16-24 bit image support, the problem is in the coding/settings. It has little, if anything, to do with your video card. Having a limited palette will save RAM simply because you require fewer bits to represent the same amount of data. That's why many doujin games either force your display into limited colour modes or ask you on startup if you want 16 or 32 bit colour.

I don't know if you realize it, but virtually all 2d animation in games nowadays is done with 3d textures. That means that in order to do palletized images, you need the 3d card to support palletized images, which they don't anymore (at least not the recent ones). This means that before displaying the image on screen, every palletized image must be converted to a full 16/24/32 bit image. It's true that 16 bits allows you to make images that are half the size though.

Secondly, triangles for animation simply is not practical from a design standpoint. You're thinking like an engineer, not an artist. A 2D texture is not a 3D texture - the reason images are compacted is simply because you're dealing with 2D textures mapped onto 3D surfaces and it's an efficient use of space as the actual order of the 2D image is irrelevant. You can't do morphing, nor mapping with a 2D image, and it'd be absolute hell to align properly.

It's actually a pretty simple idea. Right now every image is projected onto a square polygon before it can be displayed in the game. This is wasteful, because it forces you to space every image far apart. Instead of doing this, you can 'cut out' the smallest shape possible around the region you're interested in. Then you could save the images very close together. This wouldn't be difficult to morph or do anything else with -- the software would take care of the offsets.

It doesn't even save much space because of the nature of 2D images. Imagine animating a square. For you to represent a square in a triangle, you need to use a triangle with double the area of the square (don't argue with math). This loss is identical to that of trying to represent a triangle in a square. Unfortunately, animations are NOT STATIC. Mathematically, we can approximate the area needed with a circle (i.e. all directions of expansion are equally likely!) and superimposing a circle within a triangle causes quite a lot more wasted space than a circle in a square. Anything more complicated than a square, and it ceases to tesselate properly, good luck coding a viewer for that (not to mention most if not ALL animation viewers do not support triangles).

I think you're really not getting this. You can build more complicated (2d) shapes to contain the area you're interested in within the image. Sometimes a square may be the only option. Other times you can make far better shapes that'll allow you not to waste space. For example, every frame of the bat animation can be contained in something like a side-oriented ellipse, and the bats can then be crammed into a very small space. It's really not a complicated idea -- the hard part is creating the automatic infrastructure for it.

Maybe you think you need to create a shape that allows for all possible animations -- but you don't. You just make a shape per frame, and flip through those polygons, just as through currently animate through polygons for square images.

With 3D models, this is not an issue because you are just mapping onto a model. Irregular shapes are fine. You can't really use 3D theory in 2 dimensions because simply specifying the limits of the each separate irregular polygon would take FAR more memory than anything you'd ever save.

I'm not talking about having hundreds of polygons here. Most of the time 10 polygons would be the maximum you'd need per image, with the average being lower. It definitely wouldn't take anywhere near as much memory.

[Wanderer]

*blinks*

I have just learned that all the little things I thought I knew for graphics were a drop in the ocean due to the conversation you guys are having.  Please, continue, I just had no idea that graphics optimization had gotten this deep.

Oh, yeah, if possible please don't bring it offline... I'm learning a lot here... or at the least a lot of what I need to research.

[eRe4s3r]

@eRe4s3r:

I didn't do anything to it except index the colour - and this is a series of animated frames, making it even less relevant.

If you're referring to smooth edges, the word you're looking for is antialiasing. Antialiasing is a low return process with regard to sprites, especially with regard to animation (still sprites can be kept antialiased), and should generally be kept to a minimum if you're trying to keep file sizes low. The original image used 7912 colours. The indexed one uses 256. Most of that (over seven thousand) is wasted on antialiasing. If you're that convinced it matters, here's a simple test:

The following picture has some a mix of indexed and non-indexed character pngs in it. This screencap is non-lossy, so what you see, is basically what you get. Your task is to tell me exactly which images are the indexed ones. (Note this is easier than it sounds - but if you took more than 5 seconds to do this, it's not noticable ingame.)

You can actually even do minor antialiasing with indexed files while still retaining file compaction - and I can prove it. It just takes slightly longer than 3 seconds. -_-

It took me about 1 look in bridge to spot the one in the whites that is index (you should know that most forum software does not let you see png's unmolested), the middle one in the bottom row To black is impossible to tell because the matte defaulted to black. But I guess you have a point, it is hard to tell unless you look for it. So maybe it is a good thing to do that after all.

Anyhow you are correct that it is a good way to save space, I just wish the game would use alpha maps, we could easily maintain file compaction and get rid of the transparency completely. By just indexing the RGB channels, then reconverting it to normal RGB mode and add the 4th channel (which would be just grey tones). The result is a super low sized 32bit PNG. ^^ Or hell, a DDS texture and just load that as-is. Is Unity 3.3 not supporting DDS compressed textures? Or is it internally converting them?

[keith.lamothe]

I have just learned that all the little things I thought I knew for graphics were a drop in the ocean due to the conversation you guys are having.  Please, continue, I just had no idea that graphics optimization had gotten this deep.

It's pretty insane.  Chris and I both have a very deep background in enterprise database/web programming but he also has a pretty extensive background in graphics programming where I have nearly none.  So periodically we have the "Chris, please explain to me again why it's 2012 and drawing 200 rectangles on a screen is in any way a performance challenge?" discussion.  I'm not sure if I'm actually getting any better at understanding it   Well, a little bit: texture swapping being a major pain makes sense, the bus to the video card can only handle so much so fast.

[Wanderer]

Yeah, I'm coming to that conclusion.

Then there's the other part.  You know how some people can see when a car got a repaint in just one section of the vehicle?  I can't, even when my boss was pointing it out to me over and over when I drove for an Auction House.

What's the point?  I literally can't see Anti-Aliasing unless the object in question ends up with a significant halo.  Toss in a few of the other optimization/non-optimization pieces that I can barely, if at all, see and I've found my digital art ends up like the guy with no talent in singing who can still hit every note in Rock Band Expert... but you don't want to hear him.  Most of my art is simply paper art.  Doesn't mean I don't occassionally have fun goofing around with it.

Err, rambling.  Where I was going with that was I personally can't tell the difference for a number of higher end options for graphics unless they're glaring, and I'm running 1400x900 on 18" duals for years now.  Thus, some of these discussions end up going over my head simply because I can't see what they're talking about.  Add that to my personal opinion of I have 8 gigs of memory, why are we fighting for a few k/object and yeah, I'm RIGHT there with you Keith.

[nanostrike]

All I know is that without a texture pack, the characters are so awkward-looking that it makes me feel like I'm playing a slapped-together flash game, where they just use various magazine pictures as "Sprites".  No offense, but that's just the way I feel.  And a lot of my friends feel the same way.

Ditto for some of the enemies (The Mech and T-Rex really stand out in this way).

The environments are more-or-less okay, if a bit bland and generic.  Overall, I'd say that the characters would benefit from somewhat or a more cartoony, characterized look.  The "Realistic" thing just looks really awkward.

[Bluddy]

Anyhow you are correct that it is a good way to save space, I just wish the game would use alpha maps, we could easily maintain file compaction and get rid of the transparency completely. By just indexing the RGB channels, then reconverting it to normal RGB mode and add the 4th channel (which would be just grey tones). The result is a super low sized 32bit PNG. ^^ Or hell, a DDS texture and just load that as-is. Is Unity 3.3 not supporting DDS compressed textures? Or is it internally converting them?

The problem is that since modern graphics cards don't support indexing, you have to convert it back to a full image. So your savings are only so long as you keep the image in PNG form. Once you have to actually display it or keep it as textures for easy access, you're wasting huge amounts of space (though 16 bit textures would save you 50%): Each 512 by 512 32 bit image uses 1MB of RAM.

DDS compression takes time, which is why I don't think it's possible that Unity does it on the fly. The textures need to be pre-compressed. Also, the factor of compression is still limited and it leaves some artifacts. I still think it should be done though, but since the character graphics use only a few colors each, 16 bit might be a good enough solution. If you combine that with the method I proposed (which isn't trivial to implement), you could probably cut animation RAM usage down to 20% or less of the original amount.