Olivier Dagenais wrote:
Ah, yes, I tried using this function in my program (on Windows)…
Since this function isn’t recommended and not really exposed, I was
going to write my own stretch code. Anybody want to help? We could
throw together a small LGPL library for simple bitmap stretching?
Why bother with a separate library for a simple stretch blit … we
have a working function in SDL. Why it isn’t recommended - I don’t know?
But it is used in the YUV soft stretch code … and its surely useful!
I my view, all we need, is to make the existing function “recommended”
(whatever it takes to do that - any comments on that?) and expose it to
the external world by adding a single line in SDL_video.h as mentioned
in my earlier post.
As for a more generic library - why don’t you/we use my SDL_rotozoom
(see previous post) code as a starting point and make it more generic:
one can split the zoom factors into an x and y component; one can amke
it faster by considering special cases such as angle=0 and bpp=16 or 24
which are not handled very well; the current rotation code is suboptimal
as it could be decomposed into several shear operations (see
graphics.FAQ); bilinear interpolation for shrinking of images
(zoomfactors<0.5) sucks.
But we should always keep in mind that some need quality (alpha channel
preservation, interpolation) for pre-rendered stuff over real-time
rendering speed.
Ciao
Andreas
Why bother with a separate library for a simple stretch blit …
we
Stretching bitmaps is not what I’d expect SDL to do, unless it has a
way of doing it with hardware.
have a working function in SDL. Why it isn’t recommended - I don’t
know?
Because it uses inline assembler, it is not thread-safe. Also, it
does not do any smoothing. On top of it all, Mattias warns that it
may disappear or change without notice, mostly because it is not an
exposed function.
I my view, all we need, is to make the existing function
"recommended"
(whatever it takes to do that - any comments on that?) and expose it
to
the external world by adding a single line in SDL_video.h as
mentioned
in my earlier post.
I figure it would be easier to write a new function so that we don’t
have to worry about thread safety, a possibly disappearing or changing
function or the lack of quality.
As for a more generic library - why don’t you/we use my SDL_rotozoom
I’m pretty sure I didn’t use it because I needed to go from a small
surface to a larger one and it didn’t support that.
(see previous post) code as a starting point and make it more
generic:
You’re more than welcome to use the code I write in your library.–
Olivier A. Dagenais - Software Architect and Developer
“Olivier Dagenais” <olivier.dagenais at canada.com> wrote in message
news:9f7uc7$imq$1 at ftp.lokigames.com…
Why bother with a separate library for a simple stretch blit …
we
Stretching bitmaps is not what I’d expect SDL to do, unless it has a
way of doing it with hardware.
Almost all hardware supports this.
have a working function in SDL. Why it isn’t recommended - I don’t
know?
Because it uses inline assembler, it is not thread-safe.
How is inline assembler any less thread safe than straight C? Anyway, just
wrap the function in another function which performs the necessary locking
to ensure thread safety.
Also, it
does not do any smoothing. On top of it all, Mattias warns that it
may disappear or change without notice, mostly because it is not an
exposed function.
I think the proposal was to add ‘SDL_SoftStretch’ or something similar to
the official API, which would remove that problem.
Of course, what we really want is a function that is semantically identical
to ‘SDL_BlitSurface’ (including support for alpha and color key) except that
scaling is performed to map the source rectangle onto the destination
rectangle. Writing such a function with good performance characteristics is
very difficult, which I expect is the real reason no such function exists in
SDL right now.–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
What about using Hermes? They have almost all possible blitting functions with
some special cases in MMX etc and the also have stretching implemented to some
extend. Only direct hardware acceleration for blits have to be done by SDL this
way. I think the current home of Hermes is at the ClanLib site.
Proff–
Florian ‘Proff’ Schulze - @Florian_Schulze
Homepage: - http://proff.fly.to
PGP-Key available from - http://www.keyserver.net/en/
Writing such a function with good performance characteristics is
very difficult, which I expect is the real reason no such function exists in
SDL right now.
the real reason is rather that nobody has bothered to write one. Myself I
would prefer holding it to a later version since there are strong reasons
to rewrite the blitting api anyway
The main issue is being able to contain the combinatorial explosion of
(architecture) x (pixel format) x (interpolation) x (blit operation) x
x (important special cases)
to a sane amount of code without sacrificing too much performance. But it’s
something that should be done
Writing such a function with good performance characteristics is
very difficult, which I expect is the real reason no such function exists in
SDL right now.
the real reason is rather that nobody has bothered to write one. Myself I
would prefer holding it to a later version since there are strong reasons
to rewrite the blitting api anyway
The main issue is being able to contain the combinatorial explosion of
(architecture) x (pixel format) x (interpolation) x (blit operation) x
x (important special cases)
to a sane amount of code without sacrificing too much performance. But it’s
something that should be done
What about using Hermes? They have almost all possible blitting functions with
some special cases in MMX etc and the also have stretching implemented to some
extend.
hermes is very limited in its functionality but since it’s LGPL’ed we
can steal what we want and ditch the rest
And please learn how to quote
Stretching bitmaps is not what I’d expect SDL to do, unless it has
a
way of doing it with hardware.
Almost all hardware supports this.
…but SDL currently doesn’t. I need something now.
Also, it
does not do any smoothing. On top of it all, Mattias warns that
it
may disappear or change without notice, mostly because it is not
an
exposed function.
I think the proposal was to add ‘SDL_SoftStretch’ or something
similar to
the official API, which would remove that problem.
Probably, but that still doesn’t make SDL_SoftStetch perform
smoothing. I don’t need something fast, I need something
high-quality, hence why I’m looking for someone to help me a bit.–
Olivier A. Dagenais - Software Architect and Developer
Probably, but that still doesn’t make SDL_SoftStetch perform
smoothing. I don’t need something fast, I need something
high-quality, hence why I’m looking for someone to help me a bit.
try bicubic interpolation (if you have really high demands, a windowed
Sinc should be even better)
Hello,
Is it ok to manually call SDL_VideoInit() and SDL_VideoQuit() if I need to
specify a specific video driver?
By looking at the code I can’t see any problem with this, but hey, better
ask and be sure 
Yes, that’s fine. Read the notes in the SDL headers though.
See ya,
-Sam Lantinga, Lead Programmer, Loki Software, Inc.