Home » Community » Forums » » 3D Game Engine Architecture Chapter 3
  Intel sponsors gamedev.net search:   
[Control Panel] [Register] [Bookmarks] [Who's Online] [Active Topics] [Stats] [FAQ] [Search]

Add Forum to Favorites |  Send Topic To a Friend | View Forum FAQ | Track this topic


 Last Thread Next Thread 
 3D Game Engine Architecture Chapter 3
Post Reply 
Quote:
On some platforms if no hardware acceleration exists or a standard
API is unavailable, the programmer might even write the entire graphics system to
run on the CPU; the result is called a software renderer. Although current consumer
graphics hardware has a lot of power and obviates the need for writing software
renderers
on systems with this hardware, the ability to write software renderers is still
important—for example, on embedded systems with graphics capabilities such as cell
phones and handheld devices.



 User Rating: 1160   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
If the method were put in the protected section to prevent unintended use, then Node cannot call the function


What kind of rubbish is this? The whole purpose of protected methods is so that derived classes have access to internal methods of a base class!

Basically all the public methods marked for 'internal use' should in fact be protected methods.

 User Rating: 1263   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

"The issue is that SetParent is called by the Node class when a Spatial object is attached as the child of a node. No other class (or application) should call SetParent. If the method were put in the protected section to prevent unintended use, then Node cannot call the function. To circumvent this problem, Node can be made a friend of Spatial, thus allowing it access to SetParent, but disallowing anyone else to access it. In some circumstances, a Node-derived class might also need access to a protected member of Spatial. In the C++ language, friendship is not inherited, so making Node a friend of Spatial will not make the Node-derived class a friend of Spatial. To avoid the somewhat frequent addition of friend declarations to classes to allow restricted access to protected members, I decided to use the system of placing the restricted access members in public scope, but tagging that block with the “internal use” comment to let programmers know that they should not use those functions."

Try reading the whole paragraph. It's refering to the Node class calling a function on the Spacial class, hence if it were protected or private Node wouldn't be able to access it unless you get into the ugly mess of using friends.

 User Rating: 1168   |  Rate This User  Send Private MessageView ProfileView Journal Report this Post to a Moderator | Link

No the point is that Node derives from Spatial and thus will have access to any protected functions in spatial, and so the function could be made protected.

 User Rating: 1263   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

All times are ET (US)

Post Reply
 Last Thread Next Thread 
Forum Rules:
You may not post new threads
You may post replies
You may not edit your posts
You may not use HTML in your posts
Jump To:
Administrative Options: