Function to load a BMP from a porton of a file

SDL Development
1

Hi all
I need a function that load a bmp from a portion of a file, i am programing a game and i have all the images files and i am going to put them into a file… one file… and i need a function that load the image givin to it… only where the images begin and qhere the image end… like LoadBMPfromFile(const char *file , int begin, int end)
Thank
Fede!

2

Hmm… I just discovered that the SDL_RWops structure doesn’t seem to be
discussed at all in the official SDL library documentation… :frowning:

Basically, you create a SDL_RWops proxy to read the partial file (as a
complete file) on SDLs behalf…

I did a quick google search, and came up with a link to this SDL_RWops
tutorial: http://www.kekkai.org/roger/sdl/rwops/rwops.html

It basically shows how to use a memory buffer as a file (which is
implemented in the SDL library itself)… but you could also write your
own SDL_RWops functions to read a partial file in place…

Enjoy,

-LorenOn Wed, 2002-10-16 at 12:57, Federico Berardi wrote:

Hi all
I need a function that load a bmp from a portion of a file, i
am programing a game and i have all the images files and i am
going to put them into a file… one file… and i need a
function that load the image givin to it… only where the images
begin and qhere the image end… like LoadBMPfromFile(const char
*file , int begin, int end)
Thank
Fede!

3

I need a function that load a bmp from a portion of a file,
i am programing a game and i have all the images files and
i am going to put them into a file… one file…

I do something similar in my game, except that I still use more than
one file. Basically I put related images together, such as all the
frames from a certain sprite. Then my game simply loads that whole
bitmap into one SDL_Surface, and passes the rectangle corresponding
to the current frame to SDL_BlitSurface. The advantage of this is
that I don’t have to load (and manage) a gazillion different
bitmaps. Also, related graphics share the same surface, which
guarantees that they will either all be in videomem (HWSURFACE) or
all system memory (SWSURFACE).

I suggest you do something similar. If you really wish to use one
big bitmap, you can SDL_LoadBMP it into a surface, allocate several
smaller surfaces, SDL_BlitSurface the various portions to them, and
finally free the big bitmap.–
Matthijs Hollemans
All Your Software
www.allyoursoftware.com

4

I need a function that load a bmp from a portion of a file,
i am programing a game and i have all the images files and
i am going to put them into a file… one file…

I do something similar in my game, except that I still use more than
one file. Basically I put related images together, such as all the
frames from a certain sprite. Then my game simply loads that whole
bitmap into one SDL_Surface, and passes the rectangle corresponding
to the current frame to SDL_BlitSurface. The advantage of this is
that I don’t have to load (and manage) a gazillion different
bitmaps. Also, related graphics share the same surface, which
guarantees that they will either all be in videomem (HWSURFACE) or
all system memory (SWSURFACE).

Wouldn’t it make for faster blitting if the image data were stored in a
contiguous memory region?

latimeriusOn Thu, Oct 17, 2002 at 09:18:50AM +0100, Matthijs Hollemans wrote:
5

[…] Then my game simply loads that whole bitmap
into one SDL_Surface, and passes the rectangle
corresponding to the current frame to SDL_BlitSurface

Wouldn’t it make for faster blitting if the image data were
stored in a contiguous memory region?

Hmm, I don’t know how SDL or the typical video card implements
blits, but I can remember that it did not matter to the Amiga
blitter. Since blitter stands for “block image transferrer”, I
assume that current hardware blitters know how to blit rectangles,
too. In other words, you tell the blitter to start at a certain
offset in the surface (the x, y position), to blit a certain number
of pixels (the width), to skip ahead a certain number of pixels
(pitch minus width), and to repeat this a certain number of times
(the height). Since all of this happens in hardware, it wouldn’t be
slower than copying a contiguous memory region. Of course, I am only
guessing here, so you may want to take this with a grain of salt ;-)–
Matthijs Hollemans
All Your Software
www.allyoursoftware.com

6

[…] Then my game simply loads that whole bitmap
into one SDL_Surface, and passes the rectangle
corresponding to the current frame to SDL_BlitSurface

Wouldn’t it make for faster blitting if the image data were
stored in a contiguous memory region?

Hmm, I don’t know how SDL or the typical video card implements
blits, but I can remember that it did not matter to the Amiga
blitter. Since blitter stands for “block image transferrer”, I
assume that current hardware blitters know how to blit rectangles,
too. In other words, you tell the blitter to start at a certain
offset in the surface (the x, y position), to blit a certain number
of pixels (the width), to skip ahead a certain number of pixels
(pitch minus width), and to repeat this a certain number of times
(the height). Since all of this happens in hardware, it wouldn’t be
slower than copying a contiguous memory region. Of course, I am only
guessing here, so you may want to take this with a grain of salt :wink:

Copying a contiguous block of memory should always be faster than
copying several smaller blocks, because a) you enjoy all benefits of
L1/L2 processor caches, b) everything is done in system bus bursts, and
c) the blitter proper is conceptually a single x86 instruction (one of
the string family prefixed with rep). This is about as fast as you can
get when copying memory to memory.

Now the question is, does this matter in SDL at all? Is it worth the
additional work to have one image per surface to make it easier for the
SDL low-level blitters?

latimeriusOn Thu, Oct 17, 2002 at 01:40:51PM +0100, Matthijs Hollemans wrote:
7

Copying a contiguous block of memory should always be faster than
copying several smaller blocks, because a) you enjoy all benefits
of
L1/L2 processor caches, b) everything is done in system bus
bursts, and
c) the blitter proper is conceptually a single x86 instruction
(one of
the string family prefixed with rep). This is about as fast as
you can
get when copying memory to memory.

I won’t disagree with any of that. But these conditions only hold if
both surfaces live in system memory, i.e. they are SWSURFACES. And
in that case, the software blitter still has to copy the surface
line-by-line if the surface’s pitch is greater than its width. The
situation is different when it comes to HWSURFACES; the hardware
blitter lives on the videocard and it simply moves videomem around.
At least, that is how I understood this things work, and once again,
I could be mistaken.–
Matthijs Hollemans
All Your Software
www.allyoursoftware.com

8

I won’t disagree with any of that. But these conditions only hold if
both surfaces live in system memory, i.e. they are SWSURFACES. And
in that case, the software blitter still has to copy the surface
line-by-line if the surface’s pitch is greater than its width.

That’s right, I see your point (even though I would say that
performance-aware blitter would arange the data so that pitch==width).

The situation is different when it comes to HWSURFACES; the hardware
blitter lives on the videocard and it simply moves videomem around.
At least, that is how I understood this things work, and once again, I
could be mistaken.

I’m not very knowledgeable about this, either, and that’s why my
question is as stated before: does it still matter? Is there some
simple rule as “if you use SWSURFACEs, keeping image data contiguous
does improve blitting speed, if you use HWSURFACEs, don’t care”?

latimeriusOn Thu, Oct 17, 2002 at 03:17:55PM +0100, Matthijs Hollemans wrote:
9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Thursday 17 October 2002 16:11, Latimerius wrote:

On Thu, Oct 17, 2002 at 03:17:55PM +0100, Matthijs Hollemans wrote:

I won’t disagree with any of that. But these conditions only hold if
both surfaces live in system memory, i.e. they are SWSURFACES. And
in that case, the software blitter still has to copy the surface
line-by-line if the surface’s pitch is greater than its width.

That’s right, I see your point (even though I would say that
performance-aware blitter would arange the data so that pitch==width).

In fact, you have to copy line-by-line in virtually all situations (except
splash screens) because it’s not only the source surface that matters - you
need to watch out for the destination surface as well.
So basically, you can only blit in one big memcpy when src->width ==
src->pitch == dst->width == dst->pitch

cu,
Nicolai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9rur8sxPozBga0lwRAvYAAJ4sEj5ScT6kE2zrPccuQSH6tZVzwQCfSK8z
OIBRi1DNKvi+Pl75ws/sMh4=
=yd9C
-----END PGP SIGNATURE-----

10

thanks… i ll have to learn a little more about this…
if somone know for another tutorial, let me know> Hmm… I just discovered that the SDL_RWops structure doesn’t seem to be

discussed at all in the official SDL library documentation… :frowning:

Basically, you create a SDL_RWops proxy to read the partial file (as a
complete file) on SDLs behalf…

I did a quick google search, and came up with a link to this SDL_RWops
tutorial: http://www.kekkai.org/roger/sdl/rwops/rwops.html

It basically shows how to use a memory buffer as a file (which is
implemented in the SDL library itself)… but you could also write your
own SDL_RWops functions to read a partial file in place…

Enjoy,

-Loren

On Wed, 2002-10-16 at 12:57, Federico Berardi wrote:

Hi all
I need a function that load a bmp from a portion of a file, i
am programing a game and i have all the images files and i am
going to put them into a file… one file… and i need a
function that load the image givin to it… only where the images
begin and qhere the image end… like LoadBMPfromFile(const char
*file , int begin, int end)
Thank
Fede!

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

11

Its a good idea, but anyone can see the images… ant in the midle of
the file i put some administration information…
Thanks for the idea…
Fede!>

I need a function that load a bmp from a portion of a file,
i am programing a game and i have all the images files and
i am going to put them into a file… one file…

I do something similar in my game, except that I still use more than
one file. Basically I put related images together, such as all the
frames from a certain sprite. Then my game simply loads that whole
bitmap into one SDL_Surface, and passes the rectangle corresponding
to the current frame to SDL_BlitSurface. The advantage of this is
that I don’t have to load (and manage) a gazillion different
bitmaps. Also, related graphics share the same surface, which
guarantees that they will either all be in videomem (HWSURFACE) or
all system memory (SWSURFACE).

I suggest you do something similar. If you really wish to use one
big bitmap, you can SDL_LoadBMP it into a surface, allocate several
smaller surfaces, SDL_BlitSurface the various portions to them, and
finally free the big bitmap.

Matthijs Hollemans
All Your Software
www.allyoursoftware.com

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

12

If you want to distribute a single file that contains multiple files in
it, why not use physicsfs?

Check it out at:
http://www.icculus.org/physfs/

It uses many different file types (including .ZIP files like Q3 does),
written using SDL, and made by our very own Ryan C. Gordon.

I haven’t said this in a while, but, Sam and Ryan, thanks for everything
you guys are doing for cross-platform programmers. You both rock.

Joe

13

or if you are proficient in fwrite and fread you can make up your own file
type. This is what i am doing for my game.

The first unsigned int in the file says how many entries there are in the
index.

then, for each index entry it has a filename (20 chars padded with spaces),
and an offset into the file where the data starts.

After that its just chunk after chunk of data.

If you wanted to be all some l33t hax0r you could make it so people couldnt
take your art and sounds out of the file as easily by xor’ing each byte in
the data by a constant number when writing and xor it again by the same
number when reading to get the origional data back. Lets say the constant
your xor’ing against is 5 and you have 3 bytes of data: 4,3,5

when writing…xor each byte against 5 to get:
1,6,0

and then put that in the file

when reading, read in the data (1,6,0) and xor against 5 again to get:
4,3,5

wow, works like magic (:

I dont know much about physicsfs but if you are trying to protect your art
and data (esp if you store game var’s in this bin file) you might wanna use
something more proprietary like the above to make it harder to hack.> ----- Original Message -----

From: rotund@fatnsoft.com (Joe Tennies)
To:
Sent: Friday, October 18, 2002 12:33 PM
Subject: Re: [SDL] Function to load a BMP from a porton of a file

If you want to distribute a single file that contains multiple files in
it, why not use physicsfs?

Check it out at:
http://www.icculus.org/physfs/

It uses many different file types (including .ZIP files like Q3 does),
written using SDL, and made by our very own Ryan C. Gordon.

I haven’t said this in a while, but, Sam and Ryan, thanks for everything
you guys are doing for cross-platform programmers. You both rock.

Joe

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

14

thanks that what i need…
i am trying to undestand… but its the idea that i had…

or if you are proficient in fwrite and fread you can make up your own file
type. This is what i am doing for my game.

The first unsigned int in the file says how many entries there are in the
index.

then, for each index entry it has a filename (20 chars padded with
spaces),
and an offset into the file where the data starts.

After that its just chunk after chunk of data.

If you wanted to be all some l33t hax0r you could make it so people
couldnt
take your art and sounds out of the file as easily by xor’ing each byte in
the data by a constant number when writing and xor it again by the same
number when reading to get the origional data back. Lets say the constant
your xor’ing against is 5 and you have 3 bytes of data: 4,3,5

when writing…xor each byte against 5 to get:
1,6,0

and then put that in the file

when reading, read in the data (1,6,0) and xor against 5 again to get:
4,3,5

wow, works like magic (:

I dont know much about physicsfs but if you are trying to protect your art
and data (esp if you store game var’s in this bin file) you might wanna
use> something more proprietary like the above to make it harder to hack.

----- Original Message -----
From: “Joe Tennies”
To:
Sent: Friday, October 18, 2002 12:33 PM
Subject: Re: [SDL] Function to load a BMP from a porton of a file

If you want to distribute a single file that contains multiple files in
it, why not use physicsfs?

Check it out at:
http://www.icculus.org/physfs/

It uses many different file types (including .ZIP files like Q3 does),
written using SDL, and made by our very own Ryan C. Gordon.

I haven’t said this in a while, but, Sam and Ryan, thanks for everything
you guys are doing for cross-platform programmers. You both rock.

Joe

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

15

if you want detailed explanations or help in any way let me know (:

email me at Atrix2 at cox.net

-Atrix> ----- Original Message -----

From: berardi@ssdfe.com.ar (Federico Berardi)
To:
Sent: Saturday, October 19, 2002 1:37 AM
Subject: Re: [SDL] Function to load a BMP from a porton of a file

thanks that what i need…
i am trying to undestand… but its the idea that i had…

or if you are proficient in fwrite and fread you can make up your own
file

type. This is what i am doing for my game.

The first unsigned int in the file says how many entries there are in
the

index.

then, for each index entry it has a filename (20 chars padded with
spaces),
and an offset into the file where the data starts.

After that its just chunk after chunk of data.

If you wanted to be all some l33t hax0r you could make it so people
couldnt
take your art and sounds out of the file as easily by xor’ing each byte
in

the data by a constant number when writing and xor it again by the same
number when reading to get the origional data back. Lets say the
constant

your xor’ing against is 5 and you have 3 bytes of data: 4,3,5

when writing…xor each byte against 5 to get:
1,6,0

and then put that in the file

when reading, read in the data (1,6,0) and xor against 5 again to get:
4,3,5

wow, works like magic (:

I dont know much about physicsfs but if you are trying to protect your
art

and data (esp if you store game var’s in this bin file) you might wanna
use
something more proprietary like the above to make it harder to hack.

----- Original Message -----
From: “Joe Tennies”
To:
Sent: Friday, October 18, 2002 12:33 PM
Subject: Re: [SDL] Function to load a BMP from a porton of a file

If you want to distribute a single file that contains multiple files
in

it, why not use physicsfs?

Check it out at:
http://www.icculus.org/physfs/

It uses many different file types (including .ZIP files like Q3 does),
written using SDL, and made by our very own Ryan C. Gordon.

I haven’t said this in a while, but, Sam and Ryan, thanks for
everything

you guys are doing for cross-platform programmers. You both rock.

Joe

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl