Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#Actuallipsryme

Posted 02 March 2013 - 04:56 PM

I hope this is the right place to ask but I'm having a few questions on how to properly build a structure for a framework or small engine.

 

My first question is circular dependencies. Are they bad ? People say they are a flaw in the design. If so how would you construct an engine.

Let me give you an example of how I did this in the past:

 

ApplicationClass - Has an instance of my engine class

      EngineClass - Has an instance of it's application and every other component

 

or a MaterialClass - Has an instance of the renderer component class and uses this to get .e.g the rendering device to create shader resources...

and at the same time the renderer has to work with the material class.

         

Is it wrong to think that every component has to have a two-way connection to it's owner/child ?

 

 

Second question, which is similar to the above question. What I currently do is something like this:

 

Engine creates an instance of the renderer and at the same time passes a this pointer to the constructor of the renderer class which then stores this reference as a local member to have access to the engine and its components. Now even at this point if I were to use shared_ptr I'd be having a big problem as I can't easily pass a this pointer as the engine itself would be a shared_ptr stored inside the application class.

So basically often it is the case that if a certain class needs something from the timer class, it accesses it by using its local pointer to the engine class, which then gets its timer component.

I feel like I'm in a circle of bad design here and need some help on how to properly set up this kind of a structure. Or maybe I'm just paranoid biggrin.png ?

 

Third question. In my application I create my components as pointer to an object. So during runtime these pointers are getting passed around as e.g. Core* core or Renderer* renderer as parameters of the functions. As I understand this only passes a copy of the pointer to this specific object to the other class so it is rather quick, right ? Now when returning e.g. floats would I then return the address to this float member to make it as quick as possible ? Also what is the best way to pass an std::vector?


#2lipsryme

Posted 02 March 2013 - 04:53 PM

I hope this is the right place to ask but I'm having a few questions on how to properly build a structure for a framework or small engine.

 

My first question is circular dependencies. Are they bad ? People say they are a flaw in the design. If so how would you construct an engine.

Let me give you an example of how I did this in the past:

 

ApplicationClass - Has an instance of my engine class

      EngineClass - Has an instance of it's application and every other component

 

or a MaterialClass - Has an instance of the renderer component class and uses this to get .e.g the rendering device to create shader resources...

and at the same time the renderer has to work with the material class.

         

Is it wrong to think that every component has to have a two-way connection to it's owner/child ?

 

 

Second question, which is similar to the above question. What I currently do is something like this:

 

Engine creates an instance of the renderer and at the same time passes a this pointer to the constructor of the renderer class which then stores this reference as a local member to have access to the engine and its components. Now even at this point if I were to use shared_ptr I'd be having a big problem as I can't easily pass a this pointer as the engine itself would be a shared_ptr stored inside the application class.

So basically often it is the case that if a certain class needs something from the timer class, it accesses it by using its local pointer to the engine class, which then gets its timer component.

I feel like I'm in a circle of bad design here and need some help on how to properly set up this kind of a structure. Or maybe I'm just paranoid biggrin.png ?

 

Third question. In my application I create my components as pointer to an object. So during runtime these pointers are getting passed around as e.g. Core* core or Renderer* renderer as parameters of the functions. As I understand this only passes a copy of the pointer to this specific object to the other class so it is rather quick, right ? Now when returning e.g. floats would I then return the address to this float member to make it as quick as possible ?


#1lipsryme

Posted 02 March 2013 - 04:52 PM

I hope this is the right place to ask but I'm having a few questions on how to properly build a structure for a framework or small engine.

 

My first question is circular dependencies. Are they bad ? People say they are a flaw in the design. If so how would you construct an engine.

Let me give you an example of how I did this in the past:

 

ApplicationClass - Has an instance of my engine class

      EngineClass - Has an instance of it's application and every other component

 

or a MaterialClass - Has an instance of the renderer component class and uses this to get .e.g the rendering device to create shader resources...

and at the same time the renderer has to work with the material class.

         

Is it wrong to think that every component has to have a two-way connection to it's owner/child ?

 

 

Second question, which is similar to the above question. What I currently do is something like this:

 

Engine creates an instance of the renderer and at the same time passes a this pointer to the constructor of the renderer class which then stores this reference as a local member to have access to the engine and its components. Now even at this point if I were to use shared_ptr I'd be having a big problem as I can't easily pass a this pointer as the engine itself would be a shared_ptr stored inside the application class.

So basically often it is the case that if a certain class needs something from the timer class, it accesses it by using its local pointer to the engine class, which then gets its timer component.

I feel like I'm in a circle of bad design here and need some help on how to properly set up this kind of a structure. Or maybe I'm just paranoid :D ?

 

Third question. In my application I create my components as pointer to an object. So during runtime these pointers are getting passed around as e.g. Core* core or Renderer* renderer as parameters of the functions. As I understand this only passes a copy of the pointer to this specific object to the other class so it is rather quick, right ? Now when returning e.g. floats would I then return the address to this float member to make it as quick as possible ?


PARTNERS