I'm developing an app that needs to manage a custom "archive" of images (on a
single file). This file needs to be regenarated everytime the app quits. I
developed a custom format that suits my app, but I’m having problems dumping
surfaces to my file.
First of all, (sorry for the newbie question) how can I *really* determine
the actual size of the pixel array on the SDL_Surface? I thought it would
be (surface->w + surface->h)*surface->format->BytesPerPixel. I must be
missing something here.
I need to keep alpha values and colorkeys on the file, so when I load the
image, all is restored. Will a “raw dump” of the surface (keeping the
SDL_PixelFormat and etc) work? If so, how? What about endianess?
My other solution was (using SDL_RWops) to use SDL_SaveBMP_RW, directing the
output to my memory buffer. But, how can I determine it’s output beforehand?
Will it keep alphas and colorkeys? (I don’t think so).
Thanks a lot for any help.–
Eduardo B. Fonseca
ebf at aedsolucoes.com.br
15:42:59 up 6 days, 1:51, 1 user, load average: 0.17, 0.18, 0.17
First of all, (sorry for the newbie question) how can I really determine
the actual size of the pixel array on the SDL_Surface? I thought it would
be (surface->w + surface->h)*surface->format->BytesPerPixel. I must be
missing something here.
surface->pitch * surface->h * surface->format->BytesPerPixel
should do it, I think.
I need to keep alpha values and colorkeys on the file, so when I load the
image, all is restored. Will a “raw dump” of the surface (keeping the
SDL_PixelFormat and etc) work? If so, how? What about endianess?
I believe that endianness will surely be a problem with this method. But since
you have control over the pixelformat, you can compensate for this by changing
the masks.
surface->pitch is the number of pixels per row and surface->h is the number
of rows in the image, so all you need is:
surface->pitch*surface->h> ----- Original Message -----
From: btb@icculus.org (Bradley Bell)
To:
Sent: Monday, March 31, 2003 11:33 AM
Subject: Re: [SDL] Dumping a surface to a custom file
Quoting “Eduardo B. Fonseca” :
First of all, (sorry for the newbie question) how can I really
determine
the actual size of the pixel array on the SDL_Surface? I thought it
would
be (surface->w + surface->h)*surface->format->BytesPerPixel. I must be
missing something here.
surface->pitch * surface->h * surface->format->BytesPerPixel
should do it, I think.
I need to keep alpha values and colorkeys on the file, so when I load
the
image, all is restored. Will a “raw dump” of the surface (keeping the
SDL_PixelFormat and etc) work? If so, how? What about endianess?
I believe that endianness will surely be a problem with this method. But
since
you have control over the pixelformat, you can compensate for this by
changing
the masks.
surface->pitch is the number of BYTES per row and surface->h is the number
of rows in the image, so all you need is:
surface->pitch*surface->h> ----- Original Message -----
From: btb@icculus.org (Bradley Bell)
To:
Sent: Monday, March 31, 2003 11:33 AM
Subject: Re: [SDL] Dumping a surface to a custom file
Quoting “Eduardo B. Fonseca” :
First of all, (sorry for the newbie question) how can I really
determine
the actual size of the pixel array on the SDL_Surface? I thought it
would
be (surface->w + surface->h)*surface->format->BytesPerPixel. I must be
missing something here.
surface->pitch * surface->h * surface->format->BytesPerPixel
should do it, I think.
I need to keep alpha values and colorkeys on the file, so when I load
the
image, all is restored. Will a “raw dump” of the surface (keeping the
SDL_PixelFormat and etc) work? If so, how? What about endianess?
I believe that endianness will surely be a problem with this method. But
since
you have control over the pixelformat, you can compensate for this by
changing
the masks.
I’m developing an app that needs to manage a custom “archive” of images (on a
single file). This file needs to be regenarated everytime the app quits. I
developed a custom format that suits my app, but I’m having problems dumping
surfaces to my file.
First of all, (sorry for the newbie question) how can I really determine
the actual size of the pixel array on the SDL_Surface? I thought it would
be (surface->w + surface->h)*surface->format->BytesPerPixel. I must be
missing something here.
That would be (surface->w * surface->h). Notice the * rather than a +
the area of a rectangle is width*height, not width+height.
I need to keep alpha values and colorkeys on the file, so when I load the
image, all is restored. Will a “raw dump” of the surface (keeping the
SDL_PixelFormat and etc) work? If so, how? What about endianess?
Binary dumps rarely work across architectures. And raw dumps of pointers
never work. You can dump the values in binary, but when you read them
back you will have to reorder the bytes to adjust for endianess.
Also, think about what you are doing with respect to pixel depth. Are
you actually going to require everyone to have the same pixel depth on
every machine?On Mon, 2003-03-31 at 13:02, Eduardo B. Fonseca wrote:
My other solution was (using SDL_RWops) to use SDL_SaveBMP_RW, directing the
output to my memory buffer. But, how can I determine it’s output beforehand?
Will it keep alphas and colorkeys? (I don’t think so).
Thanks a lot for any help.
–
±----------------------------------+
Bob Pendleton: independent writer +
and programmer. +
email: Bob at Pendleton.com +
±----------------------------------+
surface->pitch is the number of pixels per row and surface->h is the number
of rows in the image, so all you need is:
surface->pitch*surface->h
Pitch is NOT always equal to width and can not be used as a substitute
for width. If the address if pixel image(x, y) is pa, then the address
of the pixel at image(x, y + 1) is pa + pitch. You really can’t make
assumptions about the relationship between width and pitch except that
pitch is >= (width * bytesPerPixel).
Bob PendletonOn Mon, 2003-03-31 at 13:52, Atrix Wolfe wrote:
----- Original Message -----
From: “Bradley Bell”
To:
Sent: Monday, March 31, 2003 11:33 AM
Subject: Re: [SDL] Dumping a surface to a custom file
Quoting “Eduardo B. Fonseca” :
First of all, (sorry for the newbie question) how can I really
determine
the actual size of the pixel array on the SDL_Surface? I thought it
would
be (surface->w + surface->h)*surface->format->BytesPerPixel. I must be
missing something here.
surface->pitch * surface->h * surface->format->BytesPerPixel
should do it, I think.
I need to keep alpha values and colorkeys on the file, so when I load
the
image, all is restored. Will a “raw dump” of the surface (keeping the
SDL_PixelFormat and etc) work? If so, how? What about endianess?
I believe that endianness will surely be a problem with this method. But
since
you have control over the pixelformat, you can compensate for this by
changing
the masks.
> I need to keep alpha values and colorkeys on the file, so when I load the
> image, all is restored. Will a "raw dump" of the surface (keeping the
> SDL_PixelFormat and etc) work? If so, how? What about endianess?
I use a custom image format in my current project that stores the number
of tiles, tile sizes and other information along with the image data.
My first attempt used a raw dump of surface pixel data, after some
thought I realised that this however is not a good idea, as you point
out endianess problems can crop up or you may lose image information
because of the format you used for the surface. So you will end up
having to code something that checks endianess.
IMHO it’s a much better idea to get the RGB values for each pixel, and
save each component, red, green and blue for each pixel to the file. It
doesn’t take much work to re-pack the RGB values using the mask values
of a surface. i.e you can create a blank surface large enough to hold
your data, and then load in your file, and put the RGB values into each
pixel using the mask that the surface uses.
watch out for endianness in the actual file if you use fread/fwrite or
similar you may have problems, I dunno about RWops in SDL, I assume this
can be told about endianness of data in the file
