Irrlicht Renderer
Posted: Thu Jul 15, 2004 08:38
Okay, this is not as bad as it first seems 
The Ogre and D3D8.1 Renderers currently written are using the exact same approach for implementation, but this does not mean that all renderers have to (it was just easier for me to to it that way;))
What you need to do is implement two classes, a renderer and a texture. These classes need to provide definitions for some abstract methods in the base classes. If you look in the files include/CEGUIRenderer.h and include/CEGUITexture.h you can see the interface that you need to provide (look for the pure virtual methods).
Now I'll talk a little about the way the rendering actually proceeds. Each window within the system is asked to render itself, this is done using the Image/Imageset system which in turn calls a Renderer based object to queue quads; that is, at this stage nothing is sent to the screen. Once all the windows have done their drawing operations, the Renderer::doRender method is called, which will sort the queued quads into order (required for alpha blending support), and then finally sends the quads to the underlying API or engibe to be drawn. Now, one of the optimisations the system can offer is that if nothing within the Gui has changed, then there is no need for the windows to re-queue the same information, and as such that whole stage is skipped and the previous quad queue is used again. Which leads us to something else, the renderer needs to be able to disable the queueing and send quads directly to the display (this is done with the mouse cursor - so that simply moving the mouse does not trigger a total redraw).
The texture class needs to supply implementations for methods to create textures from files, memory, and empty textures.
It's worth pointing out that obviously these classes can optionally do other things which relate to the underlying engine, for example the Ogre renderer allows you to switch around where the Gui "layer" will appear in the final output and things such as that - these functions are not part of the Gui system itself, but are offered as some extra power to users of that particular engine (various other things are possible also).
So, where do you start? First of all you need to consider how Irrlicht does its rendering, and whether the Gui system (or more correctly, the client code) will need to initiate the call to 'CEGUI::System::renderGUI' (as what happens under direct3D), or whether the engine will handle this itself (like under Ogre). Depending on how things are structured, you'll need to make this call in line with the design ideals of the target engine (I have no idea atm, I haven't looked at Irrlicht
).
I'll now discuss the Renderer a little, so that you know what is going on (this references the Ogre renderer)...
The constructor (actually constructor_impl) basically does two things; it allocates and does any pre-initialisation of resources required for using the engine (in this case sets up a vertex format and allocates a vertex buffer), and then allocates two buffers; one is an array of structs that hold information about queued quads, and the other is an array of pointers to the objects in the other buffer (which is done for fast sorting - quicker to swap two pointers than two objects). I'll just mention that this QuadInfo structure is not actually part of the Gui system, but is an implementation detail - you can use any method you wish for queueing quads.
The addQuad method will do one of two things. If queuing is enabled, some preliminary work is done onthe input data (which is a desination screen area rectangle, a z co-ord (only really needed for quad sorting), a Texture pointer, a source texture co-ordinate rectangle, and a set of diffuse colour values (as a ColourRect)), and the quad is then stored in the next free QuadInfo in the array, and a pointer to that QuadInfo added to the 'pointer array'. If queuing is disabled, basically the same things happen, except that instead of queuing the quad, it is sent directly to the engine for rendering (which is done in an implementation method called renderQuadDirect).
The doRender method performs the actual rendering. First it sorts the quads (which only does anything if the quad list has changed since last time), then it initialises the required settings within the underlying engine, finally it sends the quads to the engine for rendering.
The other required methods offer methods to clear the render list, enable/disable/and check the state of queuing (on or off), and finally methods that create Texture based objects.
Your derived Texture class does not need to do anything special other than be able to load images / copy data from memory, as well as report basic information about itself (size etc). You also need to offer some means for your Renderer class to discover the 'real' texture, though this is an implementation detail.
I hope that this has given at least a little idea as to how things are supposed to work. If you need any help with specific areas, just let me know
CE.
The Ogre and D3D8.1 Renderers currently written are using the exact same approach for implementation, but this does not mean that all renderers have to (it was just easier for me to to it that way;))
What you need to do is implement two classes, a renderer and a texture. These classes need to provide definitions for some abstract methods in the base classes. If you look in the files include/CEGUIRenderer.h and include/CEGUITexture.h you can see the interface that you need to provide (look for the pure virtual methods).
Now I'll talk a little about the way the rendering actually proceeds. Each window within the system is asked to render itself, this is done using the Image/Imageset system which in turn calls a Renderer based object to queue quads; that is, at this stage nothing is sent to the screen. Once all the windows have done their drawing operations, the Renderer::doRender method is called, which will sort the queued quads into order (required for alpha blending support), and then finally sends the quads to the underlying API or engibe to be drawn. Now, one of the optimisations the system can offer is that if nothing within the Gui has changed, then there is no need for the windows to re-queue the same information, and as such that whole stage is skipped and the previous quad queue is used again. Which leads us to something else, the renderer needs to be able to disable the queueing and send quads directly to the display (this is done with the mouse cursor - so that simply moving the mouse does not trigger a total redraw).
The texture class needs to supply implementations for methods to create textures from files, memory, and empty textures.
It's worth pointing out that obviously these classes can optionally do other things which relate to the underlying engine, for example the Ogre renderer allows you to switch around where the Gui "layer" will appear in the final output and things such as that - these functions are not part of the Gui system itself, but are offered as some extra power to users of that particular engine (various other things are possible also).
So, where do you start? First of all you need to consider how Irrlicht does its rendering, and whether the Gui system (or more correctly, the client code) will need to initiate the call to 'CEGUI::System::renderGUI' (as what happens under direct3D), or whether the engine will handle this itself (like under Ogre). Depending on how things are structured, you'll need to make this call in line with the design ideals of the target engine (I have no idea atm, I haven't looked at Irrlicht
).
I'll now discuss the Renderer a little, so that you know what is going on (this references the Ogre renderer)...
The constructor (actually constructor_impl) basically does two things; it allocates and does any pre-initialisation of resources required for using the engine (in this case sets up a vertex format and allocates a vertex buffer), and then allocates two buffers; one is an array of structs that hold information about queued quads, and the other is an array of pointers to the objects in the other buffer (which is done for fast sorting - quicker to swap two pointers than two objects). I'll just mention that this QuadInfo structure is not actually part of the Gui system, but is an implementation detail - you can use any method you wish for queueing quads.
The addQuad method will do one of two things. If queuing is enabled, some preliminary work is done onthe input data (which is a desination screen area rectangle, a z co-ord (only really needed for quad sorting), a Texture pointer, a source texture co-ordinate rectangle, and a set of diffuse colour values (as a ColourRect)), and the quad is then stored in the next free QuadInfo in the array, and a pointer to that QuadInfo added to the 'pointer array'. If queuing is disabled, basically the same things happen, except that instead of queuing the quad, it is sent directly to the engine for rendering (which is done in an implementation method called renderQuadDirect).
The doRender method performs the actual rendering. First it sorts the quads (which only does anything if the quad list has changed since last time), then it initialises the required settings within the underlying engine, finally it sends the quads to the engine for rendering.
The other required methods offer methods to clear the render list, enable/disable/and check the state of queuing (on or off), and finally methods that create Texture based objects.
Your derived Texture class does not need to do anything special other than be able to load images / copy data from memory, as well as report basic information about itself (size etc). You also need to offer some means for your Renderer class to discover the 'real' texture, though this is an implementation detail.
I hope that this has given at least a little idea as to how things are supposed to work. If you need any help with specific areas, just let me know
CE.
