From sehyo@netcom.com Thu Oct 7 18:41:29 1993 From: sehyo@netcom.com (Sehyo Chang) Message-Id: <9310080141.AA07621@netcom3.netcom.com> Subject: Performer API To: info-performer@sgi.sgi.com (Performer Mailing List) Date: Thu, 7 Oct 93 18:41:46 PDT Status: OR I am interesting in interface to Performer from non-C application. Is this will be easy to accomplish it? thanks From jimh@surreal Fri Oct 8 00:21:05 1993 Message-Id: <9310080720.AA22941@surreal.asd.sgi.com> To: sehyo@netcom.com (Sehyo Chang) Cc: info-performer@sgi.sgi.com (Performer Mailing List) Subject: Re: Performer API Date: Fri, 08 Oct 93 00:20:58 -0700 From: Jim Helman Status: OR While we only provide C bindings, customers have used Performer from Scheme and Ada. It's mainly a matter of going through the tedious task of creating foreign function wrappers for every Performer routine you want to call from your language and creating data structures (e.g. pfSegment, pfSegSet) which match the exposed C structures used in Performer's C API. If your language is f77, mkf2c(1) can generate the wrappers for you. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From moore@wrc.xerox.com Fri Oct 8 09:25:28 1993 Message-Id: <9310081625.AA12640@gargar.wrc.xerox.com> To: info-performer@sgi.sgi.com (Performer Mailing List) Cc: sehyo@netcom.com (Sehyo Chang) Subject: Re: Performer API Date: Fri, 8 Oct 1993 09:25:00 PDT From: "Lee C. Moore" Status: OR Re: languages to access the Performer API Althought it is pretty obvious, I will mention that it is easy to write C++ applications that access Performer's API. As I understand it, there is an irony here because Performer is actually written in C++ not C. Lee Moore From darken@enews.nrl.navy.mil Fri Oct 8 09:48:22 1993 Date: Fri, 8 Oct 93 12:45:50 -0400 From: darken@enews.nrl.navy.mil (Rudy Darken) Message-Id: <9310081645.AA07144@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com Subject: Performer API Status: OR Speaking of Performer and C++, why doesn't SGI release the C++ bindings as well as the C? Would this be of interest to many customers? It certainly would to us. rudy _______________________________________________________________ Rudy Darken <202> 767-6814 darken@enews.nrl.navy.mil The U.S. Naval Research Laboratory darken@seas.gwu.edu The George Washington University _______________________________________________________________ From jrohlf@tubes Fri Oct 8 10:09:17 1993 Date: Fri, 8 Oct 93 10:09:08 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310081709.AA03771@tubes.asd.sgi.com> To: darken@enews.nrl.navy.mil (Rudy Darken), info-performer@sgi.sgi.com Subject: Re: Performer API Status: OR >Speaking of Performer and C++, why doesn't SGI release >the C++ bindings as well as the C? Providing clean C++ bindings is far more difficult than providing clean C bindings and is not simply a matter of shipping .h files. It is even harder to provide extensibility through subclassing because you must rigorously define all interfaces. The initial Performer release schedule was ridiculously short for such a large software project. If we had concentrated on a nice C++ interface then you would probably have just recently received your Performer 1.0 CD in the mail. As is often the case, a conspiracy of schedules dictated the product. We have received more interest in C++ bindings than we originally thought so we will probably do it in the future. Actually, it is probably best that we wait because we can let the product mature for a while at which time it will be easier to produce a rigorous and stable C++ API. From marrou@indy.vsl.ist.ucf.edu Fri Oct 8 15:22:39 1993 Date: Fri, 8 Oct 93 18:22:41 -0400 From: marrou@indy.vsl.ist.ucf.edu (Lance Marrou) Message-Id: <9310082222.AA23794@indy.vsl.ist.ucf.edu> To: "Lee C. Moore" , info-performer@sgi.sgi.com (Performer Mailing List) Subject: Re: Performer API Cc: sehyo@netcom.com (Sehyo Chang) Status: OR >Althought it is pretty obvious, I will mention that it is >easy to write C++ applications that access Performer's API. Some aspects is a little more difficult than you might lead someone to believe. I have an object oriented visual and dynamics system and my only problem is the function callback mechanisms; specifically, pfInitPipe() and pfChanDrawFunc() in multiprocessing modes. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lance R. Marrou -- IST Visual Systems Lab -- E-mail: marrou@ist.ucf.edu From guest Mon Apr 25 14:09:06 1994 From: greg@vsl.ist.ucf.edu (Greg Wiatroski) Message-Id: <9404252106.AA01433@flash.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: Passing C++ member functions to Performer functions Status: O Does anyone out there know of a way to pass member functions to Performer calls like pfInitPipe, pfChanCullFunc, and pfChanDrawFunc that need a user provided callbacks? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Greg Wiatroski Institute for Simulation and Training University of Central Florida =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From guest Fri May 6 13:17:20 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9405062017.AA13417@tubes.asd.sgi.com> Subject: Re: Passing C++ member functions to Performer functions To: guest (Greg Wiatroski) Date: Fri, 6 May 94 13:16:59 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9404252106.AA01433@flash.vsl.ist.ucf.edu>; from "Greg Wiatroski" at Apr 25, 94 5:06 pm X-Mailer: ELM [version 2.3 PL8] Status: OR > > Does anyone out there know of a way to pass member functions to > Performer calls like pfInitPipe, pfChanCullFunc, and pfChanDrawFunc > that need a user provided callbacks? > Where are you Bwana Bob? From guest Fri May 6 22:20:55 1994 From: "Bob Buckley" Message-Id: <9405061837.ZM6199@grimmy.mss.ctaeng.com> Date: Fri, 6 May 1994 18:37:47 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Passing C++ member functions to Performer functions Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 3915 Status: O On May 6, 1:16pm, John Rohlf wrote: > Subject: Re: Passing C++ member functions to Performer functions > > > > Does anyone out there know of a way to pass member functions to > > Performer calls like pfInitPipe, pfChanCullFunc, and pfChanDrawFunc > > that need a user provided callbacks? > > > > Where are you Bwana Bob? > >-- End of excerpt from John Rohlf This questions has come up enough to get it into the FAQs. This came up when I was trying to create an ownship that could bring alongs it's own functionality. I implemented an F-18 Hornet with it's own geometry and Heads-Up-Display (HUD). I only set it up for a Node callback but the technique can be applied equally well to the system commands like InitPipe - with one VERY important catch!!!!! I created the following: // // A HUD Pass Thru Data Structure // typedef struct { float speed; float heading; float pipper_x, pipper_y; . . . // All the info required by the HUD } HUDPt_s; // // An F18 Hornet Class // class F18 : public FighterAircraft { protected: pfDCS *hud_dcs; // The HUD pfDCS HUDPt_s *hud_pt; // HUD Pass thru data public: F18(void); ~F18(void); // // The following are all called in the DRAW Process from // the HUDPreDraw and HUDPostDraw Callbacks // static void InitHUD(void); // Called only once static void RenderHUD(void *); // Dynamic Components static void RenderStaticHUD(void *);// Static Components // // The Node CallBacks // static long HUDPreDraw(pfTraverser *, void *); static long HUDPostDraw(pfTraverser *, void *); }; // // F18 Constructor // F18::F18(void) { // // Load up the Node Geometry // pfGroup *grp = (pfGroup *) LoadFlt("f18hud.flt"); hud_dcs = pfNewDCS(); pfAddChild(hud_dcs, grp); // // *** Setup the CallBacks *** // pfNodeTravFuncs(hud_dcs, PFTRAV_DRAW, (long (*)(pfTraverser *, void *)) F18::HUDPreDraw, (long (*)(pfTraverser *, void *)) F18::HUDPostDraw); // // Setup the Pass Thru Data // (All you have to do is set this structure before calling // pfFrame and Performer will handle it getting passed into the // CallBack functions as a parameter. // hud_pt = (HUDPt_s *) pfMalloc(sizeof(HUDPt_s), pfGetSharedArena()); pfNodeTravData(hud_dcs, PFTRAV_DRAW, (void *) hud_pt); } Cool? ... Cool! The BIG Catch to passing Member Functions Pointers is that Performer can make the call to the function with no problem but because of the scope involved there is no member data associated with the call! It's just a plain old function call. Think about it, you create objects in the App process and initialize them. The call back is called in the draw process - No member data! Hence, you either have to use pass thru data with nodes or use Performer or Irix Shared memory that is visible to the callback functions. The problems invloved with using shared memory is that you get into buffer coherency problems. The data in shared memory can be upto 4 frames newer than what is currently being drawn. Solution - Multibuffer in shared memory - well one solution anyways. Remember not to use any Member data in your Member Functions that are used in different processes. The other thing that comes to mind is that pfInitPipe doesn't have a data pass thru capability - but it has been suggested to the Performer Team. Hope this helps! P.S. Greg my codes there, go take a look at it! DIS_F18.h++ & DIS_F18.c++ =========================================================================== 'Bwana' Bob Buckley CTA, Inc. Sr. Software Engineer 5670 Greenwood Plaza Blvd Visual Systems Englewood, CO 80111 (303) 889-1207 (303) 889-1200 bbuckley@ctaeng.com (303) 889-1398 Fax =========================================================================== From guest Mon May 2 20:22:15 1994 Date: Mon, 2 May 1994 20:23:29 -0700 From: ptinker@netcom.com (Peter A. Tinker) Message-Id: <199405030323.UAA29837@netcom.com> To: info-performer@sgi.sgi.com Subject: new and delete Status: O I hope I'm not covering old ground here. I don't see anything in the FAQ about it. I'm running Performer 1.2a with a C++ application. My application overloads 'new' and 'delete' for some fancy memory management. It appears that Performer also overloads 'new' and 'delete'. Depending on what gets linked/referenced first, I get my new/delete or Performer's new/delete, and chaos reigns! I hope I'm doing something wrong, and that the something wrong isn't "overloading new and delete." Has anyone else encountered or worked around this problem? Pete Tinker (ptinker@netcom.com) Director, Application Development, Xtensory, Inc. Xtensory, Inc. Xtensory, Inc. P.O. Box 5103 140 Sunridge Drive West Hills, CA 91308 Scotts Valley, CA 95066 (818) 346-4253 (408) 439-0600 From guest Thu May 5 16:50:05 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9405052350.AA12444@tubes.asd.sgi.com> Subject: Re: new and delete To: guest (Peter A. Tinker) Date: Thu, 5 May 94 16:50:10 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <199405030323.UAA29837@netcom.com>; from "Peter A. Tinker" at May 2, 94 8:23 pm X-Mailer: ELM [version 2.3 PL8] Status: OR > > I hope I'm not covering old ground here. I don't see anything in the > FAQ about it. > > I'm running Performer 1.2a with a C++ application. My application > overloads 'new' and 'delete' for some fancy memory management. It > appears that Performer also overloads 'new' and 'delete'. Depending > on what gets linked/referenced first, I get my new/delete or > Performer's new/delete, and chaos reigns! > > I hope I'm doing something wrong, and that the something wrong isn't > "overloading new and delete." Has anyone else encountered or worked > around this problem? > You caught us in an unneighborly act. We do indeed overload new and delete but only delete should be visible to you. The next release will fix this but for now, modify your link order so that your delete gets used. Then you'll need to delete Performer memory for us which is easy: long addr = (long)pfGetSharedArena(); long size = (long)pfGetSharedArenaSize(); if (p >= addr && p < addr+size) afree(p, addr); else free(p); Let me know how this works for you.