Multiple Images in one file

Hello,

I was wondering if it was possible to have like a pcx file, with multiple
images in it. So one pcx file would like contain all the frames for the
animation… all the frames would be the same size, but I was wondering if
it was possible to grap certain parts of an image and put them into a
SDL_Surface structure. Kind of like a SDL_loadBMP but it wouldn’t take the
source from a file, and instead take it from an array instead…

is this possible with the sdl?

thanks. see ya

Yeah, that would be cool if you could post the code…

Thanks!!On Wed, 25 Aug 1999, John Garrison wrote:

Ryan Wahle wrote:

Hello,

I was wondering if it was possible to have like a pcx file, with multiple
images in it. So one pcx file would like contain all the frames for the
animation… all the frames would be the same size, but I was wondering if
it was possible to grap certain parts of an image and put them into a
SDL_Surface structure. Kind of like a SDL_loadBMP but it wouldn’t take the
source from a file, and instead take it from an array instead…

is this possible with the sdl?

Yes, just create a surface for the PCX and a surface for the sprite. Then do
a blit from the PCX surface to the sprite surface, but don’t blit the whole
PCX surface, just blit the rectangular area that the sprite is in, and then
do that for all of the sprites, preferably in a loop that just increments the
blit by the size of the sprite. I can post the code to do it if you need me
to.

thanks. see ya

Ryan Wahle wrote:

Hello,

I was wondering if it was possible to have like a pcx file, with multiple
images in it. So one pcx file would like contain all the frames for the
animation… all the frames would be the same size, but I was wondering if
it was possible to grap certain parts of an image and put them into a
SDL_Surface structure. Kind of like a SDL_loadBMP but it wouldn’t take the
source from a file, and instead take it from an array instead…

is this possible with the sdl?

d00d, write your own animation format. It’s easy as hell. Just write out the
surface->pixels to a file for each frame, and then load all of it into memory
with the same specs etc, it’s easy.

Paul Lowe
spazz at ulink.net

d00d, write your own animation format. It’s easy as hell. Just write out the
surface->pixels to a file for each frame, and then load all of it into memory
with the same specs etc, it’s easy.

Paul Lowe
spazz at ulink.net

Better to stick with some standard so people can mess around with the
artwork after the fact (if it’s open source). Nice to have open data files
along with the open source code.

-Dave

Better to stick with some standard so people can mess around with the
artwork after the fact (if it’s open source). Nice to have open data files
along with the open source code.

I agree. But with your own format you can make it so your sprites can be variable
sized instead of a static width and height. Unless in the PCX file you had
bounding boxes to search for, hmmm. that would be interesting.

-= aaron p. matthews
-= rival entertainment
-= http://www.Nayzak.com/~jerryma/rival

I agree. But with your own format you can make it so your sprites can be variable
sized instead of a static width and height. Unless in the PCX file you had
bounding boxes to search for, hmmm. that would be interesting.

-= aaron p. matthews
-= rival entertainment
-= http://www.Nayzak.com/~jerryma/rival

For my bomberman game I have each pcx file stored so that sprites move left
to right, top to bottom. The first sprite in the upper left is just a wire
frame of color # 1 with color # 0 interior. So it is easy to figure out how
big the sprites are, and they can be variable. I could be more clever and
have a single color #1 dot inside the box to specify the handle of the
sprite but I don’t do that. I try to make the pcx files around 640 across,
and as tall as they need to be. The graphics fetch mechanism just keeps moving
sideways until there isn’t enough space left to contain a box, then it moves
down a row.

With a frame mechanism the size must be minimum 3x3 but that doesn’t matter.

-Dave

Ryan Wahle wrote:

Hello,

I was wondering if it was possible to have like a pcx file, with multiple
images in it. So one pcx file would like contain all the frames for the
animation… all the frames would be the same size, but I was wondering if
it was possible to grap certain parts of an image and put them into a
SDL_Surface structure. Kind of like a SDL_loadBMP but it wouldn’t take the
source from a file, and instead take it from an array instead…

is this possible with the sdl?

Yes, just create a surface for the PCX and a surface for the sprite. Then do
a blit from the PCX surface to the sprite surface, but don’t blit the whole
PCX surface, just blit the rectangular area that the sprite is in, and then
do that for all of the sprites, preferably in a loop that just increments the
blit by the size of the sprite. I can post the code to do it if you need me
to.>

thanks. see ya

int load_tiles()
{
int i, j;
PD_Surface *buffer;

buffer = PD_LoadImage(“tiles.pcx”);

num=0;
for(i=0;i<4;i++) {
for(j=0;j<10;j++) {
PD_Blit (buffer, gfx_tiles[num++], j32, i50, 0, 0, 32, 50);
}
}

free(buffer);

return(1);
}

This is the code using my PowerDraw lib, to convert it to pure SDL replace

buffer = PD_LoadImage(“tiles.pcx”) with whatever image loader you are
using and replace

PD_Blit(buffer, gfx_tiles[num++], j32, i50, 0, 0, 32, 50); with

src.x = j32;
src.y = i
50;
src.w = 32;
src.h =50;
dest.x = 0;
dest.y = 0;
dest.w = 32;
dest.h = 50;
SDL_BlitSurface(Src, &src, Dest, &dest);

Dont forget to declare SDL_Rect src, dest and to declare and create a
surface for gfx_tiles[] you will need to change the 32 and 50 to the width
and height of your sprites.

*note this code is from Frank Ramsey’s isometric engine that I ported over
to my PowerDraw lib. I don’t want to take undue credit. :slight_smile:

Ryan Wahle wrote:

Yeah, that would be cool if you could post the code…

Thanks!!

Ryan Wahle wrote:

Hello,

I was wondering if it was possible to have like a pcx file, with
multiple

images in it. So one pcx file would like contain all the frames for
the

animation… all the frames would be the same size, but I was
wondering if

it was possible to grap certain parts of an image and put them into
a

SDL_Surface structure. Kind of like a SDL_loadBMP but it wouldn’t
take the

source from a file, and instead take it from an array instead…

is this possible with the sdl?

Yes, just create a surface for the PCX and a surface for the sprite.
Then do
a blit from the PCX surface to the sprite surface, but don’t blit the
whole
PCX surface, just blit the rectangular area that the sprite is in, and
then
do that for all of the sprites, preferably in a loop that just
increments the
blit by the size of the sprite. I can post the code to do it if you
need meOn Wed, 25 Aug 1999, John Garrison wrote:
to.

thanks. see ya

Or use a few pixels before the image to encode the width/height of the
following image (as a binary number). I’ve used this method.

 Warren

______________________________ Reply Separator _________________________________Subject: Re: [SDL] Multiple Images in one file
Author: at internet-mail
Date: 8/24/99 3:33 PM

Better to stick with some standard so people can mess around with the
artwork after the fact (if it’s open source). Nice to have open data files
along with the open source code.

I agree. But with your own format you can make it so your sprites can be
variable
sized instead of a static width and height. Unless in the PCX file you had
bounding boxes to search for, hmmm. that would be interesting.

-= aaron p. matthews
-= rival entertainment
-= http://www.Nayzak.com/~jerryma/rival

  Or use a few pixels before the image to encode the width/height of the 
  following image (as a binary number).  I've used this method.

I suprised that nobody has mentioned TIFF yet. It’s quite a cool format once
you get into it, and can store multiple images natively. see libtiff.

/dev

// David E. Vandewalle | The road to hell is paved with NAND gates.
// vandewal at skyblue.com | – J. Gooding
// david.e.vandewalle at lmco.com |On 25-Aug-99 Warren Downs wrote:

d00d, write your own animation format. It’s easy as hell.
Just write out the
surface->pixels to a file for each frame, and then load all
of it into memory
with the same specs etc, it’s easy.

Better to stick with some standard so people can mess around with the
artwork after the fact (if it’s open source). Nice to have
open data files
along with the open source code.

Also, it means an easier change to another format if the need arises.
Hypothetical example: maybe you’d like a lean version with a quick download
time - just convert your graphics to jpeg and rewrite your loading routine.

On the other hand, there’s a lot to be said for making up a simple
multi-image format when you’re dealing with many many little sprite
images…

Most important thing - keep the actual source of your imagery (eg bmp, png,
roll-your-own-custom-format, algorithmically generated, whatever)
independant from how it is used, so if you change your mind later on it’s
not such a big deal.

Ben.–
Ben Campbell (Antipodean Straggler)
Programmer, CyberLife Technology Ltd
ben.campbell at cyberlife.co.uk

ben.campbell at cyberlife.co.uk wrote:

d00d, write your own animation format. It’s easy as hell.
Just write out the
surface->pixels to a file for each frame, and then load all
of it into memory
with the same specs etc, it’s easy.

Better to stick with some standard so people can mess around with the
artwork after the fact (if it’s open source). Nice to have
open data files
along with the open source code.

Also, it means an easier change to another format if the need arises.
Hypothetical example: maybe you’d like a lean version with a quick download
time - just convert your graphics to jpeg and rewrite your loading routine.

On the other hand, there’s a lot to be said for making up a simple
multi-image format when you’re dealing with many many little sprite
images…

Most important thing - keep the actual source of your imagery (eg bmp, png,
roll-your-own-custom-format, algorithmically generated, whatever)
independant from how it is used, so if you change your mind later on it’s
not such a big deal.

JPEG sux. It’s lossy. Just do this:

Use PPM, or TIFF or something non-lossy, I dunno if compression is something
you need or not. One thing you can do is draw rectangles containing all the
frames of animation into the image like this:

(actual image)------------------------
| 1 | 2 | 3 | 4 |

Then load the big image, and extract those rectangles into whatever data
structure etc you use to natively reference the frames in your sprite, then
free the image.

What I do is:

make a file for each frame of each sprite:

play_walk_left_1.ppm
play_walk_left_2.ppm

explosion_1.ppm
explosion_2.ppm
explosion_3.ppm

etc.

Then load them, this way they’re easy to access, and I can edit any frame at my
conveinience.

Paul Lowe
spazz at ulink.net

Paul Lowe wrote:

Ryan Wahle wrote:

Hello,

I was wondering if it was possible to have like a pcx file, with multiple
images in it. So one pcx file would like contain all the frames for the
animation… all the frames would be the same size, but I was wondering if
it was possible to grap certain parts of an image and put them into a
SDL_Surface structure. Kind of like a SDL_loadBMP but it wouldn’t take the
source from a file, and instead take it from an array instead…

is this possible with the sdl?

d00d, write your own animation format. It’s easy as hell. Just write out the
surface->pixels to a file for each frame, and then load all of it into memory
with the same specs etc, it’s easy.

Paul Lowe
spazz at ulink.net

before creating a new format you could have a look at www.wotsit.org

i think there are enough formats out there …

bye,
ew.-------------------------------------------
lets go to another world … oberon

Enrico Weigelt wrote:

Paul Lowe wrote:

Ryan Wahle wrote:

Hello,

I was wondering if it was possible to have like a pcx file, with multiple
images in it. So one pcx file would like contain all the frames for the
animation… all the frames would be the same size, but I was wondering if
it was possible to grap certain parts of an image and put them into a
SDL_Surface structure. Kind of like a SDL_loadBMP but it wouldn’t take the
source from a file, and instead take it from an array instead…

is this possible with the sdl?

d00d, write your own animation format. It’s easy as hell. Just write out the
surface->pixels to a file for each frame, and then load all of it into memory
with the same specs etc, it’s easy.

before creating a new format you could have a look at www.wotsit.org

i think there are enough formats out there …

bye,
ew.

It’s not like I mean try to create another standard, just hack it together for your
own conveinience.

Paul Lowe
spazz at ulink.net

Paul Lowe wrote:

Enrico Weigelt wrote:

Paul Lowe wrote:

Ryan Wahle wrote:

Hello,

I was wondering if it was possible to have like a pcx file, with multiple
images in it. So one pcx file would like contain all the frames for the
animation… all the frames would be the same size, but I was wondering if
it was possible to grap certain parts of an image and put them into a
SDL_Surface structure. Kind of like a SDL_loadBMP but it wouldn’t take the
source from a file, and instead take it from an array instead…

is this possible with the sdl?

d00d, write your own animation format. It’s easy as hell. Just write out the
surface->pixels to a file for each frame, and then load all of it into memory
with the same specs etc, it’s easy.

before creating a new format you could have a look at www.wotsit.org

i think there are enough formats out there …

bye,
ew.

It’s not like I mean try to create another standard, just hack it together for your
own conveinience.
hmmm… okay,

wouldn?t it be nice, to implement viewers for standard formats, so many
other people
could use it ? (possibly raises the popularity of SDL …)

ew.> Paul Lowe

spazz at ulink.net

lets go to another world … oberon

hmmm… okay,

wouldn?t it be nice, to implement viewers for standard formats, so many
other people
could use it ? (possibly raises the popularity of SDL …)

The IMGLib demo does this (although even in the newest version I can’t
seem to get JPG or PNG files to load)>

ew.

hmmm… okay,

wouldn?t it be nice, to implement viewers for standard formats, so many
other people
could use it ? (possibly raises the popularity of SDL …)

The IMGLib demo does this (although even in the newest version I can’t
seem to get JPG or PNG files to load)

You need to edit the Makefile and uncomment the lines that are defined
for JPEG and PNG files. If somebody knows autoconf, can you fix this
silliness? :slight_smile:

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec