Archived

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

do your objects draw theselvs?

This topic is 5505 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

In most genras ?sp? for games, either the objects draw themselves or some ''mother'' draws them all. How does this norally work? How does yours work? How does this work in an RTS style game? What about a 3D shooter, kinda game? thanx for the coments/help in advance! tazzel3d ~ Dwiel

Share this post


Link to post
Share on other sites
Ususally its done with classes, and each object has a velocity, acceleration, etc. The objects are then put in a linked list or an array, and you have a loop that will draw each one, for every game frame.

- master_ball

----------------------------
We R 138

Share this post


Link to post
Share on other sites
If you have one centralized entity drawing your specialized objects sooner or later you''re going to run into problems. Rendering a billboard is different from rendering a static LOD model, which in turn is different from rendering terrain which is different from rendering indoor geometry. If you stick a lot of specialized code in one class in order to add a new object you''re going to have to modify this class which very soon will become very hard to maintain. Even more, if you decide to reuse your terrain code and use it in another engine you''re going to have to do a lot of cutting and pasting.

If you stick your specialized code into specialized classes, all the problems above disappear. Objects are responsible for rendering themselves and specialized code is located where it belongs. This makes your code a lot easier to maintain, understand, and reuse. A good idea is to create an interface (something like IRenderable) that defines general methods necessary to render an object. Then have all your specialized objects inherit this interface. This way you can stick all the specialized rendering code into your objects, but at the same time you can have a cetralized place (your scene graph) easily access all renderable objects without caring who/what they are.

Share this post


Link to post
Share on other sites
What if you set up any specialized renderor classes that rendered each of your objects. for exaple one for all your charactors, one for all of your walls/floors/etc one for all of your explotions, etc?

Is this equally not as good?

If all similar objects are rendered by one class, coul you not implement many more optimizations than if they all rew themselvs? For example, lets say that you are making an RTS and 30% of the tiles are tile A. When each object draws itself, each tile A might have a different kind of tile rendered before and after. This means that you will have to change the current texture many times. If one class draws them all for you, it can order them so that it draws all of the tile A''s at one time as to not have to re-set all of the textures/FVF modes/shaders. Would this not be much faster?

tazzel3d ~ dwiel

P.S. thanx for the quick help!

Share this post


Link to post
Share on other sites
quote:
Original post by Tazzel3D
If all similar objects are rendered by one class, coul you not implement many more optimizations than if they all rew themselvs? For example, lets say that you are making an RTS and 30% of the tiles are tile A. When each object draws itself, each tile A might have a different kind of tile rendered before and after. This means that you will have to change the current texture many times. If one class draws them all for you, it can order them so that it draws all of the tile A''s at one time as to not have to re-set all of the textures/FVF modes/shaders. Would this not be much faster?



Use some kind of tree to order all your objects by streamsource, vertex/pixelshader, texture, material, render/texturestagestates. Then move through the tree, setting all states for each node, and when you reach a leaf, you let all the objects draw themselves into their vertexbuffer. When you exit the leaf, you can draw the buffer (or do it each time its full, while looping through the objects). Similarly you could let the objects just fill an indexbuffer, or whatever.

Share this post


Link to post
Share on other sites
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...

If we order the tree by position, we defeat the whole purpose...

I don''t really unerstand how this would be a good idea....

thanx for the quick response and I love bieng able to discus some of my funamental concepts...

tazzel3d ~ dwiel

Share this post


Link to post
Share on other sites
It''s a tree of states so that each object won''t need to switch the current state to what it needs and then render itself. This would cause a huge number of state changes, which is bad. So the tree optimizes this by grouping the objects according to the states that they require and draws them at the same time.

Share this post


Link to post
Share on other sites
So is this tree generated every frame or at the start up? what are soe ore of the details...

if A: you are loading at the start up, you''ll have a large tree with any objects in it and will need to traverse something mosterous just to render a couple of things (possibly)

or if B: you create the tree real time, isn''t this extremely time consuming? If not, how do you do it!?

Thanx for the quick responses again! and also thanx for your perseverience ?sp?

tazzel3d ~ dwiel

Share this post


Link to post
Share on other sites
It''s mostly personal preference. If doing it one way makes much more sense to you or fits into your overall design more elegantly, do it.

If you''re a big OO guy then having a mother class that draws the geometry of other objects could be seen as breaking encapsulation, complicating interface and increasing class interdependency.

One case where it definitely helps to have a mother class doing the drawing is when you have a very complex scene and state changes are affecting performance (state changes are things like turning lighting on/off, binding textures, etc - whatever changes the state of the rendering machine). In that case it''s probably better to have some mother class that arranges/draws all your geometry by render state (such as the tree that Dynaguy and MagicScript mentioned) to minimize state change overhead.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites