Code Tree Reorg

[Geoff Evans]

I am going to need a better per-game split up of assets for some personal projects consuming Helium (that aren't open source), and as it also seems like a good time to re-org the source tree, too.  I took a pass at sketching out the moving of projects into folders (and splitting up the single massive Data folder).  Give it a read and let me know what you think.

The new version of git that just came out apparently supports moving submodules, so everyone will need to have git 1.8.5 at a minimum.  I still need to do some tests.  However everyone should probably plan for the worst case (pushing any changes in progress to a branch and making a new clone from master to setup the moved submodules cleanly).

Core

\Foundation

\Inspect

\Math

\MathSimd

\Persist

\Platform

\Reflect

Dependencies

\bullet

\freetype

\glew

\glfw

\libpng

\mongo-c

\nvtt

\ois

\p4api

\rapidjson

\wxWidgets

\zlib

Documentation

Tools

\Application

\Editor

\EditorScene

\EditorSupport

\Mongo

Engine

\Asset (formerly Engine)

\Components

\Jobs (formerly EngineJobs)

\Framework

\FrameworkImpl

\Graphics

\GraphicsJobs

\GraphicsTypes

\PcSupport

\PreprocessingPc

\Rendering

\RenderingD3D9

\RenderingGL

\Windowing

Game

\ComponentLibrary (formerly ExampleGame)

\PhysicsDemo

 \Data

\ShapeShooter

 \Data

\SideScroller

 \Data

Integrations

\Bullet

\Ois

Tests

\TestApp

 \Data

Utilities

\Linux

\MacOSX

\Windows

[Philip Degarmo]

I took a crack at it too. I like a lot of it but I'm not sold on renaming Engine to Asset. Engine deals with caches and packages as well as assets. I could also see us moving something down from framework to engine like the task system. EngineJobs should just go away eventually I think. Maybe just roll it in with Engine.

Here is my attempt:

Helium

 - Engine

   - Build

   - Built

   - Code

     - Core (contents match your suggestion)

     - Dependencies (contents match your suggestion)

     - Game (Everything in Engine in the above example goes here)

     - Tests

     - Tools (contents match your suggestion)

   - Data (the editor itself will probably want to use content)

   - Documentation

 - Plugins (analogous to integrations but maybe more familiar terminology to those not familiar with the project)

   - Bullet

   - SCL (Standard component library?)

   - OIS

 - Projects

   - Examples

 - Utilities

I think it would be neat if the binaries could be given a project directory like how Eclipse handles workspaces. The project/workspace would need some root file that describes paths for plugins and data. Each project/workspace could be something like

MyProject

 - Build

 - Built

 - Code

 - Data

 - DataCache

 - Documentation

 - HeliumProject.json (I kind of wanted to avoid a project file and just use directories and convention but I could see use cases where someone want to bring in data or plugins from different places on their HDD.

One thing I'm a bit concerned about is how pleasant it is to work on engine, project specific, and plugin code all at once. I think we need a way to let it all live in the same SLN file. We already auto-generate our projects so hopefully we can have a workflow that makes it easy to generate a SLN file based on what exactly the end user would want to touch. Also it may be that we want to make that a per-project choice. I think premake being lua could be used directly to achieve a lot if not all of this automation. It's kind of painful to have to do something like that but I think it will add a lot of the initial experience and polish of using the project.

--
You received this message because you are subscribed to the Google Groups "Helium Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to heliumprojec...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Geoff Evans]

Caches and Packages exist to serve Assets, so Asset for the core asset engine library seems very natural to me.  All that stuff is the Asset system, lets embrace it.

Regarding everything else you are saying here, I am going to need some time to think...