Full screen on Windows and fps

samsaga2 · December 20, 2001, 2:22am

My game :

with Linux (window and full-screen) runs at 26fps
Windows on a window at 20/21fps
And my problem: Windows at full screen 4/5 fps :(. The same code, I
only change SDL_FULLSCREEN.

I try change SetVideo flags but the frame rate not change.

icculus · December 20, 2001, 4:23am

with Linux (window and full-screen) runs at 26fps

Windows on a window at 20/21fps

And my problem: Windows at full screen 4/5 fps :(. The same code, I
only change SDL_FULLSCREEN.

I try change SetVideo flags but the frame rate not change.

Tell us what flags. Tell us what color depth. These are important as to
the reason why.

–ryan.

samsaga2 · December 20, 2001, 4:52am

SDL_SetVideoMode(800, 600, 32, SDL_HWSURFACE | SDL_DOUBLEBUFFER |
SDL_FULLSCREEN)

I use SDL_Flip and some of my sprites has alpha channel.

Anything more?

El dj, 20-12-2001 a las 13:19, Ryan C. Gordon escribi?:

> - with Linux (window and full-screen) runs at 26fps
> - Windows on a window at 20/21fps
> - And my problem: Windows at full screen 4/5 fps :(. The same code, I
> only change SDL_FULLSCREEN.
>
> I try change SetVideo flags but the frame rate not change.

Tell us what flags. Tell us what color depth. These are important as to
the reason why.

--ryan._______________________________________________
SDL mailing list
SDL at libsdl.org

http://www.libsdl.org/mailman/listinfo/sdl

slouken · December 20, 2001, 9:01am

SDL_SetVideoMode(800, 600, 32, SDL_HWSURFACE | SDL_DOUBLEBUFFER |
SDL_FULLSCREEN)

I use SDL_Flip and some of my sprites has alpha channel.

SDL_HWSURFACE + alpha channel = slow.

This is because alpha blending involves reading from the destination
memory. Since the destination memory is on the video card, it’s very
very slow to access.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Mike_Jarosch · December 20, 2001, 9:17am

You have two choices:

don’t use alpha channels
create a software back buffer and do all of your rendering to that then
blit it to the screen

Number 2 actually works quite well, the trick is converting the surfaces for
fast blit onto the back buffer.

I went trough the same thing a few weeks ago, if you need any help let me
know.

Mike> ----- Original Message -----

From: samsaga2
To: Lista de SDL
Sent: Thursday, December 20, 2001 6:51 AM
Subject: Re: [SDL] Full screen on Windows and fps

SDL_SetVideoMode(800, 600, 32, SDL_HWSURFACE | SDL_DOUBLEBUFFER |
SDL_FULLSCREEN)

I use SDL_Flip and some of my sprites has alpha channel.

Anything more?

El dj, 20-12-2001 a las 13:19, Ryan C. Gordon escribi?:

with Linux (window and full-screen) runs at 26fps

Windows on a window at 20/21fps

And my problem: Windows at full screen 4/5 fps :(. The same code, I
only change SDL_FULLSCREEN.

I try change SetVideo flags but the frame rate not change.

Tell us what flags. Tell us what color depth. These are important as to
the reason why.

–ryan.

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

Anders_Emil_Hansen · December 20, 2001, 12:44pm

Sam Lantinga wrote:

SDL_HWSURFACE + alpha channel = slow.

This is because alpha blending involves reading from the destination
memory. Since the destination memory is on the video card, it’s very
very slow to access.

Is alpha channeling not supported on newer chipsets like RivaTNT or
GeForce?
Does SDL not support hardware alpha?

Regards
Anders

David_Olofson · December 20, 2001, 1:31pm

Sam Lantinga wrote:

SDL_HWSURFACE + alpha channel = slow.

This is because alpha blending involves reading from the destination
memory. Since the destination memory is on the video card, it’s very
very slow to access.

Is alpha channeling not supported on newer chipsets like RivaTNT or
GeForce?

In fact, it’s been supported for a good while - that’s not the problem.

Does SDL not support hardware alpha?

No, and that’s because none of the underlying APIs have supported it
until recently. Even now, only a few targets support h/w alpha, and then,
in many cases, we’re talking about stuff that’s in early beta stage.

The most portable solution right now is to use OpenGL. It’s available
with acceleration on most platforms these days, and is usually very well
accelerated at that. Then there’s all the bonus features - but also, of
course, the problem that your code won’t work at all (or rather, it will
run very, very, VERY slowly) on systems without accelerated OpenGL.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 20 December 2001 21:45, Anders Emil Hansen wrote:

Keith_Lawrence · December 20, 2001, 5:19pm

AH-HA!

So that is the problem with hardware and alpha channel.

So have I got this right: The fastest way to include alpha support if you
absolutely
need to have a full-screen refresh each frame (e.g. you’re doing parallax
scrolling)
is to:

1: set up a software surface with alpha the same size as the screen, convert
all
your sprites/backgrounds/etc to that format.
2: Set up a hardware double buffered surface. Set the flags on that surface
so
that a blit to it will ignore alpha.
3: Build the screen on the software surface.
4: Blit your entire software surface to the hardware back buffer.
5: Flip.

If I’ve got this right, I vote for it (plus Mr. Lantinga’s explanation of
why hardware
alpha is slow) to go into the FAQ, since I’ve seen a lot of questions about
this on
the mailing list, but none that satisfactorily say why hardware alpha is
slow, and what
to do about it.

Keith> ----- Original Message -----

From: slouken@devolution.com (Sam Lantinga)
To:
Sent: Thursday, December 20, 2001 5:00 PM
Subject: Re: [SDL] Full screen on Windows and fps

SDL_SetVideoMode(800, 600, 32, SDL_HWSURFACE | SDL_DOUBLEBUFFER |
SDL_FULLSCREEN)

I use SDL_Flip and some of my sprites has alpha channel.

SDL_HWSURFACE + alpha channel = slow.

This is because alpha blending involves reading from the destination
memory. Since the destination memory is on the video card, it’s very
very slow to access.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

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

samsaga2 · December 20, 2001, 11:31pm

My last version…

I’m using SDL_SWSURFACE for SDL_SetVideo and SDL_Surfaces (I convert
SDL_Surfaces from SDL_HWSURFACE to SDL_SWSURFACE using
SDL_ConvertSurface because I cannot choose flags from IMG_Load)

Now at linux runs at 35/36 fps (I have gain ten frames per second more
:), on MS Windows window mode 15/20fps (the same) and Windows at
full-screen 4/5 fps (the same too).

All the surfaces are software surfaces.

I also use SDL_DisplayFormatAlpha for optimize pixel format.

El dj, 20-12-2001 a las 22:30, David Olofson escribi?:

> Sam Lantinga wrote:
> > SDL_HWSURFACE + alpha channel = slow.
> >
> > This is because alpha blending involves reading from the destination
> > memory.  Since the destination memory is on the video card, it's very
> > very slow to access.
>
> Is alpha channeling not supported on newer chipsets like RivaTNT or
> GeForce?

In fact, it's been supported for a good while - that's not the problem.

> Does SDL not support hardware alpha?

No, and that's because none of the underlying APIs have supported it 
until recently. Even now, only a few targets support h/w alpha, and then, 
in many cases, we're talking about stuff that's in early beta stage.

The most portable solution right now is to use OpenGL. It's available 
with acceleration on most platforms these days, and is usually very well 
accelerated at that. Then there's all the bonus features - but also, of 
course, the problem that your code won't work at all (or rather, it will 
run very, very, VERY slowly) on systems without accelerated OpenGL.

//David Olofson --- Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'On Thursday 20 December 2001 21:45, Anders Emil Hansen wrote:

_______________________________________________
SDL mailing list
SDL at libsdl.org

http://www.libsdl.org/mailman/listinfo/sdl

Jimmy · December 21, 2001, 12:27am

Are you sure that in Windows you’re getting the format you’re
requesting? If you’re using SDL_ConvertSurface to explicitly set the
format to what you expect Windows has set the screen to, and it’s not
set to what you expect, then there still may be conversions taking place
every time you blit to the screen.
In that case, if Linux sets the screen to the proper format and windows
does not you’d see a major framerate drop on the windows copy.
Ahem… to the best of my knowledge :)On Fri, 2001-12-21 at 02:30, samsaga2 wrote:

My last version…

I’m using SDL_SWSURFACE for SDL_SetVideo and SDL_Surfaces (I convert
SDL_Surfaces from SDL_HWSURFACE to SDL_SWSURFACE using
SDL_ConvertSurface because I cannot choose flags from IMG_Load)

Now at linux runs at 35/36 fps (I have gain ten frames per second more
:), on MS Windows window mode 15/20fps (the same) and Windows at
full-screen 4/5 fps (the same too).

All the surfaces are software surfaces.

I also use SDL_DisplayFormatAlpha for optimize pixel format.

El dj, 20-12-2001 a las 22:30, David Olofson escribi?:

On Thursday 20 December 2001 21:45, Anders Emil Hansen wrote:
> Sam Lantinga wrote:
> > SDL_HWSURFACE + alpha channel = slow.
> >
> > This is because alpha blending involves reading from the destination
> > memory.  Since the destination memory is on the video card, it's very
> > very slow to access.
>
> Is alpha channeling not supported on newer chipsets like RivaTNT or
> GeForce?

In fact, it's been supported for a good while - that's not the problem.

> Does SDL not support hardware alpha?

No, and that's because none of the underlying APIs have supported it 
until recently. Even now, only a few targets support h/w alpha, and then, 
in many cases, we're talking about stuff that's in early beta stage.

The most portable solution right now is to use OpenGL. It's available 
with acceleration on most platforms these days, and is usually very well 
accelerated at that. Then there's all the bonus features - but also, of 
course, the problem that your code won't work at all (or rather, it will 
run very, very, VERY slowly) on systems without accelerated OpenGL.

//David Olofson --- Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'

_______________________________________________
SDL mailing list
SDL at libsdl.org

http://www.libsdl.org/mailman/listinfo/sdl

–

End of Rant.

Jimmy
JimmysWorld.org

samsaga2 · December 21, 2001, 1:59am

The only difference between surface pixel format and screen pixel format
is the alpha channel, because screen hasn’t alpha channel.
On all the surfaces the flag is SDL_SWSURFACE or
SDL_SWSURFACE|SDL_SRCALPHA, and on the screen surface the flag is
SDL_SRCCOLORKEY (I don’t known why).
I use SDL_ConvertSurface for setup surface on the system memory
(SDL_SWSURFACE) from video memory. After setup then I use
SDL_DisplayFormatSurface or SDL_DisplayFormatSurfaceAlpha if have
SDL_SRCALPHA flag for omptimize the pixel format.

The code that I use for convert the surfaces:

temp = SDL_ConvertSurface(surface, screen->format, SDL_SW_SURFACE |
(surface->flags & (SDL_SRCALPHA | SDL_SRCCOLORKEY)));
if(surface->flags & SDL_SRCALPHA)
surface = SDL_DisplayFormatAlpha(temp);
else
surface = SDL_DisplayFormat(temp);
SDL_FreeSurface(temp);

The code for setup screen:

flags = SDL_SWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN;
SDL_SetVideoMode(800, 600, 32, flags);

El dv, 21-12-2001 a las 09:26, Jimmy escribi?:

Are you sure that in Windows you're getting the format you're
requesting?  If you're using SDL_ConvertSurface to explicitly set the
format to what you expect Windows has set the screen to, and it's not
set to what you expect, then there still may be conversions taking place
every time you blit to the screen.
In that case, if Linux sets the screen to the proper format and windows
does not you'd see a major framerate drop on the windows copy.
Ahem.. to the best of my knowledge :)On Fri, 2001-12-21 at 02:30, samsaga2 wrote:
> My last version...
> 
> I'm using SDL_SWSURFACE for SDL_SetVideo and SDL_Surfaces (I convert
> SDL_Surfaces from SDL_HWSURFACE to SDL_SWSURFACE using
> SDL_ConvertSurface because I cannot choose flags from IMG_Load)
> 
> Now at linux runs at 35/36 fps (I have gain ten frames per second more
> :), on MS Windows window mode 15/20fps (the same) and Windows at
> full-screen 4/5 fps (the same too).
> 
> All the surfaces are software surfaces.
> 
> I also use SDL_DisplayFormatAlpha for optimize pixel format.
> 
> El dj, 20-12-2001 a las 22:30, David Olofson escribi?:
> 
>     On Thursday 20 December 2001 21:45, Anders Emil Hansen wrote:
>     > Sam Lantinga wrote:
>     > > SDL_HWSURFACE + alpha channel = slow.
>     > >
>     > > This is because alpha blending involves reading from the destination
>     > > memory.  Since the destination memory is on the video card, it's very
>     > > very slow to access.
>     >
>     > Is alpha channeling not supported on newer chipsets like RivaTNT or
>     > GeForce?
>     
>     In fact, it's been supported for a good while - that's not the problem.
>     
>     
>     > Does SDL not support hardware alpha?
>     
>     No, and that's because none of the underlying APIs have supported it 
>     until recently. Even now, only a few targets support h/w alpha, and then, 
>     in many cases, we're talking about stuff that's in early beta stage.
>     
>     
>     The most portable solution right now is to use OpenGL. It's available 
>     with acceleration on most platforms these days, and is usually very well 
>     accelerated at that. Then there's all the bonus features - but also, of 
>     course, the problem that your code won't work at all (or rather, it will 
>     run very, very, VERY slowly) on systems without accelerated OpenGL.
>     
>     
>     //David Olofson --- Programmer, Reologica Instruments AB
>     
>     .- M A I A -------------------------------------------------.
>     |      Multimedia Application Integration Architecture      |
>     | A Free/Open Source Plugin API for Professional Multimedia |
>     `----------------------------> http://www.linuxdj.com/maia -'
>     .- David Olofson -------------------------------------------.
>     | Audio Hacker - Open Source Advocate - Singer - Songwriter |
>     `-------------------------------------> http://olofson.net -'
>     
>     _______________________________________________
>     SDL mailing list
>     SDL at libsdl.org
> 
> http://www.libsdl.org/mailman/listinfo/sdl
> 
>     
-- 

End of Rant.

Jimmy
JimmysWorld.org


_______________________________________________
SDL mailing list
SDL at libsdl.org

http://www.libsdl.org/mailman/listinfo/sdl

samsaga2 · December 21, 2001, 6:16am

It’s seems that on full screen on Windows the screen always is on video
system (hardware surface), and if I draw the sufaces on another surface
(a software surface) and then I blit this surface on the screen It’s run
at 20/21 fps (I’ve gain 15 fps).

The only that it has acceleration is the last blit, from the software
surface to the hardware surface. The another graphics that doesn’t have
alpha channel don’t have acceleration

It’s slowly but It’s less slow that the another system.

El dv, 21-12-2001 a las 10:58, samsaga2 escribi?:

The only difference between surface pixel format and screen pixel
format is the alpha channel, because screen hasn't alpha channel. 
On all the surfaces the flag is SDL_SWSURFACE or
SDL_SWSURFACE|SDL_SRCALPHA, and on the screen surface the flag is
SDL_SRCCOLORKEY (I don't known why). 
I use SDL_ConvertSurface for setup surface on the system memory
(SDL_SWSURFACE) from video memory. After setup then I use
SDL_DisplayFormatSurface or SDL_DisplayFormatSurfaceAlpha if have
SDL_SRCALPHA flag for omptimize the pixel format. 

The code that I use for convert the surfaces: 

temp = SDL_ConvertSurface(surface, screen->format, SDL_SW_SURFACE |
(surface->flags & (SDL_SRCALPHA | SDL_SRCCOLORKEY))); 
if(surface->flags & SDL_SRCALPHA) 
     surface = SDL_DisplayFormatAlpha(temp); 
else 
     surface = SDL_DisplayFormat(temp); 
SDL_FreeSurface(temp); 

The code for setup screen: 

flags = SDL_SWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN; 
SDL_SetVideoMode(800, 600, 32, flags); 


El dv, 21-12-2001 a las 09:26, Jimmy escribi?: 

    Are you sure that in Windows you're getting the format you're
    requesting?  If you're using SDL_ConvertSurface to explicitly set the
    format to what you expect Windows has set the screen to, and it's not
    set to what you expect, then there still may be conversions taking place
    every time you blit to the screen.
    In that case, if Linux sets the screen to the proper format and windows
    does not you'd see a major framerate drop on the windows copy.
    Ahem.. to the best of my knowledge :)On Fri, 2001-12-21 at 02:30, samsaga2 wrote:
    > My last version...
    > 
    > I'm using SDL_SWSURFACE for SDL_SetVideo and SDL_Surfaces (I convert
    > SDL_Surfaces from SDL_HWSURFACE to SDL_SWSURFACE using
    > SDL_ConvertSurface because I cannot choose flags from IMG_Load)
    > 
    > Now at linux runs at 35/36 fps (I have gain ten frames per second more
    > :), on MS Windows window mode 15/20fps (the same) and Windows at
    > full-screen 4/5 fps (the same too).
    > 
    > All the surfaces are software surfaces.
    > 
    > I also use SDL_DisplayFormatAlpha for optimize pixel format.
    > 
    > El dj, 20-12-2001 a las 22:30, David Olofson escribi?:
    > 
    >     On Thursday 20 December 2001 21:45, Anders Emil Hansen wrote:
    >     > Sam Lantinga wrote:
    >     > > SDL_HWSURFACE + alpha channel = slow.
    >     > >
    >     > > This is because alpha blending involves reading from the destination
    >     > > memory.  Since the destination memory is on the video card, it's very
    >     > > very slow to access.
    >     >
    >     > Is alpha channeling not supported on newer chipsets like RivaTNT or
    >     > GeForce?
    >     
    >     In fact, it's been supported for a good while - that's not the problem.
    >     
    >     
    >     > Does SDL not support hardware alpha?
    >     
    >     No, and that's because none of the underlying APIs have supported it 
    >     until recently. Even now, only a few targets support h/w alpha, and then, 
    >     in many cases, we're talking about stuff that's in early beta stage.
    >     
    >     
    >     The most portable solution right now is to use OpenGL. It's available 
    >     with acceleration on most platforms these days, and is usually very well 
    >     accelerated at that. Then there's all the bonus features - but also, of 
    >     course, the problem that your code won't work at all (or rather, it will 
    >     run very, very, VERY slowly) on systems without accelerated OpenGL.
    >     
    >     
    >     //David Olofson --- Programmer, Reologica Instruments AB
    >     
    >     .- M A I A -------------------------------------------------.
    >     |      Multimedia Application Integration Architecture      |
    >     | A Free/Open Source Plugin API for Professional Multimedia |
    >     `----------------------------> http://www.linuxdj.com/maia -'
    >     .- David Olofson -------------------------------------------.
    >     | Audio Hacker - Open Source Advocate - Singer - Songwriter |
    >     `-------------------------------------> http://olofson.net -'
    >     
    >     _______________________________________________
    >     SDL mailing list
    >     SDL at libsdl.org
    > 
    > http://www.libsdl.org/mailman/listinfo/sdl
    > 
    >     
    -- 
    
    End of Rant.
    
    Jimmy
    JimmysWorld.org
    
    
    _______________________________________________
    SDL mailing list
    SDL at libsdl.org

http://www.libsdl.org/mailman/listinfo/sdl

slouken · December 21, 2001, 7:56am

It’s seems that on full screen on Windows the screen always is on video
system (hardware surface), and if I draw the sufaces on another surface
(a software surface) and then I blit this surface on the screen It’s run
at 20/21 fps (I’ve gain 15 fps).

Somebody else reported this too. It shouldn’t happen, but I’ll look into it.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Mike_Jarosch · December 21, 2001, 8:15am

Try adding SDL_RLEACCEL to your convert surface call.> ----- Original Message -----

From: samsaga2
To: Lista de SDL
Sent: Friday, December 21, 2001 8:15 AM
Subject: Re: [SDL] Full screen on Windows and fps

It’s seems that on full screen on Windows the screen always is on video system (hardware surface), and if I draw the sufaces on another surface (a software surface) and then I blit this surface on the screen It’s run at 20/21 fps (I’ve gain 15 fps).

The only that it has acceleration is the last blit, from the software surface to the hardware surface. The another graphics that doesn’t have alpha channel don’t have acceleration

It’s slowly but It’s less slow that the another system.

El dv, 21-12-2001 a las 10:58, samsaga2 escribi?:
The only difference between surface pixel format and screen pixel format is the alpha channel, because screen hasn’t alpha channel.
On all the surfaces the flag is SDL_SWSURFACE or SDL_SWSURFACE|SDL_SRCALPHA, and on the screen surface the flag is SDL_SRCCOLORKEY (I don’t known why).
I use SDL_ConvertSurface for setup surface on the system memory (SDL_SWSURFACE) from video memory. After setup then I use SDL_DisplayFormatSurface or SDL_DisplayFormatSurfaceAlpha if have SDL_SRCALPHA flag for omptimize the pixel format.
The code that I use for convert the surfaces: 

temp = SDL_ConvertSurface(surface, screen->format, SDL_SW_SURFACE | (surface->flags & (SDL_SRCALPHA | SDL_SRCCOLORKEY))); 
if(surface->flags & SDL_SRCALPHA) 
     surface = SDL_DisplayFormatAlpha(temp); 
else 
     surface = SDL_DisplayFormat(temp); 
SDL_FreeSurface(temp); 

The code for setup screen: 

flags = SDL_SWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN; 
SDL_SetVideoMode(800, 600, 32, flags); 


El dv, 21-12-2001 a las 09:26, Jimmy escribi?: 
Are you sure that in Windows you’re getting the format you’re
requesting? If you’re using SDL_ConvertSurface to explicitly set the
format to what you expect Windows has set the screen to, and it’s not
set to what you expect, then there still may be conversions taking place
every time you blit to the screen.
In that case, if Linux sets the screen to the proper format and windows
does not you’d see a major framerate drop on the windows copy.
Ahem… to the best of my knowledge

On Fri, 2001-12-21 at 02:30, samsaga2 wrote:
My last version…

I’m using SDL_SWSURFACE for SDL_SetVideo and SDL_Surfaces (I convert
SDL_Surfaces from SDL_HWSURFACE to SDL_SWSURFACE using
SDL_ConvertSurface because I cannot choose flags from IMG_Load)

Now at linux runs at 35/36 fps (I have gain ten frames per second more
:), on MS Windows window mode 15/20fps (the same) and Windows at
full-screen 4/5 fps (the same too).

All the surfaces are software surfaces.

I also use SDL_DisplayFormatAlpha for optimize pixel format.

El dj, 20-12-2001 a las 22:30, David Olofson escribi?:
On Thursday 20 December 2001 21:45, Anders Emil Hansen wrote:
> Sam Lantinga wrote:
> > SDL_HWSURFACE + alpha channel = slow.
> >
> > This is because alpha blending involves reading from the destination
> > memory.  Since the destination memory is on the video card, it's very
> > very slow to access.
>
> Is alpha channeling not supported on newer chipsets like RivaTNT or
> GeForce?

In fact, it's been supported for a good while - that's not the problem.


> Does SDL not support hardware alpha?

No, and that's because none of the underlying APIs have supported it 
until recently. Even now, only a few targets support h/w alpha, and then, 
in many cases, we're talking about stuff that's in early beta stage.


The most portable solution right now is to use OpenGL. It's available 
with acceleration on most platforms these days, and is usually very well 
accelerated at that. Then there's all the bonus features - but also, of 
course, the problem that your code won't work at all (or rather, it will 
run very, very, VERY slowly) on systems without accelerated OpenGL.


//David Olofson --- Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'

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

End of Rant.

Jimmy
JimmysWorld.org

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