SDL_image into SDL?

SDL Development
#1

A few questions:

  1. Is there any reason why the SDL_image library isn’t incorporated into
    the main SDL library? I find it really useful, but it’s one more lib to
    keep track of…

  2. I’m going to start work on a tile-based game, and I’m just figuring out
    the techniques I’m going to use now. One of the things I need to do is load
    an image that contains all the tiles, then do some automated manipulation
    of the RGB values. After that I need to convert it to the screen format
    (I presume). What would be the best way of achieving this?

  3. Also, having done that, would I be better off splitting each tile into a
    separate surface, or would it be better to do rectangle blits when the tile
    is required?

  4. Is the GUI lib being actively developed, or is it languishing as an
    example lib?

  5. (Phew, almost done :slight_smile: For the GUI lib, what format do the font images
    take? And are there any alternative ones floating about?

Cheers
Dave–
Dave Swegen | Debian 2.2 on Linux i386 2.2
<@Dave_Swegen> | GPG key available on request
| Linux: The Choice of a GNU Generation

#2
  1. I’m going to start work on a tile-based game, and I’m just figuring out
    the techniques I’m going to use now. One of the things I need to do is load
    an image that contains all the tiles, then do some automated manipulation
    of the RGB values. After that I need to convert it to the screen format
    (I presume). What would be the best way of achieving this?

Use SDL_DisplayFormat to convert to the screen format

  1. Also, having done that, would I be better off splitting each tile into a
    separate surface, or would it be better to do rectangle blits when the tile
    is required?

I doubt either will be significantly faster. Unless your tiles have
transparency and you want to use RLE blitting; then separate surfaces will
be much faster

#3

Dave Swegen wrote:

A few questions:

  1. Is there any reason why the SDL_image library isn’t incorporated into
    the main SDL library? I find it really useful, but it’s one more lib to
    keep track of…

I don’t know what the official reasons are, but I suspect it’s because
SDL_image relies on several platform-specific libraries. SDL is supposed
to be a thin layer, not an all-encompassing monster.

  1. I’m going to start work on a tile-based game, and I’m just figuring out
    the techniques I’m going to use now. One of the things I need to do is load
    an image that contains all the tiles, then do some automated manipulation
    of the RGB values. After that I need to convert it to the screen format
    (I presume). What would be the best way of achieving this?

SDL_LockSurface(tileset);
doSomethingWith(tileset->pixels);
SDL_UnlockSurface(tileset);
temp = SDL_DisplayFormat(tileset);
SDL_FreeSurface(tileset);
tileset = temp;

SDL_DisplayFormat copies a surface into a new surface that is optimized
for fast blitting onto the current display.

  1. Also, having done that, would I be better off splitting each tile into a
    separate surface, or would it be better to do rectangle blits when the tile
    is required?

Opinions will vary. Which would be more convenient?

-John

#4

Dave Swegen wrote:

  1. I’m going to start work on a tile-based game, and I’m just figuring out
    the techniques I’m going to use now. One of the things I need to do is load
    an image that contains all the tiles, then do some automated manipulation
    of the RGB values. After that I need to convert it to the screen format
    (I presume). What would be the best way of achieving this?

Depending on the type of tile based game you are working on, you
might find my GridSlammer SDK useful. It provides an object
oriented API for the rapid development of isolinear (psuedo 3D
tile based) games. It currently supports DirectX, GGI, and very
soon SDL as rendering targets. I will release a new beta version
in a few days with SDL support and a much revamped rendering
algorithm. GridSlammer caches tile images in an offscreen visual,
much like you describe. Why not give it a look and see if it is
useful for your project. You can check out GridSlammer at:

http://www.gridslammer.org

That is assuming the %^&@#(*&#$ web hosting service is working.
If not, check out this (slightly out of date) mirror site:

http://www.glaci.com/gridslammer

GridSlammer is currently in alpha, but is rapidly approaching
a useful status. The reference game DroidWars is actually
playable (though the maze is somewhat sparsely populated).

Cheers,

Thad

#5
  1. I’m going to start work on a tile-based game, and I’m just figuring out
    the techniques I’m going to use now. One of the things I need to do is load
    an image that contains all the tiles, then do some automated manipulation
    of the RGB values. After that I need to convert it to the screen format
    (I presume). What would be the best way of achieving this?

You’ve already gotten fine answers to screen format conversion, but you
may also want to know how to grab sections of the image for tiles (other
than simply just blitting from the main image as source with an indexed
array of rect’s corresponding to each tile).

There’s a fine example of this at

http://www.libsdl.org/projects/scrap/index.html

  1. Also, having done that, would I be better off splitting each tile into a
    separate surface, or would it be better to do rectangle blits when the tile
    is required?

I’m sure this would depend on a great many factors, and you’d have to come
up with the solution best fitting your needs. (I.e., will /all/ the tiles
be used making keeping the one big tile around a better option, or can we
have a smaller memory footprint with only a few tiles and surfaces).

Plus, you’ll also want to look at picture size, color depth (if that’s an
issue) and other junk.

Also, pertaining to the first question (SDL_image into SDL), I think it is
the thin-layer idea put forth previously that is the reason it’s not in
SDL. Truthfully, SDL_image in SDL would cause more bloat… say
you’re only using JPEG images files, then you wouldn’t need the other
image filetype loaders.

You could always elliminate the need for SDL_image altogther by
cut/pasting those specific functions you need into an included file of
your own, thus making installing of your software easier for the end-user
as they don’t need SDL_image on their system. (Which is what I intend to
do in the future :wink:

I’m sure the same thing goes for SDL_mixer, SDL_net, and the rest of the
example libs.On Tue, 27 Jun 2000, Dave Swegen wrote:

–
Sam Hart http://www.physics.arizona.edu/~hart/
Web Page Highlights: Video Game History, Black Hole Simulation, & more.
OTHER WEB SITES MAINTAINED BY SAM HART
http://www.geekcomix.com/ - Geekcomix, the Daily Geek Comic Strip Site
http://www.physics.arizona.edu/~hart/gw/ - Ghostworks (Alt./Linux Computing)

#6

Also, pertaining to the first question (SDL_image into SDL), I think it is
the thin-layer idea put forth previously that is the reason it’s not in
SDL. Truthfully, SDL_image in SDL would cause more bloat… say
you’re only using JPEG images files, then you wouldn’t need the other
image filetype loaders.

While there are good arguments, this isn’t one of them. You can configure
SDL_image with just the formats you need; look at the configure script.
And for a shared library, only the pages actually used will be paged into
memory.

You could always elliminate the need for SDL_image altogther by
cut/pasting those specific functions you need into an included file of
your own, thus making installing of your software easier for the end-user
as they don’t need SDL_image on their system. (Which is what I intend to
do in the future :wink:

This is rarely a good idea. Recently a batch of errors were fixed in
SDL_image, and a couple of formats added. I also tried a game where
the author had adopted your suggestion, and of course the files he
extracted were outdated.

You don’t have to link SDL_image as a shared library. Often these small
libraries are better linked statically anyway.

#7

You could always elliminate the need for SDL_image altogther by
cut/pasting those specific functions you need into an included file of
your own, thus making installing of your software easier for the end-user
as they don’t need SDL_image on their system. (Which is what I intend to
do in the future :wink:

For maintanence reasons, this is probably a bad idea. Also keep in mind,
if you are not releasing a GPL product it gets even more difficult to do
this.–
Brian

#8

Well, thank you one and all for your replies. They will probably turn out
to be really useful, but as usual there is nothing that beats actually
trying things out (how I wish it were otherwise) :slight_smile:

Regarding the SDL_image issue, I would have thought it better to have PNG
as the one fully supoorted format in the lib. But what do I know? :slight_smile:

Cheers
Dave–
Dave Swegen | Debian 2.2 on Linux i386 2.2
<@Dave_Swegen> | GPG key available on request
| Linux: The Choice of a GNU Generation

#9

Well, thank you one and all for your replies. They will probably turn out
to be really useful, but as usual there is nothing that beats actually
trying things out (how I wish it were otherwise) :slight_smile:

Regarding the SDL_image issue, I would have thought it better to have PNG
as the one fully supoorted format in the lib. But what do I know? :slight_smile:

BMP is nice in that it requires no other libraries, is free of patent issues,
and is supported by every single image editor. :slight_smile: For anything more, check
out the SDL_image library. :slight_smile:

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software