Splitting up Spritesheets

I usually do it the other way around and build up sprite sheets from individual images with a custom tool. As well as building up larger textures, the tool also saves out the locations of all the original tiles which I can then use in my engine.

If you're really needing to approach it from the other direction and are splitting up a large sprite sheet, then it depends whether it's organised into a regular grid or not. If it's a regular grid then it's just a bit of maths required to calculate UVs. If it's not regular, then I think you're heading toward a big hardcoded table of UV coordinates.

I would go with a sprite sheet, which is the most compact way of storing frame sequences or individual sprites into 1 big texture sheet. There are several tools (commercial and free) out there that can create such a sprite sheet for you, like:

http://www.zwopple.com/zwoptex/

http://www.codeandweb.com/texturepacker

A free tool that I wrote is ShoeBox

http://renderhjs.net/shoebox/

It has 3 related tools that can do those things

I never really thought about doing it the other way around?

I had an idea in my head of having the the sheet in a regular grid then splitting it up in the engine somehow then give each grid square a coordinate.

and wow i never know tools like that existed renderhjs. i guess i didn't look around enough.

this information does clarify things thanks guys

SDL_Tileset *tileset = SDL_LoadTileset("tileset.png", 50, 50, 1, 3, 3, 2);
SDL_DrawTile(35, 200, tileset, /* Tile # */ 1, screen);
SDL_DrawTile(100, 200, tileset, /* Tile # */ 2, screen);
SDL_DrawTile(100, 100, tileset, /* Tile # */ 15, screen);

A number of years ago, I wrote a set of functions for using spritesheets in SDL

Thanks this helps a lot :D

my simple game engine i'm working on has 2 image handling classes, one is i think g_spritesheet and the other is g_material or something along those lines, you can load stuff into spritesheet, specify a cell size, then load images into the other based on xx yy -- the xxth tile from the left and the yyth tile from the top, aswell, optionally telling it how many cells to take from

-it's not a great implementation, and i will probably combine the classes at one point and have g_material able to handle the functions

anyhow, the spritesheet is structured like this

{
	
	GLuint tex;
	GLubyte *data;
	
	ILuint iltex;
public:
	bool loaded;
	unsigned int w;
	unsigned int h;
	unsigned int gridsize;
	g_spritesheet(){loaded=0;};
	g_spritesheet(char*,GLuint);
	g_spritesheet(char*);
	void load (char*,GLuint);
	GLuint getimage();
	GLuint getsprite(unsigned short,unsigned short);
	GLuint getsprite(unsigned short,unsigned short,unsigned short,unsigned short);
	void draw (int x, int y);
};

and the materials (its actually g_texture)

class g_texture
{
private:
	char* name;
	ILuint iltex;
	GLubyte *data;
	GLuint tex;
	float xoffset, yoffset;
	int w, h;
public:
	bool loaded;
	g_texture(char* nam, bool unused)
	{
		name=nam;
		tex=0; w=0; h=1; loaded=0;
		xoffset=0;
		yoffset=0;
	}
	g_texture()
	{
		tex=0; w=0; h=1; loaded=0;
		xoffset=0;
		yoffset=0;
	}
	g_texture(char*);
	bool compchars(char*);
	void load(char*);
	void load(g_spritesheet*,GLuint,GLuint);
	void load(g_spritesheet*);
	void draw(int,int); //int x, int y
	void draw(int,int,float);//x, y, dir
	void setoffset(float,float);
};

i'll probably redo both of these classes as i know what im doing a bit better now, but i hope it gives you an idea

if you want better explanation, just ask in this thread

if you want more code from my system, just send me a msg

edit: oh also these use PNG's loaded by DevIL