Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

This topic is 5527 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''m practicing on doing design before actually coding my project. I''ve wrote out all my classes that I plan to use. Then I stopped as I ran into a problem. It''s rather trivial but.. RenderObj->Draw(Object) or... Object->Draw(RenderObj) Which is correct OOP, or is there a correct way at all? I personally favor the first line and I try to keep all graphics in one class and only allow my objects (that can be rendered) to manipulate their own data. The reason I questioned this is because I''ve looked at many a source that uses the 2nd line.

Share this post


Link to post
Share on other sites
Advertisement
I think you mean either:

GfxEngine->RenderObject(Obj);

or

Object->Render();

Both are valid OOP approaches. For large classes (such as models) I''d suggest the latter - have the object handle its own drawing.

For smaller objects (such as coronas for lights, etc), the first solution should do well.

Never do anything that is a waste of time and be prepared to wage long tedious wars over this principle - Michael O''Connor

Share this post


Link to post
Share on other sites
No I knew what I was typing just a poor choice in naming my objects. My renderobject is going to essentially be a gfxengine and because Im using d3d I have to provide access to the device object which is a member. From sources I''ve studied the coders perfer to encapsulate all the d3d graphics code into a class and then when an object needs to be rendered they pass a device pointer to a draw function.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Personally, I would go with the 2nd, because that allows individual objects to decide how they want to draw themselves. Drawing will probably require access to a lot of private variables, so if you do "RenderObj->Draw(Object)" then you''ll have to make all those private variables available to RenderObj. On the other hand, if you do "Object->Draw(RenderObj)", then you''ll have to make sure that RenderObj makes available all of its drawing functions. And I think the second one would be easier. Plus I think the graphics engine will be a lot more efficient if every object uses the same primitive drawing functions (because you can optimize those functions).

But remember, the thing about OO design is that there are no easy answers. Maybe for the type of game you''re doing, the first version would be a lot easier, so take my advice with some salt.

A good OO design is really difficult to find, but really valuable once you find it.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
an addition to my last post: If all your objects are in the same format (like, they are all 3d models that are stored in the same way), then the first line would be easier. As in, if the RenderObj->Draw function does the same thing for every object, then go with that.

But if RenderObj->Draw just contains a big switch() statement that says "if Object is this class, then draw this...", then you''re better off with option 2.

Share this post


Link to post
Share on other sites
why not have both?
i do...
ie) my quadtree can choose which "nodes" of my map to render, and does so with a loop and some frustum information

-eldee
;another space monkey;
[ Forced Evolution Studios ]


::evolve::

Do NOT let Dr. Mario touch your genitals. He is not a real doctor!

Share this post


Link to post
Share on other sites
my solution was to have a listener between the gfx and objects..
this way you sort of have the best of both worlds the app still defines how things are drawn (can save alot of headaches with VB/texture switching) while you still have to call draw on each individual object.. the only real problem with this solution is the increase in virtual method overhead but i think its a small price to pay

Share this post


Link to post
Share on other sites
Basically, do you want a renderer that knows how to render objects or objects that know how to use a renderer to render themselves? For the former, you have to expose more information about your objects. For the latter, you have to expose more information about your renderer. Which will make your project''s code cleaner? That is the ultimate question, isn''t it? OO''s purpose is to make your code cleaner. Pick whichever is cleaner in your framework.

Share this post


Link to post
Share on other sites
I would go with the first because the second means each object has to know where to find the RenderObj.

It doesn''t make semantic sense to have an object draw itself. screen objects (sprite) don''t draw themselves. They tell the drawer how to draw them. Further, the object doesn''t know if its visible to the camera and I wouldn''t fancy the kludge I would have to write in order to find out of the object was visible!

Share this post


Link to post
Share on other sites
Like the AP said, if the renderer draws the objects, then it has to have access to internal information. That makes it tightly coupled to the object types. Every time you make a change to an object type or add a new type, you have to update the renderer. That is generally a bad thing.

Share this post


Link to post
Share on other sites

  • 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!