Oolite Bulletins

A while back, there were complaints that the limited granularity of JavaScript timers meant they couldn’t be use for detailed animations. At the time, I suggested it would be better to use a completely separate mechanism, since doing something every frame is conceptually distinct from regularly-occuring timers. I’ve now implemented about half of this idea, so it’s time for some feedback-seeking.

The callback timer API will consist of two methods. (I’m not sure where to put them; I don’t want to stick them on Timer, as that would confuse the distinction I’m trying to make, and making them global is a bit untidy.) addFrameCallback() will take a function, and return a tracking ID. removeFrameCallback() will take a tracking ID and remove the corresponding frame timer. (The nature of tracking IDs is unspecified; it’s just some value that you stash until you want to remove your frame callback.)

Frame callback will be invoked once per frame, with the time difference since the last frame (in  game real time seconds) as a parameter. I haven’t decided whether it will be called (with a delta of 0) while paused; this depends in part on how easy it is to hook it up properly. For minimum overhead, there will be no way to specify the “this” value of the callback (so hey, we have a use for Function.prototype.bind() already), but it will have access to the variables in its declaration scope as usual.

Frame callbacks will be invoked after all entity updates, but before drawing, which seems the sensible place for custom animation. (For historical reasons, timers and tickle events fire during the player’s updates, which occur before every other entity’s.)

To support one of the obvious cases for custom animation, we’ll provide a way to get a reference to the model on a running mission screen. There are probably ways to mess this up horribly, but hey, Cabal_Common_Library already has a nasty hack to achieve this anyway.

As a minor note, since I just had to mess about with it, adding and removing frame callbacks from within a running frame callback will be possible, but somewhat inefficient, and changes will take effect in the next frame. (This last bit shouldn’t matter since order of execution will be undefined anyway.)

Ahruman wrote:

The callback timer API will consist of two methods. (I’m not sure where to put them; I don’t want to stick them on Timer, as that would confuse the distinction I’m trying to make, and making them global is a bit untidy.)

Since the frame drawing is handled inside Universe and this is going to be essentially a frame-related timer, would it make sense to implement it inside Universe as well? Or this is what you refer to as making it global?

Wow, this sounds exciting! What sort of animations will we be able to do? will we be able to rotate subentities from one position to another depending on certain events happening? eg like a star wars X-Fighter ship opening its wings from - to x when it goes hostile, or docking bay doors opening/closing on a space station?

Griff wrote:

Wow, this sounds exciting! What sort of animations will we be able to do? will we be able to rotate subentities from one position to another depending on certain events happening? eg like a star wars X-Fighter ship opening its wings from - to x when it goes hostile, or docking bay doors opening/closing on a space station?

Those docking-bay doors inside Griff’s rock hermits… I’d like to see those open and shut.

Griff wrote:

Wow, this sounds exciting! What sort of animations will we be able to do? will we be able to rotate subentities from one position to another depending on certain events happening? eg like a star wars X-Fighter ship opening its wings from - to x when it goes hostile, or docking bay doors opening/closing on a space station?

We can do that anyway, that's simple. The problem is that as timers fire at a smallest rate of 0.25s, you essentially end up with 4FPS if you try and "animate" things using them. For simple things (e.g. my Stellar Serpents or Butterflies) it works ok, but for other things it looks lousy (especially if you try and move things rather than just rotate them).

Looking forward to having a play with this, as I have a couple of test projects on the go at the moment which I was a little disappointed with due to the 4FPS. This may re-open their possibilities somewhat, which could be fun.

another_commander wrote:

Ahruman wrote:

The callback timer API will consist of two methods. (I’m not sure where to put them; I don’t want to stick them on Timer, as that would confuse the distinction I’m trying to make, and making them global is a bit untidy.)

Since the frame drawing is handled inside Universe and this is going to be essentially a frame-related timer, would it make sense to implement it inside Universe as well? Or this is what you refer to as making it global?

I meant in terms of the JS API. There’s no Universe in JS; it mostly corresponds to system, but the frame callbacks won’t be tied to the current system in any way.

Internally, they’ll be handled by a new singleton, although I might change it into (gasp) C functions.

Griff wrote:

Wow, this sounds exciting! What sort of animations will we be able to do? will we be able to rotate subentities from one position to another depending on certain events happening? eg like a star wars X-Fighter ship opening its wings from - to x when it goes hostile, or docking bay doors opening/closing on a space station?

As Thargoid says, they won’t change what you can do, only how often you can do it. Moving subentities around is possible already, but the ship’s collision geometry doesn’t update when you do it (and I’m not going to make major changes to that before MNSR), so geometry changes need to stay roughly within the same volume.

One other thing: timers created in ship scripts are sneakily associated with the ship, and are automatically stopped when the ship disappears. Frame timers won’t be, they’ll need to be manually managed (except when the game resets, of course).

Frame callbacks are now in, as described above. addFrameCallback and removeFrameCallback are global methods, and there’s also an isValidFrameCallback (which you shouldn’t need, but it’s helpful for writing unit tests).

Griff wrote:

Wow, this sounds exciting! What sort of animations will we be able to do?

I don't know about the other guys, but when you get excited, the whole galaxy moves!