Directx Organization Techniques w/ C++
Author
Hi,
I've been trying my best to sort out projects and have come into my first big obstacle. Is there a popular way to organize a directx project? If so please explain or provide links thanks!
My problem:
I have begin_render() and end_render() functions. anything inbetween gets rendered. However, this architecture requires me to hard code everything to be rendered with individual object.draw() calls.
In games, I'm assuming that after each loop of logic is processed, a call is made to render() everything. when thousands of objects have the opportunity to be drawn, how does the programmer tell render() what and what not to draw? I hardly think that each object is passed as an argument. but possibly passed as a list of pointers? so in essence you'd update the list every refresh?
My question:
Architecturally, what's the best way to design with the above problem kept in mind?
what about gruoping the objects in arrays or even more, creating classes
for similar objects, then in a simply cycle you can render a lot of objects :)
for similar objects, then in a simply cycle you can render a lot of objects :)
Author
well in most games, a single frame has tons of objects. would code for this game look like:
Render(arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg.......................... and so on)
?
Or perhaps have inside render class keep track of ALL the games object states, followed by an if statement for each object. Then, an object(or array of said object) would be drawn depending on it's state.
The trickiest part of this problem is when you have multiples of an object, but just want particular ones drawn. I am now thinking that having if statements and linked lists is the solution, having the state of each linked list updated constantly.
Render(arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg, arg.......................... and so on)
?
Or perhaps have inside render class keep track of ALL the games object states, followed by an if statement for each object. Then, an object(or array of said object) would be drawn depending on it's state.
The trickiest part of this problem is when you have multiples of an object, but just want particular ones drawn. I am now thinking that having if statements and linked lists is the solution, having the state of each linked list updated constantly.
Here is where scenegraph, occlusion trees comes into play.
Generally, I would put every renderable object for that level in the scenegraph and the occlusion tree. Then base on the current position/culling, the scenegraph/occlusion tree automatically handles what needs to be drawn and what effects should be used.
Generally, I would put every renderable object for that level in the scenegraph and the occlusion tree. Then base on the current position/culling, the scenegraph/occlusion tree automatically handles what needs to be drawn and what effects should be used.
I think you misunderstood what afsajghfd was saying.
You can put all renderable objects in some sort of list (like an array or an std::vector) and then iterate over that list, drawing all objects that are visible. Something like:
Of course, this is a bit oversimplified and can be improved (for example, by using an std::vector instead of the array, or a more advanced data structure like a quadtree), but it demonstrates the basic idea.
You can put all renderable objects in some sort of list (like an array or an std::vector) and then iterate over that list, drawing all objects that are visible. Something like:
Renderable* renderList[50];// Add objects to render list...//...for (int i = 0; i < 50; ++i) { Renderable &obj = renderList; if (isVisible(obj)) obj.render();}Of course, this is a bit oversimplified and can be improved (for example, by using an std::vector instead of the array, or a more advanced data structure like a quadtree), but it demonstrates the basic idea.
Whilst it isn't the only way of doing things, following the basic principles of object-oriented programming will solve this elegantly. If you're not familiar with inheritance, cohesion, interfaces, polymorphism, coupling etc...etc... then you would be well advised to grab a book on the subject.
The difficult question usually arises when you consider "who" renders an object. Do you have a 'manager' object that can render an object, or does an object know how to render itself? Getting a clean architecture with loose coupling and good seperation of concerns is tricky if you also want an intuitive and extensible design.
hth
Jack
The difficult question usually arises when you consider "who" renders an object. Do you have a 'manager' object that can render an object, or does an object know how to render itself? Getting a clean architecture with loose coupling and good seperation of concerns is tricky if you also want an intuitive and extensible design.
hth
Jack
Author
Thanks for all the tips.
I'm going to build a manager class that keeps track of all objects. Taking advice of inheritance, I'll put all renderable objects in a list of the same base type. Then I'll pass a pointer to this list to render() and iterate through a loop to draw each one. The object manager can also be in charge of updating the orientation of all the objects.
Thanks! this is a good start. I'll check out the quad tree and the other advice.
I'm going to build a manager class that keeps track of all objects. Taking advice of inheritance, I'll put all renderable objects in a list of the same base type. Then I'll pass a pointer to this list to render() and iterate through a loop to draw each one. The object manager can also be in charge of updating the orientation of all the objects.
Thanks! this is a good start. I'll check out the quad tree and the other advice.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
