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:
- I don’t know a lot about monitors/resolutions, but how likely is it
that a monitor doesn’t support 32-bpp?
- 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/