Horde3D

Next-Generation Graphics Engine
It is currently 17.10.2018, 14:43

All times are UTC + 1 hour




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: 14.10.2013, 10:58 
Offline

Joined: 08.01.2008, 14:57
Posts: 66
I think we should change a little bit the way the Render Device, Renderer and Modules classes are in relationship.

At the moment, the structure is:

* Modules has a Render Device pointer. It also duplicate this pointer assigning its value to a global pointer (!!), called gRDI.
* Modules has also a Renderer.
* Renderer uses the Render Device through the global pointer (!!).
* Many classes uses the Render Device through the global pointer (!!).

So there are some kind of circular relationships which make a little bit hard to understand the ownership structure.

In general, it would be more clear and logical to give the ownership of the "Render Device" to the "Renderer" class and remove the ugly gRDI global pointer, so the general structure will become:

* Modules has a Renderer. No more Render Device pointer here (local nor global).
* Renderer has the Render Device with a simple method getRenderDevice().
* Many classes uses the Renderer and could access to the low-level Render Device through its getter.

Linear and logical. Isn't it?

I already have a working patch in my fork.

To provide a retro-compatibility layer, we can use a simple:

Code:
#define gRDI Modules::renderer().getRenderDevice()


And mark it as deprecated (with the idea to remove it in the future).


Last edited by Zuck on 15.10.2013, 10:02, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: 14.10.2013, 14:09 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1149
Location: Germany
I guess the reason why marciano has introduced the gRDI pointer was to avoid the function call overhead of Modules::renderer().getRenderDevice() all the time.


Top
 Profile  
Reply with quote  
PostPosted: 14.10.2013, 15:05 
Offline

Joined: 08.01.2008, 14:57
Posts: 66
I think that nowadays, with auto compiler optimization, the overhead is practically equal to zero. If not, we can manually cut it to zero simply inlining the getter:

Code:
inline RenderDevice* getRenderDevice() const { return _renderDevice; }


Top
 Profile  
Reply with quote  
PostPosted: 14.10.2013, 16:53 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1149
Location: Germany
If the RenderDevice becomes a member of Renderer, I guess it would be obvious to use it directly instead of accessing it through using Modules or do I miss something here?


Top
 Profile  
Reply with quote  
PostPosted: 15.10.2013, 10:08 
Offline

Joined: 08.01.2008, 14:57
Posts: 66
Yes, in fact inside the Renderer class it is used directly (except in the static functions, read below), but there are many classes the also use it for low-level rendering, so they can access it through the general "Module::renderer().getRenderDevice()" call.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group