gladiusjs / gladius-core Goto Github PK

Currently only JSON is supported (the code lives in the Resource base prototype). Allow the caller to pass in a closure so that we can handle different kinds of data, some of which can be loaded natively by the browser (video, image, sound, etc).

We need an input subsystem to manage entity actions and their mappings to input events.

We need a resource manager to manage game assets like models, textures, and sounds.

• The engine should get a Cache instance when it is constructed.

engine.cache = new Cache();

• The cache instance should have a method get() for fetching content into the cache. Get() should accept a pair of callbacks to be invoked when the content is available in the cache, or if there is an error. Callbacks for onComplete and onError are invoked once per source, while the callback for onAllComplete is invoked once for all completed sources.

engine.cache.get({
    content: [
        {
             url: [ 'http://...', ... ],            // multiple URLs specify alternate sources
             name: 'myContent'             
        }
    ],
    onComplete: function( content ) {
        ...
    },
    onAllComplete: function( content ) {
        ...
    },
    onError: function( source, error ) {
        ...
    }
});

• The cache should do all loading/processing for content in worker threads.
• The cache should keep track of interesting HTTP headers for its entries, such as Content-Type, or Expires.
• The cache instance should have a method find() for finding pre-cached content by name or url. Should return the content if it is cached, or null.

var content = engine.cache.find({
    name: ....,
    url: ...
});

• The cache instance should have a method clear() to unload cached content. If no options are given, the entire cache should be cleared.

engine.cache.clear({
    name: ...
    url: ...
});

• It might make sense to get a separate context for different parts of the client application so that assets can be fetched and cleared in batches.

var level1Cache = new engine.cache.Context();
var level2Cache = new engine.cache.Context();
level1Cache.get( ... );    // Pre-load a bunch of stuff for level 1
level2Cache.get( ... );
...
level1Cache.clear();      // This should clear out all the cached assets for level1, 
                                     // but things cached for level2 are not cleared.

@diogogmt will work on this.

This might be useful to look at: https://github.com/jussi-kalliokoski/html5Preloader.js

One question remaining is whether there is enough information provided to the API in get() so that the cache can know to use browser functionality to load sound, images, and video (for example).

Stories and tasks for this issue are here.

Engine support for accelerometer events.

Support for touch and accelerometer events. These may require watchers of their own (like MouseWatcher) to store up-to-date information.

Placeholder task for me to investigate JavaScript security and signed scripts.

Things have changed around a lot recently, and as such the test suite actually broke when running "make test". The index.html file in the test suite is pointing to ../src/gladius.js, while it's actually in ./gladius.js. qunit wasn't copied over at all, and therefore would never load up. With both of those things fixed, it's still searching for the math library which doesn't seem to exist in the same form (or isn't put into gladius.js right now), but the other tests work still.

The current engine.sound.music has play(), but no concept of looping audio.

In the code below, the function name __thread has been minified down to c:

function c(a) {
    var b = {log: function () {var a = Array.prototype.slice.call(arguments).join(" ");f("__log", {log: a});}}, c = function (a, b) {}, d = {}, e = function (a, b) {c(a.name || b);var e = a.name || b;d[e] = a;}, f = function (b, c) {c = c || {}, self.postMessage({method: b, thread: a, request: c});};
    self.onmessage = function (a) {var c = a.data;d[c.method] ? d[c.method](c.request) : b.log("ignoring unknown method " + c.method + " from thread");}, self.onerror = function (a) {};
    var g = function (a) {var d = new Function(["console", "assert", "parameters"], "var f = " + a.callable + "; return f.apply( null, parameters );"), e = d.apply(null, [b, c, a.parameters]);f("__result", {result: e}), f("__ready");};
    e(g);
    var h = function (a) {_id = a.id;};
    e(h), f("__ready");
}__thread('D6DF818B-ACBB-47EF-8923-F15D3662D74B');

The thread pool fails when this function is called.

Changing object positions seems to be broken.

Right now I'm writing unit tests as I write engine code. As a result, the tests are not well organized. Some modules need to be split up and some individual tests could probably be split into multiple ones.

Not sure exactly what this involves. At very least we need a WebGL context.

Steps to reproduce (bash):

$ make clean
$ make
Creating ./dist
Building ./dist/gladius.js

Tracing dependencies for: ../tools/almond

node.js:208
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: Error: Error evaluating module "undefined" at location "c:/Users/Hasan/Misc/Repos/Gladius/src/../external/CubicVR.js/dist/CubicVR.js":
Error: ENOENT, The operation completed successfully.
'c:/Users/Hasan/Misc/Repos/Gladius/src/../external/CubicVR.js/dist/CubicVR.js'
fileName:c:/Users/Hasan/Misc/Repos/Gladius/src/../external/CubicVR.js/dist/CubicVR.js
lineNumber: undefined
http://requirejs.org/docs/errors.html#defineerror
In module tree:
gladius-src
graphics/service

at Function.onError (c:\Users\Hasan\Misc\Repos\Gladius\tools\r.js:7355:23)
at execManager (c:\Users\Hasan\Misc\Repos\Gladius\tools\r.js:704:28)
at Object.onDep (c:\Users\Hasan\Misc\Repos\Gladius\tools\r.js:745:33)
at execManager (c:\Users\Hasan\Misc\Repos\Gladius\tools\r.js:713:45)
at Object.onDep (c:\Users\Hasan\Misc\Repos\Gladius\tools\r.js:745:33)
at execManager (c:\Users\Hasan\Misc\Repos\Gladius\tools\r.js:713:45)
at Object.onDep (c:\Users\Hasan\Misc\Repos\Gladius\tools\r.js:745:33)
at execManager (c:\Users\Hasan\Misc\Repos\Gladius\tools\r.js:713:45)
at Object.onDep (c:\Users\Hasan\Misc\Repos\Gladius\tools\r.js:745:33)
at execManager (c:\Users\Hasan\Misc\Repos\Gladius\tools\r.js:713:45)

make: *** [dist/gladius.js] Error 1

$

[17:07:23.735] A call to document.write() from an asynchronously-loaded external script was ignored. @ http://localhost:8080/gladius/external/gladius.math/test/ (x2)
[17:11:12.730] A call to document.write() from an asynchronously-loaded external script was ignored. @ http://localhost:8080/gladius/test/

I get these errors, which prevents the test suites from running. I know there was a quick fix for this in IRC last night, but I can't remember what it was.

Port the sound code from the master branch over to develop. A lot has changed since the last time this worked.

We need a configuration registry to store config parameters for Gladius and its services.

• The configurator instance needs to be created very early, so we can use it to configure the engine and other subsystems. For example, we can use it to enable or disable certain other services. The configurator should be partially constructed, like other modules.
• The configurator should accept a default configuration that is defined somewhere internally that contains sane defaults for most configuration parameters.

Example: create a new Configurator instance

var configurator = new Configurator( defaultConfiguration );

• Configurations should be specified in JSON.
• Configurations should be organized into a tree structure, with top-level nodes being core, graphics, sounds, etc. Using a path separator like '/' seems sane.
• The configurator should be able to load configurations from a URL (including file://?) to customize the engine and its services by modifying the default settings.

Example: loading a configuration

engine.configurator.load( URL );

• The configurator should provide get(), getPath() and set() methods to retrieve part of the configuration tree, or to set a value in the tree.

Example: setting a configuration value

engine.configurator.set( '/graphics/render/mode' ) = 'wireframe';

• The getTree( path ) method should return a configurator object for the subtree defined by path.

Example: getting a configuration path

var graphicsConfig = engine.configurator.getPath( '/graphics' );
graphicsConfig.set( '/render/mode' ) = 'wireframe';

• Other code should be able to register interest in a configuration subtree and provide a callback that can be invoked, with the name of the updated entry, when changes occur in that subtree. Should also be able to call ignore() on the return value of getPath() to unregister the callback from the change event.

Example: defining a callback to run when things change

var graphicsConfig = engine.configurator.getPath( '/graphics', function( path ) {
    // do something with path
});

...

graphicsConfig.ignore();

• The configurator should be able to serialize the configuration tree back into local browser cache, so that changes made while the engine is running can persist.

Example: storing the configuration to a browser cache

engine.configurator.store( URL );

@northWind87 will work on this.

Stories and tasks for this issue are here.

The spatial transform component needs to be finished and unit tested.

The thread pool unit tests take a long time to finish. This needs to be fixed before the thread pool can be used for actual work.

Me and @secretrobotron made a first smack at the network service API. We would like to build some components on top of this as well.

• Attach a network service instance to the engine.

engine.network = new Network({
    device: ...,
    port: ...
});

• A network context provides a way to send and receive messages through the network service. Many contexts can be backed by a smaller set of low-level sockets.

var context = new engine.network.Context({
    defaultTimeout: ...,
    listen: {
        onConnect: function( connection ) {
        },
        onDisconnect: function( connection ) {
        }
    }
});

• Making a new connection using a context.

var connection = context.connect({
    remote: ...,
    protocol: 'ajax',`
    defaultTimeout: ...,
    onReceive: function( data ) {
    },
    onConnect: function() {
    },
    onDisconnect: function() {
    },
    onError: function() {
    }
});

• Sending data through a connection.

connection.send({
    data: ...,
    timeout: ...,
    onComplete: function() {
    },
    onError: function() {
    }
});

• Closing a connection

connection.close();

• Close all connections on a context.

context.closeAll();

• Send data to all connections on a context.

context.sendAll({
    data: <...>,
    onComplete: function() {
    },
    onCompleteAll: function() {
    },
    onError: function() {
    }
});

• Find the first connection on a context that matches a filter.

context.find({
    <filter>
});

• Find all connections on a context

context.findAll({
    <filter>
});

@jbraffoul will work on this.

We need to split our code into modules. Require.js seems like a good way to achieve this goal.

Makefile target 'test' requires dist to be built first, but this should be done automatically. make test should execute other targets it needs.

The messenger does not handle keyboard or mouse events consistently for all browsers. See http://unixpapa.com/js/key.html.

We want to write a server in node.js to support Gladius games. The server should report correct content-length and MIME types for game assets. We can also use this to tie into social gaming support?

Obviously, Paladin needs audio services, and I imagine that they'll be designed in a similar way to the structure of the graphics system already inside of Paladin.

Should look at Corban's dsp.js for some nice FFT & modulation features in the subsystem. Also, look at Unity for their Audio API.

The input subsystem needs some work.

1. Separate event string from event state (true/false).
2. Add input objects to keep track of input state vectors (humphd has already started this).
3. Move InputMap into game object/entity prototype.

I cloned an updated version, and after running the tests, realized that test 5 fails.

I do veleive JSilver mentioned he added the Math module to the test build.

Test 5. "common/Math/Vector2: Constants (4, 0, 4)" Fails

Here's the User Agent string from the test-output heading.
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1

I'm using chrome 13.0.782.220

The test only fails in chrome!

The test heading appears like so in chrome:
common/Math/Vector2: Constants (4, 0, 4)

In firefox, the test doesn't fail and the paraemter list is ordered differently.
common/Math/Vector2: Constants (0, 4, 4)

Investigate how possible/feasible it is for us to automate some of our functional testing. Can we automate some gameplay tests?

This might be a good start: http://funcunit.com/.

See cube.js in this commit. Renderer fails with

[12:46:32.801] compileMap.elements is undefined @ http://localhost/~afk/project/gladius.git/external/CubicVR.js/source/CubicVR.Mesh.js:1635

Send keydown events only once for the first time. Clients can optionally specify that they wish to receive the event each frame.

Port CubicVR's COLLADA loader into Gladius.

gladius.math submodule uses ssh://[email protected]:alankligman/gladius.math.git as the repo url, rather than an https: or git: URL, which means that someone cloning gladius must have a Github account to successfully checkout all of the submodules.

Seems there's some transposition going on somewhere. This causes two problems:

• Object positions are interpreted incorrectly. By convention, position is represented as:

[ 1, 0, 0, x,
  0, 1, 0, y,
  0, 0, 1, z,
  0, 0, 0, 1 ]

However, this seems to cause rendering problems. I 'fixed' this by changing the code in the math library, but my fix is incorrect and should be reverted.

• Using the conventional matrix representation for affine transforms, net transform should be computed thusly:

ParentTransform x LocalTransform

However, I had to transpose the operands in order to get position and rotation to work as expected.

Move investigation is needed here, as well as a solution.

When creating an instance of a Model component, a mesh and material must be provided.

new engine.graphics.component.Model({
  mesh: resources.mesh,
  material: resources.material
})

When many Models are created with the same procedural mesh but with different materials, the meshes end up sharing a single material. The problem seems to be related to model.mesh._cvr.mesh.materials. When creating a new material, it is appended to the 'shared' materials array.

The current workaround is to create a unique procedural mesh and material for each Model.

Gladius should rely on requirement for boilerplate require.js project stuff.

I'll put this on @secretrobotron for now.

Remove python dependency for dist tests by adding a node.js web server in the tools/ directory. Python web server can be removed when this is done.

JSCoverage looks like a good tool. Can we get this working with qunit?

Many games use the mouse to control the camera. We will need a way to report mouse deltas and to re-center the mouse pointer so it doesn't go outside of the canvas.

The engine needs a logger. This would allow us to filter logging to specific levels and should be fairly straight forward in implementation. In addition, it would unify and prettify error output.

Tentative use-cases:

var logger = engine.logger;

logger.info( 'core', 'someFunc', 'I am emitting information' );
logger.debug( 'core', 'someFunc', 'I am emitting debug information' );
logger.severe( 'core', 'someFunc', 'This information is quite severe' );

// Output
info    : core/someFunc: I am emitting information
debug   : core/someFunc: I am emitting debug information
SEVERE  : core/someFunc: This is quite severe

Requirements:

// Can construct a logger instance
var logger = new engine.Logger();

// Can also set module and/or function on a logger
logger.setModule( 'myModule' );
logger.setFunction( 'myFunction' );

// Shortcut for creating module logger and/or function logger
logger = new engine.Logger( 'myModule' );
logger = new engine.Logger( 'myModule', 'myFunction' );

// info, debug, severe, etc... can be invoked with fewer parameters...
//     if module/function have been set.
logger.info( 'message!' );

// <output>
info    : myModule/myFunction: message!
// </output>

Issues Worth Noting:

• Logger hierarchies? logger.getInstance( ... )?
• Nested modules?
• Output verbosity? eg logger.setVerbosity( 'info' )
• More logger configuration? Perhaps settable through configurator/registry?

Thoughts? Requirements?

Let's create a manual that covers the various parts of the engine and how to use it, along with example code for each section (where appropriate). We can also make an appendix of runnable example programs to go with the manual.

We are going to need a better tool than Github's Issues to log and track work for this project. Pivotal is the logical choice since it's already available and some of us have experience with it now.

It's still worthwhile to use Issues for tracking things at a high-level. I would like to try keeping milestones and larger tickets in here (because they have a bit more visibility to anyone watching the repository), with links in the issues to individual stories in Pivotal.

Dmose, can you make a Pivotal project for Gladius?

Engine support for ammo.js physics.

Not all browsers support the same audio codecs. The sound.Effect and sound.Track objects need to take this into account, and allow more than one URL to be defined, for various codecs.

It sands off a number of rough edges that we've been bumping against, include:

• Allow objects with no prototype to tested against object literals.
• Fixes #134 - Add a window.onerror handler. Makes uncaught errors actually fail the testsuite, instead of going by unnoticed.
• Fixes a bug where after an async test, assertions could move between test cases because of internal state (config.current) being incorrectly set

I have some concerns about adopting this branching model for Gladius. Consider this scenario:

• We have made several releases, 1.0, 2.0 and 3.0.
• Each major version has significant changes, such that it would be non-trivial to port a game between versions.
• Games have been deployed based on 1.0 and 2.0, and we discover a bug that affects all releases.

Using the workflow above, it is not possible to fix the bug in all the releases. Only in 3.x could we fix it. I don't see a way to fix the critical bug that doesn't require users to port their code to the 3.x that contains the fix.

Instead, we may need to maintain several production branches, instead of using master as the only production branch. I don't think git requires that we have a master branch at all, so do we even want one?

Thoughts?

I've started implementing a math module. Right now it's written into the global environment because it doesn't rely on an engine instance. Implementations are required for Vector (2, 3, and 4), Matrix (2, 3, and 4) and Quaternion.

Existing code is in src/common/Math.js, and unit tests are in the test/ subtree.

This chunk of code needs to be split out into a separate repository for both Gladius and CubicVR to use.

Currently we create an engine instance for each unit test in the qunit setup code. This causes problems when the engine fails to finish constructing itself and no unit tests will run, and no error messages are emitted. Also, these really aren't unit tests.

Fix the unit test suite to work with require, and only require the code we want to test.

Currently we handle all tasks for a particular frame before returning control to the browser. What is the impact of yielding after each task instead?

There's also an issue with using setTimeout() to control context changes.

I have a patch.

Rename the repository from Paladin to Gladius. Change all references in engine source from to engine, or gladius if engine isn't appropriate.

We should have more matrix math tests, especially if we want to replace the math module later on.