R0J0hound's Forum Posts

  • worm1

    This doesn't really work with any other behaviors. Motion should be done with the set isometric position actions. The example capx show some ideas how to do this. You'd basically be creating the behavior with events but this provides some useful things to make that easier.

    Actually using some other behavior to do the motion could possibly be done by using a separate object and setting isometric position with that, but eh, it's simpler to just do it with events than to wrangle something to do something it wasn't designed for.

  • No problem

  • Why don't you want to use "move at angle"?

    You can do it with:

    Set X to self.x + dist*cos(angle(self.x,self.y,door.x,door.y))

    Set y to self.y + dist*sin(angle(self.x,self.y,door.x,door.y))

    Where dist is however far you want to move.

    You can use 100*dt if you want it to move 100 pixels per second.

  • You're probably better off just duplicating obstacles off screen to handle that.

  • Use a separate identical sprite that you position manually.

    So say the screen width is 640

    player.x < 320

    --- clone: set position to (player.y, player.x+640)

    else

    --- clone: set position to (player.y, player.x-640)

  • YoHoho

    A simple way to do multiple would be to clone the band object, duplicate the events and change the old band of the new with replace.

    The length and location of the band is hard coded into the events. You'd have to change the positions of the bands, change the event that resets the band's angle and length when no can is on it (event 1), and change the event that sees if the can is on the band (three conditions on event 3).

    To appear and disappear it's probably as simple as destroying and creating the bands, and setting the length and position from what can be figured out with the previous question.

    Overall the capx wasn't really designed for a lot of that so it would have to be reworked. Maybe understanding what is done would be useful in making something that makes everything easier.

    basically it just checks if the can is between and below two points. When the can first falls in that area then the distance from the can to the the two ends is measured, this is the rest length of the two halfs of the band. Than after that both halves apply a force to the can. It's a spring force and both are calculated with F=-k*(length-rest_length) for each band half. We then apply those forces in direction to the endpoints and that's what moves the can. The spinning and slipping along the band are more of a fuzzy thing. The capx condenses that stuff and also using the band sprites as a visualization.

    Anyways a fixed capx or a redesigned one that supports what you want to do more easily is left to someone else to do. I won't get around to it.

  • mikehive

    If the events are the same and the image points are placed in a clockwise order in the sprites then it should work.

  • orangpelupa

    link updated

  • As stated elsewhere spriter, spine or any other third party plugin that draws is waiting on this issue as far as i know.

    https://github.com/Scirra/Construct-3-bugs/issues/510

  • 100x100 x 30x30 x8 is 72Mb

    100x100x 100x100 x8 is 800Mb

    Saving it to disk as json will be quite a bit larger since each number no longer only takes 8byte but usually more depending on the number.

    But idk. you can always generate less than a row in an array at a time. Still i only have a vague idea of what's going on. Good luck with the project.

  • Sounds like a logic issue. It shouldn't get progressively slower and use more and more ram. It should stay constant.

    100x100x25x25 is nothing.

  • It doesn't sound like an absurd amount of data. As you sure reading each pixel of the 100x100 image isn't the issue? That's a slow action.

    Javascript can be a much faster at running but you lose the ease of interacting with the rest of C2. I wouldn't recommend it. Using just javascript with some other game library and not use c2 at all would be simpler i think.

    Anyways, if doing everything all at once locks up the browser you could redo your logic to do the generation over multiple ticks instead of all at once.

    so instead of this:

    start of layout

    array: for each xy

    --- do something

    you could do something like this:

    global number y=0

    y<array.height

    --- for "x" from 0 to array.width-1

    ------ do something

    --- add 1 to y

  • Sure, but I don't think it'll be that much more accurate because the fit curve can deviate a lot.

    Anyway, the first step is to find the equation of a curve through multiple points.

    2 points would be a line,

    3 would be quadratic

    4 would be cubic

    So basically you'd keep track of the last 4 positions and then using these cubic equations:

    x(t)=a*t^3+b*t^2+c*t+d

    y(y)=e*t^3+f*t^2+g*t+h

    you'd plug in all the x,y and t values and solve for the unknowns. you can probably pick evenly spaced values for t. Here would be all your equations:

    x0=d

    y0=h

    x1=a+b+c+d

    y1=e+f+g+h

    x2=a*2^3+b*2^2+c*2+d

    y2=e*2^3+f*2^2+g*2+h

    x3=a*3^3+b*3^2+c*3+d

    y3=e*3^3+f*3^2+g*3+h

    Then you'd just solve for all the unknowns: a,b,c,d,e,f,g,h which would define the shape of the cubic curve that goes through the last four points.

    The solving could be done with algebra as a system of equations. you could also use a matrix and guass-jordon to solve it but the result would be the same. You can get someone else more current with math to do it if it's not something you want to do.

    Anyways after that you'd have the cubic equations through the last four points, and going from t=0.0 to t=1.0 would give a curve from the current position to the previous. Actually that's flawed because if you drew that curve every frame the resulting curve would break every frame. so a better solution would be to use a different curve such as catmoll-rom or hermite or bezier. basically using p(0)-p(1) and p(2)-p(3) as tangents a only looking at the curve between 1 and 2. I've seen equations that do that and keep the curve continuous, but it probably can be derived.

    So the above gets you the equations for a curve, or at least gives some leads how to get it. Next the actual getting of the length. To get it perfectly you could use an integral, but that's not solvable in most cases. The simplest solution is to use the equations we found to get a bunch of positions between frames and add the distances between those together. The more you use the more accuracy you'd get.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You probably can assume an addon works with minify unless the plugin description says it doesn't work with it. Often though the addon dev never tests it with minify to catch the issues in their plugin.

    Minify or no, it's not like it makes a game any harder or easier to reverse engineer.

  • I do all I can to avoid using JavaScript usually, but the solution is just like I said. You pass offsetX and offsetY to the condition and then before you use testOverlap you add the offsets to the inst position, then after the test you subtract it.