Jump to content
  • Advertisement
Sign in to follow this  
NIm

OO question

This topic is 4376 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am programming in c++. I need to have a renderable class, containing a position and orientation, and a pointer to a model. My problem is this: display->draw(renderable r) does not have access to the private aspects of renderable. Nor does it have access to the data of model. How do I give display->draw() access to renderable wihtout giving the rest of my program access to renderable?

Share this post


Link to post
Share on other sites
Advertisement
Making it a friend would work, but that doesn't look like a good solution to me, that's just locally breaking open encapsulation.

The classic OO way would be to have the renderable render itself: renderable->render(display). If however this render-operation depends on both the (dynamic) type of the display and that of the renderable object, you need multiple dispatch. The visitor design pattern offers a solution to this problem (also see double dispatch).

Share this post


Link to post
Share on other sites

1) give Renderable getters to the relevant data
2) give Renderable a draw method which the display->draw(...) method calls

-me

Share this post


Link to post
Share on other sites
Quote:
Original post by Simian Man
Make it a friend.

That is a poor suggestion. In most cases, friend is the option of last resort.

One solution is to modify your design, making a distinction between game objects and renderable objects. A game object renders itself by handing a renderable object to the renderer.

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
Quote:
Original post by Simian Man
Make it a friend.

That is a poor suggestion. In most cases, friend is the option of last resort.

One solution is to modify your design, making a distinction between game objects and renderable objects. A game object renders itself by handing a renderable object to the renderer.


I did make a distinction between game objects and renderables, that's why they're called renderable rather than spacecraft element. The renderable needs to have a model(so you know what to draw), a position(so it knows where to draw it), and an orientation(so it know how to rotate it). All these things are updated using methods that renderable has.

To draw a spaceshippart, you call graphics->draw(renderable).

So I do pass the renderable to the draw function, as you said. Once draw has the renderable, how do I get the model out of it? and how do I then get the data out of the model?

Share this post


Link to post
Share on other sites
I couold see why you'd want to make the mesh data private but could you maybe allow the renderable object to return a deep copy of the mesh?

Share this post


Link to post
Share on other sites
My idea of a Display should know how to draw dumb primitives (not necessarily a complete Model), not a generic Renderable.
A method of Renderable, say "render", taking a Display as a parameter should ask that Display to draw Models or other primitives.
This would allow encapsulation of Model instances that are created or modified on the fly, shared, switched, etc.
Moreover, Renderables that are composites, decorators etc. could delegate their rendering to other Renderables without twisty callbacks and undue visibility of their nature.

Share this post


Link to post
Share on other sites
Quote:
Original post by NIm
Quote:
Original post by JohnBolton
Quote:
Original post by Simian Man
Make it a friend.

That is a poor suggestion. In most cases, friend is the option of last resort.

One solution is to modify your design, making a distinction between game objects and renderable objects. A game object renders itself by handing a renderable object to the renderer.


I did make a distinction between game objects and renderables, that's why they're called renderable rather than spacecraft element. The renderable needs to have a model(so you know what to draw), a position(so it knows where to draw it), and an orientation(so it know how to rotate it). All these things are updated using methods that renderable has.

To draw a spaceshippart, you call graphics->draw(renderable).

So I do pass the renderable to the draw function, as you said. Once draw has the renderable, how do I get the model out of it? and how do I then get the data out of the model?


To recapitulate the 3 answers provided to you:

1. Make renderable a friend (Simian Man, but I consider this bad advice)
2. Provide accessor functions to all necessary data (Palidine)
3. Turn things around and have Renderable draw itself; it has access to its own data, and in general, OO means you put behavior where your data is (Palidine, LorenzoGatti and myself). I consider this to be the best option, since it gives you the most flexibility (code is always more general/flexible than data, so instead of having Renderable just raw data, have it be code). Also, if you have several kinds of display, and you need dynamic dispatch on the type of display, I again refer you towards the links about multiple dispatch above.

Share this post


Link to post
Share on other sites
Why is it such a bad idea to make draw() a friend?

Thank you for your other answers. I don't like providing accessors, as if I do this, then all other parts of the program can get to it too, and I don't want that. the data is part of the implementation, not the interface.

I like the idea of making renderable able to render itself, but this requires a redesign. Thank you for your help.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!