Move scaling, rotation, alpha, etc to me.Renderable

[parasyte]

For discussion: I think the me.Renderable base class should be responsible for all drawing, including scaling, rotation, and opacity/alpha blending.

I'm indifferent about keeping backward compatibility by continuing to support these properties on ObjectEntity.

[agmcleod]

Yup agreed. I think it should be simple enough to put in the migration guide to change angle/scale/alpha on an ObjectEntity to invoke on the entities' renderable. Plus, we could also change the constructor to apply it to the renderable, if someone sets those properties in tiled.

[petarov]

👍

[agmcleod]

Might as well write this here. Was trying to think of how to implement this. Since the SpriteObject does not call parent renderable draw, and it does all the rotation stuff, it is able to wrap that around it's call to the context.drawImage(). The AnimationSheet simply invokes the SpriteObject Draw, and does not implement its own. It just simply updates the image to be drawn each time.

So If we want to put the context save, followed by the alpha, rotation & scaling followed by the context restore, there needs to be an execution between those.

draw : function(context) {
  context.save();
  context.globalAlpha = 0.5;


  // draw logic to happen here

  context.restore();
}

Because of that, the sprite object can't just invoke this.parent(). One way might be to do the actual draw image call in another method on the sprite object, and pass that to the parent:

drawImage : function(context, x,y) {
  context.drawImage(this.image, x, y, this.width, this.height);
},

draw : function(context) {
  this.parent(this.drawImage);
}

But I'm not sure if that might have other issues or drawbacks.

My Concern with it is how does one subclass Renderable and draw? I imagine we could put the setup phase of the draw in one method, and the restore in a teardown.

setup : function(context) {
  context.save();
  context.globalAlpha = 0.5;
},

teardown : function(context) {
  context.restore();
},

draw : function(context, exec) {
  this.setup(context);
  typeof exec === 'function' && exec();
  this.teardown(context);
  this.parent(context);
}

Then extend like so:

var MyDrawer = me.Renderable.extend({
  init : function() {
    this.parent(new me.Vector2d(100, 100), 100, 100);
  },

  draw : function(context) {
    this.setup(context);

    context.fillStyle = '#f00';
    context.fillRect(this.pos.x, this.pos.y, this.width, this.height);

    this.teardown(context);
  }
});

Though the issue with that is you can't call the Rectangle's draw method.

[petarov]

I like the idea about:

draw : function(context) {
  this.parent(this.drawImage);
}

I think it is a nice way to inject more code in the draw routine. From what it seems, it'd also be backwards compatible in contrast to the setup and teardown concept?

[agmcleod]

I was thinking the setup/teardown would be needed if you want to subclass renderable, but maybe not.

drawStuff : function(context) {
  context.fillStyle = '#f00;'
  context.fillRect(0, 0, 100, 100);
},

draw : function(context) {
  this.parent(context, this.drawStuff);
}

[petarov]

Yeah, probably the only question that remains (which setup and teardown maybe would have solved) is when to execute the injected function. At the beginning or at the end in the parent drawcall? Or maybe configurable?

[agmcleod]

After the calls to alpha, scale and rotation is how I see to approach it. Then either do a restore() or undo those values after the passed function is called. Be sure to invoke rect#draw as well. The renderable does not really implement much as far as drawing is concerned right now. The only logic it will have is the logic I want to move into it, which is the a/a/s values.

[obiot]

just thinking out lout, but another way to tackle this would be through this texture object i was mentioning in another ticket or in the forum.

iany object would render to a local texture (canvas), and the base renderable would then render the texture on the final canvas, applying any required transformation.

[agmcleod]

Hmm, interesting. How would the renderable know about that canvas? Would it be simply passed an id or something?

Would managing many texture canvases be an issue from a dom/memory perspective?

I might be misunderstanding, if so, maybe just dish out some quick pseudo code or somethin :)

[obiot]

i guess that every renderable objet would hold a texture object that inheriting object would render on ?

but yes I guess this would impact performances somehow, although it might however help for composed sprites ? (i'm thinking object container, or other complex composed objects like spine)

[agmcleod]

This is where WebGL would be really useful, haha. With transformation matrices and such. The parent renderable having a public property would make implementation easy though.

Maybe it's a matter of having both ways to approach it, have the programmer decide what is best?

[parasyte]

Actually the texture idea is really easy to use; draw already accepts a canvas context. So pass the context of the local texture instead of destination screen.

I think it might be a bit memory intense, and will add some CPU cycles to do the final drawImage to the screen context, too. But it is an interesting idea.

So far the callback idea for draw sounds the most interesting to me. Everything we can do to limit the total number of canvas calls will be useful. :)

[obiot]

Note that more complex transform was the intention behind the following branch :
https://github.com/melonjs/melonJS/tree/matrix-based-transform

But it's still in early alpha stage :)