Has anyone compiled a list of links relating to SDL?
?
Thanks
?
Scott
I’m trying to write a PCX file loader based loosely on the bitmap loader
code in SDL_bmp.c. It works on most images, but it occassionally flakes
out, and I want to see whether the bugs are in my PCX decoder or in the
way I’m using SDL’s surfaces.
Basically, I’m accessing surface pixels like this (for 256-color images):
surface->pixels[(current_y * surface->pitch) + current_x)] = foo;
This is based on the code in SDL_bmp.c and in the examples in the SDL
documentation, but I really don’t understand the meaning of
surface->pitch, and I’d also like to see if there’s a Right Way of
accessing surface pixels in general.
Thanks for your help,
Nathan
Nathan Thompson-Amato wrote:
I’m trying to write a PCX file loader based loosely on the bitmap loader
code in SDL_bmp.c. It works on most images, but it occassionally flakes
out, and I want to see whether the bugs are in my PCX decoder or in the
way I’m using SDL’s surfaces.
PCX is a lamo file format dOOd, it’s sooo ghetto, does ZSoft still exist? I
even believe someone has already written a PCX loader for SDL!!!
Basically, I’m accessing surface pixels like this (for 256-color images):
surface->pixels[(current_y * surface->pitch) + current_x)] = foo;
This is based on the code in SDL_bmp.c and in the examples in the SDL
documentation, but I really don’t understand the meaning of
surface->pitch, and I’d also like to see if there’s a Right Way of
accessing surface pixels in general.Thanks for your help,
Nathan
surface->pitch is the width of the surface in bytes.
Check out the tutorials on the SparkGL page, one of them goes in depth on
how / why this form of referencing pixels works.
http://SparkGL.netpedia.net (bottom of page, tutorials, the second one)
I remember once asking the SDL dude this question myself 
Paul Lowe
spazz at ulink.net
PCX is a lamo file format dOOd, it’s sooo ghetto, does ZSoft still exist?
It may not be the best format, but it’s easy to implement and is much
better than raw, uncompressed pixmaps. I really don’t think I have the
gray matter to write a PNG decoder.
I even believe someone has already written a PCX loader for SDL!!!
Ooo! Cool! Got a URL? (I poked around on several search engines, but
nothing came up.)
surface->pitch is the width of the surface in bytes.
That seems consistent with how I was using it… I guess the bugs are in
my PCX code. 
Thanks again,
NathanOn Wed, 12 May 1999, Paul Lowe wrote:
Hi,
Nathan Thompson-Amato wrote:
PCX is a lamo file format dOOd, it’s sooo ghetto, does ZSoft still exist?
It may not be the best format, but it’s easy to implement and is much
better than raw, uncompressed pixmaps. I really don’t think I have the
gray matter to write a PNG decoder.
I have got a png loader lying around here. It loads pngs by the use of
libpng (which also crosscompiles to Win32) and returns an SDL_Surface.
If you are interested, drop me a note.> On Wed, 12 May 1999, Paul Lowe wrote:
–
Karsten-O. Laux
klaux at student.uni-kl.de
http://www.rhrk.uni-kl.de/~klaux
UIN 21614933 (Bert)
Karsten-O. Laux said:
I have got a png loader lying around here. It loads pngs by the use of
libpng (which also crosscompiles to Win32) and returns an SDL_Surface.If you are interested, drop me a note.
Hi! Does it handle alpha channels, too?
-bill!
At 10:43 PM 5/11/99 -0700, you wrote:
I’m trying to write a PCX file loader based loosely on the bitmap loader
code in SDL_bmp.c. It works on most images, but it occassionally flakes
out, and I want to see whether the bugs are in my PCX decoder or in the
way I’m using SDL’s surfaces.
Thought I’d send a “loosely-based” pcx loader I built a while back, see if
this works for you. It’s written in C, not C++, you’ll need to modify to
make it run, but pcx.c is pretty close to what I suspect you’re looking for.
Pcxshow is fixed to DOSmode and a 320x200 screen.
I’m sure you could modify it accordingly.
if you run the exe, use full screen DOS mode and type pcxshow picture.pcx
zip contains:
pcxshow.exe DOS program
pcxshow.c main routine that calls loader
pcx.c loader function
picture.pcx a picture that fits within 320x200x256
pcx.txt details on pcx format right out of the horse’s mouth(ZSOFT)
Sending Sam a copy in case he thinks there’s something worth looking at.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: PCXSHOW.ZIP
Type: application/octet-stream
Size: 56963 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/19990513/5b881bfd/attachment.obj
Nathan Thompson-Amato wrote:
I’m trying to write a PCX file loader based loosely on the bitmap loader
code in SDL_bmp.c. It works on most images, but it occassionally flakes
out, and I want to see whether the bugs are in my PCX decoder or in the
way I’m using SDL’s surfaces.
Got this a year back, and maybe you’ll find it helpful.
It was answering someone else’s question on “best” format to use.*****************************************************
Hello,
I’ve got a graphics artist doing 8-bit images for
my game and he has shown me both .gif and .jpg.
The .gif was grainy but had tranparent backgrounds,
the .jpg was smoother, but did not have the transparency.
I’m kinda hung up about what image format to use in this
game. It will
JPEG is lossy, but (more importantly) the decoding is
nasty. GIF is very limited, and very patented (well, the
compression is…).
Check out the TARGA format. It has four channels
available (red, green, blue compose the image and
alpha can be your transparency mask). Because
the alpha channel is likely to be grayscale instead
of black and white, you can have slightly transparent
portions of your image (ie translucent).
TGA is a good format. The alpha support is the nicest
thing about it, IMO. Raw BMPs are OK, too.
If you want compressed images:
- JPEG is a pain to decode and the specs aren’t freely
available. On top of this, there’s no support for
alpha/transparency and it’s lossy compression. - PCX, RLE BMPs and RLE TGAs are fairly easy to
code for, but the compression is pretty poor (2:1). - GIF is more difficult and compresses better, but there
are problems with the LZW patent, and the format
limits you to 8-bit max. GIF does support animation,
though. - PNG is (IMO) a good choice. It’s free, lossless,
compresses better than GIF, supports 24+bit images
and although the decompression code is more difficult
to write than GIF, it’s the same as used in ZIP files. Yay!
Nathan Thompson-Amato wrote:
I’m trying to write a PCX file loader based loosely on the bitmap loader
code in SDL_bmp.c.
[snip, snip]
Check out the TARGA format. It has four channels
available (red, green, blue compose the image and
alpha can be your transparency mask). Because
the alpha channel is likely to be grayscale instead
of black and white, you can have slightly transparent
portions of your image (ie translucent).TGA is a good format. The alpha support is the nicest
thing about it, IMO. Raw BMPs are OK, too.
Both are uncompressed, though, aren’t they? (I noticed some
blow-up-on-compressed-BMP code in the SDL, so I guess somebody, somewhere
uses that format, but I’ve never heard of it before.)
If you want compressed images:
- JPEG is a pain to decode and the specs aren’t freely
available. On top of this, there’s no support for
alpha/transparency and it’s lossy compression.
Most of my images will be 256 color (because I’m used to doing 256 color
graphics for DOS progs), so JPEGs would probably be overkill. And if
they’re hard to decode, well, that’s the clincher.
- PCX, RLE BMPs and RLE TGAs are fairly easy to
code for, but the compression is pretty poor (2:1).
It’s better than nothing, I say.
- GIF is more difficult and compresses better, but there
are problems with the LZW patent
[snip]
Patents suck in general, and patented software really doesn’t belong in
the GPLed program I’m working on.
- PNG is (IMO) a good choice. It’s free, lossless,
compresses better than GIF, supports 24+bit images
and although the decompression code is more difficult
to write than GIF, it’s the same as used in ZIP files.
I’m with you – if I don’t, for example, pack all my images into a
compressed datafile (or something), I’ll probably use PNGs
eventually. But for right now, I’d rather get down to the program
itself and not spend my entire life on support routines.
(“Why not use bitmaps in the interim, then?” you ask. Well, I guess I
just don’t like the Microsoft-stigma that comes along with using BMP files
in a program. And, of course, if I never find the time to change to PNGs
or datafiles, at least there’ll be a little bit of compression.)
Thanks for your suggestions,
NathanOn Thu, 13 May 1999, Silva wrote:
Is there a PNG loader for SDL?
Nathan Thompson-Amato wrote:> On Thu, 13 May 1999, Silva wrote:
Nathan Thompson-Amato wrote:
I’m trying to write a PCX file loader based loosely on the bitmap loader
code in SDL_bmp.c.[snip, snip]
Check out the TARGA format. It has four channels
available (red, green, blue compose the image and
alpha can be your transparency mask). Because
the alpha channel is likely to be grayscale instead
of black and white, you can have slightly transparent
portions of your image (ie translucent).TGA is a good format. The alpha support is the nicest
thing about it, IMO. Raw BMPs are OK, too.Both are uncompressed, though, aren’t they? (I noticed some
blow-up-on-compressed-BMP code in the SDL, so I guess somebody, somewhere
uses that format, but I’ve never heard of it before.)If you want compressed images:
- JPEG is a pain to decode and the specs aren’t freely
available. On top of this, there’s no support for
alpha/transparency and it’s lossy compression.Most of my images will be 256 color (because I’m used to doing 256 color
graphics for DOS progs), so JPEGs would probably be overkill. And if
they’re hard to decode, well, that’s the clincher.
- PCX, RLE BMPs and RLE TGAs are fairly easy to
code for, but the compression is pretty poor (2:1).It’s better than nothing, I say.
- GIF is more difficult and compresses better, but there
are problems with the LZW patent[snip]
Patents suck in general, and patented software really doesn’t belong in
the GPLed program I’m working on.
- PNG is (IMO) a good choice. It’s free, lossless,
compresses better than GIF, supports 24+bit images
and although the decompression code is more difficult
to write than GIF, it’s the same as used in ZIP files.I’m with you – if I don’t, for example, pack all my images into a
compressed datafile (or something), I’ll probably use PNGs
eventually. But for right now, I’d rather get down to the program
itself and not spend my entire life on support routines.(“Why not use bitmaps in the interim, then?” you ask. Well, I guess I
just don’t like the Microsoft-stigma that comes along with using BMP files
in a program. And, of course, if I never find the time to change to PNGs
or datafiles, at least there’ll be a little bit of compression.)Thanks for your suggestions,
Nathan
Hi,
Nathan Thompson-Amato wrote:
PCX is a lamo file format dOOd, it’s sooo ghetto, does ZSoft still exist?
It may not be the best format, but it’s easy to implement and is much
better than raw, uncompressed pixmaps. I really don’t think I have the
gray matter to write a PNG decoder.I have got a png loader lying around here. It loads pngs by the use of
libpng (which also crosscompiles to Win32) and returns an SDL_Surface.
If you are interested, drop me a note.
Karsten, this has reached the level of FAQ.
Why don’t you send me the PNG loader again, I’ll dig up the GIF and PCX
loaders, and write up a sample image loader library to add to the samples.
Anyone else want to do it too?
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software> > On Wed, 12 May 1999, Paul Lowe wrote:
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
[snip, snip]
[snip]
Use compressed PPM images. Who needs an alpha channel in an image anyways?
Especially since you’re using 256 colors.
[snip, snippity snip]
(warning, seriously opionionated statement ahead…
256 color palettized modes may be fast, but I don’t think they’re that cool
compared to like 16bpp…
Paul Lowe
spazz at ulink.net
I have got a png loader lying around here. It loads pngs by the use of
libpng (which also crosscompiles to Win32) and returns an SDL_Surface.
Thanks, but I feel guilty enough about having my game depend on the SDL –
I don’t want to add other dependencies if I don’t have to. (Yes, I’ve had
lots of problems with apps requiring 73 different libs that I didn’t have
installed.) If I have a loader some something, I want it small and
embedded.
NathanOn Thu, 13 May 1999, Karsten Laux wrote:
Has anyone compiled a list of links relating to SDL?
Some major links relating to SDL can be found at:
http://www.devolution.com/~slouken/SDL/intro/whatisit.html
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
LateKnights Web Page URL has changed, it now:
http://www.angelfire.com/ct/lateknights/index2.html
Stuart