Original Post
Sorry for the vague title, my whole question wouldn't fit, which is:
What's the point of having a single render device, when so many things need different ways of handling?
I'm trying to implement my own rendering system, really basic, Dx9 and all that, and from overhauling some of my old code, I've found out that out that the more I keep responsibilities of objects/functions separate, the easier I can maintain and extend stuff, pretty much what people recommend anyways.
That means:
Avoid monolithic do-it-all god classes, right? Yes.
Isn't a render device pretty much monolithic, that way if one wants it to be actually substantial, and not just some sort of delegate thing that shoves data between specialized components?
Or is that the point of one, after all?
So, isn't it better to have things like "GuiWindowRenderer", "FontRenderer", "3dRenderer" that could maybe act as plugins, or well, components for a big class?
Or would it be better to completely split those things and use them on their own, when one wants to render a GuiWindow instead of an actual ingame object?
The only need for a RenderDevice I can see that way would be a common framework like thing, that access backbuffers, and flips them and all that, but in that case the renderdevice is not the main hero, but the shadow sidekick.
So, what are the "rendering system" blocks one can see in engine design diagrams really?
I'm aware that that question is kind of a bad one, since a monolithic, rigid spaghetti-like monster class could do it all, and still pass as a rendering system, but let's say we don't want it that way...
Instead...would you make the components the stars, and have the device be some sort of low level widget?
Or have the components act more like scripts, or plug ins something that wants to be rendered can use?
Like with 2D GUI rendering, if it were a script, it could set the device to use an orthogonal view, and then feed it a stream of vertices, and material data.
Then, when it's time to render some scene object, a different view would be used, and so on.
So in short, I'm having trouble designing a sort of layout plan for responsibilities, what should depend on what, etc.
Any resources that focus on that particular topic?
(Again I apologize for vagueness, please act as if this topic never happened if it's too vague for you. Don't want people to feel like they put effort into a reply in vain)
What's the point of having a single render device, when so many things need different ways of handling?
I'm trying to implement my own rendering system, really basic, Dx9 and all that, and from overhauling some of my old code, I've found out that out that the more I keep responsibilities of objects/functions separate, the easier I can maintain and extend stuff, pretty much what people recommend anyways.
That means:
Avoid monolithic do-it-all god classes, right? Yes.
Isn't a render device pretty much monolithic, that way if one wants it to be actually substantial, and not just some sort of delegate thing that shoves data between specialized components?
Or is that the point of one, after all?
So, isn't it better to have things like "GuiWindowRenderer", "FontRenderer", "3dRenderer" that could maybe act as plugins, or well, components for a big class?
Or would it be better to completely split those things and use them on their own, when one wants to render a GuiWindow instead of an actual ingame object?
The only need for a RenderDevice I can see that way would be a common framework like thing, that access backbuffers, and flips them and all that, but in that case the renderdevice is not the main hero, but the shadow sidekick.
So, what are the "rendering system" blocks one can see in engine design diagrams really?
I'm aware that that question is kind of a bad one, since a monolithic, rigid spaghetti-like monster class could do it all, and still pass as a rendering system, but let's say we don't want it that way...
Instead...would you make the components the stars, and have the device be some sort of low level widget?
Or have the components act more like scripts, or plug ins something that wants to be rendered can use?
Like with 2D GUI rendering, if it were a script, it could set the device to use an orthogonal view, and then feed it a stream of vertices, and material data.
Then, when it's time to render some scene object, a different view would be used, and so on.
So in short, I'm having trouble designing a sort of layout plan for responsibilities, what should depend on what, etc.
Any resources that focus on that particular topic?
(Again I apologize for vagueness, please act as if this topic never happened if it's too vague for you. Don't want people to feel like they put effort into a reply in vain)
