On 5/27/07, Dirk Reiners <[EMAIL PROTECTED]> wrote: > > Hi Dan, > > Daniel E. Shipton wrote: > > Excuse the top posting.. > > ? > > > I think that a better option would be to get rid of all the legacy > > code for 2.0. Having just finished a big project that was using 2.0 I > > I assume it was using 1.0 (actually I know it was ;).
??? Don't understand what your saying. The project began its life as a 1.0 application. We needed some of the 2.0 features for it so I was faced with a choice: use the 1.0 compat bits or port it to 2.0. I chose the compat bits....in hindsight, this was a mistake because the 1.0 compat bits don't work well and are a hassle. > > > can tell you that trying to make your old 1.x code work with 2.0 is a > > huge pain...and frankly not worth the hassle. > > > > A better option would have been to spend the few days to port > > everything to 2.0 In the end I probably spent just as much time > > fighting all the deprecated interfaces, OSG_1_COMPAT, and deprecated > > properties to make them work properly. > > Can you elaborate on that a little bit? What didn't work, what problems did > you > have making it work with the compats defined? It has been a while since I trudged through that part....but from what I recall: missing API parts from 1.0 needed my own wrapper for begin/end edits osg_1_compat introduced endless loops in commitChanges halfway through the project...(hence what the original message is about) lack of documentation for porting I'm sorry that I don't remember the specifics of what was missing/etc... I simply remember it was a *big* hassle and a full port to 2.0 would have been easier and less buggy. > > > Having one codepath is really in everyones *best* interest. There are > > to many permutations to test thoroughly as it stands. > > > > So here are my suggestions: > > 1. Get rid of enable_osg1_compat > > 2. Get rid of disable_deprecated > > 3. Get rid of enable_deprecated_props > > All of those should be one define, to keep things simple. Don't we have better things to spend our time on than hobbling 1.x support forward? As soon as someone takes advantage of the 2.0 features or writes code in the new 2.0 style it won't run/compile again on 1.x. Making the 1.x compatibility features work correctly in 2.0 will just delay 2.0 even more. > > > 4. Write a GOOD porting guide that covers how to change the 1.x code > > into 2.0 code > > Can you give us some hints what that means? Right now I think you're the one > with the most experience in that regard. I have harped on this before....but this porting guide would include: when to call commitChanges() API calls that have changed in 2.0 ( I know there is an incomplete list somewhere ) any small caveats ( SceneFileHandler::the()->read() changed for example ) typecasting traversing the scenegraph using boost::bind 2.0 best practices Info on the RenderTraversalAction > > > Having reflected my last project I also have some other suggestions. > > > > 1. Get rid of the RenderAction (yet another code path) > > Agreed. > > > 2. Documentation for 2.0 creating,editing FC's in 2.0 (ex. FClusterLocal!) > > FCClusterLocal is actually a big improvement over 1, where those were > hard-coded > into the Cluster lib. Why you ran into those problems is an open question (did > you open a ticket for it BTW?). Carsten, (bless his soul) gave me that hint and I fixed all of the problems related to GlIds being shared across clusters. There are probably some still left (I know there are 2 texture bugs ....and will open a ticket for them) -dan -- Daniel E. Shipton Software Engineer, Infiscape Corp. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
