Will Start Working On Sprites, But...
- Thread starter Jourdy288
- Start date
dflemstr
It's a ball.
Try to make them as large as possible if they aren't pixel based. I mean, really: as large as possible. 8000x6000 preferred.Jourdy288 said:
If they ARE pixel based (meaning: they're supposed to look blocky), then it depends on the game how large they should be, but the norm is to use base2-even numbers, like 32x32, 64x64, 128x128, 256x256, 512x512, 1024x1024, 2048x2048 etc. I've also seen combinations of those numbers for non-square sprites like 32x64.
The reason why base2-images are used is that you can use them as OpenGL-textures without wasting pixels (because when you use OpenGL, you have to have base2 sizes for your textures on many graphics cards so if you use non-base2-sizes, you have to use textures that are larger than the images to store them). Also, you can often do some drawing optimizations when the images are base2, so yeah, really no reason why you would use anything else than base2 images.
Last edited by a moderator:
iprice
Certified Guru
This question doesn't make any sense as it stands.
Sprites can be any size from 1 pixel square to larger than the screen of the game you're working on.
Try to reduce the amount of free space around a sprite, as wasted space just takes up memory. So if your total sprite is 24x30 pixels, using a 100x100 sized image is a lot of wasted memory, something like 32x32 would be more appropriate in this example.
Obviously the size of the sprites will depend on the game that requires them.
Also it is a waste of space if you have a basic image that only has small changes in different frames - in this case it's often better just to draw just the changes and place them on top of the basic image. Eg if you have a face and only the eyes move/blink, then don't create 10 face frames, just draw the eyes and place them on top of a face sprite.
Does that make any sense?
Sprites can be any size from 1 pixel square to larger than the screen of the game you're working on.
Try to reduce the amount of free space around a sprite, as wasted space just takes up memory. So if your total sprite is 24x30 pixels, using a 100x100 sized image is a lot of wasted memory, something like 32x32 would be more appropriate in this example.
Obviously the size of the sprites will depend on the game that requires them.
Also it is a waste of space if you have a basic image that only has small changes in different frames - in this case it's often better just to draw just the changes and place them on top of the basic image. Eg if you have a face and only the eyes move/blink, then don't create 10 face frames, just draw the eyes and place them on top of a face sprite.
Does that make any sense?
dflemstr
It's a ball.
Actually, I don't see why you would want to separate the eyes in this case (requiring alpha tests and another pass to draw etc). I would myself just use multiple face sprites, especially if I'm using OpenGL instead of SDL (ugh) since there really isn't a reason why you'd want to optimize small things like that when you have multipass shaders and such that you don't want to run more than necessary.iprice said:
Last edited by a moderator:
iprice
Certified Guru
Perhaps it's because I come from the 8bit school of computer gaming, that I try to optimise everything in my games - just because you can have huge graphics and textures nowadays doesn't mean that you should. Doesn't make it wrong either, just that many programmers don't optimise code or graphics like they used to - hence increasing file sizes and bloatware. Each to their own. Their are 1001 solutions to every problem 
dflemstr
It's a ball.
No you got my point wrong -- "optimizations" in this case would require more cycles than what you'd need if you'd just have multiple images (alpha testing, blending, custom shaders get messed up because of overdraws etc). Well, unless the face is 1024x1024 and the eyes 3x3 or something.iprice said:Perhaps it's because I come from the 8bit school of computer gaming, that I try to optimise everything in my games - just because you can have huge graphics and textures nowadays doesn't mean that you should. Doesn't make it wrong either, just that many programmers don't optimise code or graphics like they used to - hence increasing file sizes and bloatware. Each to their own. Their are 1001 solutions to every problem
Last edited by a moderator:
Vorporeal
Yes, no, I, this is.
Chances are that it would be more efficient if you're using color-keyed transparency. I'm pretty sure that SDL can handle that with no issues; doubt GL can though.
dflemstr
It's a ball.
I think that we'll need a little more than that to be able to make any decisions. A portfolio would be nice!Jourdy288 said:OK, here's the GIF of one I made by modifying a picture of a dendrite:
Last edited by a moderator:
Sphinxter
Says What?
Dude, SVG.
What do you use to create those? I think I saw there was a gimp plugin for .svg, but I don't know if there's a free app out there that's better suited to the task.Sphinxter said:
Edit: Inkscape I guess?
Last edited by a moderator:
bzar
A Commando
Inkscape is the tool I'd recommend for SVG's
dflemstr
It's a ball.
Yeah, there's no point in taking a normal image and trying to turn it into a vector image.B-ZaR said:
Last edited by a moderator:
iprice
Certified Guru
There's an online bitmap to vector image utiltity here - http://vectormagic.com/home
I've used it in the past and got respectable results, considering.
I've used it in the past and got respectable results, considering.
dflemstr
It's a ball.
Yes, I even own a "pro" copy of it, but the results you get by using it are often very chaotic. You get 28-layered SVGs for example, or shapes that look right but are implemented in a too complex way (a square might be implemented using 16 bezier vertices instead of just 4 normal corner vertices).iprice said:
And why create something using pixels first just to then vectorize it? Don't see the point, especially since it's simpler to create a vector image than a rasterized image imho.
Last edited by a moderator:
iprice
Certified Guru
I don't use vectors normally and I wanted to create a smoother version of a scaled sprite, which is why I used it. It did the job.
I'm not a graphics artist by any stretch of the imagination, but I can get by, so tools like this are of use to me sometimes.
I'm not a graphics artist by any stretch of the imagination, but I can get by, so tools like this are of use to me sometimes.
dflemstr said:
You would separate eye, mouth, hair stand animation, etc. and overlay it because it saves a ton of memory. And you don't have an image the same size as the face with just the eyes on it, you have a rectangle just slightly larger than the eyes themselves. And there won't be a lot of alpha tests if the sprites are RLE encoded; you'll just draw the pixels of the eye sprite that have information in them. Also if you have sprites broken up like face, eyes, and mouth, then you can combine different mouth animation with different eye animation, without having to store every possible combination as a full face sprite.
All of this is assuming of course that you are dealing with larger sprites, like portrait sprites.
Cheers,
Michael
Last edited by a moderator:
