Resize images at runtime with SDL

I have a 1600x1200 image that I want to make fit the screen in SDL (so that it will work regardless of the screen size) but I can't find an SDL function to do this. I've looked at SDL_rotozoom but I don't think that's what I want.

What can I use to make images larger or smaller to fit the screen?
Why would you want to use SDL? Is it in any way better that OpenGL?
Doesn't the lack off documentation about such trivial problem as scaling discourage you?
:S
I'm using SDL because I'm writing a 2D game. If I were writing a 3D game I would use OpenGL...
You know, OpenGL does support 2D graphics...
edit: by the way, what sort of game is it?
Last edited on
You know, OpenGL does support 2D graphics...

Yeah, but is there much point learning a whole new library just for the sake of one function I haven't found?

what sort of game is it?

Well, at the moment all I'm writing is a wrapper for SDL (but I'm writing it in such a way that if I completely changed the internal API, no external code would need to be modified) or another low-level API; but I plan to eventually make a Tetris clone or something simple out of it.

I'm also taking the opportunity to learn how to use Autotools.
Last edited on
Yeah, but is there much point learning a whole new library just for the sake of one function I haven't found?


It's not just one function. OpenGL has lots of stuff over SDL. One of the big ones being speed.

Alpha blending, rotation, scaling, etc, etc are all additional perks.
Well, I'll have a look at OpenGL then. Can someone direct me to an OpenGL 2D tutorial? I'm looking for one, but I can't really find one.

Found one: http://nehe.gamedev.net/lesson.asp?index=01

stupid tutorial wrote:
1
2
3
4
5
6
7
8
9
#include <windows.h>								// Header File For Windows
#include <gl\gl.h>								// Header File For The OpenGL32 Library
#include <gl\glu.h>								// Header File For The GLu32 Library
#include <gl\glaux.h>								// Header File For The GLaux Library

HGLRC           hRC=NULL;							// Permanent Rendering Context
HDC             hDC=NULL;							// Private GDI Device Context
HWND            hWnd=NULL;							// Holds Our Window Handle
HINSTANCE       hInstance;							// Holds The Instance Of The Application 


<rage workSafe="false">

Why the fuck would you use backslashes in include paths??? That's completely retarded! Windows supports BOTH and POSIX platforms only tend to support forward slashes! What the fuck is the point in using a cross-platform library if you're going to use the windows API for EVERYTHING? What a damn idiot!

Also, LOL global variables!

</rage>
Last edited on
Thanks :)
That one looks better.

Now that I re-read my previous post, I have to laugh at myself... but it's still pretty annoying when people use a cross-platform library and then make it windows only :S
You can use SDL to set up the OpenGL window. It's just a matter of passing the right flags to SDL_SetVideoMode.

The plus side of doing it that way is you get the crossplatform-ness, and SDL's audio/joypad/etc stuff.
I like the idea of that. I wanted to use SDL_mixer. Does OpenGL have support for playing videos?
I wanted to use SDL_mixer.


If you're interested... I could hook you up with my WIP library that supports Ogg Vorbis output and has some other crap. It's pretty decent and is easier to use than SDL_mixer (IMO -- but then again I'm pretty biased).



Does OpenGL have support for playing videos?


I have no idea.
A library you created? Send link!
http://rapidshare.com/files/366535729/dshlib_for_cpp_forums_21-Mar-2010.zip.html

Forgive the rapidshare, but I no longer have webhosting.

googlepages doesn't work anymore, geocities is nonexistant, and I lost touch with the guy who was giving me arc-nova space.

Basic usage:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#include <iostream>
#include "SDL.h"
#include "dshlib/dshlib.h"

int main()
{
    using namespace dshlib;

    // dshlib doesn't initialize SDL -- do this yourself
    SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO);

    // initialize the output device
    SDLAudioOut audout(44100,2,100);  // 44100 KHz, 2 channels (stereo), 100 ms latency

    // create a 'BGMSound'.  Consists of 2 parts:  an "intro" portion
    //  and a "loop" portion.  The intro portion plays once, followed by the
    //  loop portion which plays repeatedly.

    // this looks more complicated than it is.  The complication is due to the flexibility you have here.
    // SoundSources are loaded from files
    // StreamedSounds require a SoundSource (streamed vs. buffered)
    // Basically there's a lot of abstraction.
    BGMSoundPtr bgm = new BGMSound(
               new StreamedSound( SoundSource::Load( new File("introportion.ogg") ) ),
               new StreamedSound( SoundSource::Load( new File("loopportion.ogg") ) )
                                  );

    // play sounds by playing them in the output device's mixer
    audout.GetMixer().PlaySound( bgm );

    // enjoy the music
    char c;
    cin >> c;

    // destroy the audio output device before you SDL_Quit
    //  (or you can have the destructor destroy it -- but make
    //   sure it happens before you SDL_Quit)
    audout.Destroy();

    SDL_Quit();

    return 0;
}


Don't worry about the 'new's, pretty much everything in dshlib uses smart pointers.

I'm working on documentation but it's huge and incomplete, and boring as hell to work on.

Other pieces of dshlib:

-) better random number generators (well better than rand())
-) utf string class(es)
-) CRC32 stuffs
-) zip file reading/writing
-) zlib wrappers
-) abstraction for files, filesystems, and other system constants (not unlike Qt/wx/etc... only not nearly as complete as them)
-) really really basic threads/mutexes which I'm thinking of revamping completely.

Fun stuff.

I'm more than happy to answer any questions. And I'm open to criticism.

EDIT: found a bug in RNGBase. I'll fix tomorrow
Last edited on
Also, LOL global variables!


I think the reason global variables are used in that tutorial because it's focus is towards game programming so performance is more critical. And global variables are better when it comes to performance than local variables. Sometimes there are conflicts between performance and "good design". However "good design" actually depends on what the system needs. So in this case that is actually "good design" because it's aim is to crank out better performance for 3D games.

Understanding the requirements of the system depends on us programmers, so we need to be knowledgeable enough to know when to break certain "rules" and I think that is what separates good programmers from great ones.
Last edited on
Hey, thanks, Disch. I'll download that library later on and have a look at it.

@Dacster13,
I don't think having those globals will make much of a speed boost, tbh.
Topic archived. No new replies allowed.