On 8-Dec-05, at 5:38 AM, Nick Lockwood wrote:
Is it just me who thinks that switching to plugins is a retrograde
step?
Depends :)
Advantages of declares:
- Easy for end users to add features, such as additional commands
for obscure ARB extensions, or even support for other platforms
Actually, GL extensions are one reason to use a plugin. I'm not even
sure you can grab the function pointers properly on Windows with
declares (Mac OS X is not a problem here).
- Easy for end users to find and correct bugs
Agreed.
- Open source! Whoo! Freedom!
Well either one can be closed/open (though I guess you're referring
to existing open source GL declares). I personally only use open
source classes/plugins, though not so much for freedom*.
- No nasty DLLS deployed on end user's PC
That's been fixed in Rb2005 (plugins
- Reduced application size because unused code can be excluded
(slightly offset by poor RB code optimisation versus gcc, but we're
getting there)
This can go either way, but for 1:1 API mappings you're probably
right. Most GL apps use less than 20% of the API.
- When RB is updated to make x86-compatible fat binaries, code
based on declares will still work, but plugins will need a new version
Good point, though it's only one check box ;)
- Will still work even after developer gets bored and stops
supporting it (especially relevant given previous point)
*That's why I only use open source plugins (and only release open
source plugins myself!)
Advantages of plugins
- Slightly faster, sometimes
"Sometimes" is the key word here... The problem with real-time apps
like games is that function call overhead can become a measurable
bottleneck. Apple supplies alternate macro versions of the GL headers
for exactly this reason. So in this case I have a real problem with a
plugin that maps 1:1 with the API since that's two function calls per
GL call (macro headers aside for the moment as they may not be
practical to implement in a plugin). I also have a problem with
declares that are mapped 1:1 with the API, since that is again, 2
function calls per GL call.
What I do personally is abstract all the 3D functionally inside a
"renderer" interface that does its work in methods that may use
dozens of GL calls. Then I declare only the calls I need per-method
(duplicated where needed). A quick count shows this saves more than
50 function calls per mesh, and can easily save a couple hundred
calls for multi-pass meshes. That's thousands of function calls per
frame...
Yes this gets messy at times, but I manually inline GL state
management too so the code's a mess to begin with :) Needless to say,
I *really* want to see inline functions in Rb: <http://
www.realsoftware.com/feedback/viewreport.php?reportid=blhycmye>
Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|