Todd Lang | 1 Mar 04:19 2005
Picon

SDL_LoadBMP question

What format of BMP does the SDL_LoadBMP support?  Basically, I'm curious if
I generate a BMP written out in A8R8G8B8 format, can I load that BMP and
have an alpha channel, without needing SDL_Image and loading it as a TGA
instead?

I've tried loading it in to memory and loading it from there:
			rw = SDLInterop.RWFromMem(arr, arr.Length)
			temp = SDLInterop.LoadBMP_RW(rw, 1)

And then I call SDL_DisplayFormatAlpha, but the resulting image does not
have per-pixel transparency.  Is what I'm trying to do even possible?

Todd Lang
Paulo V W Radtke | 1 Mar 04:59 2005
Picon

Re: SDL_LoadBMP question

> What format of BMP does the SDL_LoadBMP support?  Basically, I'm curious if
> I generate a BMP written out in A8R8G8B8 format, can I load that BMP and
> have an alpha channel, without needing SDL_Image and loading it as a TGA
> instead?
...
> And then I call SDL_DisplayFormatAlpha, but the resulting image does not
> have per-pixel transparency.  Is what I'm trying to do even possible?

	I'm using PNG files with SDL Image and no problem loading the alpha 
channel from them. The greatest point on using PNG files is that they 
are *MUCH* smaller than BMPs, and the image quality is way better than 
with JPEG files.

	Besides, does BMP files actually (or officially, for that matter) 
support alpha channel?

	Best regards,

	Paulo V W Radtke - Chien Loco Jogos de GaragemĀ®

http://blog.chienloco.com
http://www.chienloco.com
Todd Lang | 1 Mar 05:37 2005
Picon

RE: SDL_LoadBMP question

> 	I'm using PNG files with SDL Image and no problem 
> loading the alpha 
> channel from them. The greatest point on using PNG files is that they 
> are *MUCH* smaller than BMPs, and the image quality is way 
> better than 
> with JPEG files.
> 
I agree that using SDL_Image would be ideal.  After all, loading disparate
image formats is what it was designed to do.  Unfortunately, I'm using SDL
on my PocketPC and we are having a heckuva time getting SDL_Image to compile
and *work*, so for now we're sticking with the base library.

I believe I have found my own answer.  It does appear to load the 32bpp BMP
files, but I'm more than a little rusty in RGBA->RGB blits in SDL, so I'm
not 100% certain the alpha is working.  (I seem to remember something about
having to load the image, create another surface, blit the loaded image to
the target surface, etc.)  I'm working on it.  (Anyone have any definitive
alpha examples?)

> 	Besides, does BMP files actually (or officially, for 
> that matter) 
> support alpha channel?
> 
Geeze, if you want to get all "official" and everything.  :)  No, I do not
believe it's officially supported, but many image editors will write 32bpp
BMP files since there's no TECHNICAL reason they can't have that colour
depth.  Photoshop even lets you choose X8R8G8B8 and A8R8G8B8 if you want.
It's pretty nice.

Todd Lang
(Continue reading)

Paulo V W Radtke | 1 Mar 07:37 2005
Picon

Re: SDL_LoadBMP question

> Geeze, if you want to get all "official" and everything.  :)  No, I do not
> believe it's officially supported, but many image editors will write 32bpp
> BMP files since there's no TECHNICAL reason they can't have that colour
> depth.  Photoshop even lets you choose X8R8G8B8 and A8R8G8B8 if you want.
> It's pretty nice.

	Technically if the formal BMP specification does not specifies such 
information, it means that not everybody may support it. PaintShopPro 
does not even recognize a 32 bits BMP as a valid file, the same for the 
Windows XP integrated Windows Picture and Fax Viewer - and if there's 
somebody who should know BMP files, Microsoft should be the one. So 
maybe there's a point on why SDL may be missing the alpha channel (may 
someone involved with this part step up and confirm it?).

	But getting back to the point, i.e., helping you solve your problem, 
one solution is to separate the alpha channel on Photoshop and save it 
as a gray scale bitmap. Then you load your color BMP file, convert it to 
a 32 bits surface and fill the alpha values from the second file which 
contains the alpha from the complete image.

	Another option is to make a TGA loader, which is very simple - check 
http://organicbit.com/closecombat/formats/tga.html for some info, it's 
very straightforward.

	Best regards,

	Paulo V W Radtke - Chien Loco Jogos de GaragemĀ®

http://blog.chienloco.com
http://www.chienloco.com
(Continue reading)

Brian Barrett | 1 Mar 12:35 2005
Picon

Re: Problem SDL_mixer, I do not know what is bad, please help

is the .dll in your project directory (never used SDL_mixer , but most
SDL_thingy's have a dll).

i got the same problem the first time i used dev-cpp because various
sources said to put the dll in c:\windows or c:\windows\system so they
would be available system-wide, but i needed to put SDL.dll in the
source directory
Todd Lang | 1 Mar 14:07 2005
Picon

Re: SDL_LoadBMP question

> somebody who should know BMP files, Microsoft should be the one. So
> maybe there's a point on why SDL may be missing the alpha channel (may
> someone involved with this part step up and confirm it?).
>
It does seem that the alpha channel is loaded as I'm definately getting
some per-pixel alpha effect in my experimentations.  Of course, I could be
misinterpreting some other effect.  I'm still having a great deal of
difficulty remembering all the tricks to getting alpha-blended images to
the display, but I'm getting there.  :)

> 	But getting back to the point, i.e., helping you solve your problem,
> one solution is to separate the alpha channel on Photoshop and save it
> as a gray scale bitmap. Then you load your color BMP file, convert it to
> a 32 bits surface and fill the alpha values from the second file which
> contains the alpha from the complete image.
>
Would you load the image and the alpha, then create another surface at
32bpp, then blit the image on to the surface, and then use... what, some
kind of SetPixel command to push the alpha over?  Just not sure of what
the approach would be here.

> 	Another option is to make a TGA loader, which is very simple - check
> http://organicbit.com/closecombat/formats/tga.html for some info, it's
> very straightforward.
>
Actually, thanks very much for that link.  That's probably one of the
clearest explanations of the file format that I've seen.  And while I can
definately load the image in to memory, I'm having a great deal of
difficulty in creating the SDL_RWOps structure, due to the large number of
pointers it uses.  (As I mentioned before I'm writing this code in the
(Continue reading)

Vandekerckhove Davy | 1 Mar 16:13 2005

SDL_SYSWMEVENT on windowsXP

> I have an SDL videowindow where I only process SDL_VIDEORESIZE and SDL_QUIT events.
> Processing the messages works at acceptable speed.
> I also need to process the window move event. Since there is no SDL event for that I catch the SDL_SYSWMEVENT
event, and perform an action when I receive a WM_MOVE. Basically it all works, but as soon as I start
listening to SDL_SYSWMEVENT events, the event processing goes very slow.
> (I takes almost 2 seconds to process a resize message) It seems I receive a big number of SDL_SYSWMEVENT
events continuously. If I process these events or not has no influence on the speed. I notice that my
WM_MOVE message arrives 6 times in the eventqueue, while I would expect it only once.
> Are there known issues with SDL_SYSWMEVENT on windows?
> Is there perhaps another way to catch videowindow move events without using SDL_SYSWMEVENT?
> 
> Basically I do this (Maybe this is not how its supposed to be?):
> 
> SDL_EventState(SDL_SYSWMEVENT, SDL_ENABLE); 
> while (SDL_WaitEvent(&event))
> {
> 	switch(event.type) 
>       { 
>             case SDL_SYSWMEVENT:
>                 if (event.syswm.msg->msg == WM_MOVE)
>                 {
>                     //ACTION
>                 }
>                 break;
> 		//SNIP....
> } 
Vandekerckhove Davy | 1 Mar 15:10 2005

SDL_SYSWMEVENT on windowsXP

I have an SDL videowindow where I only process SDL_VIDEORESIZE and SDL_QUIT events.
Processing the messages works at acceptable speed.
I also need to process the window move event. Since there is no SDL event for that I catch the SDL_SYSWMEVENT
event, and perform an action when I receive a WM_MOVE. Basically it all works, but as soon as I start
listening to SDL_SYSWMEVENT events, the event processing goes very slow.
(I takes almost 2 seconds to process a resize message) It seems I receive a big number of SDL_SYSWMEVENT
events continuously. If I process these events or not has no influence on the speed. I notice that my
WM_MOVE message arrives 6 times in the eventqueue, while I would expect it only once.
Are there known issues with SDL_SYSWMEVENT on windows?
Is there perhaps another way to catch videowindow move events without using SDL_SYSWMEVENT?

Basically I do this (Maybe this is not how its supposed to be?):

SDL_EventState(SDL_SYSWMEVENT, SDL_ENABLE); 
while (SDL_WaitEvent(&event))
{
	switch(event.type) 
      { 
            case SDL_SYSWMEVENT:
                if (event.syswm.msg->msg == WM_MOVE)
                {
                    //ACTION
                }
                break;
		//SNIP....
}
Petri Kero | 1 Mar 16:27 2005
Picon

Macro function argument safety issues.

Hi all,

I've been using SDL (also ttf, net and mixer) library for my hobby 
project and I must say I've absolutely loved the minimalistic API design 
principle. It gives such a low learning curve that I haven't gotten 
frustrated with it, which happens with most libraries. Lots of Kudos to 
you for that!

Anyway, I noticed that there are some safety issues with how macro 
function arguments are used in some parts of SDL. The SDL_net.h is the 
worst where there are usually no parenthesis at all around the 
arguments. The main library seems to be almost clean, but I found one 
place in there as well which might result in some erroneous behaviour.

I know that macros can never be truly safe (have you considered using 
innline functions, btw?), but I think you should thrive for as much 
safety as is possible.

Anyway, here's one example of the problem (found in SDL_net.h):
#define SDLNet_Write16(value, areap)	\
do 					\
{					\
	Uint8 *area = (Uint8 *)(areap);	\
	area[0] = (value >>  8) & 0xFF;	\
	area[1] =  value        & 0xFF;	\
} while ( 0 )

Now imagine I use this macro in my code like this:
   SDLNet_Write16(a | b >> 8, ptr);

(Continue reading)

Paulo V W Radtke | 1 Mar 20:38 2005
Picon

Re: SDL_LoadBMP question

> Would you load the image and the alpha, then create another surface at
> 32bpp, then blit the image on to the surface, and then use... what, some
> kind of SetPixel command to push the alpha over?  Just not sure of what
> the approach would be here.

	That's it. You can use the SDL page provided set pixel example and the 
alpha mask to change the alpha values.

> Actually, thanks very much for that link.  That's probably one of the
> clearest explanations of the file format that I've seen.  And while I can
> definately load the image in to memory, I'm having a great deal of
> difficulty in creating the SDL_RWOps structure, due to the large number of
> pointers it uses.  (As I mentioned before I'm writing this code in the
> compact framework for PocketPC, which makes constructing things like that
> ... challenging.)

	Actually you can get rid wit RWOps if you make your own TGA loader, you 
can use the raw RGB data read from the TGA file to create an SDL surface.
	
	Best regards,
	
	Paulo V W Radtke - Chien Loco Jogos de GaragemĀ®

http://blog.chienloco.com
http://www.chienloco.com

Gmane