Engine Layout Critique

Quote:

1) You have nine "Managers", nine more than a tasteful amount: find better names for them and you'll discover better defined classes.

class Module {// Abstract class interface};class StaticModule : public Module {...};class DynamicModule : public Module {...};class ModuleManager {   std::vector <Module*> m_kvpModules; //mabey a list would be better};

Quote:

3) The diagram has some lines and some arrows, hollow arrows that are used UML to express inheritance, unlabeled boxes around other boxes, a mixture of classes and subsystems, a strange sidebar, shaded boxes, a bizarre and badly drawn layout. What about a plain old UML class diagram?

Quote:

1) What is the boundary between game-specific data and logic and engine services? What is constrained but sophisticated, and what is basic but flexible?

Quote:

2) What are the platform dependent and platform independent parts of the Graphics Subsystem, Graphics Interface, GUI? How do different capabilities (e.g. OpenGL vs software rendering) come into the picture?

// Display could represent HWND (For Win32), or a buffer ptr for unkown systems // ie, mabey it represents ptr to video memory? We dont know, so keep it void*typedef void* DisplayPtr;// Abstract Video class (Software render) SYSTEM SPECIFIC, so its part of OSI// Layerclass VideoDriver {   DisplayPtr   m_pkPrimary;  // primary displaypublic:   virtual int SetDisplay (DisplayPtr display) {      if (display)         m_pkPrimary = display;      return 0;   }   virtual inline void DrawPixel (int x,int y, int z, int c) {//OSI layer is only set of classes that could have system-specific code..if (m_pkPrimary) {#ifdef _WIN32   // m_pkPrimary represents window handle..   ::SetPixel (GetDC ((HWND)m_pkPrimary),x,y,c);#else   //dont know platform. Assume m_pkPrimary is byte* buffer to memory block   m_pkPrimary [x+y*iDisplayWidth] = c;#endif   }}};

// OpenGL Driver class for Graphics SubSystem. If the API is system specific // (DirectX), we dont care if there are system-specific code in that library.// For other APIs (ie, OpenGL), the OSI (In this case, the base VideoDriver // class) initializes WGL to work with OpenGL// Library...class VideoDriverOgl : public VideoDriver {   DisplayPtr   m_pkPrimary;  // primary displaypublic:   VideoDriverOgl () : VideoDriver () {} //initialize base class   virtual int SetDisplay (DisplayPtr display) {      if (display)         m_pkPrimary = display;      return 0;   }   virtual inline void DrawPixel (int x,int y, int z, int c);}};// ALL Video drivers are REQUIRED to have this initialize routine.// This hides the API-specific implimentation behind our "VideoDriver" classVideoDriver* InitGraphics () {   return new VideoDriverOgl;}

Quote:

3) How are the Task Manager and the Timer related? What about frame rate and game model update rates? How do you use multithreading?

class OSI {   TaskManager*  m_kpTaskMngr;   ModuleManager* m_kpModuleMngr;   OSI () {}  //made private for singletonpublic:   virtual inline int CreateNew (Task& rkTask) {      m_kpTask->Add (rkTask);   }   virtual inline OSI* Get () {      static OSI* pkOSI = new OSI;      return pkOSI;   }};

Quote:

Original post by Crypter I use the prefex "k" as a way to easily seperate our own data types with other library's.

Quote:

Original post by Crypter Quote: 1) What is the boundary between game-specific data and logic and engine services? What is constrained but sophisticated, and what is basic but flexible? I am trying to make everything as flexable as possible. Unless I do not understand your question?

Quote:

Original post by _goat Quote: Original post by Crypter I use the prefex "k" as a way to easily seperate our own data types with other library's. That's what namespaces are for. :)

namespace xyz{  Core* pCore = new Core;}xyz::pCore->doSomething();

Core* pkCore = new Core;pkCore->doSomething();

namespace pointer{  namespace xyz  {    Core* core = new Core;  }}pointer::xyz::core->doSomething();

namespace count{  int items;}

namespace member{  std::string name;}

namespace max{  int items;}

Quote:

For example an engine could expose blank OpenGL windows (e.g. JOGL or LWJGL) and another could expose a scene graph (e.g. Java3D): the former requires significant amounts of design and code but is general, the latter is specialized and efficient (we can say it has some "added value" over no scene graph), but limited since some things cannot be done easily with a scene graph (or with a certain type of scene graph).

//Graphics SubSystemclass Surface {   void*  m_pData;   int    m_iWidth, m_iHeight;  //etc..   operator void* () {return m_pData;}};// Create windowint GraphicsDriver::Create (int iWidth, int iHeight) {// create our primary surface#ifdef _WIN32   // create and register window..   // now store window under surface abstraction..   m_pDisplay = new Surface ((void*) HWND);#endif}// Scene Manager..class SceneManager {   GraphicsDriver* m_pGfx;   Surface*        m_pDisplay;   int Create (GraphicsDriver& rK) {      m_pGfx=rK;      m_pDisplay = m_pGfx->GetDisplay ();   }};

Quote:

Original post by tstrimp Hell, then why bother with the p prefix either. All pointers should then be in a pointer namespace. ...

float fSpeed; // is wrong, butfloat mphSpeed, // (Miles Per Hour)      mpsSpeed, // (Meters Per Second)      upsSpeed; // (world-Units Per Second)// are all correct.

Quote:

The abbreviation's should of course be explained in some src readme so users and fellow coders understand what you mean when you type mps :)

Quote:

Original post by tstrimp Hell, then why bother with the p prefix either. All pointers should then be in a pointer namespace...

• The first is the infamous "iItems" type, which shows that Items is an int. This has many disadvantages, not least that when you change the type of variable, you have to change the variable name for every time you used it. For example, if I pointed out your Surface class should use size_t (or unsigned int) for its width and height, instead of int (because a surface can't have a negative area), you'd have to change everything. Whether or not you agree that it needs changing isn't the issue - the point is that if there ever was (and often is) a case where you need to change something, it quickly becomes rather time-consuming. Especially as the project grows.



• The second is hungarian notation, or isn't hungarian notation, depending on who you ask. Using m or m_ before member variables avoids collisions inside the class. So m_height = height works inside functions which have a temporary variable called height. Interestingly enough, before Hungarian Notation was popularised by that guy at Microsoft, people used a trailing underscore to signify the same thing. I.e., height_ = height. Seeing as it predates HN, and is actually necessary (no namespaces inside classes), unless you want to use this->height = height all over the place, it's considered okay. (Yes, I use m, as in mCaption)



• The third is what sirGustav mentioned, which is Applications Hungarian Notation (the first mentioned was Systems Hungarian Notation). It is effectively just shortening a possible variable name, (counter examples include: miles_per_hour, metres_per_second, WU_per_second). This has its place, because it adds semantics to the code, but fails for international things (it is easy to translate words, but difficult to translate abbreviations unless you know the language flawlessly).



• The fourth, and final one, is Crypter's original usage, which is to simply avoid collisions between names at a global level, basically across his entire library. I.e., if he made a 2d vector, and called it vector, it would clash with std::vector. However, kVector won't. It is basically the same thing as namespacing, but with the added disadvantage of not working if someone else calls their class kVector (however unlikely that may be). The namespace was included in C++ for this reason. So Crypt::vector is unambiguous.

Quote:

Original post by _goat ... are you a troll, hiding in a respectable person's clothing?

Quote:

The fourth, and final one, is Crypter's original usage, which is to simply avoid collisions between names at a global level, basically across his entire library. I.e., if he made a 2d vector, and called it vector, it would clash with std::vector. However, kVector won't. It is basically the same thing as namespacing, but with the added disadvantage of not working if someone else calls their class kVector (however unlikely that may be). The namespace was included in C++ for this reason. So Crypt::vector is unambiguous.

Core* pCore = new kCore;

Core* pkCore = new Core;

Quote:

Original post by Crypter Quote: The abbreviation's should of course be explained in some src readme so users and fellow coders understand what you mean when you type mps :) What if "mps" represents different things among multple source files?