As started on the shared_ptr thread here are some ideas on how I would change the structure of the cocos2d library:
At the moment the library is a huge repository containing everything including test and sample apps (which I do not need when developing my own project). Also the library contains the project as the subfolder. However the library is a dependency of the application and therefore should reside in a sub-folder of the application:
MyApplicationProject | |-Classes (contains the application source files) |-Resources (contains the application resources) |-Libraries (contains dependencies to third party code) | |- cocos2dx (contains the source and resources from the cocos2dx library) |- CocosDenshion (contains the source and resources from the Cocosdeshion library) |- box2d |-
With this setup I can more easily manage dependencies and repositories for each third party library I am using.
Platform specific code in cocos2dx
At the moment the platform folder is quite a mess, and some platforms need various files that should not be added to other (CCImage.cpp for example)
So we may define different subsystems, which get included by a specific platform. Each of these subsystems may provide different backends (which contain the actual code, and may be platform dependant or used by serveral platforms):
So for example we have a WindowToolkit which should be responsible for managing the windowing system and forwarding user input to cocos2dx:
WindowToolkit | |- IWindowToolkit.h (provides the interface for all window toolkit backens) |- WindowToolkit.cpp (contains a singleton which forwards access to the actual backend that is used)
A window toolkit backend, then implements the protocol for a specific or multiple platforms. For example glfw or SDL coud be used on all PC platforms, so it would make much more sens to share this code, then to write three different implementations for managing the window system.
WindowToolkitGLFW | |-WindowToolkitGLFW.h |-WindowToolkitGLFW.cpp (include the implementation for the window toolkit interface by using the GLFW library) |-platform |-Linux | |- WindowToolkitGLFWLinux.h/.cpp (includes linux specific implementation details if required) | |- libraries | |- libGLFW.a (dependency library, required by the glfw implementation) | |-Windows |-MacOSX
Each platform can now define which toolkit backend it wants to use. Multiple platforms could share implementations of a specific toolkit.
When implementing a new platform, I need to verify that there are backends available for all required subsystems.
Some other examples are:
Playing sounds using OpenAL (can be used on all PC platforms and iOS)
Font rendering using libfreetype (possible on PC platforms, a library may be compiled for the mobile platforms)
Implementing this may also make the next point easier (not sure if this is planned)
Integrate an abstraction layer for the rendering API
For the game code it should not matter that much if it gets rendered on Direct3D or OpenGL. So it might be a goog idea to integrate an abstraction layer for the most commonly used operations. Which may allow unifying the WinRT and default branch of cocos2d.
Implement multi-threaded rendering
We should at least to try to put the game rendering code to a different thread. This may significantly speed up the performance of the engine:
* scene graph is generated on the main thread, once the frame is calculated, the scene graph is given to the renderer thread.
* renderer thread takes the scene graph and starts rendering
* the main thread can immediatly continue, calculating the next frame, we don’t need to wait until glSwapBuffers() will finish (which may take quite some time depending on the implementation of the graphics driver)
* as an optimization, the main thread should now use the same objects for generating the scene graph, If an object has changed, it should perform a copy-on-write (i.e creating a new rendering object and put it in the scene graph)
What are your thoughts on any of these issues?
Feel free to add further issues to the list.