R0J0hound's Forum Posts

  • You use the layer2canvas expression first, the parameters are fairly straight forward, it uses x and y because it also takes into account rotation as well. After that you use the canvas2layer expression to convert the coordinates to another layer.

    the other expression wasn't tested which could explain it not working.

    You could try newts sugestion and just move the background by giving it the bullet behavior and setting its angle of motion to be opposite to the players angle of motion. You then would set its speed to 0.25*player.speed to get the same visual effect a paralex, except on the same layer without the need for coordinate calculations.

  • You should be able to convert an x on a paralex layer to an x that is visually the same as an x of a non paralex later with something like:

    X + (scrollx-view_width/2)*layer_paralex_x/100

    And similarly for y.

    Also alternatively there are some system expressions to do the conversion: Layer2canvas and canvas2layer.

  • I managed to simplify the capx that creates the error to two events.

  • Ashely Ancillary

    Here's a simplified capx that produces the error.

    https://dl.dropboxusercontent.com/u/542 ... r_bug.capx

    To reproduce from scratch:

    1. create a new project

    2. add another layout

    3. in the new layout add a sprite and array, then put them in a container.

    4. In the first layout add two events:

    every tick: create sprite at (0,0)

    system->pick by comparison Array 0=0

    5. run layout for error.

  • To save set the array size to (sprite.count, 2, 1) and use a

    For each sprite

    --- array: set (loopindex, 0) to sprite.x

    --- array: set (loopindex,1) to sprite.y

    To load use

    Array: for each x

    --- system:create sprite at (array.at(array.curx, 0), array.at(array.curx, 1))

  • I think it's the same bug as in ancillary's bug report. It has to do with the "pick by comparison" condition with an object in a container. I perused his capx a bit to see if it can be simplified, but I ran out of time.

  • You can use google instead to search the forum/scirra site like so:

    https://www.google.com/#q=nw.js+site:ht ... scirra.com

    Edit:

    Opps, I need to read better. Newt already posted that.

  • Here's the one skinkan is talking about:

    And here's another:

    But yeah, it's not really too simple, as both capx of relatively efficient events are both at least 100 events a piece.

  • You could use the .ZIndex expression to get the z order of the object, then you could draw the instances in the same order with:

    For each behindinfront ordered by behindinfront.ZIndex ascending

    --- paster: paste behindinfront

  • Hi,

    I was tinkering with something similar a few months back. I was going for a replication of the way event sheets can be manipulated. What I came up for drawing the tree was have each node know what node was next and what it's first child was.

    In a picture one possible tree could look something like this:

    node -> child -> node
 |                |
 v                v
next             next
 |                |
 v                v
node             node[/code:atbyigrr]

Then to draw the tree I start at the root node and recursively position all the other nodes.

In this capx the relevant stuff is in the "tree layout" group.
[url=https://dl.dropboxusercontent.com/u/5426011/examples27/node_tree.capx]https://dl.dropboxusercontent.com/u/542 ... _tree.capx[/url]

  • —

    It's not using the object's origin, it's just using the center of the object regardless of where the origin is. It was an oversight to not take into account the center of a polygon shape. I'll be taking a look into it.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Added a bugfix:

    • there was an error if you destroyed a paster object when webgl wasn't available.

  • Upadated to 2.2d

    spongehammer

    I think I fixed it. It was caused by using polygon collision shape and there was an uninitialized variable named "tri". After that I found another bug by turning on "use strict". It should work now. Also I fixed a bug with paster when webgl isn't available that your capx exposed.

  • The events run after the behaviors so actions do override it. For the pin behavior even on a slow computer it should not jitter, because drawing still isn't done till the behaviors and events are done running.

  • This post has the update order using SDK terminology:

    The order you have the behaviors is the order they run. The main exception is the pin behavior which isn't run till after the events. The following is the order things are run:

    run Behaviors

    run Events

    run Certain behaviors like pin are run here instead

    Draw

    Well it's actually a bit more complex than that when considering multiple object types and instances. You generally don't have any control which object type is run first. The order they're added define the order. Usually it doesn't matter though.

    For each object type

    For each instance

    For each behavior except pin

    --- run behavior

    run events

    For each object type

    For each instance

    For each pin behavior

    --- run behavior

    draw

    In the example you stated the pin behavior should correct object1's position before drawing, so you the bullet behavior shouldn't affect it.