Image resizing and SDL_gfx

I need code that will take a 1024x768 SDL surface and convert it to a
640x480, 800x600, or 1200x1024 SDL surface. Basically all I want to do
is blit images to a virtual 1024x768 screen surface and if the user
requests a different resolution I can just re-size that virtual screen
surface before flipping the buffer to the screen. After looking around I
discovered the rotozoom function in the SDL_gfx library, but I decided
rather than require another dependant library on my program I’ll just
take the code snippet that I need and modify it to fit my own needs
(Plus SDL_gfx isn’t supported on very many platforms). After looking at
the code, I found that zooming is only supported for 8-bpp and 32-bpp
surfaces. So I have the following questions:

  1. I don’t know a lot about monitors/resolutions, but how likely is it
    that a monitor doesn’t support 32-bpp?

  2. Is there a better solution for my image resizing needs than SDL_gfx’s
    rotozoom function?

The program in question is a 2D RPG game I’m developing. I want it to be
as platform-independant as possible and be able to work well even on
slower machines. Thanks for any help you can give.—
Tyler Olsen - Lead Developer
Hero of Allacrost: http://www.allacrost.org

Tyler Olsen wrote:

  1. I don’t know a lot about monitors/resolutions, but how likely is it
    that a monitor doesn’t support 32-bpp?

colordepth does not really depend on the monitor, but on the gfx card
(videomemory). though monitor do have a bandwidth limit that is reached
sooner with more colors enabled. so every monitor i know of, supports
32bit as long as vertical/horizontal frequenzy does not excede a certain
limit.

  1. Is there a better solution for my image resizing needs than
    SDL_gfx’s rotozoom function?

that rotozoom does only support 8 and 32 bit images should not bother
you. you can just blit your 32 bit surface to the one you created in the
desired colordepth and free the old one.

no big deal …
clemens

Ok, but if I don’t use 32-bpp surfaces then rotozoom has to do a
conversion which will cause a slowdown. Not sure if the slowdown would
be noticable to the user or not, but yeah whatever. Do you have any
recommendations on what bpp I should call SDL_SetVideoMode with? I feel
embarassed but I’m such a n00b with graphics programming I can’t help it
:slight_smile: Thanks.

I need code that will take a 1024x768 SDL surface and convert it to a
640x480, 800x600, or 1200x1024 SDL surface. Basically all I want to do
is blit images to a virtual 1024x768 screen surface and if the user
requests a different resolution I can just re-size that virtual screen
surface before flipping the buffer to the screen. After looking around
I discovered the rotozoom function in the SDL_gfx library, but I
decided rather than require another dependant library on my program
I’ll just take the code snippet that I need and modify it to fit my
own needs (Plus SDL_gfx isn’t supported on very many platforms). After
looking at the code, I found that zooming is only supported for 8-bpp
and 32-bpp surfaces. So I have the following questions:

  1. I don’t know a lot about monitors/resolutions, but how likely is it
    that a monitor doesn’t support 32-bpp?

  2. Is there a better solution for my image resizing needs than
    SDL_gfx’s rotozoom function?

The program in question is a 2D RPG game I’m developing. I want it to
be as platform-independant as possible and be able to work well even
on slower machines. Thanks for any help you can give.


Tyler Olsen - Lead Developer
Hero of Allacrost: http://www.allacrost.org

I have run into the same problem with SDL. This issue can be easily
solved if you are using openGL with SDL but if you are using pure software
blitting, you don’t want to be doing a stretch blit in software every
frame and besides, it would look exactly the same without some sort of
filtering. What you might want to consider though is maybe reloading all
of your images scaled proportionally to the new resolution but also you
have to abstract your screen to the concept of a viewport which is
resolution independant (eg opengl style) then you blit images into your
viewport space and inside your rendering function it would translate the
viewport coords to resolution dependant coords. You’d still need a
stretchblit function for this though :stuck_out_tongue:

  • Will

so you want your game to run on slower machines?

in 2d?
with first drawing to a 1024x768 surface and then software scaling it
to 640x480.

i don’t think you will get a decent framerate.

even on a 1800+ w/ 256 mb sd ram.

when working with software functions (this is what sdl and directdraw
does most of the time (not speaking of other platforms)) the cpu and ram
is the biggest limiter.

and getting a decent framerate at 1024x768 is already a problem for fast
pcs (when having sd ram). ddr ram works a lot faster, but most low level
machines won’t have it.

and software scaling every frame to another (maybe even bigger)
resolution will most probably be far too much for almost every pc you
target.

i don’t know which hardware your aiming at, but with software functions
i won’t go beyong 1024x768.
and i think scaling will give you a slowdown of min 50%? (minimum when
scaling to 640x480 (1.5x blitting the screen), and not taking the scale
calculations into account).

i don’t think what you want is possible.
unless you use 3d accelartors.
or smaller resolutions without scaling

Tyler Olsen wrote:> I need code that will take a 1024x768 SDL surface and convert it to a

640x480, 800x600, or 1200x1024 SDL surface. Basically all I want to do
is blit images to a virtual 1024x768 screen surface and if the user
requests a different resolution I can just re-size that virtual screen
surface before flipping the buffer to the screen. After looking around I
discovered the rotozoom function in the SDL_gfx library, but I decided
rather than require another dependant library on my program I’ll just
take the code snippet that I need and modify it to fit my own needs
(Plus SDL_gfx isn’t supported on very many platforms). After looking at
the code, I found that zooming is only supported for 8-bpp and 32-bpp
surfaces. So I have the following questions:

  1. I don’t know a lot about monitors/resolutions, but how likely is it
    that a monitor doesn’t support 32-bpp?

  2. Is there a better solution for my image resizing needs than SDL_gfx’s
    rotozoom function?

The program in question is a 2D RPG game I’m developing. I want it to be
as platform-independant as possible and be able to work well even on
slower machines. Thanks for any help you can give.


Tyler Olsen - Lead Developer
Hero of Allacrost: http://www.allacrost.org


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

You will expering a very LARGE slowdown if you attempt this. If you
notice in the SDL documentation they always advise you to make sure
that the screen surface is the same resolution as the surface you blit
onto it, to make sure that SDL doesn’t have to convert. Just to give
you an idea, a friend of mine wrote a Pong game, that on a Pentium 3
800mhz laptop ran at about 300fps (when the surface’s were the same
resolution); if he changed the resolution of the screen to be
different than the surfaces of the images he blit, it droped to 12fps.

If your really want to do something like this, you’re better off using
OpenGL to draw your 2D graphics, and then using the hardware
acceleration of the video card (if present). However, less machines
will support OpenGL hardware acceleration than those able to handle
SDL in 2D mode.

I should mention that using a 3D API (like OpenGL) for 2D games has
now become quite popular because it gives you access to things that
are quite difficult to do with a 2D API (true alpha blending,
lighting, cell shading) just to name a few.

Well, I hope this helps. Good luck with your game!

Regards,

Johnathan Gurley> > I need code that will take a 1024x768 SDL surface and convert it to a

640x480, 800x600, or 1200x1024 SDL surface. Basically all I want to do
is blit images to a virtual 1024x768 screen surface and if the user
requests a different resolution I can just re-size that virtual screen
surface before flipping the buffer to the screen. After looking around I
discovered the rotozoom function in the SDL_gfx library, but I decided
rather than require another dependant library on my program I’ll just
take the code snippet that I need and modify it to fit my own needs
(Plus SDL_gfx isn’t supported on very many platforms). After looking at
the code, I found that zooming is only supported for 8-bpp and 32-bpp
surfaces. So I have the following questions:

  1. I don’t know a lot about monitors/resolutions, but how likely is it
    that a monitor doesn’t support 32-bpp?

  2. Is there a better solution for my image resizing needs than SDL_gfx’s
    rotozoom function?

The program in question is a 2D RPG game I’m developing. I want it to be
as platform-independant as possible and be able to work well even on
slower machines. Thanks for any help you can give.


Tyler Olsen - Lead Developer
Hero of Allacrost: http://www.allacrost.org


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

in the docu they mean bpp, not resolution, but you’re right with the
large slowdown.

Johnathan Gurley wrote:> You will expering a very LARGE slowdown if you attempt this. If you

notice in the SDL documentation they always advise you to make sure
that the screen surface is the same resolution as the surface you blit
onto it, to make sure that SDL doesn’t have to convert. Just to give
you an idea, a friend of mine wrote a Pong game, that on a Pentium 3
800mhz laptop ran at about 300fps (when the surface’s were the same
resolution); if he changed the resolution of the screen to be
different than the surfaces of the images he blit, it droped to 12fps.

If your really want to do something like this, you’re better off using
OpenGL to draw your 2D graphics, and then using the hardware
acceleration of the video card (if present). However, less machines
will support OpenGL hardware acceleration than those able to handle
SDL in 2D mode.

I should mention that using a 3D API (like OpenGL) for 2D games has
now become quite popular because it gives you access to things that
are quite difficult to do with a 2D API (true alpha blending,
lighting, cell shading) just to name a few.

Well, I hope this helps. Good luck with your game!

Regards,

Johnathan Gurley

I need code that will take a 1024x768 SDL surface and convert it to a
640x480, 800x600, or 1200x1024 SDL surface. Basically all I want to do
is blit images to a virtual 1024x768 screen surface and if the user
requests a different resolution I can just re-size that virtual screen
surface before flipping the buffer to the screen. After looking around I
discovered the rotozoom function in the SDL_gfx library, but I decided
rather than require another dependant library on my program I’ll just
take the code snippet that I need and modify it to fit my own needs
(Plus SDL_gfx isn’t supported on very many platforms). After looking at
the code, I found that zooming is only supported for 8-bpp and 32-bpp
surfaces. So I have the following questions:

  1. I don’t know a lot about monitors/resolutions, but how likely is it
    that a monitor doesn’t support 32-bpp?

  2. Is there a better solution for my image resizing needs than SDL_gfx’s
    rotozoom function?

The program in question is a 2D RPG game I’m developing. I want it to be
as platform-independant as possible and be able to work well even on
slower machines. Thanks for any help you can give.


Tyler Olsen - Lead Developer
Hero of Allacrost: http://www.allacrost.org


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

Oh wow, I’m glad I made this post then. I never expected that kind of
slowdown would occur (dammit, I knew I should have taken that computer
graphics course in college!). Well you all have my thanks for pointing
out the errors of my ways; You’ve saved me a lot of time and frustration
:slight_smile: I will definitely look into using OpenGL for my graphics. I thought
that was just for use with applications that use 3D imaging. Alright
well thanks again!—
Tyler Olsen - Lead Developer
Hero of Allacrost: http://www.allacrost.org

Johnathan Gurley wrote:

You will expering a very LARGE slowdown if you attempt this. If you
notice in the SDL documentation they always advise you to make sure
that the screen surface is the same resolution as the surface you blit
onto it, to make sure that SDL doesn’t have to convert. Just to give
you an idea, a friend of mine wrote a Pong game, that on a Pentium 3
800mhz laptop ran at about 300fps (when the surface’s were the same
resolution); if he changed the resolution of the screen to be
different than the surfaces of the images he blit, it droped to 12fps.

If your really want to do something like this, you’re better off using
OpenGL to draw your 2D graphics, and then using the hardware
acceleration of the video card (if present). However, less machines
will support OpenGL hardware acceleration than those able to handle
SDL in 2D mode.

I should mention that using a 3D API (like OpenGL) for 2D games has
now become quite popular because it gives you access to things that
are quite difficult to do with a 2D API (true alpha blending,
lighting, cell shading) just to name a few.

Well, I hope this helps. Good luck with your game!

Regards,

Johnathan Gurley

I need code that will take a 1024x768 SDL surface and convert it to a
640x480, 800x600, or 1200x1024 SDL surface. Basically all I want to do
is blit images to a virtual 1024x768 screen surface and if the user
requests a different resolution I can just re-size that virtual screen
surface before flipping the buffer to the screen. After looking around I
discovered the rotozoom function in the SDL_gfx library, but I decided
rather than require another dependant library on my program I’ll just
take the code snippet that I need and modify it to fit my own needs
(Plus SDL_gfx isn’t supported on very many platforms). After looking at
the code, I found that zooming is only supported for 8-bpp and 32-bpp
surfaces. So I have the following questions:

  1. I don’t know a lot about monitors/resolutions, but how likely is it
    that a monitor doesn’t support 32-bpp?

  2. Is there a better solution for my image resizing needs than SDL_gfx’s
    rotozoom function?

The program in question is a 2D RPG game I’m developing. I want it to be
as platform-independant as possible and be able to work well even on
slower machines. Thanks for any help you can give.


Tyler Olsen - Lead Developer
Hero of Allacrost: http://www.allacrost.org


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

Tyler Olsen wrote:

Oh wow, I’m glad I made this post then. I never expected that kind of
slowdown would occur (dammit, I knew I should have taken that computer
graphics course in college!). Well you all have my thanks for pointing
out the errors of my ways; You’ve saved me a lot of time and
frustration :slight_smile: I will definitely look into using OpenGL for my
graphics. I thought that was just for use with applications that use
3D imaging. Alright well thanks again!

I have a patch that adds an SDL backend that does scaling through
OpenGL. You could look at the code to see how it works :
http://icps.u-strasbg.fr/~marchesin/sdl/sdl_glscale.patch
Note that scaling up the pictures is ok with respect to quality (it uses
bilinear interpolation), however scaling down can be a problem since
(like software methods) it only takes out some of the pixels which can
lead to some aliasing problems.

Stephane

I’m just starting to learn OpenGL through nehe.gamedev.net and
the SDL coversions at libsdl.org

I’m on tutorial #6 texture mapping. I’m wondering Should I free
the surface where I did? The texture still shows up if I do, so
does the origional code have a leak?

( I attached the code hoping it would be easier to read for you
guys, if that’s a bad idea, just say so )__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
-------------- next part --------------
A non-text attachment was scrubbed…
Name: tmp.cpp
Type: text/x-c++src
Size: 609 bytes
Desc: tmp.cpp
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040714/7123cf82/attachment.cpp

including source code?? your source code could have viruses!!

haha im jk (:

i free my surfaces just like your code does and it works great so i say
yeah, free it!> ----- Original Message -----

From: ninmonkeys@yahoo.com (jake b)
To:
Sent: Wednesday, July 14, 2004 1:03 PM
Subject: [SDL] SDL OpenGL should I free the surface?

I’m just starting to learn OpenGL through nehe.gamedev.net and
the SDL coversions at libsdl.org

I’m on tutorial #6 texture mapping. I’m wondering Should I free
the surface where I did? The texture still shows up if I do, so
does the origional code have a leak?

( I attached the code hoping it would be easier to read for you
guys, if that’s a bad idea, just say so )


Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail



bool LoadGLTextures(void)
{
//load texture
SDL_Surface *image1;
image1 = LoadBMP(“Data05/NeHe.bmp”);
if(!image1)
{
SDL_Quit();
return false;
}

//create texture
glGenTextures(1, &texture[0]);
glBindTexture(GL_TEXTURE_2D, texture[0]); //2d texture (x and y size)

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

glTexImage2D(GL_TEXTURE_2D, 0, 3, image1->w, image1->h, 0, GL_RGB,
GL_UNSIGNED_BYTE, image1->pixels);

//Here’s what I added:
SDL_FreeSurface(image1);

return true;
}




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

The glTexImage2D(); copies your image data from CMU-memory to GPU-memory
(some times reffered to as Texture memory, but don’t let that confuse you).
So if your not planning to use the surface for somethinge else you should
free it or it will leak.

/JakobOn Wed, 14 Jul 2004 13:03:42 -0700 (PDT), jake b wrote:

I’m just starting to learn OpenGL through nehe.gamedev.net and
the SDL coversions at libsdl.org

I’m on tutorial #6 texture mapping. I’m wondering Should I free
the surface where I did? The texture still shows up if I do, so
does the origional code have a leak?

( I attached the code hoping it would be easier to read for you
guys, if that’s a bad idea, just say so )


Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


Using Opera’s revolutionary e-mail client: http://www.opera.com/m2/

The glTexImage2D(); copies your image data from CMU-memory to
GPU-memory
(some times reffered to as Texture memory, but don’t let that
confuse you).

Is GPU my graphics card memory/video RAM and CMU is software
memory(RAM/swap)?

So if your not planning to use the surface for somethinge else
you should
free it or it will leak.

Does glTextImage2D() clean up afteritself or do I need to free
textures created using that?

Does OpenGL need cleanup at all? The source just has SDL_Quit()
after the program is done, no glQuit().

thanks,
–jake__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Quoth jake b , on 2004-07-14 13:51:29 -0700:

The glTexImage2D(); copies your image data from CMU-memory to
GPU-memory
(some times reffered to as Texture memory, but don’t let that
confuse you).

Is GPU my graphics card memory/video RAM and CMU is software
memory(RAM/swap)?

Generally speaking, yes. (I’m assuming the original poster meant "CPU"
rather than “CMU”.) These are also known as “video memory” and “system
memory”.

So if your not planning to use the surface for somethinge else
you should
free it or it will leak.

Does glTextImage2D() clean up afteritself or do I need to free
textures created using that?

glTexImage2D replaces the image in the current GL_TEXTURE_2D object.
If you don’t switch texture objects with glBindTexture (including if you
never bind any texture object at all), the next image will replace the
current one in texture memory, and the current one will be discarded.
Images that are bound to texture objects stick around until they are
replaced or until the objects are deleted with glDeleteTextures.

Does OpenGL need cleanup at all? The source just has SDL_Quit()
after the program is done, no glQuit().

There is no glQuit(), just like there’s no glInit(). There’s
usually platform-specific OpenGL context deconstruction that has to be
done, but that’s all handled by the SDL video driver when you
SDL_Quit(), so you don’t have to worry about it.

—> Drake Wilson
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040714/a8fe045a/attachment.pgp

replaced or until the objects are deleted with
glDeleteTextures.

And

There is no glQuit(), just like there’s no glInit(). There’s
usually platform-specific OpenGL context deconstruction that
has to be
done, but that’s all handled by the SDL video driver when you
SDL_Quit(), so you don’t have to worry about it.

So if i’m using SDL and use glTexImage2D() I do not need to use
glDeleteTextures()?

I thought it was weird that the glTexImage2D() man page see also
did not have glDeleteTextures(), but the glDeleteTextures()
man page see also does have glTexImage2D()…__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Quoth jake b , on 2004-07-14 14:32:53 -0700:

replaced or until the objects are deleted with
glDeleteTextures.

And

There is no glQuit(), just like there’s no glInit(). There’s
usually platform-specific OpenGL context deconstruction that
has to be
done, but that’s all handled by the SDL video driver when you
SDL_Quit(), so you don’t have to worry about it.

So if i’m using SDL and use glTexImage2D() I do not need to use
glDeleteTextures()?

All the texture memory in an OpenGL context is generally freed when
the context is destroyed, so it’s as though an implicit glDeleteTextures
were called on every existing texture object. At least, if the
OpenGL implementation is sane, it should work this way; I’m not sure
whether the spec actually requires it or not.

I thought it was weird that the glTexImage2D() man page see also
did not have glDeleteTextures(), but the glDeleteTextures()
man page see also does have glTexImage2D()…

glDeleteTextures only makes sense after creating texture objects with
glBindTexture. If you never glBindTexture, you need never
glDeleteTextures; also, if you want the texture objects to all stay alive
until the context disappears, you need never glDeleteTextures. The usual
sequence for using an OpenGL texture object is approximately:

  • Use glGenTextures to allocate a name for the object.
  • Use glBindTexture to switch to it.
  • Use glTexImage2D, glTexParameteri, etc. to set up the contents of
    the object.
  • Later, use glBindTexture again to switch to it and have the contents
    made available for texturing following primitives.
  • Use glDeleteTextures to erase the texture object when it will no
    longer be used.

One can also allocate multiple texture object names at once, or delete
multiple texture objects at once.

The last step should, again, be performed implicitly by the context
destruction that happens as part of SDL_Quit().

—> Drake Wilson
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040714/b1605666/attachment.pgp

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Wednesday 14 July 2004 23:32, jake b wrote:

I thought it was weird that the glTexImage2D() man page see also
did not have glDeleteTextures(), but the glDeleteTextures()
man page see also does have glTexImage2D()…

That’s because texture objects in OpenGL are a little weird. The original
OpenGL 1.0 didn’t have texture objects at all. Yes, this means you could
only have one texture “uploaded” at a time.

Texture objects were added as an extension that became part of the core
rather quickly (1.1 in fact), but the slightly strange semantics remain.
For example, you don’t even have to use GenTextures() if you don’t want to:
In theory, you can just make up your own “texture names”, though I wouldn’t
consider that good style.

cu,
Nicolai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9qMtsxPozBga0lwRAjVBAJ0dE8T0UUXktYFDg2RZ4OofyU0AjgCg3i+s
ULH4tLt3MjbGbZJ/epqlwIs=
=2Puk
-----END PGP SIGNATURE-----

Hi there

I will give you 2 suggestions, but I do not know if one of them is a “good
practice”, but, anyway, here it is:

when asked to change the resolution, you can keep the resolution, show a
"please wait, reescaling graphics" dialog,
with a progressbar or similar thing, re-escale all the sprites, tiles,
keep it on a surface
Then, change the video mode, and use the surfaces you have created.

the second, is, at “boot time”, you load all the graphics in 3
resolutions, and just select (a var like “mode”) and
choose from wich source layer it is.

But, anyway, the second one will spend a lot more run, will be the
faster, because you just set the source, and users are used to a
slow/heavy loading of software… but, int the middle of run time, it is a
little harder for
them to accept, But, the first is the more reasonable.

I hope I helped you somehow.On Wed, 14 Jul 2004 11:14:03 +0200, Florian Hufsky wrote:

so you want your game to run on slower machines?

in 2d?
with first drawing to a 1024x768 surface and then software scaling it
to 640x480.

i don’t think you will get a decent framerate.

even on a 1800+ w/ 256 mb sd ram.

when working with software functions (this is what sdl and directdraw
does most of the time (not speaking of other platforms)) the cpu and ram
is the biggest limiter.

and getting a decent framerate at 1024x768 is already a problem for fast
pcs (when having sd ram). ddr ram works a lot faster, but most low level
machines won’t have it.

and software scaling every frame to another (maybe even bigger)
resolution will most probably be far too much for almost every pc you
target.

i don’t know which hardware your aiming at, but with software functions
i won’t go beyong 1024x768.
and i think scaling will give you a slowdown of min 50%? (minimum when
scaling to 640x480 (1.5x blitting the screen), and not taking the scale
calculations into account).

i don’t think what you want is possible.
unless you use 3d accelartors.
or smaller resolutions without scaling

Tyler Olsen wrote:

I need code that will take a 1024x768 SDL surface and convert it to a
640x480, 800x600, or 1200x1024 SDL surface. Basically all I want to do
is blit images to a virtual 1024x768 screen surface and if the user
requests a different resolution I can just re-size that virtual screen
surface before flipping the buffer to the screen. After looking around
I discovered the rotozoom function in the SDL_gfx library, but I
decided rather than require another dependant library on my program
I’ll just take the code snippet that I need and modify it to fit my own
needs (Plus SDL_gfx isn’t supported on very many platforms). After
looking at the code, I found that zooming is only supported for 8-bpp
and 32-bpp surfaces. So I have the following questions:

  1. I don’t know a lot about monitors/resolutions, but how likely is it
    that a monitor doesn’t support 32-bpp?
  2. Is there a better solution for my image resizing needs than
    SDL_gfx’s rotozoom function?
    The program in question is a 2D RPG game I’m developing. I want it to
    be as platform-independant as possible and be able to work well even on
    slower machines. Thanks for any help you can give.

Tyler Olsen - Lead Developer
Hero of Allacrost: http://www.allacrost.org


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


Using Opera’s revolutionary e-mail client: http://www.opera.com/m2/