Naji - Also, unbeknownst to most here is that the file you are looking at is broken in a small but huge way, thanks to emscripten. The construct 2 implementation of box2d is far from feature complete and so avoids the bugs...

Naji - unless you already have some files in java and want them in javascript... I would recommend just writing the scripts you need in javascript. Emscripten doesn't work perfectly and tracking down bugs is a pain. Also, you have to spend alot of time familiarizing yourself to the way the results are outputed. Also, I have no clue if it works on java to javascript.

TLDR - it probably isn't worth your time, unless you have a file that = box2d in complexity and need a performance boost.

YetAnotherSuperhero - I like the idea of having control over the way in which layers are rendered, rather than having it tied to parallax

rexrainbow - Thanks for your help!

I can't seem to be able to get a plugin call to work, though: It always returns NaN...

//Runtime

Acts.prototype.SetX = function (tilemap, zX)

{

cr.plugins_.Tilemap.prototype.Exps.PositionToTileX.call(tilemap , fake_ret , zX);

this.testing = fake_ret.value;

};

//edittime

AddObjectParam("TileMap", "Set the tilemap");

AddNumberParam("X", "X");

AddAction(6, af_none, "Get tilemap x ", "", "gets test x", "No Description", "SetX");

Ashley - Layer offsets, Any chance of this happening?

Another solution to this problem can be to only add velocity to position whole integers. For example:

vector2 velocity;

vector2 preIntegrated;

vector2 position;

every tick

--- preIntegrated+=velocity

---

--- If ( abs( velocity.x ) > abs( velocity.y ) ) {

--- --- if ( preIntegrated.x >= 1 ) {

--- --- --- position.x += floor( preIntegrated.x );

--- --- --- preIntegrated.x -= floor( preIntegrated.x );

--- --- --- // Integrate Y

etc

There are some bugs here but the idea is simple (negative compared to positive would have to be handled)

When pixel rounding is on, the objects are drawn at the nearest pixel positions. ie -> 0.4 is drawn at 0 and 0.5 is drawn at 1.

Consider the following : Y = -0.5x

An object slowly moving to the right will also move upwards at half the rate it is moving to the right. However, because of the pixel rounding, the object appears to...

move right,

wait,

move right,

move up,

move right,

wait

move right,

move up,

etc...

This cause a noticeable hitching, as the object does not move up at the same time as right.

If, rather than rounding the objects position, floor can be used to eradicate this hitch. The movement appears as follows

Move right,

wait,

move right and up in the same tick

wait,

This is much more visually appealing, and is preferable to the visual syncopation resulting from rounding positions.

You can can get around this by subtracting 0.5 from the positions of all drawn objects at the end of all events and then adding it back to them at the beginning. However, of course this doesn't work with other behaviors that move objects.

The solution is to be able to specify whether you want an object rounded to the nearest pixel, or to be rounded down when using pixel rounding. This should not be hard to add.

There is also a historical precedence for this option, studying mario 3 and super mario world shows that an object never moves along one axis independent of the other unless that axis is is being changed at a greater rate than the other. If velocity x = 10 and velocity y = 5, visually y will never move without also moving x.

This effect is even more pronounced when a camera is also involved moving at dynamic rates set via x=target.x * 0.5 etc. Equations such as these result in visual transitions that create an jittering effect despite the fact that the game is running smoothly.

Anyway, any one up for discussing this? I think it is a needed feature.

Tokinsom - I must be missing something, how do you copy the tile then? I didn't see a relevant portion in the manual, but then I only glanced quickly at it. I wish just a little more work would go into the tilemap. In all honesty, I know how hard it can be as a single developer, but I feel designing levels in construct 2 should be as smooth and seamless as possible. Saying that construct 2 tilemap is to tiled as the construct 2 image editor is to photshop is a bad comparison. It's easy to switch between photoshop and construct. It's not so easy to always be switching from tiled to construct.

BTW, I have had some relative success editing other vanilla plugins to make them more robust (physics for one thing). Many changes can be simple to implement and won't break existing projects. Usually, I end up reading through them so I can argue with Ashley in a more informed manner about what needs to be done (I'm sure that's not annoying in the least). But anyway, if it becomes a productivity issue (as I think the no copy blocks or move existing tiles around will be) I may see If I can add the feature myself.

Tokinsom -

"4) Will we be able to "copy" tiles that have already been placed (like right-clicking a tile in Tiled)? This is very useful for laying down certain patterns to place elsewhere, and keeps you from having to go all the way to the tileset to pick a tile."

"5) Will there be hotkeys for the tools? (At the very least right-click to erase tiles?) "

Ashley - "4-5) The current tilemap editor is very much a first iteration. We'll be improving it over time."

I think that this is still a good question? Has there been any updates on this front? I was messing around with the tilemap plugin and it seems like 4 still haven't been addressed. #4 isn't just a handy feature- I would call it necessary. Making maps in tiled kills workflow when a game "needs" levels that work with game mechanics. ...and lets face it... a copy tool within the plugin should be easy to make....

In the end, it's little features like this that make all the difference.

QuaziGNRLnose

That's good to know, It's crazy how smart compilers are at this point. My problem is, is that I am never sure if I am slowing things down or doing good. I have been setting a system that sorts the objects and tries to ensure I can compute sin(a) and then use it on all objects with the same angle calculation. after those are taken care of I then calculate the rest. I try to save as much cpu time as possible due to a heavy physics system.

Hey,

Does anyone know if sin and cos have look up tables in c2 to speed it up or is it calculated every time it is called?

Thanks

R0J0hound ... I imagined you would be first to answer. The first one works so long as you use degrees and not radians. The whole data oriented approach sounds good though. I will build some testers for this and find out. I had always heard sqrt() was slow but I figured it might be faster than multiple calls to sin or cos.

sqiddster - I never cared much until I wanted to create a small library and wanted to make sure I do things the most efficient way. If I can... Just so it doesn't bite me somewhere down the road.