My petty dillema: Separation of graphical drawing of UI objects

[Brax]

In my new project, I have started to seperate the graphic drawing from the ingame objects ( i.e. an object contains the position, size, velocity ect... and a Graphic class contains sf::sprite)

My dillema is, does the same code design should also apply to the UI objects, like mostly stationary buttons and labels?

I can understand such logic for game objects, where they would get constantly updated and changed and should not be burdened by all the drawing components, but for UI objects, I do not view them as complex enteties, and I wonder should they contain the drawing components and draw themselves?

Sorry if the question is kinda noobish to you guys.

[Erdrick]

Hi.  I personally dont see whats wrong with having game objects draw themselves.  In fact all of mine do.  It sounds like you may be trying to optimize too early but example code could help in understanding your concern.

[Hapax]

I think it would just be a design choice. There may be very little benefit in separating a user interface element from its visual representation. In fact, you may consider that the element itself should be a drawable one; that's what it is - a display element, a graphic.

I do agree with separating for the main objects though, although this is not required. It allows for a number of benefits including using proxies for collision and ability to batch graphics.

[Brax]

Hi.  I personally dont see whats wrong with having game objects draw themselves.  In fact all of mine do.  It sounds like you may be trying to optimize too early but example code could help in understanding your concern.

When I was starting out with SFML, I too was writing objects in a way that they could draw themselves. It is indeed more convinient for a beginner to write code like that, but it becomes more limitating as the code becomes more complex. Maybe it can affect preformanse significantly, but my projects were never that much demanding, so I can not tell.

In this project I wanted to change my code desing to be more modular, so the classes should not contain the more variables and function than they need.

Oh, and this is how I consider separation of drawing from objects:

(click to show/hide)

Pseudocode and simplified

class Object
{
   int            mID;   // I find this variable most imprortant!!!
   sf::Vector2f   mPosition;
   sf::Vector2f   mSize;
   sf::Vector2f   mVelocity;
// and rest of variables you may want.
public:
   void           update();
   int             getID();
   sf::Vector2f   getPosition();
   sf::Vector2f   getSize();
   sf::Vector2f   getVelocity();

}
 

class Graphics
{
   std::map<int, sf::Sprite>   mGraphicObjects;  // the int is the ID of the object!!!
public:

   void   draw(sf::RenderWindow&);
   void   removeObject(int)   // removes the object of particular "int" ID
   void   addObject(Object); // it takes everything it needs from the object during creation of sprite and puts it in the map container.
   void   refresh(std::vector<Objects>& mObjectContainter); // assume we have more objects
}

 

Of course, the real code that I wrote is more complex, but this is in a nutshell. Don't know is it any good, I will probably find out the hard way. 

And the priciple is the same for UI objects, if I want to draw them like this.

There may be very little benefit in separating a user interface element from its visual representation. In fact, you may consider that the element itself should be a drawable one; that's what it is - a display element, a graphic.

Exactly what I tought.

Maybe I should rephrase my question: Should my code design be the same for all elements, or should I make exeptions where applicable, in case the code design would make things more complex that necessary?

[Erdrick]

In this project I wanted to change my code desing to be more modular, so the classes should not contain the more variables and function than they need.

Thank you Brax for the code example, now I understand your point much better.
I think I may want to investigate the method you are talking about as my code gets more complex.

[Recoil]

Just throwing this out there because I just finished reading this: Game Programming Patterns

It really helped me get a better feel for how I was designing my engine, and how to better setup the architecture.  Following along the best I can with the code example, it looks like you are simply trying to break up the objects rendering from the object.  The section Design Patterns Revisited may be of interest in this situation, but the whole book is really good...and it's free to read

[Mortal]

i have tried it once, i was expected at least those classes would be an independent. but  i found myself i have to find a way for those classes class Graphic and class Object to be interacting. although, i ended up with some thing like Graphic::update and object::update which is, IMO, pointless.

i come up with a design that allow me to store update functions (logic parts) and render functions in arrays. c++ offers inheritance and virtual function to do it. but it has performance drawback. however, it can be done by help of Boost.Variant/Boost.Any + Visitor Pattern. for me i just created those boost classes from scratch for self-teaching as shown here. with simple example how it works.

[Brax]

Alright, thanks everyone for writing, and thanks recoil for the link, I will read it whole.
I will go with the route of less ressistance and combine the UI objects with drawing components. I do not intent to make them complex, so they can live with it. 

but  i found myself i have to find a way for those classes class Graphic and class Object to be interacting. although, i ended up with some thing like Graphic::update and object::update which is, IMO, pointless.

You do need to compensate for decoupleing objects from drawing. It may look pointless to write two functions that do almost identical thing, but as I said, the perk of decoupleing is to make smaller objects, making them easier to manipulate.

As for their mutual interaction, that is why my objects have an ID variable (simple unsigned int) within them, so the graphic class could know which sprite (or sf::RectangleShape) belongs to which object. It is indeed obvious to me that this aproach can have preformanse impact - graphic class first needs to find a coresponding ID within the std::map before it can update the spirte, and that thing alone can be bad.

But I will not bother with optimisation just yet. I will do so when my FPS drops bellow 30 with 50 drawn objects. In release mode.