The same screenshot I posted in another topic may help.
[attachment=7939:EngineOrg.png]

I have 15 modules/libraries.  The way in which things depend on other things is entirely logical.

At the bottom you have LSStandardLib.  It provides a lot of macros for general use by the entire engine and all other modules, including LSE_CALL, LSE_INLINE, LSE_WINDOWS, LSE_APPLE, etc.
Additionally it provides general-purpose functions such as CStd::StrLen(), etc.  These functions can usually be optimized beyond what you will find in the standard C library, but you don’t have to do it.
It also provides CTime, CLargeInteger, CSearch, CCrc, and a few other general-purpose classes that rely on nothing else.  It is the lowest level in the engine.


Just above that you have LSMathLib and LSThreadLib.

Next up is LSMemLib.  My memory manager.  It relies on threads and CStd.

Next up is LSTL, which is my game-oriented replacement for the STL, and it relies on memory allocation.  You don’t really need to do this probably, but if you do it would be here.

Next up are LSCompressionLib, LSFileLib, LSNetLib, and LSPhysicsLib.  These rely on standard macros/functions, memory allocations, templates, file access, math, etc.

Next is LSImageLib.  Textures may use these, but this class has no idea what a texture is.  It knows what an image is and how to manipulate and load them.  The reason it is not on the next level down is because it relies on LSCompressionLib and LSFileLib.

Next is LSGraphicsLib.  It relies on LSImageLib for use with textures.

Next is LSModelLib and LSTerrainLib.  They need to render themselves, so they need to know what a renderer is.

Finally LSEngine needs to know what everything in the engine is and how they should be connected.  It is obviously at the top.


For ideas on how to manage states and the data in each state, you can read my article about it.
http://lspiroengine.com/?p=351


L. Spiro

The same screenshot I posted in another topic may help.
[attachment=7939:EngineOrg.png]

I have 15 modules/libraries.  The way in which things depend on other things is entirely logical.

At the bottom you have LSStandardLib.  It provides a lot of macros for general use by the entire engine and all other modules, including LSE_CALL, LSE_INLINE, LSE_WINDOWS, LSE_APPLE, etc.
Additionally it provides general-purpose functions such as CStd::StrLen(), etc.  These functions can usually be optimized beyond what you will find in the standard C library, but you don’t have to do it.
It also provides CTime, CLargeInteger, CSearch, CCrc, and a few other general-purpose classes that rely on nothing else.  It is the lowest-level in the engine.


Just above that you have LSMathLib and LSThreadLib.

Next up is LSMemLib.  My memory manager.  It relies on threads and CStd.

Next up is LSTL, which is my game-oriented replacement for the STL, and it relies on memory allocation.  You don’t really need to do this probably, but if you do it would be here.

Next up are LSCompressionLib, LSFileLib, LSNetLib, and LSPhysicsLib.  These rely on standard macros/functions, memory allocations, templates, file access, math, etc.

Next is LSImageLib.  Textures may use these, but this class has no idea what a texture is.  It knows what an image is and how to manipulate and load them.  The reason it is not on the next level down is because it relies on LSCompressionLib and LSFileLib.

Next is LSGraphicsLib.  It relies on LSImageLib for use with textures.

Next is LSModelLib and LSTerrainLib.  They need to render themselves, so they need to know what a renderer is.

Finally LSEngine needs to know what everything in the engine is and how they should be connected.  It is obviously at the top.


For ideas on how to manage states and the data in each state, you can read my article about it.
http://lspiroengine.com/?p=351


L. Spiro

The same screenshot I posted in another topic may help.
[attachment=7939:EngineOrg.png]

I have 15 modules/libraries.  The way in which things depend on other things is entirely logical.

At the bottom you have LSStandardLib.  It provides a lot of macros for general use by the entire engine and all other modules, including LSE_CALL, LSE_INLINE, LSE_WINDOWS, LSE_APPLE, etc.
Additionally it provides general-purpose functions such as CStd::StrLen(), etc.  These functions can usually be optimized beyond what you will find in the standard C library, but you don’t have to do it.
It also provides CTime, CLargeInteger, CSearch, CCrc, and a few other general-purpose classes that rely on nothing else.  It is the lowest-level in the engine.


Just above that you have LSMathLib and LSThreadLib.

Next up is LSMemLib.  My memory manager.  It relies on threads and CStd.

Next up is LSTL, which is my game-oriented replacement for the STL, and it relies on memory allocation.  You don’t really need to do this probably, but if you do it would be here.

Next up are LSCompressionLib, LSFileLib, LSNetLib, and LSPhysicsLib.  These rely on standard macros/functions, memory allocations, templates, file access, math, etc.

Next is LSImageLib.  Textures may use these, but this class has no idea what a texture is.  It knows what an image is and how to manipulate and load them.  The reason it is not on the next level down is because it relies on LSCompressionLib and LSFileLib.

Next is LSGraphicsLib.  It relies on LSImageLib for use with textures.

Next is LSModelLib and LSTerrainLib.  They need to render themselves, so they need to know what a renderer is.

Finally LSEngine needs to know what everything in the engine is and how they should be connected.  it is obviously at the top.


For ideas on how to manage states and the data in each state, you can read my article about it.
http://lspiroengine.com/?p=351


L. Spiro

The same screenshot I posted in another topic may help.
[attachment=7939:EngineOrg.png]

I have 15 modules/libraries.  The way in which things depend on other things is entirely logical.

At the bottom you have LSStandardLib.  It provides a lot of macros for general use by the entire engine and all other modules, including LSE_CALL, LSE_INLINE, LSE_WINDOWS, LSE_APPLE, etc.
Additionally it provides general-purpose functions such as CStd::StrLen(), etc.  These functions can usually be optimized beyond what you will find in the standard C library, but you don’t have to do it.
It also provides CTime, CLargeInteger, CSearch, CCrc, and a few other general-purpose classes that rely on nothing else.  It is the lowest-level in the engine.


Just above that you have LSMathLib and LSThreadLib.

Next up is LSMemLib.  My memory manager.  It relies on threads and CStd.

Next up is LSTL, which is my game-oriented replacement for the STL, and it relies on memory allocation.  You don’t really need to do this probably, but if you do it would be here.

Next up are LSCompressionLib, LSFileLib, LSNetLib, and LSPhysicsLib.  These rely on standard macros/functions, memory allocations, templates, file access, math, etc.

Next is LSImageLib.  Textures may use these, but this class has no idea what a texture is.  It knows what an image is and how to manipulate and load them.

Next is LSGraphicsLib.  It relies on LSImageLib for use with textures.

Next is LSModelLib and LSTerrainLib.  They need to render themselves, so they need to know what a renderer is.

Finally LSEngine needs to know what everything in the engine is and how they should be connected.  it is obviously at the top.


For ideas on how to manage states and the data in each state, you can read my article about it.
http://lspiroengine.com/?p=351


L. Spiro