do your objects draw theselvs?

Started by
13 comments, last by Dwiel 21 years, 4 months ago
Dobbs: You stated that having a "mother" class to render other classes'' geometries could be seen as breaking encapsulation, complicating interface and increasing class interdependency. How would you avoid this by having each class draw itself? Wouldn''t that require that each class have a pointer to Textures and Vertex Buffers, as well as the rendering Device? This would require that each class know how to render, which seems counter to the goal of OO. Can someone please explain this further?
Advertisement
quote:Original post by Tazzel3D
Wouldn''t the tree be inefficient, because it would need to be fully traversed to find all of the nodes, but only some of them would be rendered? And even if you make a tree of your potentially visible set, I don''t think that it would be very quick and would end up slowing down the prosess...


You''d need to traverse the whole tree, that''s right. But that''s really no big deal compared to minimizing state changes.

The tree is only used for rendering. It doesn''t need to be rebuilt every frame. You only need to have fast insertion/deletion. You could even use several trees, one for static objects, one for dynamics, etc, which could even have different underlying structures for storing the data, so a static tree would have slow insertion/deletion, but very fast traversal.
It all depends on how you design your engine/game.

Personally I think it''s bad design to have your objects take care of their own drawing.

Why? Well a game object such as a sprite or a model is pure data. It has no attachments to the game engine specifically unless you begin to implement game engine specific functionality into the classes such as rendering, or input. This means as long as you don''t implement such functionality the model/sprite class will be able to be re-used at a later point in time. This gets to be a big plus especially if you''ve written a image/model loader.

It is much more effective to design your game engine with a manager type of interface where the manager determines which game objects need rendering, and then draws them if nessassary.

But then again this is just my opinion. Everyones got one.
yeah, I was thinking about it at school, (the only thing it''s good for, is planning programing projects) and was thinking that if the objects drew themselvs, first of all, they would have to have information about the device and such. they would also not be copatible in other programs I wanted to borrow the code for. Basically what the AP said...

I think I will probobly do something like Dynaguy explained with trees for dynamic and static data.

Oh... I just got a great way to render my world.... I''m going to have everything be rendered by one class, but it works best this way, for well I won''t explain unless someone really cares...

thanx for all of the insightful coments and ideas!

tazzel3d ~ dwiel
We''re all here to hear each others'' ideas and comment on or be inspired by them, so out with it!

This topic is closed to new replies.

Advertisement