R0J0hound's Recent Forum Activity

  • One frame behind would be from double buffering. 2 frames from triple buffering. Guess it’s mostly dependent oh what the browser does, or maybe graphics card settings. No idea if construct does its own buffering on top of that.

    Typically games hide the windows cursor and just position the mouse to hide that.

    Chrome does have a feature when creating a canvas context to be desyncronized, which lets it bypass a lot of the browser’s renderer to be single buffered, but there seem to be drawbacks such as tearing and I’m not sure if other browsers support it.

  • I'd say there is nothing wrong with the way you're doing it. It works and it's easy enough to understand and modify.

    A lot of the events have a similar structure so yeah you could make it so most of it as data instead of all events. That has the benefit of being easier to change how it works with a few events instead of changing all the events. The data can be array/json/xml/something else but it comes down to what you want to do.

  • The c3p file is just a zip file with all the games source as jsons of the events and such.

    The exported project packs all the game into a data json, and the runtime and plugins are minified together.

    Most porting services go the route of generating code from the source, but I think at least one just makes their own runtime which uses the same exported data json. But even if they have tools that automate most of it I think they deal with things case by case since construct is heavily tied to html5 tech.

    In short there is nothing readable that will show how events equate to JavaScript. You’re better off just writing equivalent code from reading the events manually.

  • I tried opening it. No new ideas. Maybe rotate the layer instead of the layout? I ran out of time to fiddle with it. JavaScript won’t provide anything more than what you can do with events.

    I won’t be able to debug it. If the sprite isn’t being drawn where you touch then construct isn’t doing what it should or we just aren’t understanding what is happening. I gave the rotation formula to give a way to correct it. With 90 degree turns the coordinates come out to either

    -touch.y+2*scrollx, touch.x

    Touch.y, -touch.x+2*scrolly

    If it’s not drawing the whole area then check the drawing canvas size.

    If none of that works or doesn’t makes sense then I’m explaining it poorly or missing something.

    Probably best to wait for someone else’s answer at that point.

  • Rotation is just an extra step. The math to rotate is:

    NewX=(x-centerX)*cos(a)-(y-centerY)*sin(a)+centerX

    NewY=(x-centerX)*sin(a)+(y-centerY)*cos(a)+centerY

    So you’d take the mouse location and rotate it by sprite.angle around the sprite’s location as the center. And you’d just use that rotated mouse location in the steps in the previous post.

    The scaling is already handled.

    You could have it work with the origin in other locations such as centered but it just takes fiddling with the math a bit.

  • You’ll have to calculate it manually since you can’t access mesh points, only set them.

    For simplicity I’m assuming the sprite isn’t rotated and the mesh points are just laid out in a square grid where you just changed the zelevation.

    First step would be to save the zelevations into an array as you set them. 

    Start of layout
— sprite: set mesh size to 10,10
— array: set size to 10,10,1
— For x from 0 to 9
— For y from 0 to 9
— — array: set at (x,y) to mountainFunction(x,y)
— — sprite: set mesh point (x,y) to … zelevation= array.at(x,y)

    The next step would be to figure out what square a layout position is over. For simplicity I’ll use the mouse location and the sprite will have its origin at its top left.

    X0 = (mouse.x-sprite.x)/sprite.width*10

    Y0 = (mouse.y-sprite.y)/sprite.height*10

    Then int(x0), int(y0) would give the top left index of that square in the array. You may want to clamp that value or do a condition to see if the values are in the range of 0 to 10 otherwise it’s off the mesh. Btw 10 is just the mesh size.

    Anyways with that we are almost there to find the z. One approximate way is to bilinearly interpolate between the corners of the square.

    Z= lerp( lerp(array.at(int(x0),int(y0)), array.at(int(x0)+1,int(y0)), x0-int(x0)), lerp(array.at(int(x0),int(y0)+1), array.at(int(x0)+1,int(y0)+1), x0-int(x0)), y0-int(y0))

    A more perfect way is to understand that each square is made up of two triangles. You just figure out which triangle you’re over and use barycentric coordinates to interpolate the value over a triangle. I don’t know this over the top of my head but Wikipedia can help of you can derive it.

  • Maybe just add a hud layer that you don’t rotate? Again construct should do the conversions for you.

    Alternately if you just want to do the conversions your self here is the formula to rotate a position around a point. Maybe you can use that to unrotate the touch position or something.

    NewX=(x-centerX)*cos(a)-(y-centerY)*sin(a)+centerX

    NewY=(x-centerX)*sin(a)+(y-centerY)*cos(a)+centerY

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • In general construct will handle that for you. By default I think that touch.x will get the position on the top layer but you can specify the layer with touch.x(layer)

  • Vanilla Construct 2 doesn't come with any 3d. With some math you can transform sprites to move in a 3d way but for raycasting to make sense you'll want triangles. We can't draw arbitrary triangles or distort meshes like we can in C3. There is a trick though where we can make any triangle out of two right triangles. After that a raycast is just a 2d collision check with the triangle sprites.

    dropbox.com/scl/fi/g56pg4thhheg71yourl94/c2_simple3d_triangle_raycast.capx

  • It's probably in how events work or something. I don't have a link.

  • It probably covers that elsewhere in the manual. By default all instances are picked. Conditions filter the instances that are picked, but some are just logical conditions and do no picking. When an object is created it becomes the only instance of that type that is picked for the rest of that event or until another instance is created.

    That's basically the meat of picking but there is also some nuance to "else", "or" and how created instances are added but you don't have to typically worry about those.

  • Another option to make it faster is to do the same thing in JavaScript. That would churn through the loops faster than the event sheet. Further down that rabbit trail is wasm but not sure it’s worth all the extra effort. Faster still could be to somehow leverage the gpu to do it in parallel. Maybe pack all the data into a texture, run that through a shader onto an output shader, and read back the pixels for the result. I may be mistaken though since I’ve never attempted that and your sim may not be able to be parallelized.