R0J0hound's Recent Forum Activity

  • nutmix

    a) This is because of how a computer samples the mouse. The solution is to use a line from position to position or draw at in between positions like Coin-coin le Canapin's example.

    b) With the canvas plugin you can by using canvas.alphaAt(x,y) for each pixel or use the slightly more esoteric yet faster canvas.AsJSON expession to get the pixel data into an array.

  • christina

    Here is a capx with the idea I posted. The only error was "screeny = ((v-0.5)/z + 0.5)*h2 + o2.y" needed to be changed into "screeny = (v/z)*h2 + o2.y".

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

    I tested it with a plane rendered with two different field of views and it seems to become less accurate if I use a fov other than 60. It probably needs to account for that somehow.

    Your last capx isn't working right because it's it's scaling from the left instead of the center. See 2 above^

    Also for your original capx changing the set y expression to "board.Y + (relativeY*board.Height) /lerp(2,1,relativeY)" seems to get the y working better. You can adjust 2 to change the strength of the effect.

  • I didn't test it so there may be errors. Also I can't look at the capx till tomorrow.

    Z is the distance from the eye, which is at z=0. The camera is at z=1. Anything further will have a greater z which in turn will look smaller since the perspective is calculated with x/z, y/z. Basically the bottom width divided by 1.7 should equal the top width.

    1. The idea I had was to find how far away the back edge would have to be if it was that width. Without perspective the top edge should be just as wide as the bottom. With perspective the same projection formula can be used proj_width=width/z. Sovlving for z it come out to z=proj_width/width, and then it's just a matter of interpolating by y or v.

    2. The 0.5 is so we're scaling at the center instead of the left edge. U and v are in the range of 0 to 1, so 0.5 is halfway. Also /z is scaling.

    As a simple example say you wanted to double the x distance from 320 you'd do:

    X=(x-320)*2+320 if instead we wanted to just scale from 0 it would be

    X=x*2

  • This may work:

    In it's basic form a perspective projection in just dividing x and y by z.

    This is the 2d map.
o1 is the top-left corner and p is a point to project.

   w
o1----+
|     |
| p   |h
|     |
+-----+

Convert them to u and v to get coordinates from 0-1
u=(p.x-o1.x)/w
v=(p.y-o1.y)/h

Next we have the perspective sprite.  w1 and w2 are the widths of the top and bottom. o2 is the top-left and h2 is the height.
      w1
o2  ______     -+
   /      \     |
  /        \    | h2
 /          \   |
/____________\ -+
      w2

We find the z from v with:
z = w2/lerp(w1, w2, v)

Then we can do the perspective transform with:
screenx = ((u-0.5)/z + 0.5)*w2 + o2.x
screeny = ((v-0.5)/z + 0.5)*h2 + o2.y
[/code:1ikwzr29]

  • My guess is x and y are needed if The layout or layer is rotated. If you really want to see the math you can look at the js files in the exporter directory of the C2 install.

    The manual covers what the mouse expressions do pretty well imo:

    https://www.scirra.com/manual/114/mouse

    [quote:2u6007p7]Mouse expressions

    AbsoluteX

    AbsoluteY

    Return the position of the mouse cursor over the canvas area in the HTML page. This is (0, 0) at the top left of the canvas and goes up to the window size. It is not affected by any scrolling or scaling in the game.

    X

    Y

    Return the position of the mouse cursor in game co-ordinates. This is (0, 0) at the top left of the layout. It changes to reflect scrolling and scaling. However, if an individual layer has been scrolled, scaled or rotated, these expressions do not take that in to account - for that case, use the layer versions below.

    X("layer")

    Y("layer")

    Return the position of the mouse cursor in game co-ordinates, with scrolling, scaling and rotation taken in to account for the given layer. The layer can be identified either by a string of its name or its zero-based index (e.g. Mouse.X(0)).

    https://www.scirra.com/manual/126/system-expressions

    [quote:2u6007p7]Layers

    In expressions where a layer is required, either its name (as a string) or index (as a number, zero-based) can be entered.

    CanvasToLayerX(layer, x, y)

    CanvasToLayerY(layer, x, y)

    Calculate the layout co-ordinates underneath a position in canvas co-ordinates for a given layer.

    LayerToCanvasX(layer, x, y)

    LayerToCanvasY(layer, x, y)

    Calculate the canvas co-ordinates above a position in layout co-ordinates for a given layer.

    I'm curious in what ways you'd like it to be improved?

  • You can using the wallclocktime expression. Basically do something like this:

    global number starttime=0

    every tick:

    --- set starttime to wallclocktime

    [some events here]

    every tick

    --- set debug text to wallclocktime-starttime

  • Aurel

    Feel free to post it. I haven't had time as of late to mess with it. I'm just glad it could be improved.

  • The lines are being drawn on sub-pixel lines. Mouse.x and .y aren't always integers.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Aurel

    Just saw this, glad you got it sorted.

  • It appears that when extend-box-horizontal or extend-box-vertical are both 0 the vTex coordinates are on the sprite, where the origin is the bottom-left corner of the sprite. But when either is non-zero then the coordinates are on the screen, where the origin is the bottom-left corner of the screen.

    The issue is if we wanted to scale from the center of the sprite we'd need to find the vTex coordinate of the center of the sprite, and I haven't seen any example of this in the plugins. Looking at some of the radial effects you can use the center of of either the object or screen, depending on what the vTex's are on, but it's not helpful if we want the center of the object when the vTex is on the screen.

    Trying to see what we have to work with, here are some of the variables that C2 provides for shaders (from glwrap.js):

    pixelWidth;

    pixelHeight;

    destStartX;

    destStartY;

    destEndX;

    destEndY;

    layerScale;

    layerAngle;

    viewOriginLeft

    viewOriginTop

    Poking around glwarp.js there seem to a couple more, like samplerFront, vTex...

    Also built in to glsl you have these:

    https://www.opengl.org/wiki/Built-in_Va ... der_inputs

    The bottom-left is always (0,0) and the top-right is always (1,1).

    You can calculate the width in pixels with 1.0/pixelWidth, the height can be calculated in a similar way.

    Interesting, but nothing really helpful. The only solution I can think of would be to add two more parameters for the center x and y and set them every tick. Then the math would be something like (x-center)*scale+center.

  • Describe the offset. If you set extend-box-horizontal to say 10 is it offset right 10 pixels? Maybe the vTex positions have an origin at the top left? So The points clockwise are (0,0), (1,0),(1,1),(0,1) perhaps?

    At any rate maybe you could offset it back using the built in pixelWidth var? So with a extend-box-horizontal of 10 and a extend-box-vertical of 5 maybe this would work?

    uniform mediump float pixelWidth;
uniform mediump float pixelHeight;

vec2 tex = vTex * (1.0-size);
tex.x -= pixelWidth*10;
tex.y -= pixelHeight*5; [/code:39h6zqw8]

  • Sprite's in the debugger show their angle in the range of 0-360 so I assume it's variables you have?

    Sprite.Angle gives it's angle in the range 0 to 360.

    The angle() expression gives a value of -180 to 180.

    If you just subtract from a variable it will naturally go to negative infinity.

    This will convert any angle to the range of 0 to 360:

    (a%360+360)%360

    This will convert any angle to the range of -180 to 180

    angle(0,0,cos(a),sin(a))