moai / moai-dev Goto Github PK

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.)

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

...to allow method chaining.

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.

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.

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

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.

MOAIImage needs fillRect/clearRect method.

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

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

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.

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

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

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

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.

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

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.

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.

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

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

Possibly clearer than current addChild/start/stop methods.

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

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.

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.

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 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.

Would be useful to have trig functions in particle script.

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.

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.

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.

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

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.

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

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

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).

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.

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.

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.

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.

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).

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.

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.

These singletons may contain redundant or conflicting APIs.