Well that's effectively how it would work, except I think it's far more elegant and easier to implement a generic observable pattern. It's actually fortunate in this case as setters are not universally supported in JavaScript, but every setter is a function in construct. Every action in construct is a function (but I may be wrong).

I assume it would be no trouble adding observable logic to these actions inside the runtime, and it would be far cleaner than writing functions manually for each value that you wish to observe. It would be easier to code in an event driven way with this.

If construct objects were event emitters, the value setting function would emit a change event with the property name that had changed. This would then drive any events listening for the change. I might take a look to see if this is possible to update the construct objects to do this myself.

I can execute an event if and only if it changes, but the syntax is horrible. As I said, you have to a) make a comparison every tick, b) store the old value in a variable every tick. It's ugly not the most efficient approach.

You don't have to check every time in an observable pattern. In the observable pattern there is a check in the setter to see if anything is observing the value, and to trigger that event from the setter.

When you call Set Player.State, that is when you know that the value changed. Here is where the flag is raised. I do not check it on every tick and store the value every tick, I just trigger an event when someone tries to change it.

Yes one can test if a value has changed on every loop but it requires you to store the old state and it requires you to test on every loop. Observables are event driven. That means the event is triggered if and only if it changes. You don't have to store previous state, the hook is embedded in the set function, and you don't have to test the value every tick. You could make every property observable just by hooking into the set function.

I think it would be nice if you could have onchange events for variables. For example, I have an object with a state value associated with it. It would be pretty sweet to be able to say On State changed.

Ok, thanks. The multiple images as I said was just to demo a problem, not a suggested use case. However, you say it should be faster to tile one object, as I would have thought as well, but it's not with cocoonjs. The difference between pasting multiple whole images and using a single filled rectangle is the difference between 27fps and 22fps respectively in my tests, contrary to the expectation.

I will try and produce the other issue in a capx asap.

The seams should never show unless you filter the textures. Without filtering you dont see the seams and there is no reason why you should in a pixel perfect scenario. I would like an explanation otherwise.

I was trying to highlight a bug with cocoonjs. It doesnt look like a normal seam artifact in cocoonjs, the image is rendered smaller. I dont understand this behaviour when opengl will do the texture repeating for you...

There is no reason why 2 exactly the same squares with exact pixel sizes and no resampling should have gaps between the objects. The problem with cocoonjs is that the repeated image takes up less space than it is supposed to and the repeated images inside the rectangle overlap each other.

Ludei are aware of this bug.

It's a bug in cocoonjs I think. The repetition style is buggy. I edited the tiled background object to paste in images (I am using whole repetitions) and not only does it work, it's surprisingly faster...

FYI, I sent a bug report to Ludei today. It is quite likely that there is a bug in their fillRect implementation, since this is all the tiled background does. I will let you know how it goes.

In cocoonjs, the tiled background objects appear to have the wrong size when actually tiled. It seems to accumulate at a rate of 1 pixel per repetition.

To demonstrate this, I created a grid of tiled background objects. The image I used was 32 x 32 pixels and the grid was made of tiled backgrounds at 64 x 64 pixels each. From what I could tell, there is a 1 pixel (or so) gap between each tile.

Since I don't know the implementation behind construct and behind cocoonjs I can't say for certain who's fault this is, but I'd hope that since this affects construct that scirra will take this bug on and liaise with ludei if this is a fault in their canvas implementation.

Also, I placed a ring of tiled background objects around the level. So they are not visible and do not lie inside the level, they simply surround the level. In chrome, the object outside the level bleeds into the frame by 1 pixel.

We need pixel perfect rendering please.

To save you the time of reproducing the cocoonjs bug:

dl.dropbox.com/u/17781372/image%20bug.capx

I'd make it a link but I can't be trusted :P

Ashley, I understand why it's happening, I just think that not only is this majorly confusing, it's not ideal as a default.

I am beyond doubt that changing it would break a whole load of things. It's actually really nice that you can tell if an object is sitting on a platform or not for example without having to sink a detector 1 pixel down, it's just the wording is misleading.

My suggestion is to add something like "strictly overlapping", i.e. use strict inequalities instead of less than or equal. Add a strict option mitigates for the non-strict behaviour of the default overlapping condition. The boundaries only overlap because there is no convenient way of specifying (object width - smallest floating point delta), and had you been writing a game yourself in javascript you would want to use strict inequalities.

p.s. I might add, overlapping at offset is brilliant, a strict version would be sweet.

Why dont you support formal extension methods aka the decorator pattern?