Bob Buckley (bbuckley++at++grimmy.mss.ctaeng.com)
Fri, 6 May 1994 18:37:47 -0600
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++at++ctaeng.com (303) 889-1398 Fax
===========================================================================
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:16 PDT