[atraub]

I decided to unshelve an old project of mine and I'm trying to put some more sophisticated design ideas into it. Right now, I'm re-working the way my program reads sprite sheets. On my sprite sheet, I moved all my sprites 1 column to the right. Then, in the first column, I placed a few pixels to encode data into the sheet.

Pixel (0,0) = width & height of all my sprites (FF FF FF green is width, orange is height)
Pixel (1,0) = # of rows
Pixel ((2,3,...n), 0)= # of columns in corresponding row.

Here's the problem. I'm using SDL for this program. It reads the width and the height perfectly using this function:

Uint32 Sprite::get_pixel32( SDL_Surface *surface, int x, int y )
{
    //Convert the pixels to 32 bit
    Uint32 *pixels = (Uint32 *)surface->pixels;
    
    //Get the requested pixel
    return pixels[ ( y * surface->w ) + x ];
}

But when I try to get the number of columns, I'm wondering if this get_Pixel function is correct. Here's the relevant code I have thus far: (Keep in mind it truly pains me to show unfinished work, I'm sure there are MANY problems). I

Eventually I intend to turn Sprite into an abstract class, for testing purposes I'm hardcoding an image into it.

#include "SDL.h"
#include <vector>
#include <utility>
#include <iostream>
using namespace std;

#pragma once

class Sprite
{
	private:
		SDL_Surface *image;
		Uint32 get_pixel32( SDL_Surface *surface, int x, int y );
		void populateImages();
		Uint32 getNumberOfPoses();
		void getDimensions(Uint32* width, Uint32* height);

	public:
		Sprite();
		~Sprite();
};

Sprite::Sprite()
{
	image = SDL_LoadBMP("yellowdevil.bmp");
    Uint32 colorkey = SDL_MapRGB(image->format,0xFF,0,0xFF);
    SDL_SetColorKey(image,SDL_SRCCOLORKEY,colorkey);
	populateImages();
}
Sprite::~Sprite(){}


void Sprite::populateImages()
{
	Uint32 width;
	Uint32 height;
	Uint32 poses;
	getDimensions(&width, &height);
	poses = getNumberOfPoses(); 
}


void Sprite::getDimensions(Uint32* width, Uint32* height)
{
	Uint32 x = get_pixel32(image,0,0);
	x = x & 16777215;
	*height = x & 4095;
	*width = x>>12;
}


/**
 *ERROR!
 */
Uint32 Sprite::getNumberOfPoses()
{
	Uint32 x = get_pixel32(image,1,0);
	x = x & 16777215;
	return x;
}


Uint32 Sprite::get_pixel32( SDL_Surface *surface, int x, int y )
{
    //Convert the pixels to 32 bit
    Uint32 *pixels = (Uint32 *)surface->pixels;
    
    //Get the requested pixel
    return pixels[ ( y * surface->w ) + x ];
}

Here's the image: (Thank you spriters resource, credit will be given to original artist)
Sabaku
The value I should get for (1,0): 000008
And the Value I'm getting for position (1,0): FFFF00


Once the game is written for PC, I plan on porting it to run on Android and Objective C. Should I just abandon SDL and move to OpenGL? What do you guys think?

This post has been edited by atraub: 06 February 2011 - 09:57 AM

[ghillieLEAD]

What I like to do for sharing images is to create a free website hosting account that I use just for hosting images. Go to a site like webs.com, create a free account, upload the image, share!

[atraub]

Hmmm, get_pixel32 was designed to be used with a png. Could the problem be that I'm using a bitmap?

[ghillieLEAD]

Lets find out. Try using something like the following to snag a specific pixel:

SDL_Surface* screen;
Uint8* pixel;
int x = // x coord of pixel
int y = // y coord of pixel

pixel = (Uint8*) screen->pixels + y * screen->pitch + x * screen->format->BytesPerPixel;

EDIT: epic fail, I was thinking screen pixels when I wrote this. disregard.

This post has been edited by ghillieLEAD: 06 February 2011 - 03:09 PM

[atraub]

OK, I talked to lazy foo, about my problem. Here's what he had to say:

Quote

get_pixel32() only works with 32 bit pixels. For getting [24bit] pixels,
you'll have to create a routine that gets the array of pixels as an
array of 24bit integers.

Putting sprite data in a header might not be worth the return on
investment. bmp files are uncompressed and it might be more beneficial
simply to have the sprites on a png and creating a second sprite index
file.

He raises some good points I suppose... I really liked my idea of encoding data into the sheet too. I thought it was clever

This post has been edited by atraub: 06 February 2011 - 01:37 PM

[ghillieLEAD]

What I did for when I need sprite sheet specific data is create a tool that writes a binary file with the information I need in a format my engine understands. Then in my resources folder I have the folders spritesheets and spritesheetdata. My game engine then loads the information it needs when it first initializes as well as at runtime if needed.

EDIT: Not sure how long it took me to make the tools and modify my engine. I don't think it was very long. It was worth it though, with the tools and engine handling all the dirty work adding a sprite sheet to my games takes seconds.

This post has been edited by ghillieLEAD: 06 February 2011 - 02:21 PM

[atraub]

Yeah, I definitely don't want to hard-code sprite data into my game. The way I was creating my sheets was my attempt to make the sprite sheets contain the data necessary to read them. I still really like my old approach; but the feature is not important enough to justify dedicating any more time to it. I'll instead be brainstorming on efficient ways of generating the data files... and rooting for the Steelers!

EDIT:
Steelers, you were too sure of yourselves...

This post has been edited by atraub: 06 February 2011 - 10:19 PM

[Fib]

I agree with Mr. LazyFoo.

[atraub]

Passing thought:

I wonder if there's any reason why I couldn't use my encoding scheme in PNG images?

[Fib]

I feel that your encoding scheme introduces unneeded complication. Since you will be creating the sprite sheets, you will already know how many rows and columns there will be in it. If you really want that information about your sprite sheets, maybe use a separate text file.

That's just my opinion though.

[stayscrisp]

If you load in a configuration file for an object then couldn't you just have this data in the file as well. You could have the sheet you want to use, the width and height of each frame and the max starting frames. If the sheet has varying frame amounts for different animations then an animate function that can change the values would be pretty simple to do.

I think this is what Fib was suggesting.

This post has been edited by stayscrisp: 07 February 2011 - 11:06 AM
Reason for edit:: Beaten to it by Fib

[atraub]

I think you misunderstand StayCrisp, my encoding scheme would be in lieu of a configuration file for a given sheet. I really do love the idea of sprite sheet data being self contained, but this may be a project for another day.

Once the game is written for PC, I plan on porting it to run on Android and iPhone (I've heard converting C++ to objective C is not tough). I will need to change the control style to use touch screen commands, but aside from that, do you think this is a realistic strategy?

This post has been edited by atraub: 07 February 2011 - 11:13 AM

[stayscrisp]

I understand I was just suggesting an alternative

[Fib]

Yes that is what I was suggesting.

An iphone port would be cool. I've been interested in iphone development but I really don't want to buy a mac.

How far along are you on your game? Do you have any cool screen shots to show?

[atraub]

The game was shelved for about 6 months. In that time, I learned a lot more about C++. In the past, I was treating it like Java. I didn't realize that there was not a benevolent GC watching my bum. I'm currently taking classes at the Game Institute to try to get my C++ skills where they should be.


I've stepped back to the design phase of the game. I know how to design it from a Java perspective (ooh, I'll make an abstract class for sprites and have all sprites extend it. I'll create an interface called playable for the ones the player can use.) but I need to examine how appropriate my design is for a C++ setting.

EDIT:
When the time comes, I will probably invest in a used Intel Mac Mini and then set it up to a KVM switch connected to my desktop. Take THAT Apple!.

This post has been edited by atraub: 08 February 2011 - 09:07 AM