Jump to content

  • Log In with Google      Sign In   
  • Create Account


Code design


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Raap   Members   -  Reputation: 104

Like
0Likes
Like

Posted 20 November 2012 - 02:17 PM

I'm relatively new to c++ programming, but I feel like I got the basics through various tutorials and practice. I've gotten to the point where console programming has become less interesting, and I've just started to scratch using OpenGL.

I'm using SDL as my base and OpenGL through that, to simplify the learning process somewhat. I've gotten started and things are working nicely, but I find that I continue to run into not coding questions but design questions. I'm purely focusing on 2D at the moment, simply building quads and texturing them.

The results are coming out as I had planned, which is good, but it has led me to question what the most efficient way( both in terms of performance and general code organization) of doing this might be.For instance, do I keep the drawing code in my game/graphics class and iterate through UIelements/gameobjects to get coordinates/textures and draw stuff that way, or do I add the actual drawing code to the gameobject classes themselves, then iterate through and call it in each of them? What about the textures? Do I keep them in a separate container in the main class, thus allowing me to use the same texture for several objects, or do I store each object's texture inside the object thus leading to duplication but no time spent searching for the texture? Maybe just store a pointer to a place in a container?

I'm also struggling with some more general stuff. For instance, what would be a good way of only calling the writing function for stuff that will actually be visible? I could just check the coordinates, but that would definitely add a lot of overhead every time I'm rewriting the screen.

As of right now, I haven't even started on the actual game. But in that regard, should I make a game class/object that is separate from my current main class which currently just contains SDLstuff/graphics/eventhandling and such?Or do I just keep it all inside one huge main class?

Anyway, I'm not necessarily looking for detailed answers to each and every question, but general advice and maybe some links. I've been through a few tutorials obviously, but they all seem to focus more on the code-typing part instead of code management and design. At least they don't seem to go very far in explaining why things should be as they have set them up. I know there's rarely a 'right answer', but any input from someone with actual experience would be good. Thanks!

Sponsor:

#2 freeworld   Members   -  Reputation: 325

Like
0Likes
Like

Posted 20 November 2012 - 05:27 PM

The overhead of checking if an object is in view is most likely magnitudes less hen drawning it. Google "culling or frustrum culling"

As for what's most efficient completely relies on the rest of your program and the platform it's running on. I would advise you take the short time to implement both ideas and see how they work for you. If not just for more practice but it'll help get an understanding of how things work across different designs. You'll probably find that performance wise they're the same and he big difference is in manageability of your code.
[ dev journal ]
[ current projects' videos ]
[ Zolo Project ]
I'm not mean, I just like to get to the point.

#3 rip-off   Moderators   -  Reputation: 7640

Like
4Likes
Like

Posted 20 November 2012 - 06:12 PM

But in that regard, should I make a game class/object that is separate from my current main class which currently just contains SDLstuff/graphics/eventhandling and such?Or do I just keep it all inside one huge main class?

You don't want to have any huge classes. Ideally, each class will be focused, it will have a "single responsibility". This is a good goal, but when you're starting out it isn't the only thing. It will come with time.

Some great articles on class design, the SOLID object oriented principles from "objectmentor":

For instance, what would be a good way of only calling the writing function for stuff that will actually be visible? I could just check the coordinates, but that would definitely add a lot of overhead every time I'm rewriting the screen.

It depends heavily on the game. Performing visibility tests in Pong would be a waste, while drawing every object to the screen wouldn't work on Minecraft. For small games or at the very beginning, drawing everything every frame usually works and doesn't take too long to write. I'd start there.

For instance, do I keep the drawing code in my game/graphics class and iterate through UIelements/gameobjects to get coordinates/textures and draw stuff that way, or do I add the actual drawing code to the gameobject classes themselves, then iterate through and call it in each of them?

For simpler games, I wouldn't worry about it. As the game gets more complex, separating the rendering from the logical game objects makes more sense.

What about the textures? Do I keep them in a separate container in the main class, thus allowing me to use the same texture for several objects, or do I store each object's texture inside the object thus leading to duplication but no time spent searching for the texture?

A typical solution is to have a class which holds an associative container to shared texture pointers (such as std::map<std::string, std::shared_ptr<Texture>>). This avoids the need to load a given resource twice.

The actual classes that do the rendering will request their texture(s) during initialisation, and store them locally. For instance, taking a PacMan example:
class Texture {
    // Immutable texture class...
};

typedef std::shared_ptr<Texture> TextureHandle;

class Loader {
    typedef std::map<std::string, TextureHandle> Cache;
public:
    TextureHandle load(const std::string &amp;name) {
        Cache::iterator it = cache.find(name);
        if(it == cache.end()) {
            TextureHandle texture = loadFromDisk(name);
            cache.insert(std::make_pair(name, texture));
            return texture;
        }
        return it->second;
    }
private:
    Cache cache;
};

class GhostRenderer {
public:
    GhostRenderer(const Loader &amp;loader) : texture(loader.load("ghost")) {
    }

    void draw(Renderer &amp;renderer, const Ghost &amp;ghost) const {
        renderer.drawQuad(ghost.bounds(), texture, ghost.colour());
    }

private:
    std::shared_ptr<Texture> texture;
};
I haven't compiled or tested this code.

Note there that for a game like Pac Man, separating the rendering code from the game object (while theoretically better) might not buy you much.

Maybe just store a pointer to a place in a container?

Handing out pointers that point to a location inside a container is typically brittle, both because raw pointers are usually unnecessary and frowned upon, and because modifications to the container could invalidate such pointers.

... but it has led me to question what the most efficient way ... in terms of performance ... but that would definitely add a lot of overhead ...

Performance/efficiency is a siren whose call has ensnared many a lost soul. In particular, inexperienced individuals often make questionable decisions based on their "hunches" about the speed of code.

First things first, you need something working before you can discover if it is fast enough. Think about a new car - would changing some panels make it more or less aerodynamic, or make no difference at all? There is no way to answer that question in general - it is 100% dependant on the nature of the car in question.

Most importantly, for small projects efficiency is often one of the easiest things you can "add later" as needed, particularly if you bootstrap yourself with naive data structures, algorithms and memory layouts. Larger projects presently more difficulties because some design decisions will end up propagating assumptions deep into a body of code, where it is more resistant to change.

As of right now, I haven't even started on the actual game.

Start.

The biggest threat to a game - any game - is not potential performance problems, nor is it architectural code issues, it is not having gameplay, mechanics and controls all implemented and working.

Edited by rip-off, 20 November 2012 - 06:12 PM.


#4 yckx   Prime Members   -  Reputation: 1163

Like
0Likes
Like

Posted 21 November 2012 - 12:53 AM

Before you get too deep into SDL you may want to look at SFML. It takes a more OO approach and may save you some effort if you're looking to wrap the API. But if you're happy with SDL go ahead and use it.

#5 solipcoder   Members   -  Reputation: 300

Like
0Likes
Like

Posted 21 November 2012 - 01:57 AM

Make the game first. And redesign as you go. If performance is not an issue, don't bother optimizing.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS