Okay now I have your attention, I have a pretty general design question for my terrain engine. I have my whole shiznit working from within the d3dapp class supplied with the dx sdk. The terrain engine is composed of two classes: a fat one that does general stuff which has an array of little ones that handle the details. Now, both the fat and the little classes need to get their gritty hands on the camera class that''s defined in d3dapp class. That''s what I''m not sure how to do. I started out giving the fat and little classes pointers to the camera that I initialized in their respective constructors, but I''m wondering if there''s a better way to do this. Anyway help would be super sweet, thanks!

I''m not completely sure i understand you properly.

I don''t use the D3D framework app structure,but played with doing things with it in the beginning.

If you give me some more details on what problems your having,and the way youv''e written it(just give me an idea in pseudo)i''ll try to help out if i can.

Paul.

Yeah that wasn't all that clear I must admit. Basically, my problem is with variable scope. You don't really need to know anything about the d3dapp since its just a wrapper for API calls and windows stuff. Anyway, in this d3dapp I have my terrain class that I call to render that to the screen; however, it needs access to a camera class that's also declared in the wrapper class. That alone would be trivial, but the terrain class uses another class that also needs this information from the wrapper, and this other class is declared in the terrain class.

Lemme try pseudo that...

class wrapper{  class camera;  class terrain;};class terrain{  class helper;};  

...so both terrain and helper need easy access to helper. And so my problem specifically is I'm trying to let all terrain and helper member functions have access to camera while avoiding pointer dereferencing hell because I need to access it often and therefore efficiently.

[edited by - Silex on January 24, 2004 11:44:16 PM]

I'm still not totaly positive of the advice i should give.
(it's just difficult without seeing it in front of me).
maybe its just me

In my engine,my main header file(most stuff is accessable)i do something like:

#include windows.h>
#include DirectX stuff...util,file,font,Input,DPlay..etc
#include <Python stuff here...>
#include <tokamak physics here..>

#include Language stuff here...
#include VectorMath.h ...
#include Timer.h...
#include windows.h...
#include Geomitry.h...
#include BSPLoader.h...
#include DX9FX.h...
#include WorldCollision.h...
#include triggerSys...
#include Network.h..
#include Lightwave.h..
#include 3dsMax.h...
#include ASM.h...
#include Console.h...
#include WeaponAct.h...

etc etc....

Loads more specific functions and stuff here..

a class that is derived from..

class Win32Application
{
etc...
};

I make my D3DDevice extern(as is a lot of stuff)
and in the main implementation file,something similar:

Timer _Timer;
3DSMax _3DSMax;
DInput _DIput;
BSPLoader _BSPLoader;
Geomitry _Geomitry;
ASM _ASM;

etc etc...

You could probably do something like this with what youv'e done already,using the D3DFramework app,let me know this isn't clear to you,what i mean,and i'll try to explain it better tommorow(i'm a bit tired now).

Paul.


[edited by - paul8262 on January 24, 2004 12:01:56 AM]

I have actually been running into similar problems - there are a few ''environment'' classes that I need to have access to from a whole lot of other classes. An example would be the enemies in any kind of action game - these are objects that need to have access to their environment to determine their behaviour. I could just give each and every one of them some pointers - one to the object that contains all other characters in the game, and one to the game map, and maybe some more. But that seems a little ugly to me. I am also hestitant to have global pointers or instances of these ''environment'' classes because that would cause problems with their lifetime.

You can use persistant pointers in each class (although you have to be careful with this, because if you ever change what they are pointing to (ie. reallocate)... lots of trouble!

You can also pass in the pointers when needed. You can bundle a lot of this stuff up in a structure or class of "common" pointers/game objects and pass that to routines when needed. No real performance hit to this unless in an extremely tight loop (where you''d use another method or inline functions).

Or, you can use a singleton class for the "common" structure, or all of the objects that you need. This one works pretty well for game resources (images, etc.) but no so well for some other things.

Usually if you think about it, and put some away-from-computer time into designing your class heirarchy, the "best" way of approaching the "data sharing" in an explicit "data-hiding" architecture (ie. modular object orientation) becomes more obvious.