-
Notifications
You must be signed in to change notification settings - Fork 48
Home
secretrobotron edited this page Jul 21, 2011
·
63 revisions
Alan Kligman [email protected]
Get the tasker working.Update the protogame with some entity and event pseudocode.Write some basic entity code that can listen() and ignore() events.Write a messenger to handle callbacks and dispatching.Get Javascript events working with the messenger.Get mouse events working with the messenger. This will likely have to hook into the canvas.Figure out the details for an engine-level scene model.Merge components branch back into master.Component rework, support for add/remove.Tasker: suspend/resume for tasks.Finish component implementations for Scene, Model, Camera.Fix spatial component to use arrays so that they're compatible with MJS.- Update project wiki with more detailed information about Paladin (what is Paladin? why is Paladin?).
- Tasker: refactor to setTimeout(0) after each dispatch rather than after each frame. What is the impact of this on performance?
- Messenger: enhancement to allow entities to suspend/resume listening.
- Messenger: handle remaining keyboard events, and add a handler for window repaint (for the renderer).
- Spatial component: transform support, required to connect homogenous entities together.
- Add support for named components.
- Add some API documentation to the code.
Robert Richter [email protected]
Get subsystem registration working.- Integrate the CubicVR.js renderer into the engine using the messenger and tasker.
Dummy Graphics Component- Camera, Light layer in render subsystem
Subsystem registry inheritanceFix loadFrom property in for Mesh to use booleanAddShorthand for Entities/Components- Fix protogame so it doesn't touch Component internals (component.object, component.camera)
- Paladin instance scoping
Dan Mosedale [email protected]
Post-refactoring subsystem.js testing fixupincorporate existing test bits into test automation (note to self: check out popcorn qunit setup)- talked to jrburke; he has graciously volunteered to put together a require.js branch for consideration
make protogame use FoTN ship- continuing to coordinate with a variety of Moz folks around resourcing
- cleanly land FoTN ship patch
refactor graphics tests to minimize concurrency issuesaugment camera/model tests + code with position & rotation initializers (in-progress)- merge camera-position-rotation branch into master
- add loadMesh test & complete/land functionality
- land fotn-ship branch
- possible next pieces: get protogame working better on mobile
- Firefox support for mouse capture, web sockets.
- Testing and require.js.
- Subsystem integration status: current state of cubicvr.js and ammo.js.
- Paladin instance isolation and closure syntax https://gist.github.com/1095134
- Discuss what we want as our next milestone.
- Build a prototype game that consists of a controllable ship that flies around a simple landscape.
- Focus should be on mobile games, with an interest in social gaming.
- [2011-07-15]
A simple game with a player model flying around a room.
- Can the engine run in Spidermonkey/V8 as a standalone application?
- Neither of these interpreters provide a window context.
- Use browser-based interpreters for now.
- We can provide our own GL context for Spidermonkey and V8, but this is not critical for now.
- How can we handle game resources, like models and textures?
- They will need to be stored in the browser cache, which could become quite large.
- It is not possible to associate the WebGL context with multiple canvases.
- Use a single canvas for now, created by default for the user.
- There's some frame buffer magic we can use to support multiple display regions.