Elysian Shadows

Nokurn wrote:You need to define "crash." Are you getting an error message? Where does the problem crop up if you step through the code with a debugger?

For starters you might want to try fixing your GL attributes. They must be set before SDL_SetVideoMode, as per SDL_GL_SetAttribute's documentation.

RandomDever wrote:What is the most efficient way to deal with texture reloading?

class TextureManager {
public:
    static TextureManager& getInstance()
    {
        static TextureManager instance;
        return instance;
    }

    ~TextureManager()
    {
        for (TextureMap::iterator i = textures_.begin(); i != textures_.end(); ) {
            delete *i;
            i = textures_.erase(i);
        }
    }

    Texture* getTexture(std::string const& name)
    {
        TextureMap::iterator i = textures_.find(name);
        if (i == textures_.end()) {
            Texture* texture = new Texture(name);
            textures_[name] = texture;
            return texture;
        }
        return i->second;
    }

    void reload()
    {
        for (TextureMap::iterator i = textures_.begin(); i != textures_.end(); ++i) {
            delete i->second;
            i->second = new Texture(i->first);
        }
    }

private:
    typedef std::map<std::string, Texture*> TextureMap;
    TextureMap textures_;

    TextureManager() {}
    TextureManager(TextureManager const&) {}
    TextureManager& operator=(TextureManager const&) {}
};

Nokurn wrote:

RandomDever wrote:What is the most efficient way to deal with texture reloading?

Usually you will want some form of central asset management. It can be something fancy, or it can be something really simple, like this:

Code: Select all

class TextureManager {
public:
    static TextureManager& getInstance()
    {
        static TextureManager instance;
        return instance;
    }

    ~TextureManager()
    {
        for (TextureMap::iterator i = textures_.begin(); i != textures_.end(); ) {
            delete *i;
            i = textures_.erase(i);
        }
    }

    Texture* getTexture(std::string const& name)
    {
        TextureMap::iterator i = textures_.find(name);
        if (i == textures_.end()) {
            Texture* texture = new Texture(name);
            textures_[name] = texture;
            return texture;
        }
        return i->second;
    }

    void reload()
    {
        for (TextureMap::iterator i = textures_.begin(); i != textures_.end(); ++i) {
            delete i->second;
            i->second = new Texture(i->first);
        }
    }

private:
    typedef std::map<std::string, Texture*> TextureMap;
    TextureMap textures_;

    TextureManager() {}
    TextureManager(TextureManager const&) {}
    TextureManager& operator=(TextureManager const&) {}
};

Of course, you'll probably want to use some form of lifetime management (reference counting is a popular choice), and I wouldn't advise using a singleton (maybe you'll want multiple texture pools). So the short answer is yes, maintain a list of textures that are currently in use, and reload them when you lose your OpenGL context (changing window modes, etc).

If you're interested in how other people implement asset management, I would definitely recommend looking at the Resources module in Jan Haller's Thor library.

Falco Girgis wrote:Make sure that you are deallocating and reallocating all textures if you are dynamically changing video resolutions. You can run into some obscure bullshit otherwise.

RandomDever wrote:Would it be ill advised to build the asset manager directly into my video manager?

Nokurn wrote:

RandomDever wrote:Would it be ill advised to build the asset manager directly into my video manager?

It depends on what exactly your video manager does. If you're loading textures through it, it probably is already some form of asset manager and you just need to extend it.

Setup //Sets up a window
SetCaption //Sets the caption of the window
LoadTexture //Loads a texture from a png
DeleteTexture //Deletes a texture
ReloadTexture //Deletes and reloads a texture
BlitTexture //Renders a texture on the screen to a quad
Clear //Clears the screen
Render //Swaps the buffers
Resize //Resizes the window
ToggleFullscreen //Self-explanatory
IsFullscreen //Returns true if screen->flags & SDL_FULLSCREEN

RandomDever wrote:

Nokurn wrote:

RandomDever wrote:Would it be ill advised to build the asset manager directly into my video manager?

It depends on what exactly your video manager does. If you're loading textures through it, it probably is already some form of asset manager and you just need to extend it.

Here's a list of all the functions:

Code: Select all

Setup //Sets up a window
SetCaption //Sets the caption of the window
LoadTexture //Loads a texture from a png
DeleteTexture //Deletes a texture
ReloadTexture //Deletes and reloads a texture
BlitTexture //Renders a texture on the screen to a quad
Clear //Clears the screen
Render //Swaps the buffers
Resize //Resizes the window
ToggleFullscreen //Self-explanatory
IsFullscreen //Returns true if screen->flags & SDL_FULLSCREEN

Thats it right now, but it is early in development.

Nokurn wrote:

RandomDever wrote:

Nokurn wrote:

RandomDever wrote:Would it be ill advised to build the asset manager directly into my video manager?

It depends on what exactly your video manager does. If you're loading textures through it, it probably is already some form of asset manager and you just need to extend it.

Here's a list of all the functions:

Code: Select all

Setup //Sets up a window
SetCaption //Sets the caption of the window
LoadTexture //Loads a texture from a png
DeleteTexture //Deletes a texture
ReloadTexture //Deletes and reloads a texture
BlitTexture //Renders a texture on the screen to a quad
Clear //Clears the screen
Render //Swaps the buffers
Resize //Resizes the window
ToggleFullscreen //Self-explanatory
IsFullscreen //Returns true if screen->flags & SDL_FULLSCREEN

Thats it right now, but it is early in development.

Personally, I would part that class out (see the single responsibility principle). It could be split into classes like Renderer and TextureManager. Also, if you're using OpenGL seriously, you probably shouldn't have a function named "BlitTexture" anywhere in your code. Unless you have a very specific reason for targeting video cards that lack support for VBOs (OpenGL 1.5) or VAOs (OpenGL 3.0), you shouldn't be rendering in immediate mode. You'll get MUCH better performance by using VBOs instead; this may or may not be an issue for your game, depending on how many quads you'll be rendering at once in the final version. If you're planning on reusing your code, however, I'd definitely recommend implementing a better system for rendering quads.

RandomDever wrote:

Nokurn wrote:

RandomDever wrote:

Nokurn wrote:

RandomDever wrote:Would it be ill advised to build the asset manager directly into my video manager?

It depends on what exactly your video manager does. If you're loading textures through it, it probably is already some form of asset manager and you just need to extend it.

Here's a list of all the functions:

Code: Select all

Setup //Sets up a window
SetCaption //Sets the caption of the window
LoadTexture //Loads a texture from a png
DeleteTexture //Deletes a texture
ReloadTexture //Deletes and reloads a texture
BlitTexture //Renders a texture on the screen to a quad
Clear //Clears the screen
Render //Swaps the buffers
Resize //Resizes the window
ToggleFullscreen //Self-explanatory
IsFullscreen //Returns true if screen->flags & SDL_FULLSCREEN

Thats it right now, but it is early in development.

Personally, I would part that class out (see the single responsibility principle). It could be split into classes like Renderer and TextureManager. Also, if you're using OpenGL seriously, you probably shouldn't have a function named "BlitTexture" anywhere in your code. Unless you have a very specific reason for targeting video cards that lack support for VBOs (OpenGL 1.5) or VAOs (OpenGL 3.0), you shouldn't be rendering in immediate mode. You'll get MUCH better performance by using VBOs instead; this may or may not be an issue for your game, depending on how many quads you'll be rendering at once in the final version. If you're planning on reusing your code, however, I'd definitely recommend implementing a better system for rendering quads.

I may separate those out then.
But what is 'immediate mode'? I looked it up and it seems to be simply not using something called 'display lists'.
I don't know what those are, but I will probably implement it because it apparently is alot more efficient.
BTW the whole 'BlitTexture' thing is just what I call it because that's what I'm used too.
It may be the wrong thing to call it but IDK.
I want this to be as good of an engine as can be so thank you for all your advice.

Nokurn wrote:

RandomDever wrote:

Nokurn wrote:

RandomDever wrote:

Nokurn wrote:

RandomDever wrote:Would it be ill advised to build the asset manager directly into my video manager?

It depends on what exactly your video manager does. If you're loading textures through it, it probably is already some form of asset manager and you just need to extend it.

Here's a list of all the functions:

Code: Select all

Setup //Sets up a window
SetCaption //Sets the caption of the window
LoadTexture //Loads a texture from a png
DeleteTexture //Deletes a texture
ReloadTexture //Deletes and reloads a texture
BlitTexture //Renders a texture on the screen to a quad
Clear //Clears the screen
Render //Swaps the buffers
Resize //Resizes the window
ToggleFullscreen //Self-explanatory
IsFullscreen //Returns true if screen->flags & SDL_FULLSCREEN

Thats it right now, but it is early in development.

Personally, I would part that class out (see the single responsibility principle). It could be split into classes like Renderer and TextureManager. Also, if you're using OpenGL seriously, you probably shouldn't have a function named "BlitTexture" anywhere in your code. Unless you have a very specific reason for targeting video cards that lack support for VBOs (OpenGL 1.5) or VAOs (OpenGL 3.0), you shouldn't be rendering in immediate mode. You'll get MUCH better performance by using VBOs instead; this may or may not be an issue for your game, depending on how many quads you'll be rendering at once in the final version. If you're planning on reusing your code, however, I'd definitely recommend implementing a better system for rendering quads.

I may separate those out then.
But what is 'immediate mode'? I looked it up and it seems to be simply not using something called 'display lists'.
I don't know what those are, but I will probably implement it because it apparently is alot more efficient.
BTW the whole 'BlitTexture' thing is just what I call it because that's what I'm used too.
It may be the wrong thing to call it but IDK.
I want this to be as good of an engine as can be so thank you for all your advice.

You are using "immediate mode" whenever you send the vertices you want to be rendered when you want them to be rendered. It's bad for a number of reasons, but the primary reason is that you can't render until your vertices (and other data) are done being sent to the video card. This takes time, and it's really inefficient to do every single frame. You can avoid this in OpenGL by using vertex buffer objects, which allow you to pre-load your vertices (and other data).

Display lists are an improvement, and are probably the simplest optimization to implement, but in my experience, they don't quite reach the level of performance or flexibility that you get from a well-tuned VBO system. With display lists, you define sequences of OpenGL calls that are stored on the GPU, which can later be executed directly on the GPU, therefore avoiding the overhead involved in sending each command to the GPU in real time. Display lists can only call a limited subset of OpenGL.

I assume that you are using immediate mode in a function called BlitTexture because the name suggests that it operates directly on the Texture and has no existing knowledge of the geometry. With no knowledge of the geometry, the geometry must be generated on-the-fly, and rendered immediately.

RandomDever wrote:Yes 'BlitTexture', based on your description, does use immediate mode.
It would be fairly easy to make it use a display list, but I'll have to do some research on VBOs, after I get some sleep.
Because essentially I am building this engine to be as fast as fast as possible, while trying to maintain some ease of use. ( As well as finally implementing a bunch of cool debug features to make it a lot easier to find bugs )
And also to make a 2D platformer.