moai/moai-dev — pull request #1026 by patrickmeehan (2014-11-12 01:22:42+00:00)
Title: Changes to MOAIActionMgr, MOAIInputMgr, graphics resource lifecycle

This is a fist crack at some changes to MOAIActionMgr and MOAIInputMgr I've been meaning to do for a while. There also also some changes to MOAIAppIOS and way the iOS host works.

The iOS specific changes are meant to simplify the host, pull more of the housekeeping 'under the hood' and better encapsulate the use of AKU in MOAIView). Eventually we'll come full circle and have a few officially supported hosts that can be built as modules and used without AKU.

The changes to MOAIActionMgr are part of a push to expose more of the Moai subsystems to Lua and allow users to more easily roll their own game loops. I'll eventually give MOAINodeMgr the same treatment; it will become MOAIDepGraph (or something). I also tried to find a simpler way of making sure newly added actions don't run until the tree update, though this will eventually be an option users can set.

The changes to MOAIInputMgr were a way to get MOAIMotionMgrIOS working quickly. I may go back to using one global input manager, but the model for adding 'devices' will need to change, as some will be added by the host and some will be added by Moai.

...

The graphics lifecycle changes (MOAIGfxResource, etc.) are the touchiest changes in this pull request, but have been needed for a long time. The resource lifecycle is confusing at best, but I'm hoping the renamed methods and simplified states will make this code easier to maintain. I also added explicit controls for deciding when and how the work of creating a resource is done. In the original implementation, the CPU-side assets (such as image buffers for textures) would be loaded immediately but only sent to the GPU (and discarded in some cases) when the resource is first bound for drawing. Which was Bad, because those assets would sit around in memory and then go to the GPU in a non-deterministic way. So the new system defaults to sending the assets to the GPU as soon as possible, but is fully configurable at runtime and on a per-resource basis if so desired.

I also did away with the notion of a 'non-renewable' graphics resource altogether. Since most or all of our platforms are subject to losing the graphics context, all resources *must* support renewal. So we still discard CPU-side assets if we can, but never at the expense of renewability.

Yeah, all this will be documented Soon(tm). In the mean time, here is a picture of a monkey smoking a cigarette:

![image](https://cloud.githubusercontent.com/assets/682819/5003717/1802192e-69c7-11e4-8f77-6820dd0e9f43.png)