views:

187

answers:

6

I know a decent amount of C++, and now I wanted to explore making a game. I was wondering what the best approach would be in terms of writing a hardware accelerated game that's still cross-platform (Windows/OSX/Linux). It's going to be a 2d game, but intensive enough that a CPU renderer probably wouldn't cut it.

I know there's OpenGL, but I can't seem to find any tutorials on how to use it in a cross platform manner, they all focus on one platform.

Using SDL is also a possibility, but I'm afraid the game may not perform as well if I use it. Is this necessarily true?

Lastly, I've seen libraries like http://www.sfml-dev.org/ that supposedly make it easier, should I go down that route?

Thanks again.

+2  A: 

If you want OpenGL in a cross platform manner you can embed it in a Qt application using QGLWidget.

Vitor Py
+1  A: 

There's also wxWidgets, which has OpenGl support.

Evan Cordell
+3  A: 

That's nonsense guys

OpenGL IS cross-platform. No need for Qt or such. Only a few part must be adapted : the windowing API and the input API, which are the only functions that depend on OS-specific routines.

You have several possibilities :

  • roll your own. I don't recommend this, since you won't learn anything interesting (hardly)
  • SDL. It has a flag to be HW accelerated, so it's as good as any other
  • SFML. This seems good but not mature enough IMHO. The other parts (networking, ...) are wrappers for other libraries so I don't really see the advantage
  • GLUT. This one is evil.
  • GLFW. This one is great, really. I've been using it for years now. It's perfect from every point of view. The only limitation is that you can only have one openGL window, but since it's for a game it should be ok.
Calvin1602
Using QT makes sense if you want to make GUI application.
SigTerm
Yes, but he wants to make a game
Calvin1602
A: 

Yes, go with SFML. SDL is not inherently hardware accelerated.

OpenGL is indeed portable but it does have platform-specific methods for creating the OpenGL context. SFML solves that.

Kylotan
SDL+OpenGL - portable, hardware accelerated, no platform-specific methods for context creation needed.
SigTerm
Which requires more work than SFML on its own.
Kylotan
A: 

To me the question is not to know if you should use libraries or not. It is what library you should use. If you want to write a game, then find libraries that will solve most portability issues for you. It will let you concentrate on what matters the most: the game itself. Others gave more library suggestions that I could have given you.

I think it is a mistake to overly worry about performance before you have even started your project. Work on performance issues like any other problem you face during development. Design your program to isolate libraries in a layer separate from the rest of your program logic. It will be easier to switch implementation if needed. That will even allow to experiment different implementations.

Ie:

// separate files

class LowLevelGraphicStuff {
  // abstract
};

class LowLevelGraphicStuff_SFML : public LowLevelGraphicsStuff {
  // actual SFML implementation
};

class LowLevelGraphicsStuff_OGL : public LowLevelGraphicsStuff  {
  // actual OpenGL implementation
};

// main

// Run the game with the SFML implementation.
gameLoop(new LowLevelGraphicsStuff_SFML());
// Run the game with the OpenGL implementation.
gameLoop(new LowLevelGraphicsStuff_OGL());
Philippe A.
A: 

Cross platform hardware accelerated 2d C++ app?

SDL + OpenGL. Maybe also glee or glew if you use shaders and/or extensions. Glee is easier to use, but it looks like it doesn't support OpenGL versions after 3.0. Also you might need SDL_image for loading images.

I know there's OpenGL, but I can't seem to find any tutorials on how to use it in a cross platform manner, they all focus on one platform.

    SDL_Init(SDL_INIT_VIDEO);

    SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
    SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
    SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);
    SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16);
    SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
    SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 0);//disable vsync

    if (SDL_SetVideoMode(scrWidth, scrHeight, 32, SDL_OPENGL) == 0){
        fprintf(stderr, "couldn't set mode %dx%d!\n", 640, 480);
        SDL_Quit();
        return -1;
    }
    glewInit();//if you use glew, shaders, extensions.

    while(gameIsRunning()){//game loop
        glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
        //OpenGL rendering here 
        glFlush();
        SDL_GL_SwapBuffers();       
    }
    SDL_Quit();

See sdl documentation for more info.

Using SDL is also a possibility, but I'm afraid the game may not perform as well if I use it. Is this necessarily true?

With vsync disabled, you can get from few hundreds to thousand frames per second. Exact performance depends on your hardware and scene complexity - I had 300 fps reports for simple 3D dungeon crawler that used "RAW" opengl without display lists/vertex buffer objects. Also, if you use fixed framerate or timer-driven engine, you won't get more frames per second than you asked for.

SDL was used for porting Unreal 2004 to Linux. It also was used in Doom 3/Quake 4 linux port. So it is thoroughly tested and well known.

See this list for more info.

SigTerm