SDL_SoftStretch

Hi folks!

I need some scaled surfaces and just found SDL_stretch.c in the SDL src. But
I didn’t found docu nor a prototype in the headers. What’s up with it? Did
you include this function in 1.2? Should I implement it by myself (don’t want
to, cause I’m sure, you have the faster code thru inline assembly)?

So long
Thomas

I need some scaled surfaces and just found SDL_stretch.c in the SDL src. But
I didn’t found docu nor a prototype in the headers. What’s up with it? Did
you include this function in 1.2? Should I implement it by myself (don’t want
to, cause I’m sure, you have the faster code thru inline assembly)?

right now it’s mostly used for the software video overlay functions and
not officially supported, so it can disappear or change semantics without
prior notice. keep this in mind and you may use it anyway :slight_smile:

note that it is a very-low-quality scaler that just replicates pixels
without any interpolation so it may not be what you want

right now it’s mostly used for the software video overlay functions and
not officially supported, so it can disappear or change semantics without
prior notice. keep this in mind and you may use it anyway :slight_smile:

I think SDL should include such function “officially”. Isn’t SDL here to
move away architeture dependency and “boring” allways needed tasks for
graphic programming (8,16,24,… surface stuff; video initializing and so on)?

It’s right that eg. sprite stuff should handle the application. But what
about scaling, rotating and such common tasks? I think SDL is the right
place for such functions, because there’s lot of architecture dependency
if you want it fast (I think of assembly). And in this case, this stretch
function is needed inside SDL, why not offer it to the “outside” world?

note that it is a very-low-quality scaler that just replicates pixels
without any interpolation so it may not be what you want

Well, it’s enough for me.On Fri, Mar 16, 2001 at 11:25:26AM +0100, the boisterous Mattias Engdeg?rd wrote:

I think SDL should include such function “officially”. Isn’t SDL here to
move away architeture dependency and “boring” allways needed tasks for
graphic programming (8,16,24,… surface stuff; video initializing and so on)?

the criterion for including surface scaling functions is whether it
can be accelerated in hardware on sufficiently common platforms.
I have a feeling this is the case so this is something we’ll probably
add at some point in the future (probably in 1.3)

as usual the hard part isn’t in writing the code but designing a good api

It’s right that eg. sprite stuff should handle the application. But what
about scaling, rotating and such common tasks? I think SDL is the right
place for such functions, because there’s lot of architecture dependency
if you want it fast (I think of assembly). And in this case, this stretch
function is needed inside SDL, why not offer it to the “outside” world?

SGE, for example, is available under the terms of the LGPL and includes
those functions.
You can even strip it from the other functions (drawing primitives,
collision detection) and build your own (as long as you link it
dynamically), so I think it is the best solution for this problem.

I think the current (“unofficial”) API is pretty nice and intuitive…

But seeing the rotozoom post, how about including full polygon support in the
API, similar to a low level 3D rasterization API? Pass 4 "corner points"
instead of a rect for the destination.

And do the same for the source, and add perspective transformation, and we’re
halfway to OpenGL! Well, that wasn’t the idea, I guess…! :wink:

IIRC, Flash does quad transformation something like this. It doesn’t do
perspective transformation (as it’s not really meant for 3D), but the 3D
applets I’ve seen still look pretty good.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 16 March 2001 14:36, Mattias Engdeg?rd wrote:

I think SDL should include such function “officially”. Isn’t SDL here to
move away architeture dependency and “boring” allways needed tasks for
graphic programming (8,16,24,… surface stuff; video initializing and so
on)?

the criterion for including surface scaling functions is whether it
can be accelerated in hardware on sufficiently common platforms.
I have a feeling this is the case so this is something we’ll probably
add at some point in the future (probably in 1.3)

as usual the hard part isn’t in writing the code but designing a good api

If somebody just needs a scaling blit with smoothing, they can use the
code in maim-sdl.c in

 http://bumba.net/~hmaon/angband-sdl/main-sdl-292-pre2.tar.gz

which is available under the GPL.

There is an SDL_FastScaleBlit() which takes the same arguments as
SDL_BlitSurface() and uses fixed-point math. There is also an
SDL_ScaleBlit() which is an older implementation using floating-point
math. (I suppose they should be SDL_ScaleBlit() and SDL_SlowScaleBlit().)
These function will perform stretching and shrinking with smoothing.

Send me a note if you use these and especially if you see some way to
improve them.

Greg V. (hmaon)

    "It's today!" said Piglet.
"My favorite day," said Pooh.On Fri, 16 Mar 2001, Pius II. wrote:

SGE, for example, is available under the terms of the LGPL and includes
those functions.
You can even strip it from the other functions (drawing primitives,
collision detection) and build your own (as long as you link it
dynamically), so I think it is the best solution for this problem.

There is an SDL_FastScaleBlit() which takes the same arguments as
SDL_BlitSurface() and uses fixed-point math. There is also an
SDL_ScaleBlit() which is an older implementation using floating-point
math.

note that it’s not recommended to use the SDL_ prefix for any identifiers
in code linked to SDL — it may cause collisions later

note that it’s not recommended to use the SDL_ prefix for any identifiers
in code linked to SDL — it may cause collisions later

Hm, OK. I didn’t know that. At the time, I was trying to prevent future
collisions with other identifiers in Angband.

Greg V. (hmaon)

    "It's today!" said Piglet.
"My favorite day," said Pooh.On Fri, 16 Mar 2001, Mattias Engdegard wrote:

Allegro, the game library for DJGPP, has stretch blitting. You might want to
see what sort of API they used.

However, your SDL_SurfaceBlit() already takes 2 surfaces and 2 rects for each
surface. So you should already have the API in place for this. It’s a
simple matter of looking to see if the width and height are different between
the source and destination, and if so, the stretched blit is required instead
of the normal one. This is certainly the most intuitive solution. If I
hadn’t already read somewhere that SDL didn’t do stretch blitting, I would
have assumed this is now it would work. Of course then when I tried it, I’d
have realized it didn’t work. :slight_smile:

I for one am looking forward to stretch blit support in SDL. I’m trying to
port an old Allegro project I started to SDL and finish it up. Seemed like
stretch blit was the one missing feature I used in Allegro that wasn’t in SDL.On Friday 16 March 2001 05:36, you wrote:

I think SDL should include such function “officially”. Isn’t SDL here to
move away architeture dependency and “boring” allways needed tasks for
graphic programming (8,16,24,… surface stuff; video initializing and so
on)?

the criterion for including surface scaling functions is whether it
can be accelerated in hardware on sufficiently common platforms.
I have a feeling this is the case so this is something we’ll probably
add at some point in the future (probably in 1.3)

as usual the hard part isn’t in writing the code but designing a good api

This question has come up in the past (I recall a similar thread about a year
ago) and I think the general concensus was that SDL was intended to be “Simple”
(hence, “Simple DirectMedia Layer” :wink: and that starting to add in functions
like this make it not quite as simple any more (relative, I know, but that was
what I recall).

I was under the impression SDL was /not/ a catch all for any and every needed
feature, and that functionality like this can best be delivered by other
add-on libraries. I tend to agree with this, because for quite a few
applications these features aren’t needed.

Then again, a simple soft-stretch function is a pretty nice thing to have, and
as long as we don’t go nuts with tons of rotating, scaling, aliasing, etc.,
etc. features that add to code bloat, I think a soft-stretch function would be
a nice (and not too intrusive) addition to SDL.On Fri, 16 Mar 2001, you wrote:

On Fri, Mar 16, 2001 at 11:25:26AM +0100, the boisterous Mattias Engdeg?rd wrote:

right now it’s mostly used for the software video overlay functions and
not officially supported, so it can disappear or change semantics without
prior notice. keep this in mind and you may use it anyway :slight_smile:

I think SDL should include such function “officially”. Isn’t SDL here to
move away architeture dependency and “boring” allways needed tasks for
graphic programming (8,16,24,… surface stuff; video initializing and so on)?

It’s right that eg. sprite stuff should handle the application. But what
about scaling, rotating and such common tasks? I think SDL is the right
place for such functions, because there’s lot of architecture dependency
if you want it fast (I think of assembly). And in this case, this stretch
function is needed inside SDL, why not offer it to the “outside” world?


Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

Samuel Hart wrote:

This question has come up in the past (I recall a similar thread about a year
ago) and I think the general concensus was that SDL was intended to be “Simple”
(hence, “Simple DirectMedia Layer” :wink: and that starting to add in functions
like this make it not quite as simple any more (relative, I know, but that was
what I recall).

I agree!

I was under the impression SDL was /not/ a catch all for any and every needed
feature, and that functionality like this can best be delivered by other
add-on libraries. I tend to agree with this, because for quite a few
applications these features aren’t needed.

Yes, it is in lots of add-on libraries including my super-code-bloated
library!! But I think that you over look how simple a stretch blit is
to
do. Its just linear interpolation. Remember from math class in high
school the equation “y = mx + b”? A minimum stretch blit could take
five lines!! If you want hardware acceleration use OpenGL! There was
asm mentioned but I don’t think that it’ll help much (in my very
non-expert opinion) because you can’t use fast ways of
traversing/copying the image since you move accross in
uneven-fractional-increments. The only speed-up I can think of (again,
I am no expert) is using fixed-point math…

-- David Snopek

/-- libksd –
| The C++ Cross-Platform Game Framework
| Only want to write it once??
| http://libksd.sourceforge.net
------------

However, your SDL_SurfaceBlit() already takes 2 surfaces and 2 rects for each
surface. So you should already have the API in place for this.

it would break the existing api semantics which is one of clipping rather
than scaling (in fact the dest rect size is ignored altogether but updated
after the blit). we might do it that way in 1.3 though

I for one am looking forward to stretch blit support in SDL

I think it should be added but we might as well do it right

But I think that you over look how simple a stretch blit is
to
do. Its just linear interpolation.

a correct raster image resizing is a lot more than a linear interpolation;
for performance there are trade-offs of course. a little overview:

reconstruction filter quality===============================================
boxed (pixel duplication) amazingly low
linear low - works as a low-pass filter so result is
blurred
cubic quite ok, keeps higher frequencies as well
windowed sinc about as good as you can make it

of course the higher quality you want, the more cpu you have to use on it

Din’t overlook that. Just was saying that once we started adding things like
this… others can be more easily argued… and soon things can get out of hand.On Sat, 17 Mar 2001, you wrote:

Samuel Hart wrote:

I was under the impression SDL was /not/ a catch all for any and every needed
feature, and that functionality like this can best be delivered by other
add-on libraries. I tend to agree with this, because for quite a few
applications these features aren’t needed.

Yes, it is in lots of add-on libraries including my super-code-bloated
library!! But I think that you over look how simple a stretch blit is
to
do.


Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

Yeah… The question is probably something like where to draw the line where
you should definitely switch to OpenGL.

I’d say pure scaling is a rather simple operation which belongs in a 2D API,
while rotation and mapping to polygons is where we’re beginning to talk about
3D stuff. The main reason why I want to draw the line there is that rotation
(let alone texture mapped polygons) change the rules totally for both the API
and the rendering.

Maybe it’s a question of how the API would relate to the current 2D API, more
than one of whether or not it can be hardware accelerated… (There’s a lot
of stuff that can be hardware accelerated with OpenGL, but surely wouldn’t be
considered for inclusion in the SDL 2D API, unless possibly if it was
supported by the underlying 2D target.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Monday 19 March 2001 16:28, Samuel Hart wrote:

On Sat, 17 Mar 2001, you wrote:

Samuel Hart wrote:

I was under the impression SDL was /not/ a catch all for any and every
needed feature, and that functionality like this can best be delivered
by other add-on libraries. I tend to agree with this, because for quite
a few applications these features aren’t needed.

Yes, it is in lots of add-on libraries including my super-code-bloated
library!! But I think that you over look how simple a stretch blit is
to
do.

Din’t overlook that. Just was saying that once we started adding things
like this… others can be more easily argued… and soon things can get out
of hand.

Hi all,

I picked up in the suggestion to include SDL_SoftStretch in my rotozoom
code. The routine works well on Linux, but the SDL.dll (build with
cross-mingw) doesn’t include it so my testcode doesn’t build for windows
using a stock SDL.dll.

The following should be added to ‘include/SDL_video.h’ to make it work:

extern DECLSPEC int SDL_SoftStretch(SDL_Surface *src, SDL_Rect *srcrect,
SDL_Surface *dst, SDL_Rect *dstrect);

Question: Does the function need surfaces to be locked?

Regards
Andreas

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 :slight_smile:

I cannot use SDL_VIDEODRIVER since I’m compiling under Win with linked libc,
so the environment set of the DLL is different from the one of the program.

Thanks—
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

  • Black holes are generated when God divides by zero -

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?–

Olivier A. Dagenais - Software Architect and Developer

“Andreas Schiffler” wrote in message
news:3B164532.58345DFA at home.com

Hi all,

I picked up in the suggestion to include SDL_SoftStretch in my
rotozoom
code. The routine works well on Linux, but the SDL.dll (build with
cross-mingw) doesn’t include it so my testcode doesn’t build for
windows
using a stock SDL.dll.

The following should be added to ‘include/SDL_video.h’ to make it
work:

extern DECLSPEC int SDL_SoftStretch(SDL_Surface *src, SDL_Rect
*srcrect,
SDL_Surface *dst, SDL_Rect
*dstrect);

Question: Does the function need surfaces to be locked?

Regards
Andreas

Actually, I’d be interested. I’ve been working on adding a similar feature
to Kyra, so it can scale bitmaps. I’m not sure how applicable that work
would be, but I’d be willing to throw it into the mix.

lee
www.grinninglizard.com/kyra>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?

Olivier A. Dagenais - Software Architect and Developer

“Andreas Schiffler” wrote in message
news:3B164532.58345DFA at home.com

Hi all,

I picked up in the suggestion to include SDL_SoftStretch in my
rotozoom
code. The routine works well on Linux, but the SDL.dll (build with
cross-mingw) doesn’t include it so my testcode doesn’t build for
windows
using a stock SDL.dll.

The following should be added to ‘include/SDL_video.h’ to make it
work:

extern DECLSPEC int SDL_SoftStretch(SDL_Surface *src, SDL_Rect
*srcrect,
SDL_Surface *dst, SDL_Rect
*dstrect);

Question: Does the function need surfaces to be locked?

Regards
Andreas