I'm finding myself running into the same kind of problem over and over again, and I'm wondering if there's a pattern I should be using for it.
It started with my rendering system. I'm using a component based architecture, and naturally my GameObjects would possess renderable components, such as a sprite. In order to render these components in an appropriate order, I had made a renderer object which would sort the renderable components and call render() on them in order. So when I construct a given GameObject, and it will have a renderable component, I pass a renderer to the constructor which the renderable is then added to.
The rub is that I'd like to be able to clone my GameObject, so all my components have to be cloneable. I'd like any renderables that I clone to end up registered to the same renderer as the renderable they were cloned from. To do this, my renderables keep track of which renderers they've been added to, and when they clone themselves, they can add the cloned renderable to the appropriate renderers.
It seemed like a good way of doing it at first, but now I'm beginning to wonder. I've now got an Actor component that needs to be registered to a Time object that manages which Actor takes their turn next (it's a turn based game). By the same reasoning as used for the renderable, the Actor will have to keep track of which Time object it's been added to. But now I'm adding more code to the actor, just to allow it to keep track of which Time object it was added to, than I've got describing the functionality of the Actor.
I'm being tempted by singletons for these object managers, but they make me feel dirty. Has anyone encountered similar issues?
Looking for a pattern, objects registering to a manager
Why not have the Renderer and Time object (and whatever other systems you need) act as factories instead of cloning objects directly? i.e. instead of saying GameObject->Clone() you say Renderer->Clone(*GameObject).
There's more than one renderer? That seems like a fundamental flaw in basic design.
There's more than one renderer? That seems like a fundamental flaw in basic design.
Says who?
I've worked with systems with several renderers even within the framework of a single graphics API. Different things like UI, debug information, particle effects, and so on might all benefit from slightly different rendering paths.
How is this code on the Actor object to keep track of Time objects? It feels like you could use just a pointer to a TimeBase object and create the Actor objects passing TimeImpl1 and TimeImpl2 which derive from TimeBase.
I use something like that with Renderers. All my renderer objects inherit from a RendererBase and each rendereable class has a pointer to a RendererBase object. Take a look at dependency injection.
I use something like that with Renderers. All my renderer objects inherit from a RendererBase and each rendereable class has a pointer to a RendererBase object. Take a look at dependency injection.
Instead of passing a Renderer to the Renderable in the constructor, you could have the Renderable "know" which Renderer to use behind the scenes. The relationship could be stored as a class static variable in each concrete Renderable type, and injected when the Renderer is created at initialization. This is assuming that the Renderer for each Renderable type stays the same from startup to shutdown. This is my preferred method to avoid using Singletons and also not have to pass references all up and down the call stack for injection.
why not registering Renderable multiple times to all Renderers that need it?. A list for each renderer should be enough. also agree with first post of ApochPiQ.
also registering each item that need to be rendered into a list each frame shouldn't be a big performance hit (just profiling it now with my engine, registering to a list compared to time for a draw call is nothing, interesting is the tradeoff with mesh batchin in my case).
also registering each item that need to be rendered into a list each frame shouldn't be a big performance hit (just profiling it now with my engine, registering to a list compared to time for a draw call is nothing, interesting is the tradeoff with mesh batchin in my case).
Renderer1->register(this);
Renderer2->register(this);
etc.
Says who?
Just me - I used the word "seems" because I'm not sure, and I wanted the OP to provide good reasons for using multiple renderers to draw game objects, because if there were no good reasons, the problem could be solved in a very elegant manner.
I've worked with systems with several renderers even within the framework of a single graphics API. Different things like UI, debug information, particle effects, and so on might all benefit from slightly different rendering paths.
But when we talk about "different things", isn't the fact that they're different reflected in the data that describes their visual appearance?
When I made my original statement, it was in the context of this particular case, and in that context, I think that a well designed material system would be considerably better than yet another renderer. For one, the OP wouldn't have to think about which game objects belong to which renderer, because there's only one (fairly elegant way to solve that particular problem, wouldn't you say?
). Also, in order to change the visuals, one would only need to change material data, rather than recode the renderer for some specific look, or add yet another renderer.I realize that things like UI or Particle systems are less general, and probably warrant a whole new path (in certain cases), but for game objects ... I just don't see the benefits.
Fair enough; I'd say that on the whole without more detail from the OP on what his needs/plans are it's basically a toss-up as to whether or not multiple rendering objects makes sense.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
