Hi,
Just working on a small test program at the moment and performance is
rapidly
deteriorating as the size increases. Removing alpha blended images just
about
doubles the performance, but I’d really prefer to keep them in the
application.
Just wondering if there are any particularaly fast methods of using image
alpha channels? I’ve searched around a bit but there doesn’t seem to be any
good tutorials/guides on alpha channels and SDL.
It is VERY HARD to get fast 2D alpha-channel blits; very few things except
OpenGL can support it in hardware. Note that SDL has a faster special-case
alpha blitter for alpha=128.On September 16, 2005 03:23 am, Mathew Byrne wrote:
Hi,
Just working on a small test program at the moment and performance is
rapidly
deteriorating as the size increases. Removing alpha blended images just
about
doubles the performance, but I’d really prefer to keep them in the
application.Just wondering if there are any particularaly fast methods of using image
alpha channels? I’ve searched around a bit but there doesn’t seem to be any
good tutorials/guides on alpha channels and SDL.
It is VERY HARD to get fast 2D alpha-channel blits; very few things except
OpenGL can support it in hardware. Note that SDL has a faster
special-case
alpha blitter for alpha=128.
Also note that the special 128 Alpha value applies only to Per-Surface
alpha, and not per-pixel. the special 128 value really is a bit faster, if
your surfaces only need the per-surface transparency on the whole image. If
you’re trying to get smooth edges on some sprites, for instance, you’ll need
to stick with the slower per-pixel, or try out glSDL backend, which I
haven’t tried so I can’t tell you anymore than that.
-Dave>
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
[…]
If you’re trying to get smooth
edges on some sprites, for instance, you’ll need to stick with the
slower per-pixel,
Well, yes - but antialiazed sprites are generally mostly (as in 90% or
so) fully transparent and fully opaque pixels. If you enable the RLE
acceleration, the cost of alpha blending only impacts the pixels that
actually need blending.
or try out glSDL backend, which I haven’t tried so I can’t tell you
anymore than that.
glSDL is handy if you want to optionally support high resolutions
and/or additional blending effects, or just want to give demanding
users insane frame rates - but if software rendering just doesn’t cut
it regardless of settings, glSDL isn’t really a solution. If you
depend on OpenGL through glSDL for playable frame rates, you’re
probably better off using OpenGL directly.
(One might argue that there might be systems where there are
accelerated SDL backends, but no accelerated OpenGL. However, most of
the time it seems to be the other way around; if anything at all is
accelerated, it’s OpenGL… That’s why glSDL came to be in the first
place.)
//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.net — http://www.reologica.se —On Friday 16 September 2005 19.40, David Olsen wrote:
[…]
If you’re trying to get smooth
edges on some sprites, for instance, you’ll need to stick with the
slower per-pixel,Well, yes - but antialiazed sprites are generally mostly (as in 90% or
so) fully transparent and fully opaque pixels. If you enable the RLE
acceleration, the cost of alpha blending only impacts the pixels that
actually need blending.Now, this I did not know. That’s really great. I had thought that RLE only
really accelerated on a color-based level. So if I call SDL_SetAlpha(xxxxx)
and include both the Alpha, and RLE flags, that it will accelerate when
possible? Is there any time when it would make it go slower?
I guess I’ll try it out on my current project and post the results…Okay, some quick implementing results in the following difference :
123 FPS without the RLE technique
125 FPS with the RLE - a small but definite increase in FPS, however :
because of the way I am using these images(as buttons) and checking whether
or not the mouse is over the button by checking if they are over a
transparent pixel or not, when the mouse is over one of these buttons, the
FPS drops to 110 FPS(whereas without the RLE, it stays around 123 FPS). I
assume this is because of the decompressing of the info on each frame to see
whether the mouse is still over an opaque part of the button. (Also, the
performance hit is less, when I do it over a small button, and more when
over a large button, which makes sense - there’s more to decompress on a
larger image.)
So, for my money, a non-RLE acccelerated surface “works” faster, even though
the RLE-accel one blits a little faster… But, it all depends on how you
use it in your project.
Thanks for the great mailing list everyone! I don’t post often, but I learn
lots from reading everyone’s elses posts, and I pipe up once in a while when
I think I know something, even if I actually don’t… anyway, keep up the
good work!
-Dave----- Original Message -----
From: david@olofson.net (David Olofson)
On Friday 16 September 2005 19.40, David Olsen wrote:
Hi!
Pls, exsists glSDL for Delphi? Thx