SDL Digest, Vol 12, Issue 21

Send SDL mailing list submissions to
sdl at libsdl.org

To subscribe or unsubscribe via the World Wide Web, visit
http://www.libsdl.org/mailman/listinfo/sdl
or, via email, send a message with subject or body ‘help’ to
sdl-request at libsdl.org

You can reach the person managing the list at
sdl-owner at libsdl.org

When replying, please edit your Subject line so it is more specific
than “Re: Contents of SDL digest…”

Today’s Topics:

  1. Re: strange 2D problem (Florian Liefers)
  2. Re: working with n-bit surfaces (Bill Kendrick)
  3. Re: error in SDL_image (Bill Kendrick)
  4. Possible bug in SDL_surface.c discovered, line 87, improper
    malloc (Paul Lowe)
  5. Re: Possible bug in SDL_surface.c discovered, line 87,
    improper malloc (Ryan C. Gordon)
  6. Re: Colorkey (jorgefm at cirsa.com)
  7. Re: Possible bug in SDL_surface.c discovered, line 87,
    improper malloc (David Olofson)
  8. Re: SDL ignoring AUDIODEV and SDL_DSP_DEV? (Tyler Montbriand)
  9. SDL_TTF with asian characters (Gabriel)
  10. Re: SDL_TTF with asian characters (Bill Kendrick)

Message: 1
SDL-announce)"
Message-ID: <4266AEB7.4030005 at web.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed

Johannes Schmidt schrieb:

Using SDL 1.2.8, Mesa 6.2.1, XFree86 4.3,
it looks as expected:
http://libufo.sf.net/gl2d_lines.png

Perhaps you should update your graphics card driver?

I updated my graphics card driver, updated to SDL 1.2.8 and used other
opengl-libs to link, but
the result is exactly the same.
Maybe someone can compile this little sample to a w32 executable and
give me a link to download
or send it direct to replman at web.de that i can see if my libraries are
responsible for
this problem. That would be very nice.
I googled for an opengl-application wich only shows amongst others a
lined rectancle, but with no success :-(.

Tnx,
Florian


Message: 2
using the SDL library. (includes SDL-announce)"
Message-ID: <20050420203824.GA4362 at sonic.net>
Content-Type: text/plain; charset=us-ascii

Hallo, SDL.

   How can i create 1 (or n) bit surface. Draw on it (i can draw
   on 32 bit surface, but what happened if i'll draw pixel in
   32-bit format in 1 bit surface? How can i avoid problems with
   this (I mean, if there is some function to convert pixels?)).

The putpixel code on this page might be of use:

http://www.infres.enst.fr/docs/sdl/guidevideo.html

It examines the surface’s BytesPerPixel to determine whether the surface
is 8bpp, 16bpp 24bpp or 32bpp. Use SDL_MapRGB() to create the Uint32 pixel
that function wants, for example.

Good luck!

PS - I have no idea how up-to-date the rest of that guide is, so YMMV.
But the putpixel example looks fine.


-bill!
bill at newbreedsoftware.com Tonight’s Forecast: Dark. Continued darkness
http://newbreedsoftware.com/ until widely scattered light in the morning.


Message: 3
library. (includes SDL-announce)"
Message-ID: <20050420204103.GB4362 at sonic.net>
Content-Type: text/plain; charset=us-ascii

hi

I am rushiraj.I want to use SDL_image-1.2.4 lib but when I add this to my project I

What compiler or development environment are you using? (You said project,
which is terminology often used in IDEs like Microsoft Visual Studio)

got error SDL.h not found when I add that I got new error SDL_endian.h not found and all .h files that included in SDL.h file plese give me prorer way to use it with example.

Did you tell your compiler where to find SDL’s header files?
In my MSVC++ project, I must edit the Properties of the project
and add them to the “Additional Include Directories”, under C/C++ -> General.

In Makefiles under Linux, I simply use “sdl-config --cflags” to pull in
the appropriate “-I” option (and others).


-bill!
bill at newbreedsoftware.com Tonight’s Forecast: Dark. Continued darkness
http://newbreedsoftware.com/ until widely scattered light in the morning.


Message: 4
improper malloc
Message-ID: <200504202344.57963.pauls_lists at tetravista.net>
Content-Type: text/plain; charset=“us-ascii”

Could someone please correct me if I’m wrong, but I believe
I have found a bug in the SDL 1.2.8 source code:

File: “SDL-1.2.8/src/video/SDL_surface.c”
Line: 87

The pointer surface is never initialized, but is
dereferenced as a “size_t” argument of malloc.

    /* Allocate the surface */

/* BUG BELOW THIS LINE??? */
surface = (SDL_Surface *)malloc(sizeof(surface));
/
BUG ABOVE THIS LINE??? */

    if ( surface == NULL ) {
            SDL_OutOfMemory();
            return(NULL);
    }

Thanks,

Paul Lowe
paul at tetravista.net


Message: 5
improper malloc
SDL-announce)"
Message-ID: <42675C7F.5090307 at clutteredmind.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

The pointer surface is never initialized, but is
dereferenced as a “size_t” argument of malloc.

    /* Allocate the surface */

/* BUG BELOW THIS LINE??? */
surface = (SDL_Surface *)malloc(sizeof(surface));
/
BUG ABOVE THIS LINE??? */

Not a dereference in sizeof()…this is naughty C syntax stuff.

For a clearer example:

#include <stdio.h>

int main(void)
{
int *x = NULL;
printf("%d\n%d\n", sizeof (*x), sizeof (5+1));
return(0);
}

–ryan.


Message: 6
Message-ID:
<OF5189A22B.A9FCE957-ONC1256FEA.002CA1B6-C1256FEA.002CA1C1 at cirsa.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi all!

My question is about colorkeying. I’ve been reading the glSDL
code and the colorkey is implemented with alpha blending when
it’s used in openGL. Is there other way to do it?

No. Well, not with OpenGL 1.2 (which is what glSDL targets) at least.

I’m working on a 16 bpp XServer and I’m trying to save some
bits from the alpha channel to dedicate it to the colour channels.

What do you expect from that ? That the hardware itself will support
more bits ? That’s not the case.
Which means, that, as soon as the hardware gets the data, it has to be
in the one format it supports (usually that’s 565 for 16bpp).

Plus, you say “some bits” but there is only one alpha bit to “save”.

When I create a texture from a graphic resource with colorkey
i have to use the internal format GL_RGB5_A1. For a normal RGB
graphic resource I use the GL_RGB5 format. When I show the first
the blue colour gradation is very visible! but the same without
colorkey I get a perfect uniform gradation.

Do you know a good tutorial, link, etc about openGL texture’s
internal formats ?? because red book, etc basically only
enumerates this values!

What do you want to know precisely ?

I’m not sure what you’re trying to achieve here, but it doesn’t sound
like it’s possible at all.

I only expect a similar way to do the colorkey in openGL like the
SDL way. I was thinking in setting a mask, a filter, an special
opengl extension, ?, to block a specific color (the colorkey) to reach
the color framebuffer. This way I’ll save to make it through the alpha
channel way (via a blending operation) and save this bit.

In a 16bpp xserver is visible the difference between a graphic file
in 565 format and the 555 one. In my app I display the same graphic
once mapped over a texture with the GL_RGB5_A1 format (that it’s the
case when i apply the colorkey) and the graphic mapped over a texture
with the GL_RGB5 format. In the first case the color gradation is
visible but the colorkey color is filtered, and in the second case
the color gradation is not visible but the colorkey is not filtered.

My loading function is the next one. I hope this helps to clarify
my question :slight_smile:

Thanks,
Jorge

int TGSGraphicRes::LoadTexture( char *filename, TGSTexture *tex )
{
SDL_Surface *image;
SDL_Rect src;
Uint32 saved_flags;
Uint8 saved_alpha;
GLint internal_format;
GLenum format;

// Try to load the surface from disk.
SDL_Surface *surface = IMG_Load( filename );
if( surface == NULL ) {
TRACEMSG( “Error loading ‘%s’.\n”, filename );
return 0;
}

// Check if the surface has a transparent color defined.
if( LoadColorKey( filename ) == 1 ) {
Uint8 r, g, b;
GetColorKey( r, g, b );
SDL_SetColorKey( surface,
SDL_SRCCOLORKEY,
SDL_MapRGB( surface->format, r, g, b ) );
}

// Create a temporal surface.
image = SDL_CreateRGBSurface( SDL_SWSURFACE,
tex->size_w, tex->size_h,
32,
#if SDL_BYTEORDER == SDL_LIL_ENDIAN /* OpenGL RGBA masks */
0x000000FF,
0x0000FF00,
0x00FF0000,
0xFF000000
#else
0xFF000000,
0x00FF0000,
0x0000FF00,
0x000000FF
#endif
);
if( image == NULL ) {
SDL_FreeSurface( surface );
return 0;
}

// Save the alpha blending attributes.
saved_flags = surface->flags & (SDL_SRCALPHA|SDL_RLEACCELOK);
saved_alpha = surface->format->alpha;
if( (saved_flags & SDL_SRCALPHA) == SDL_SRCALPHA ) {
SDL_SetAlpha( surface, 0, 0 );
}

// Copy the surface into the GL texture image.
src.x = tex->rect.x;
src.y = tex->rect.y;
src.w = tex->size_w;
src.h = tex->size_h;
SDL_BlitSurface( surface, &src, image, NULL );

// Restore the alpha blending attributes.
if( (saved_flags & SDL_SRCALPHA) == SDL_SRCALPHA ) {
SDL_SetAlpha( surface, saved_flags, saved_alpha );
}

// Create an OpenGL texture for the image.
glGenTextures( 1, &(tex->id) );
glBindTexture( GL_TEXTURE_2D, tex->id );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP );

// ***** THIS IS THE IMPORTANT CODE TO CHECK *****

// Set the format to use.
// Check if the surface has alpha blending else we use the optimum
// values to get the maximum speed.
if( (saved_flags & SDL_SRCALPHA) == SDL_SRCALPHA ) {
internal_format = GL_RGBA8;
format = GL_RGBA;
} else {
if( m_colorkey_defined ) {
internal_format = GL_RGB5_A1;
format = GL_RGBA;
} else {
internal_format = GL_RGB5;
format = GL_RGBA;
}
}

// ***** END *****

// Generate the texture.
glPushClientAttrib( GL_CLIENT_PIXEL_STORE_BIT );
glPixelStorei( GL_UNPACK_ROW_LENGTH, image->pitch /
image->format->BytesPerPixel );
glTexImage2D( GL_TEXTURE_2D,
0,
internal_format,
image->w, image->h,
0,
format,
GL_UNSIGNED_BYTE,
image->pixels );
glPopClientAttrib();

// Free the surfaces.
SDL_FreeSurface( image );
SDL_FreeSurface( surface );

return 1;
}


Message: 7
improper malloc
SDL-announce)"
Message-ID: <200504211027.24920.david at olofson.net>
Content-Type: text/plain; charset=“iso-8859-1”

Could someone please correct me if I’m wrong, but I believe
I have found a bug in the SDL 1.2.8 source code:
[…]
surface = (SDL_Surface *)malloc(sizeof(*surface));
[…]

This just determines the size of the target type of the surface
pointer at compile time (C is a statically typed language! :-), so
the value of the pointer at run time is totally irrelevant.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se


Message: 8
Message-ID: <200504210822.31704.tsm at accesscomm.ca>
Content-Type: text/plain; charset=“iso-8859-1”

$ export SDL_DSP_DEV="/dev/sound/dsp1"
$ ls -lh $SDL_DSP_DEV
crw------- 1 monttyle audio 14, 19 Dec 31 1969 /dev/sound/dsp1
$ export AUDIODEV="/dev/sound/dsp1"
$ ls -lh $AUDIODEV
crw------- 1 monttyle audio 14, 19 Dec 31 1969 /dev/sound/dsp1
$ export SDL_AUDIODRIVER=“dsp”
$ echo $SDL_AUDIODRIVER
dsp
strace blobwars

open("/dev/sound/dsp1", O_WRONLY|O_NONBLOCK) = 5

access("/dev/sound/dsp", F_OK) = 0
open("/dev/sound/dsp", O_WRONLY
(hangs)

It does this not just for blobwars, but for all SDL audio-using
applications.

lsof confirms artsd has grabbed /dev/sound/dsp, not /dev/sound/dsp1, and
also confirms nothing else is using /dev/sound/dsp1. I’ve specifically
disabled SDL’s ESD and ARTS backends to ensure they’re not causing it.
I’m using SDL-1.2.8 on gentoo linux amd64, kernel 2.6.5,

Any ideas?

That’s the SDL OSS behaviour, if it fails to open a device, it tries the
next ones.
No, that’s not the behavior I expected at all. Observe:

$ strace blobwars

open("/dev/sound/dsp1", O_WRONLY|O_NONBLOCK) = 5

access("/dev/sound/dsp", F_OK) = 0
open("/dev/sound/dsp", O_WRONLY
(hangs)

It shouldn’t be trying for alternatives after /dev/sound/dsp1 – it succeeds
in opening the device I specified, otherwise it that open would return -1.
After that, something goes and tries to open the other one! All SDL programs
that initialize and open audio end up doing this. I have not a clue why.

Another riddle is that the devices are being opened in different
ways. /dev/sound/dsp1 is not being checked with access() and is being opened
with O_RWONLY|O_NONBLOCK, meaning that it won’t hang when /dev/dsp1 is
occupied, just fail. This corresponds directly with what I’ve seen in the
SDL OSS implimentation.

/dev/sound/dsp on the other hand is checked with access beforehand, then
opened in blocking mode – and since ARTSD has already monopolized this
device it hangs hard. It takes a kill -9 to get rid of it unless I kill
artsd instead, after which case the application works and plays through the
correct device even though it insists on opening the wrong one too.

I’m guessing the two have been opened by different SDL backends but I don’t
understand why SDL would try initializing more than one driver when the one I
specified succeeds, and I have been unable to trace this behavior to any
place in the SDL code anyway.

But I’m not sure what your question is exactly ? You seem to get the
result you want…
I most definitely don’t want it hanging! :slight_smile:


Message: 9
Message-ID: <1114101675.3259.30.camel at davinci>
Content-Type: text/plain

I’m trying to use SDL_TTF to render asian characters. However, I’m
getting an empty (though not zero-sized) rectangle instead of the text.
This is using the test program included with SDL_TTF and a font with
chinese chraracters.

I can’t figure out what am I doing wrong, since SDL doesn’t give any
error. Is there some special trick I’m not doing? Does anyone have a
working example?

Thanks,
–Gabriel


Message: 10
SDL-announce)"
Message-ID: <20050421175629.GA8753 at sonic.net>
Content-Type: text/plain; charset=us-ascii

I can’t figure out what am I doing wrong, since SDL doesn’t give any
error. Is there some special trick I’m not doing? Does anyone have a
working example?

I’m not sure it’s the best /example/, since it’s no doubt pretty cluttered
in there, but Tux Paint supports Japanese, Chinese (Trad & Simpl), Korean.

http://www.newbreedsoftware.com/tuxpaint/

You can browse the code in CVS using the web interface at SourceForge:

http://cvs.sourceforge.net/viewcvs.py/tuxpaint/tuxpaint/src/

Enjoy!
On Thu, 2005-04-21 at 15:52 -0400, sdl-request at libsdl.org wrote:
Date: Wed, 20 Apr 2005 19:34:15 +0000
From: Florian Liefers
Subject: Re: [SDL] strange 2D problem
To: "A list for developers using the SDL library. (includes

Am Mittwoch 20 April 2005 14:32 schrieb Florian Liefers:
Date: Wed, 20 Apr 2005 13:38:24 -0700
From: Bill Kendrick
Subject: Re: [SDL] working with n-bit surfaces
To: Alexei Sergeev , "A list for developers
On Tue, Apr 19, 2005 at 09:18:47PM +0400, Alexei Sergeev wrote:
Date: Wed, 20 Apr 2005 13:41:03 -0700
From: Bill Kendrick
Subject: Re: [SDL] error in SDL_image
To: rushiraj at tatvasoft.com, "A list for developers using the SDL
On Tue, Apr 19, 2005 at 11:41:40PM -0500, Rushiraj wrote:
Date: Wed, 20 Apr 2005 23:44:57 -0700
From: Paul Lowe <pauls_lists at tetravista.net>
Subject: [SDL] Possible bug in SDL_surface.c discovered, line 87,
To: sdl at libsdl.org
Date: Thu, 21 Apr 2005 03:55:43 -0400
From: “Ryan C. Gordon”
Subject: Re: [SDL] Possible bug in SDL_surface.c discovered, line 87,
To: "A list for developers using the SDL library. (includes
Date: Thu, 21 Apr 2005 10:07:29 +0200
From: jorgefm at cirsa.com
Subject: Re: [SDL] Colorkey
To: sdl at libsdl.org
Date: Thu, 21 Apr 2005 10:27:24 +0200
From: David Olofson
Subject: Re: [SDL] Possible bug in SDL_surface.c discovered, line 87,
To: "A list for developers using the SDL library. (includes
On Thursday 21 April 2005 08.44, Paul Lowe wrote:
Date: Thu, 21 Apr 2005 08:22:31 -0600
From: Tyler Montbriand
Subject: Re: [SDL] SDL ignoring AUDIODEV and SDL_DSP_DEV?
To: sdl at libsdl.org
On Wednesday 20 April 2005 13:04, Stephane Marchesin wrote:
Date: Thu, 21 Apr 2005 13:41:15 -0300
From: Gabriel
Subject: [SDL] SDL_TTF with asian characters
To: SDL Mailing List
Date: Thu, 21 Apr 2005 10:56:29 -0700
From: Bill Kendrick
Subject: Re: [SDL] SDL_TTF with asian characters
To: "A list for developers using the SDL library. (includes
On Thu, Apr 21, 2005 at 01:41:15PM -0300, Gabriel wrote: