R0J0hound's Forum Posts

  • 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)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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.

  • I guess you could move the object by the offset, check for overlap, then move it back.

  • You probably wouldn't want to use the angle of the car to check if another was behind. What happens if your car is going backward on the track?

  • For a game creation tool geared toward beginners this is a hard to understand and hard to explain quirk of picking. It has everything to do with when newly created objects are pickable.

    What Construct does is keep track of three seperate lists:

    object list (OL)

    new object list (NOL)

    selected object list (SOL)

    Before a event starts the SOL is the same as OL, and the conditions do picking that changes the SOL. So far so good, that's easy to understand.

    When an object gets created it isn't added to the OL right away. Instead it's added to the NOL and the SOL is set to just that new object. The NOL is only added to the OL at the end of a top-level event. Bear in mind a function isn't a top-level event.

    Also the pick by uid condition is special in that it can pick an object at anytime after it was created. This is the simplest way to just ignore this picking mess.

    Anyways that's a bit hard to follow so let's consider the examples in your capx.

    Test1 

    global spawnedCard=0

on "spawnCard"
--- create card
--- set card.carduid to card.uid
--- return card.uid

on "setScale"
pick by comparison card.carduid = param(0)
--- set card scale

start of layout
--- call "spawnCard"
--- set spawnedCard to returnValue
--- call "setScale" (spawnedcard, 0.1)
    Start of layout is triggered and the lists are:
OL=[], NOL=[], SOL=[]

spawncard is called
OL=[], NOL=[], SOL=[]

card is created and before the function exits:
OL=[], NOL=[card0], SOL=[card0]

Back in the start of layout event
OL=[], NOL=[card0], SOL=[]

setscale is called
OL=[], NOL=[card0], SOL=[]

it tries to pick the card with pick by comparison condition but since the SOL is empty it fails. The solution here would be to use the "pick by uid" condition.

the function returns and the "start of layout" ends and since it's top-level the NOL is moved into the OL:
OL=[card0], NOL=[], SOL=[]

    Test2 

    on setscale
pick card by comparison
--- set card scale

start of layout
--- create card
--- call setscale
    start of layout triggered
OL=[], NOL=[], SOL=[]

new card created
OL=[], NOL=[card0], SOL=[card0]

setscale function called
OL=[], NOL=[card0], SOL=[]

pick by comparison attempted. No objects in SOL to pick from so it fails. Again using "pick by uid" would fix this.

function returns and start of layout ends:
OL=[card0], NOL=[], SOL=[]

    test3 

    Start of layout
--- create card

trigger once
pick by comparison
--- set card scale
    Start of layout triggered
OL=[], NOL=[], SOL=[]

new card created
OL=[], NOL=[card0], SOL=[card0]

start of layout ends
OL=[card0], NOL=[], SOL=[]

trigger once starts. The SOL is set to the OL.
OL=[card0], NOL=[], SOL=[card0]

card is picked by comparison. This one works because the card we want is in the sol.

    The examples in your capx are fixed as i mentioned by using the "pick by uid" condition instead of "pick by comparison". Again that's because "pick by uid" is special in that regaurd in picking newly created objects. There are other situations where this picking is annoying to deal with, but in this case it's trivial.

    This behavior is a heavily ingrained part of how events work so I wouldn't count on it changing. Also i do believe it was intentional to avoid some bugs, not to mention i'm not sure a better solution as it relates to the picking system is available. I don't think something like this is very nice for beginners though.