moai / moai-dev Goto Github PK

Add a bin search and an optional 'hint' parameter to improve look-up speeds into USAnimCurve. This hasn't been a performance bottleneck yet, but as we move to 3D it may become one.

Current A* implementation is naive: dynamically allocates and frees ever node on demand and performs a linear search through the (unsorted) node list every step. Clearly this can be improved by adding a mem pool and a binary heap.

Josh Lytle reported that certain touch events appear to get dropped on iOS and Android in spite of the internal event queue. This needs to be investigated and fixed.

MOAIDraw currently assumes 2D, untextured solid colored primitives. We should make this API more useful by exposing additional vertex elements.

Users may wish to access Moai's built-in shaders for use with their own props and meshes.

Made sure input devices are implemented to handle gamepad input. Add a demo that controls a character via a gamepad.

We've received a request to include luasec. It is not clear how to link this library in statically as it redefines many of the methods in luasocket. Needs some research and possible help.

Some platforms support basic, native pop-ups for simple dialogues and alerts. To the extent these ad hocs and alerts can be supported across all platforms, we should expose them. (The intent here is not to provide a full featured native UI wrapper. Just alerts, pop-ups and simple dialogues that can be supported across all platforms.)

...to allow method chaining.

Users have requested the ability to turn on and off drawing of certain Box2D elements.

Current anim curve just clamps when t goes off either end. Users might want fancier wrapping modes when using MOAIAnimCurve's to represent functions.

Current cross-platform implementation is a little clunky. Look into replacing implementation object with derived class from abstract virtual MOAIHttpTask.

We'd like to know what letter or word a given point lies inside of in a text box.

This will integrate with the Moai 2D physics framework and the arcade style physics to provide basic support for rigid body physics and constraints. The proof of concept should mainly focus on stability of sets of resting objects.

Begin framework for 2D physics (world, iterations, contacts, bodies, etc.). This will be the basis for the integrated rigid body/arcade game physics system.

Implement a way to bound pathfinding based on number of iterations and total nodes used. Current implementation is susceptible to filling entire available grid if no solution exists.

Possibly clearer than current addChild/start/stop methods.

This will be the basis for the arcade/platform style physics model.

With the move to 3D we now use a view volume for culling, even when rendering 2D or mostly 2D scenes. This obviously is a lot less efficient. We should look into falling back on a simpler culling scheme using 2D rectangles in certain situations. This could be done automatically or as an extra setting on MOAILayer or MOAIPartition.

Need to replace all picking routines with 3D equivalents. For axis-aligned orthographic projections the 3rd point component and ray may be optional (for backward compatibility).

Review current implementation w/ Rob and Adam to make sure the current set of features is supported. We know of at least one (custom headers) that needs to be added.

We need a way to compute or set content size in decks for use when drawing grids. When indexing a single deck element and displaying with a prop, it's not a problem: the bounds of that element are used for view culling. But when attempting to render a grid of arbitrarily sized elements, we need to pad the grid region with the dimensions of the largest element in the deck to make sure cells containing that element will be rendered even when just off screen.

The current implementation naively intersects all edges of the frustum with the prop's plane then uses the in-plane bounding rectangle. We should consider scan converting a more snugly fitting polygon to produce a more efficient set of tiles to render. We also need a way to enforce a 'horizon' and/or maximum viewable tiles limit: right now, if grid is set to wrap, we wind up with a huge number of tiles to draw as the camera approaches a side-view of the tilemap.

Current implementation no longer supports orthographic projection. Need to add this back in.

Text style particulars (such as font, point size and color) should no longer be inlined into the text itself or set for the entire text box. It would be better to inline style names then attach a set of styles to the textbox for application when rendering. Styles should be user-named and support additional effects such as animation (offset of text being styled and text color).

Current implementation assumes alpha-only textures; shader assumes this as well. Make sure full color bitmap fonts are supported.

Fonts and glyph caching should be handled automatically and behind the scenes. Right now users have to explicitly rip fonts to specific point sizes and character subsets; this should be automatic and dynamic at runtime.

We can build all of the libraries and package them, along with moai.cpp and the user will have to do the final compile when specifying a package name.

When attempting to render a grid of arbitrarily sized elements, we need to pad the grid region with the dimensions of the largest element in the deck to make sure cells containing that element will be rendered even when just off screen.

The new 3D API adds extra mandatory parameters to some frequently used functions (moveLoc, moveScl, etc.). To avoid breaking the world, use the new moai class 'extent' functionality to re-implement the original 2D style API. Right now we are refactoring to have just MOAIProp and MOAILayer. These should be extended with Lua APIs into MOAIProp2D and MOAILayer2D.

Write a lua script to convert collada to an equivalent, platform-agnostic not-lossy intermediate format suitable for loading and further processing into a Moai scene graph.

These singletons may contain redundant or conflicting APIs.

Add support for video playback on operating systems where video API is available.

Right now individual particles ignore the system prop's index. This should probably be used as an offset in addition to the particle register's index.

MoaiHttpTaskInfo::PerformSync() on NaCl should perform a synchronous HTTP request.

MOAIImage needs fillRect/clearRect method.

Would be useful to have trig functions in particle script.

To support generalized bind/unbind from parent transforms we need to include shear in the MOAITransform internals. We can consider rewriting these to look more like a basis with some extra info. The new representation should be well suited for 3D, able to quickly be animated across all components and readily return information about each component performing as few conversions and calculations as possible.

Right now wndToWorld assumes a 2D point and camera. This needs to be rewritten (and renamed) to use a 3D point and camera and to return a point plus a ray.

The current A* implementation uses Euclidian distance as the default heuristic for hex, oblique and diamond shaped grids. We need to implement versions of the other heuristics (where applicable) and also see if there are better heuristics to use for hex grids.

Some sounds will stop playing and no longer play until re-loaded. We've noticed this in Wolf Toss with the interactive music sounds. They usually play OK the first few times, then stop playing and don't come back until the sound resources are reloaded.

MOAIPartition currently assumes an XY plane. For some 3D scenes, an XZ plane is more appropriate. Implement these alternatives as settings on the partition object.

Need to look into how this will break current users and what can be done to ease the transition.