How does your renderer work?
I am having trouble designing mine so I wanted to see some examples to get some idea of how to make it. So please post yours.
*note* bye renderer I meant class/structore whatever in charge of rendering your game objects.
Yo tambien quiero el knowledgo.
(I also want t3h knowledg--o. Didn't know spanish for knowledge)
Hey Ainokea, who you votin for? Politics different outside the continental US? Which uh, island you on?
Yo quiero panqueques.
EDIT: I did respond, responded by saying that I don't know the answer and would appreciate it if somebody else would answer. Also, I forgot aboot PM system.
[Edited by - Boku San on October 3, 2004 1:09:25 AM]
(I also want t3h knowledg--o. Didn't know spanish for knowledge)
Hey Ainokea, who you votin for? Politics different outside the continental US? Which uh, island you on?
Yo quiero panqueques.
EDIT: I did respond, responded by saying that I don't know the answer and would appreciate it if somebody else would answer. Also, I forgot aboot PM system.
[Edited by - Boku San on October 3, 2004 1:09:25 AM]
Quote:Original post by Boku San
Yo tambien quiero el knowledgo.
Hey Ainokea, who you votin for? Politics different outside the continental US? Which uh, island you on?
Yo quiero panqueques.
Im under 18 I dont vote. No politics are about the same and I am on the big island, now why are you posting instead of pming the question?
Quote:Original post by Ainokea
I am having trouble designing mine so I wanted to see some examples to get some idea of how to make it. So please post yours.
*note* bye renderer I meant class/structore whatever in charge of rendering your game objects.
Hmmm well simply taking a peek at others might not be what you are after.
Usually you should start out with what features you want to implement on the rendering side (like what type of game is it going to be for, the renderer will be different for an fps and rts). Then work your way into how should the game talk to the renderer, pass the objects to render. This will also depend on the game genre. In the case of rts's you have many little models (units), so passing just one model and an instancing system would probably be nice. In the case of FPS's your world would be your biggest concern, is it going to be terrain (dynamic data to renderer, LOD) or is it just indoor. What effects are you going to need to render, particle systems, etc.
Maybe if you posted some requirements, you would get a better response on how to design an efficient renderer for what you want.
HTH
There's an article here called "abstracting your renderer" or quite similar to that.
The author sets up basic requirements and makes them abstract enough to be used with DirectX or OpenGL.
Basically he has an interface for the Renderer, Textures and Vertex Buffers.
I built my new system kinda like this too. I made an DX8 and DX9 render module and have a half working OpenGL module too. All of those reside in DLLs and can be switched during runtime.
I also added a basic Mesh class (for simple object loading and dynamic modification), which has functions like AddFace and can be used as source for a vertex buffer. I avoided to have a basic vertex structure as for different vertex formats.
This renderer is just a rendering system for abstracting the API. There's no entity manager on top. If i decide to add one it will be a separate class, you shouldn't mix those too.
The rendering class has functions like initialize, loadtexture, loadfont, createvertexbuffer and some simple display helpers for fast testing like renderquad, renderquad2d.
You might also want to take a look at existing renderers like OGRE or Irrlicht.
The author sets up basic requirements and makes them abstract enough to be used with DirectX or OpenGL.
Basically he has an interface for the Renderer, Textures and Vertex Buffers.
I built my new system kinda like this too. I made an DX8 and DX9 render module and have a half working OpenGL module too. All of those reside in DLLs and can be switched during runtime.
I also added a basic Mesh class (for simple object loading and dynamic modification), which has functions like AddFace and can be used as source for a vertex buffer. I avoided to have a basic vertex structure as for different vertex formats.
This renderer is just a rendering system for abstracting the API. There's no entity manager on top. If i decide to add one it will be a separate class, you shouldn't mix those too.
The rendering class has functions like initialize, loadtexture, loadfont, createvertexbuffer and some simple display helpers for fast testing like renderquad, renderquad2d.
You might also want to take a look at existing renderers like OGRE or Irrlicht.
I have seperate renderers for seperate types of objects.
For example, I have a renderer for meshes's, camera's, particle engines.
What happens at start up:
- Graphics: read settings file
- Graphics: create OGL renderer
- OGL: create MD2, Cam, Particle, menu renderer
- Mesh: register with OGL
- Cam: register with OGL
- Particle: register with OGL
- Menu: register with OGL
...
- OGL: render loop
- OGL: fetch object
- OGL: get object render type
- OGL: call specialised renderer
- Renderer: do stuff
In practise the loop looks as follows:
Every object is sorted by the renderer it needs. Camera's are sorted first, then meshes, particles and menus.
I think this is quite a neat manner of doing this.
For example, I have a renderer for meshes's, camera's, particle engines.
Graphics | ------------------- | | DX (for future) OGL | ---------------- | | | | Mesh Cam Part Menu
What happens at start up:
- Graphics: read settings file
- Graphics: create OGL renderer
- OGL: create MD2, Cam, Particle, menu renderer
- Mesh: register with OGL
- Cam: register with OGL
- Particle: register with OGL
- Menu: register with OGL
...
- OGL: render loop
- OGL: fetch object
- OGL: get object render type
- OGL: call specialised renderer
- Renderer: do stuff
In practise the loop looks as follows:
while ((o = (IDrawableInterface*)getNext())) { type = o->getRendertype(); if (type < MAX_RENDERERS) { r = renderers[type]; if (r) { if (oldRenderer != r) { if (oldRenderer) oldRenderer->deactivate(); oldRenderer = r; r->activate(); } r->render(o, ms); } } }
Every object is sorted by the renderer it needs. Camera's are sorted first, then meshes, particles and menus.
I think this is quite a neat manner of doing this.
For every viewport I have, run this loop (viewports are stored in rendering order):
0. Run this viewport's shader.
1. Render scene from the viewport's attached camera, using triangle ID's instead of textures.
2. Raytrace every pixel "owned" by this viewport. (Viewport stores a CPixel object for every pixel it owns to eliminate testing) Use the interface's pixel mask to blend/assign the color of pixels touched by an interface object.
3. (NOT YET IMPLEMENTED) Update global illumination. Im still thinking of ways to do this fast.
I know this isn't considered real-time bit it wont matter since my engine is designed for "future hardware." I am currently coding my viewport manager (for 2-player split screen, little boxes with other info or graphics in them, rear-view mirrors, or anything else game designers see fit for a new viewport) and then I can test the rendering speed. Ill update my web-site when I have a working demo or screenshots. Right now it only has info on the networking side of my engine. (BTW, I will eventually code a distributed processing system to take some of the load off the server and client)
0. Run this viewport's shader.
1. Render scene from the viewport's attached camera, using triangle ID's instead of textures.
2. Raytrace every pixel "owned" by this viewport. (Viewport stores a CPixel object for every pixel it owns to eliminate testing) Use the interface's pixel mask to blend/assign the color of pixels touched by an interface object.
3. (NOT YET IMPLEMENTED) Update global illumination. Im still thinking of ways to do this fast.
I know this isn't considered real-time bit it wont matter since my engine is designed for "future hardware." I am currently coding my viewport manager (for 2-player split screen, little boxes with other info or graphics in them, rear-view mirrors, or anything else game designers see fit for a new viewport) and then I can test the rendering speed. Ill update my web-site when I have a working demo or screenshots. Right now it only has info on the networking side of my engine. (BTW, I will eventually code a distributed processing system to take some of the load off the server and client)
I've found it very nice to think of the whole thing as a pipeline. Minimazing the connection between the objects.(Ok. That wasn't something new, I admit. But I find it handy :))
Quote:Original post by Ainokea
I am having trouble designing mine so I wanted to see some examples to get some idea of how to make it. So please post yours.
*note* bye renderer I meant class/structore whatever in charge of rendering your game objects.
i have an abstract class CMesh that has a Draw() function
all 3d render objects are derived from it
to render:
i have a class C3DDevice that wraps all the 3d functionality needed, all i do is call C3DDevice->Draw(CMesh *mesh), the reason behind it is cuz the device also polls the tri, and vertex count of the mesh and adds it to its private statistics
Quote:Original post by Endurion
There's an article here called "abstracting your renderer" or quite similar to that.
Are you talking about this?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement