kantholtz / norne Goto Github PK

It would be nice if color ranges could be provided. The actual particle color would be a random value inside the defined range.

Currently, when outside values like the worlds depth or angle change, the whole cache must be recalculated. This can be prevented by getting a smaller subset of the original values. A function based on world.map is needed to do this calculation and should have this form:

x = y / (b + ( (100-dist)/100 * (1-b)))

Currently, to hinder physical particles from flying through the lanes ground, PhysicsJS convex polygons are used. Aside from technical problems that could lay on PhysicsJS side, this may better be solved by using lines and rigid constrains.

Whether this will replace or enhance util.clock is not clear. Currently util.clock is a multipurpose ticker and used for twists as well as rendering. The design is not finished, yet.

Without any indication why, the world is not rendered sometimes. Even an invocation of world.broker.render() does not help.

How particles are repelled by the ground gets implicitly defined by the data.lanes 'renderer' property. Every body-broker must listen on renderer changes of its lane and update the physics.body.lane.* accordingly.

To have a (linear) range of values only defined by start and end value is not only a requirement for core.story.storyline but can also be applied to a bigger array of problems.

If this functionality gets implemented, gradients and randomized color values can easily be created in conjunction with #8

Since the gradients color distribution is handled by the highest and lowest y-value at any given time, color jumps occur when the broker decides to remove or add points based on the worlds position.

A better approach would be to define the gradients values beforehand. Maybe based on the highest y-value of the lanes ground in general or a more complex object as described in #8

Currently removing lanes won't change the broker.proxy.

Currently, to raise a module specific exception, a work-around like this is used heavily:

var my_exc = _(norne.exc.raise).partial('my_module_name');

This is not acceptable since most of the time it is the only reason to encapsulate the whole module into an iife and also a bit hacky. It would be nice to make util.exc work like util.evt:

define('my_module').uses('util.exc').as({
  doSomething: function () {
    this.raise('my message to describe the problem');
  }
});

Dependencies:
util.obj must remember the objects name.

It must be possible to add, change and remove applied behaviours to any body.

Create color objects with convenient getter and setter methods for colors. It would be pretty easy to just adjust just the hue of a color value but retrieve an rgb(...)-String when needed. Overwrite toString to return the colors hex-code or something like that.

They could also encapsulate ranges as described in #6

A method to use some sort of newtonian behaviour must be found. It is possible to write a behaviour that lets all bodies be attracted to another subset of those bodies. But PhysicsJS does not explicitly group its maintained bodies.

So there may be different approaches to this problem:

1. Use the query facility of PhysicsJS. But I must look at it further, since everything I found was the (now closed) issue. It must be possible to save a query, otherwise there might be a lot of computation overhead for repeated querying. However, this saved query must be maintained carefully, since forcefields can be added and removed arbitrarily.
2. Add a property directly to every PhysicsJS world, that saves references to all added forcefields. This approach looks simple at the first glance but might cause a lot of trouble. Forcefield bodies would be maintained redundantly which could lead to inconsistency.
3. Add a property to every body or use body[i].geometry.name (might be slow though because of the necessary prototype chain lookup). This could be handled pretty well on the behaviour implementation level, but may cause overhead since the subset must be filtered every time 'behave' gets called.

Currently nobody listens to changes of the canvas' width and height. At least the brokers must be informed to update the broker.proxy.

The whole design choice to put physics related definitions inside data.body must be reviewed. All data.* objects should only hold static, render-independent data. Currently the state of data.body objects directly affect the rendering process.