Surface scaling again

SDL Development
1

I have the same problem that David Olsen did here:
libsdl.org/pipermail/sdl/2005-December/071786.html. I need a scaling
function to implement resolution-independent sprites and the obvious
"make things bigger" effect. Right now I have rotozoom statically linked
into my project, but, as he mentioned, it uses ugly integer division
when downscaling. Given that the images will be downscaled on most
screens, I find this unacceptable. So, what I need is basically a
function that will handle at least bilinear scaling, alpha channels, and
hopefully all the common pixel formats.

That thread seems to have left off with him hacking the code from that
Sega emulator to handle more pixel formats and alpha channels. AFAIK he
hasn’t posted the code anywhere for we freeloaders to use and love. With
a 7th grade education under my belt, I’m not quite capable of even
understanding how that function from SMS+SDL operates, much less hack it
to use alpha (which I need). My question is, does anyone here have a
scaling function that 1) handles common pixel formats 2) uses at least
bilinear interpolation even when downscaling 3) handles alpha channels
and 4) that you want to give away?

Thanks,
Me.

2

Kevin,
I just noticed this post! I’ll tell you what I did, I did lots of digging
around on the net, found no pre-made solutions, and finally came up with
something that works well for me and my situation - loading images and
scaling them all before using them on-screen. It doesn’t work well with
real-time scaling, as it’s a little slow, though for typical sprite-sized
images, it’s pretty quick. What I ended up doing was scrapping the SMS
emulator B-spline implementation(which worked, but didn’t produce as sharp
an image as I would have liked.) and modified a grayscale resizing function
from “Graphics Gems”, published like back in the mid- or early ninties.
Anyway, allow me to clean up the code just a little bit, and I’ll post a
link to it.

The “library” basically is called by functions where you pass in a
SDL_Surface *, and the new size you want(either in exact x,y sizes, or a
percentage/float), and it returns the new image, optimized for the current
screen format. It actually has several options for quality vs. speed,
different interpolation techniques. I’m happy to say that it gives really
quite good results when shrinking images, which is what I was looking for
back in December. Oh, yeah, it automatically handles alpha, too. I can’t
vouch for the common pixel formats beyond 32-bit, but I think I made it so
that it converts first to 32-bit, does all the calculations, then converts
back to screen format. I know it works just fine with 16 and 32 bit images -
might have problems with 8-bit, might not.

Okay, off to the IDE for some cleanup of code. I’ll post a link soon.
-David Olsen> ----- Original Message -----

From: kevinmb500@gawab.com (Kevin Baragona)
To:
Sent: Tuesday, May 23, 2006 7:04 PM
Subject: [SDL] Surface scaling again.

I have the same problem that David Olsen did here:
libsdl.org/pipermail/sdl/2005-December/071786.html. I need a scaling
function to implement resolution-independent sprites and the obvious
"make things bigger" effect. Right now I have rotozoom statically linked
into my project, but, as he mentioned, it uses ugly integer division
when downscaling. Given that the images will be downscaled on most
screens, I find this unacceptable. So, what I need is basically a
function that will handle at least bilinear scaling, alpha channels, and
hopefully all the common pixel formats.

That thread seems to have left off with him hacking the code from that
Sega emulator to handle more pixel formats and alpha channels. AFAIK he
hasn’t posted the code anywhere for we freeloaders to use and love. With
a 7th grade education under my belt, I’m not quite capable of even
understanding how that function from SMS+SDL operates, much less hack it
to use alpha (which I need). My question is, does anyone here have a
scaling function that 1) handles common pixel formats 2) uses at least
bilinear interpolation even when downscaling 3) handles alpha channels
and 4) that you want to give away?

Thanks,
Me.

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

3

I’ve had exceptional luck with the Bresenham resize. It gives almost
bicubic quality, and I’ve done 640x480 images in realtime. To me, realtime
is decoding MPEG-2 in, resizing, and encoding MPEG-4 out. If I remember
correctly, my MPEG-2 in was 720x480 and my MPEG-4 out was 320x240.

A web search will bring up C++ template code for the algorithm.

Gerald> ----- Original Message -----

From: sdl-bounces+gbr=majentis.com@libsdl.org
[mailto:sdl-bounces+gbr=majentis.com at libsdl.org] On Behalf Of David Olsen
Sent: Thursday, May 25, 2006 4:08 PM
To: A list for developers using the SDL library. (includesSDL-announce)
Subject: Re: [SDL] Surface scaling again.

Kevin,
I just noticed this post! I’ll tell you what I did, I did lots of digging
around on the net, found no pre-made solutions, and finally came up with
something that works well for me and my situation - loading images and
scaling them all before using them on-screen. It doesn’t work well with
real-time scaling, as it’s a little slow, though for typical sprite-sized
images, it’s pretty quick. What I ended up doing was scrapping the SMS
emulator B-spline implementation(which worked, but didn’t produce as sharp
an image as I would have liked.) and modified a grayscale resizing function
from “Graphics Gems”, published like back in the mid- or early ninties.
Anyway, allow me to clean up the code just a little bit, and I’ll post a
link to it.

The “library” basically is called by functions where you pass in a
SDL_Surface *, and the new size you want(either in exact x,y sizes, or a
percentage/float), and it returns the new image, optimized for the current
screen format. It actually has several options for quality vs. speed,
different interpolation techniques. I’m happy to say that it gives really
quite good results when shrinking images, which is what I was looking for
back in December. Oh, yeah, it automatically handles alpha, too. I can’t
vouch for the common pixel formats beyond 32-bit, but I think I made it so
that it converts first to 32-bit, does all the calculations, then converts
back to screen format. I know it works just fine with 16 and 32 bit images -

might have problems with 8-bit, might not.

Okay, off to the IDE for some cleanup of code. I’ll post a link soon.
-David Olsen

----- Original Message -----
From: kevinmb500@gawab.com (Kevin Baragona)
To:
Sent: Tuesday, May 23, 2006 7:04 PM
Subject: [SDL] Surface scaling again.

I have the same problem that David Olsen did here:
libsdl.org/pipermail/sdl/2005-December/071786.html. I need a scaling
function to implement resolution-independent sprites and the obvious
"make things bigger" effect. Right now I have rotozoom statically linked
into my project, but, as he mentioned, it uses ugly integer division
when downscaling. Given that the images will be downscaled on most
screens, I find this unacceptable. So, what I need is basically a
function that will handle at least bilinear scaling, alpha channels, and
hopefully all the common pixel formats.

That thread seems to have left off with him hacking the code from that
Sega emulator to handle more pixel formats and alpha channels. AFAIK he
hasn’t posted the code anywhere for we freeloaders to use and love. With
a 7th grade education under my belt, I’m not quite capable of even
understanding how that function from SMS+SDL operates, much less hack it
to use alpha (which I need). My question is, does anyone here have a
scaling function that 1) handles common pixel formats 2) uses at least
bilinear interpolation even when downscaling 3) handles alpha channels
and 4) that you want to give away?

Thanks,
Me.

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

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

4

That sounds great, however, my (soon to made puclicly avaliable) "library"
has bicubic as a “middle quality” option. The Lanczos3 filter is slow, but
gives truly fantastic results, especially when down-sizing. Plus, it will be
something that people can just drop in and use with a simple #include
statement…

That came across somewhat negatively, sorry. I encountered many fast
algorithms during my weeks of searching, and none of them gave me the
quality I wanted. (I wanted quality over speed. Seems like Kevin is looking
for that too.)

Anyway, I’m cleaning up the library right now. I’m having to extract all of
the SMS b_spline junk that was left over, which I don’t use any more.

Back to the grind! (Oh, and the Graphics Gems code was from 1999, so, not
early ninties, but rather late nineties.)
-David Olsen> ----- Original Message -----

From: gbr@majentis.com (Gerald Brandt)
To: "‘A list for developers using the SDL library. (includesSDL-announce)’"

Sent: Thursday, May 25, 2006 4:22 PM
Subject: Re: [SDL] Surface scaling again.

I’ve had exceptional luck with the Bresenham resize. It gives almost
bicubic quality, and I’ve done 640x480 images in realtime. To me,
realtime
is decoding MPEG-2 in, resizing, and encoding MPEG-4 out. If I remember
correctly, my MPEG-2 in was 720x480 and my MPEG-4 out was 320x240.

A web search will bring up C++ template code for the algorithm.

Gerald

-----Original Message-----
From: sdl-bounces+gbr=majentis.com at libsdl.org
[mailto:sdl-bounces+gbr=majentis.com at libsdl.org] On Behalf Of David Olsen
Sent: Thursday, May 25, 2006 4:08 PM
To: A list for developers using the SDL library. (includesSDL-announce)
Subject: Re: [SDL] Surface scaling again.

Kevin,
I just noticed this post! I’ll tell you what I did, I did lots of digging
around on the net, found no pre-made solutions, and finally came up with
something that works well for me and my situation - loading images and
scaling them all before using them on-screen. It doesn’t work well with
real-time scaling, as it’s a little slow, though for typical sprite-sized
images, it’s pretty quick. What I ended up doing was scrapping the SMS
emulator B-spline implementation(which worked, but didn’t produce as sharp
an image as I would have liked.) and modified a grayscale resizing
function
from “Graphics Gems”, published like back in the mid- or early ninties.
Anyway, allow me to clean up the code just a little bit, and I’ll post a
link to it.

The “library” basically is called by functions where you pass in a
SDL_Surface *, and the new size you want(either in exact x,y sizes, or a
percentage/float), and it returns the new image, optimized for the current
screen format. It actually has several options for quality vs. speed,
different interpolation techniques. I’m happy to say that it gives really
quite good results when shrinking images, which is what I was looking for
back in December. Oh, yeah, it automatically handles alpha, too. I can’t
vouch for the common pixel formats beyond 32-bit, but I think I made it so
that it converts first to 32-bit, does all the calculations, then converts
back to screen format. I know it works just fine with 16 and 32 bit
images -

might have problems with 8-bit, might not.

Okay, off to the IDE for some cleanup of code. I’ll post a link soon.
-David Olsen

----- Original Message -----
From: “Kevin Baragona”
To:
Sent: Tuesday, May 23, 2006 7:04 PM
Subject: [SDL] Surface scaling again.

I have the same problem that David Olsen did here:
libsdl.org/pipermail/sdl/2005-December/071786.html. I need a scaling
function to implement resolution-independent sprites and the obvious
"make things bigger" effect. Right now I have rotozoom statically linked
into my project, but, as he mentioned, it uses ugly integer division
when downscaling. Given that the images will be downscaled on most
screens, I find this unacceptable. So, what I need is basically a
function that will handle at least bilinear scaling, alpha channels, and
hopefully all the common pixel formats.

That thread seems to have left off with him hacking the code from that
Sega emulator to handle more pixel formats and alpha channels. AFAIK he
hasn’t posted the code anywhere for we freeloaders to use and love. With
a 7th grade education under my belt, I’m not quite capable of even
understanding how that function from SMS+SDL operates, much less hack it
to use alpha (which I need). My question is, does anyone here have a
scaling function that 1) handles common pixel formats 2) uses at least
bilinear interpolation even when downscaling 3) handles alpha channels
and 4) that you want to give away?

Thanks,
Me.

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

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

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

5

Sounds great! I’m looking forward to your code! It would be great to
have it added to SDL libraries page, for all to use.On Thu, 2006-05-25 at 16:07 -0500, David Olsen wrote:

Kevin,
I just noticed this post! I’ll tell you what I did, I did lots of digging
around on the net, found no pre-made solutions, and finally came up with
something that works well for me and my situation - loading images and
scaling them all before using them on-screen. It doesn’t work well with
real-time scaling, as it’s a little slow, though for typical sprite-sized
images, it’s pretty quick. What I ended up doing was scrapping the SMS
emulator B-spline implementation(which worked, but didn’t produce as sharp
an image as I would have liked.) and modified a grayscale resizing function
from “Graphics Gems”, published like back in the mid- or early ninties.
Anyway, allow me to clean up the code just a little bit, and I’ll post a
link to it.

The “library” basically is called by functions where you pass in a
SDL_Surface *, and the new size you want(either in exact x,y sizes, or a
percentage/float), and it returns the new image, optimized for the current
screen format. It actually has several options for quality vs. speed,
different interpolation techniques. I’m happy to say that it gives really
quite good results when shrinking images, which is what I was looking for
back in December. Oh, yeah, it automatically handles alpha, too. I can’t
vouch for the common pixel formats beyond 32-bit, but I think I made it so
that it converts first to 32-bit, does all the calculations, then converts
back to screen format. I know it works just fine with 16 and 32 bit images -
might have problems with 8-bit, might not.

Okay, off to the IDE for some cleanup of code. I’ll post a link soon.
-David Olsen

----- Original Message -----
From: “Kevin Baragona” <@Kevin_Baragona>
To:
Sent: Tuesday, May 23, 2006 7:04 PM
Subject: [SDL] Surface scaling again.

I have the same problem that David Olsen did here:
libsdl.org/pipermail/sdl/2005-December/071786.html. I need a scaling
function to implement resolution-independent sprites and the obvious
"make things bigger" effect. Right now I have rotozoom statically linked
into my project, but, as he mentioned, it uses ugly integer division
when downscaling. Given that the images will be downscaled on most
screens, I find this unacceptable. So, what I need is basically a
function that will handle at least bilinear scaling, alpha channels, and
hopefully all the common pixel formats.

That thread seems to have left off with him hacking the code from that
Sega emulator to handle more pixel formats and alpha channels. AFAIK he
hasn’t posted the code anywhere for we freeloaders to use and love. With
a 7th grade education under my belt, I’m not quite capable of even
understanding how that function from SMS+SDL operates, much less hack it
to use alpha (which I need). My question is, does anyone here have a
scaling function that 1) handles common pixel formats 2) uses at least
bilinear interpolation even when downscaling 3) handles alpha channels
and 4) that you want to give away?

Thanks,
Me.

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

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

    This signature intentionally left not blank.

My new password is glauwie. Of course it could have been tweelk, criw,
or poote just as well.

6

Okay Kevin (and anyone else who’s interested),
I put my image resizing library on the SDL libaries page, you can search for
"Resize". I hope that you find it useful. Please let me know if it fits the
bill. Also if you find any bugs, etc.
Here’s a direct link, as well: http://members.cox.net/dolsen6/resize.zip

Silly me, when I submitted it, in the name category, I put my name, not
realizing that it meant the name of the library, so in the News section, it
says “David Olsen, Image resizing library, high quality output suited for
prerendering images, has been added to the libraries page.” Oops!

I have since changed the name to SDL_Resize, but how do I fix the news item?
Thanks!
-David Olsen> ----- Original Message -----

From: kevinmb500@gawab.com (Kevin Baragona)
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Thursday, May 25, 2006 6:08 PM
Subject: Re: [SDL] Surface scaling again.

Sounds great! I’m looking forward to your code! It would be great to
have it added to SDL libraries page, for all to use.

On Thu, 2006-05-25 at 16:07 -0500, David Olsen wrote:

Kevin,
I just noticed this post! I’ll tell you what I did, I did lots of digging
around on the net, found no pre-made solutions, and finally came up with
something that works well for me and my situation - loading images and
scaling them all before using them on-screen. It doesn’t work well with
real-time scaling, as it’s a little slow, though for typical sprite-sized
images, it’s pretty quick. What I ended up doing was scrapping the SMS
emulator B-spline implementation(which worked, but didn’t produce as
sharp
an image as I would have liked.) and modified a grayscale resizing
function
from “Graphics Gems”, published like back in the mid- or early ninties.
Anyway, allow me to clean up the code just a little bit, and I’ll post a
link to it.

The “library” basically is called by functions where you pass in a
SDL_Surface *, and the new size you want(either in exact x,y sizes, or a
percentage/float), and it returns the new image, optimized for the
current
screen format. It actually has several options for quality vs. speed,
different interpolation techniques. I’m happy to say that it gives really
quite good results when shrinking images, which is what I was looking for
back in December. Oh, yeah, it automatically handles alpha, too. I can’t
vouch for the common pixel formats beyond 32-bit, but I think I made it
so
that it converts first to 32-bit, does all the calculations, then
converts
back to screen format. I know it works just fine with 16 and 32 bit
images -
might have problems with 8-bit, might not.

Okay, off to the IDE for some cleanup of code. I’ll post a link soon.
-David Olsen

----- Original Message -----
From: “Kevin Baragona”
To:
Sent: Tuesday, May 23, 2006 7:04 PM
Subject: [SDL] Surface scaling again.

I have the same problem that David Olsen did here:
libsdl.org/pipermail/sdl/2005-December/071786.html. I need a scaling
function to implement resolution-independent sprites and the obvious
"make things bigger" effect. Right now I have rotozoom statically
linked
into my project, but, as he mentioned, it uses ugly integer division
when downscaling. Given that the images will be downscaled on most
screens, I find this unacceptable. So, what I need is basically a
function that will handle at least bilinear scaling, alpha channels,
and
hopefully all the common pixel formats.

That thread seems to have left off with him hacking the code from that
Sega emulator to handle more pixel formats and alpha channels. AFAIK he
hasn’t posted the code anywhere for we freeloaders to use and love.
With
a 7th grade education under my belt, I’m not quite capable of even
understanding how that function from SMS+SDL operates, much less hack
it
to use alpha (which I need). My question is, does anyone here have a
scaling function that 1) handles common pixel formats 2) uses at least
bilinear interpolation even when downscaling 3) handles alpha channels
and 4) that you want to give away?

Thanks,
Me.

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

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

   This signature intentionally left not blank.

My new password is glauwie. Of course it could have been tweelk, criw,
or poote just as well.

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

7

Bresenham coming close to bicubic quality ? Errrrr… not very likely.

For whole pixel bresenham, I don’t see this happening… But if you use the
bresenham error term to figure out an alpha/mix ratio for the
under/overflow… then perhaps. It’s still fairly single dimentional in
application, unless you make two passes over the surface…

Bresenham or fixed point resize should give decent-enough scaling with a
good enough speed for ‘real time’ use, tho…

-WillOn 5/25/06, Gerald Brandt wrote:

I’ve had exceptional luck with the Bresenham resize. It gives almost
bicubic quality, and I’ve done 640x480 images in realtime. To me,
realtime
is decoding MPEG-2 in, resizing, and encoding MPEG-4 out. If I remember
correctly, my MPEG-2 in was 720x480 and my MPEG-4 out was 320x240.

A web search will bring up C++ template code for the algorithm.

Gerald

-----Original Message-----
From: sdl-bounces+gbr=majentis.com at libsdl.org
[mailto:sdl-bounces+gbr=majentis.com at libsdl.org] On Behalf Of David Olsen
Sent: Thursday, May 25, 2006 4:08 PM
To: A list for developers using the SDL library. (includesSDL-announce)
Subject: Re: [SDL] Surface scaling again.

Kevin,
I just noticed this post! I’ll tell you what I did, I did lots of digging
around on the net, found no pre-made solutions, and finally came up with
something that works well for me and my situation - loading images and
scaling them all before using them on-screen. It doesn’t work well with
real-time scaling, as it’s a little slow, though for typical sprite-sized
images, it’s pretty quick. What I ended up doing was scrapping the SMS
emulator B-spline implementation(which worked, but didn’t produce as sharp
an image as I would have liked.) and modified a grayscale resizing
function
from “Graphics Gems”, published like back in the mid- or early ninties.
Anyway, allow me to clean up the code just a little bit, and I’ll post a
link to it.

The “library” basically is called by functions where you pass in a
SDL_Surface *, and the new size you want(either in exact x,y sizes, or a
percentage/float), and it returns the new image, optimized for the current
screen format. It actually has several options for quality vs. speed,
different interpolation techniques. I’m happy to say that it gives really
quite good results when shrinking images, which is what I was looking for
back in December. Oh, yeah, it automatically handles alpha, too. I can’t
vouch for the common pixel formats beyond 32-bit, but I think I made it so
that it converts first to 32-bit, does all the calculations, then converts
back to screen format. I know it works just fine with 16 and 32 bit images

might have problems with 8-bit, might not.

Okay, off to the IDE for some cleanup of code. I’ll post a link soon.
-David Olsen

----- Original Message -----
From: “Kevin Baragona”
To:
Sent: Tuesday, May 23, 2006 7:04 PM
Subject: [SDL] Surface scaling again.

I have the same problem that David Olsen did here:
libsdl.org/pipermail/sdl/2005-December/071786.html. I need a scaling
function to implement resolution-independent sprites and the obvious
"make things bigger" effect. Right now I have rotozoom statically linked
into my project, but, as he mentioned, it uses ugly integer division
when downscaling. Given that the images will be downscaled on most
screens, I find this unacceptable. So, what I need is basically a
function that will handle at least bilinear scaling, alpha channels, and
hopefully all the common pixel formats.

That thread seems to have left off with him hacking the code from that
Sega emulator to handle more pixel formats and alpha channels. AFAIK he
hasn’t posted the code anywhere for we freeloaders to use and love. With
a 7th grade education under my belt, I’m not quite capable of even
understanding how that function from SMS+SDL operates, much less hack it
to use alpha (which I need). My question is, does anyone here have a
scaling function that 1) handles common pixel formats 2) uses at least
bilinear interpolation even when downscaling 3) handles alpha channels
and 4) that you want to give away?

Thanks,
Me.

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

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

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

8

Okay Kevin (and anyone else who’s interested),
I put my image resizing library on the SDL libaries page, you can search for
"Resize". I hope that you find it useful. Please let me know if it fits the
bill. Also if you find any bugs, etc.
Here’s a direct link, as well: http://members.cox.net/dolsen6/resize.zip
The file is of length 0. Something’s seriously wrong! Oh, the pain of
not having access to code you really want!

Silly me, when I submitted it, in the name category, I put my name, not
realizing that it meant the name of the library, so in the News section, it
says “David Olsen, Image resizing library, high quality output suited for
prerendering images, has been added to the libraries page.” Oops!

I have since changed the name to SDL_Resize, but how do I fix the news item?
I’m guessing that you don’t! Maybe you can get someone to remove the
entry on the news page and add it again?On Thu, 2006-05-25 at 20:26 -0500, David Olsen wrote:
Thanks!
-David Olsen

----- Original Message -----
From: “Kevin Baragona” <@Kevin_Baragona>
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Thursday, May 25, 2006 6:08 PM
Subject: Re: [SDL] Surface scaling again.

Sounds great! I’m looking forward to your code! It would be great to
have it added to SDL libraries page, for all to use.

On Thu, 2006-05-25 at 16:07 -0500, David Olsen wrote:

Kevin,
I just noticed this post! I’ll tell you what I did, I did lots of digging
around on the net, found no pre-made solutions, and finally came up with
something that works well for me and my situation - loading images and
scaling them all before using them on-screen. It doesn’t work well with
real-time scaling, as it’s a little slow, though for typical sprite-sized
images, it’s pretty quick. What I ended up doing was scrapping the SMS
emulator B-spline implementation(which worked, but didn’t produce as
sharp
an image as I would have liked.) and modified a grayscale resizing
function
from “Graphics Gems”, published like back in the mid- or early ninties.
Anyway, allow me to clean up the code just a little bit, and I’ll post a
link to it.

The “library” basically is called by functions where you pass in a
SDL_Surface *, and the new size you want(either in exact x,y sizes, or a
percentage/float), and it returns the new image, optimized for the
current
screen format. It actually has several options for quality vs. speed,
different interpolation techniques. I’m happy to say that it gives really
quite good results when shrinking images, which is what I was looking for
back in December. Oh, yeah, it automatically handles alpha, too. I can’t
vouch for the common pixel formats beyond 32-bit, but I think I made it
so
that it converts first to 32-bit, does all the calculations, then
converts
back to screen format. I know it works just fine with 16 and 32 bit
images -
might have problems with 8-bit, might not.

Okay, off to the IDE for some cleanup of code. I’ll post a link soon.
-David Olsen

----- Original Message -----
From: “Kevin Baragona” <@Kevin_Baragona>
To:
Sent: Tuesday, May 23, 2006 7:04 PM
Subject: [SDL] Surface scaling again.

I have the same problem that David Olsen did here:
libsdl.org/pipermail/sdl/2005-December/071786.html. I need a scaling
function to implement resolution-independent sprites and the obvious
"make things bigger" effect. Right now I have rotozoom statically
linked
into my project, but, as he mentioned, it uses ugly integer division
when downscaling. Given that the images will be downscaled on most
screens, I find this unacceptable. So, what I need is basically a
function that will handle at least bilinear scaling, alpha channels,
and
hopefully all the common pixel formats.

That thread seems to have left off with him hacking the code from that
Sega emulator to handle more pixel formats and alpha channels. AFAIK he
hasn’t posted the code anywhere for we freeloaders to use and love.
With
a 7th grade education under my belt, I’m not quite capable of even
understanding how that function from SMS+SDL operates, much less hack
it
to use alpha (which I need). My question is, does anyone here have a
scaling function that 1) handles common pixel formats 2) uses at least
bilinear interpolation even when downscaling 3) handles alpha channels
and 4) that you want to give away?

Thanks,
Me.

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

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

   This signature intentionally left not blank.

My new password is glauwie. Of course it could have been tweelk, criw,
or poote just as well.

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

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

    I have just set a new personal record. I am the oldest I have
    ever been.

My new password is braufie. Of course it could have been praug, zaufie,
or blauw just as well.

9

Okay, the link is fixed. Sorry, when I uploaded it to my web-space, I didn’t
realize it hadn’t uploaded all the way. Let me know if there are any more
problems!
(And, yes, I guess I’ll email someone like Ryan or Sam, to see if they can
fix the funny name issue, unless they happen to see this here and do
something about it!)
-David Olsen> ----- Original Message -----

From: kevinmb500@gawab.com (Kevin Baragona)
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Thursday, May 25, 2006 9:19 PM
Subject: Re: [SDL] Surface scaling again.

On Thu, 2006-05-25 at 20:26 -0500, David Olsen wrote:

Okay Kevin (and anyone else who’s interested),
I put my image resizing library on the SDL libaries page, you can search
for
"Resize". I hope that you find it useful. Please let me know if it fits
the
bill. Also if you find any bugs, etc.
Here’s a direct link, as well: http://members.cox.net/dolsen6/resize.zip
The file is of length 0. Something’s seriously wrong! Oh, the pain of
not having access to code you really want!

Silly me, when I submitted it, in the name category, I put my name, not
realizing that it meant the name of the library, so in the News section,
it
says “David Olsen, Image resizing library, high quality output suited for
prerendering images, has been added to the libraries page.” Oops!

I have since changed the name to SDL_Resize, but how do I fix the news
item?
I’m guessing that you don’t! Maybe you can get someone to remove the
entry on the news page and add it again?
Thanks!
-David Olsen

----- Original Message -----
From: “Kevin Baragona”
To: "A list for developers using the SDL library. (includes
SDL-announce)"

Sent: Thursday, May 25, 2006 6:08 PM
Subject: Re: [SDL] Surface scaling again.

Sounds great! I’m looking forward to your code! It would be great to
have it added to SDL libraries page, for all to use.

On Thu, 2006-05-25 at 16:07 -0500, David Olsen wrote:

Kevin,
I just noticed this post! I’ll tell you what I did, I did lots of
digging
around on the net, found no pre-made solutions, and finally came up
with
something that works well for me and my situation - loading images and
scaling them all before using them on-screen. It doesn’t work well
with
real-time scaling, as it’s a little slow, though for typical
sprite-sized
images, it’s pretty quick. What I ended up doing was scrapping the SMS
emulator B-spline implementation(which worked, but didn’t produce as
sharp
an image as I would have liked.) and modified a grayscale resizing
function
from “Graphics Gems”, published like back in the mid- or early
ninties.
Anyway, allow me to clean up the code just a little bit, and I’ll post
a
link to it.

The “library” basically is called by functions where you pass in a
SDL_Surface *, and the new size you want(either in exact x,y sizes, or
a
percentage/float), and it returns the new image, optimized for the
current
screen format. It actually has several options for quality vs. speed,
different interpolation techniques. I’m happy to say that it gives
really
quite good results when shrinking images, which is what I was looking
for
back in December. Oh, yeah, it automatically handles alpha, too. I
can’t
vouch for the common pixel formats beyond 32-bit, but I think I made
it
so
that it converts first to 32-bit, does all the calculations, then
converts
back to screen format. I know it works just fine with 16 and 32 bit
images -
might have problems with 8-bit, might not.

Okay, off to the IDE for some cleanup of code. I’ll post a link soon.
-David Olsen

----- Original Message -----
From: “Kevin Baragona”
To:
Sent: Tuesday, May 23, 2006 7:04 PM
Subject: [SDL] Surface scaling again.

I have the same problem that David Olsen did here:
libsdl.org/pipermail/sdl/2005-December/071786.html. I need a scaling
function to implement resolution-independent sprites and the obvious
"make things bigger" effect. Right now I have rotozoom statically
linked
into my project, but, as he mentioned, it uses ugly integer division
when downscaling. Given that the images will be downscaled on most
screens, I find this unacceptable. So, what I need is basically a
function that will handle at least bilinear scaling, alpha channels,
and
hopefully all the common pixel formats.

That thread seems to have left off with him hacking the code from
that
Sega emulator to handle more pixel formats and alpha channels. AFAIK
he
hasn’t posted the code anywhere for we freeloaders to use and love.
With
a 7th grade education under my belt, I’m not quite capable of even
understanding how that function from SMS+SDL operates, much less
hack
it
to use alpha (which I need). My question is, does anyone here have a
scaling function that 1) handles common pixel formats 2) uses at
least
bilinear interpolation even when downscaling 3) handles alpha
channels
and 4) that you want to give away?

Thanks,
Me.

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

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

   This signature intentionally left not blank.

My new password is glauwie. Of course it could have been tweelk, criw,
or poote just as well.

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

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

   I have just set a new personal record. I am the oldest I have
   ever been.

My new password is braufie. Of course it could have been praug, zaufie,
or blauw just as well.

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