Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Mar 2009
Offline Last Active Sep 02 2016 09:31 AM

Posts I've Made

In Topic: Interfaces and code duplication

13 August 2016 - 03:42 AM

So, the GameObject itself contains almost no data or functionality, except that needed to request and store pointers to the various components? It's basically just a collection (small 'c') of components?

Almost everything it can 'do' is actually done by the components, which themselves are stored and assigned as necessary by the relevant logic units (renderer, physics iterator, game logic etc)?

So if I had, say, a ball. The 'Ball' object needs to be drawn, needs to move in the world, and needs to react to its surroundings.
When it's created, it would request a 'Renderable' component from the Renderer, which would create one, store it and hand a pointer to the new Ball object. The ball could then configure this accordingly and store the pointer.
Now the renderer can happily get on with drawing whatever it has in its list without ever needing to bother with the actual GameObject to which each renderable has been attached.
The same applies to the physics and game logic components.

Am I getting closer?

In Topic: Best comment ever

12 August 2016 - 05:33 PM

In a VBA project at work:


' Bear in mind that every time the middleware gets updated, the API changes; I presume simply to keep VBA developers on their toes.

In Topic: Interfaces and code duplication

12 August 2016 - 05:26 PM

Thanks for the advice and the quick replies :)



Riiiiightt..... I think I'm getting there. The concepts are still floating in my head just out of reach, but they're beginning to brush against my fingertips.


So, I could make a class called Renderable, which contains all the basic things such as position, graphics (or location of graphics at least). To make an object Renderable, I'd just add a pointer to an instance of the Renderable class, rather than directly inheriting from it.


My Renderer would need to take an object of type 'Renderer' - I think I see now where Interfaces fit in. I could make my object implement a 'Renderer' interface (but I'll not call it IRenderer, for fear of angering TheChubu...  :wink:  ) and implement a method to direct it to the renderer class. True, I'd need to duplicate those couple of lines but the actual heavy-lifting would be handled by the Renderer component.





Obligatory reading: Evolve Your Hierarchy


Excellent read, thank you.

In Topic: Function "Overload" Question

17 June 2012 - 06:33 PM

Could you not just pass a reference to a vector of the parameters? This also lets you use templates if you plan on having several versions for different parameter types.

typedef std::vector<std::string> ParamsVec;

int foo(ParamsVec& params)


	 std::string str;

	 cin >> str;

	 int count = 0;

	 for (ParamsVec::iterator it = params.begin(); it != params.end(); ++it)


	 	 if ((*it) == str) return count;




EDIT: aargh, stupid source tags, why do they cut off angle brackets if I specify a language type?...

In Topic: SampleLevel not returning alpha component

07 April 2012 - 04:11 AM

haha, I feel like an idiot, I can't believe that didn't occur to me.