R0J0hound's Recent Forum Activity

  • What have you tried so far? Generally most would just use the physics behavior for that. Turn off gravity and add a lot of linear damping to the balls so they slow down.

    That would basically be sliding circles and can look good enough and is easy to do.

    More advanced would be to model the balls as actual 3d balls with more elaborate physics. That would be done by either wiring in a general 3d physics library or rolling your own specialized 3d physics.

  • So a damped spring works well for getting the position to match but since the target is moving we probably want to match the velocity too.

    If you assume the target is moving at a constant velocity or with a constant acceleration it’s fairly easy to predict where it will be in the future. Ideally you’d take the predicted path and the path of the crosshairs and solve it so that they cross paths at the same time. But I can think of a few reasons why that would be hard to calculate.

    Alternately maybe we could modify the formula a bit. It’s basically -spring*dx/dt-damping*velocity. So the damping is applied to the total velocity. Instead we could damp by the relative velocity. That would let it settle on the path the target is moving instead of lagging behind. So something like this? I haven’t tested it.

    Scope: Add -0.005*(scope.x-target.x)/dt-0.1*(scope.vx-target.vx) to vx

  • You mentioned a rubber band so you could do that with a damped spring. Basically add two variables for xy velocity: vx,vy. Then do the following. You can tune it by changing the 0.005 and 0.1 values. You can use any value from 0 to 1. The first value is the strength of the spring and the second is the amount of damping to apply.

    Compare: dt > 0

    -- add -0.005*(scope.x-target.x)/dt-0.1*vx to vx

    -- add -0.005*(scope.y-target.y)/dt-0.1*vy to vy

    -- scope: set position to (scope.x+vx*dt, scope.y+vy*dt)

  • Probably you’d just need to make a feature request to do that if the export doesn’t have an option to remove the title bar.

    Webview2 doesn’t come with much of a js api like nw.js did. It also has no command line switches. One rabbit hole you could explore are “wrapper extensions” as mentioned in the sdk manual. That would let you make a plugin in c++ land which has far less limits on what is possible. Presumably you could make a plugin that uses the winapi to get the current process, then the window, and from that change a flag to hide the title bar. Could be a pretty big time sink to figure out and do though. I won’t venture it since I just use the free version and never use exports.

    Making an official feature request is probably the easiest approach.

  • Do you have a project you’re trying to open that relies on those versions?

    Even though the GitHub doesn’t have the updated 0.24 files it does have the change log from 0.23: two expressions and a fix. You could update it to a 0.24 release yourself.

    It’s simple enough to change the version to 0.24 and add the two expressions to the plugin. I’d imagine they have two number parameters for x and y. You’ll have to guess the ids of the expressions unless you have a project that uses them, in which case you can find the ids in the event sheet xml file. But if you had to guess I’d imagine they were 0 and 1 based on how the actions are numbered. That would at least let you open your project and be compatible with the real 0.24 release.

    Implementing the js side of the expressions should be simple enough.

    The fix for “block using object” would be the most involved, but not too bad. At a glance the plugin uses a 2d array to store the cost of cells and if they are blocked. When it uses an object to block it loops over all the cells that overlap the objects bounding box and sets them. So I’d assume there was a simple typo or oversight in 0.23 that needed correcting.

  • I don’t have an example. The way to load a data url is simple. For example use the “load frame from url” action of the sprite object.

    Start of layout

    — Sprite: load frame from url "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAgAAAAICAMAAADz0U65AAAAwFBMVEUcdLVRaKWfbHD5VlL9WFX/W1H1T2igEeOwUn2naGL8VFL/WlXbUU9mO0ZrQT+lPmjlp6r0cnP/VU/uT0tFPkoWNkcSLT8eMz3rdne0rLjJnqaTWF8vSVlGUV8gLTwgLz37UEv9XVnFkpqPpLNzgY83RlYlM0JHX3XDTlDqUk/2UExZVmN1hpeTpat2fpR0GOe4Sk3pVVLqVlMoLDsZLjo9RmSPPPaFAP/TUFD7WFP0VlNEOEYSMDtQLlCLAOd6AP8xRjMWAAAAH0lEQVQIW2NkYIQCDhhDAMaQgDEUYAwNGMMAxrCA0gAgEAEhAJ4eUwAAAABJRU5ErkJggg=="

    That replaces the current frame with an 8x8 version of your avatar.

    You can convert an image into a dataurl with tools online, or in construct with the drawing canvas, or with JavaScript I suppose.

  • You could load an image from a dataurl to get an image without a file. You just have to do that in events. A data url has the file encoded as a base64 text string. The main drawback is base64 is 33% larger than a normal file. It could similarly be done with audio files.

    In a more complex fashion you could load a file you previously encrypted with some js or into the binary object. Then you’d decrypt it and convert it into a dataurl to then load into the sprite or audio plugin. That would avoid the size increase but you’d add to the loading time to do the decryption and conversion.

    Probably you’d only do that for a few spoiler images. It would be laborious for doing that with a full sprite animation. Not to mention you’d lose the optimization of images being sprite sheeted together.

    Bear in mind you can’t load images into all the plugins at runtime. For example spritefont and tilemap don’t have that capability. Also loading images into tiled backgrounds load it per instance so that would be inefficient.

    Probably look at the cryptography object.

  • So, the Separating Axis Theorem (SAT) is probably the easiest algorithm to use to implement collision detection and response between rotated rectangles. Here's one possible implementation in events:

    dropbox.com/scl/fi/buz1axwu4pv9p16m2qos9/sat_test2.capx

    I don't have a js version of that.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That bit of code just resolves overlaps between a bunch of circles that are the same size. Then to make it faster all the circles are first added to a grid spatial hash.

    So roughly it creates the grid spacial hash, adds the circles to all the grids their bounding box overlaps, then loops over the circles and uses the spacial hash to get other nearby circles, and finally it detects collision and pushes them apart.

    I don’t understand the question to have a rectangle instead of a square. You can make the grid of any size but it just needs to be the same size or smaller than the circle size.

    The layout size is used to have something to divide into grids. It could be made to reuse the same grids when objects are outside the layout. Probably by using x%layoutWidth or something.

    The angle is used for the push out logic for circles. Circles are the simplest to do that for. Using object bounding boxes instead are a bit more complex. Beyond that the push out logic would require some fancier algorithm such as SAT,GJK/EPA, MPR, SDFs,…etc to do the collision detection and resolving.

    If all you want to do is detect if two objects overlap it’s easiest to just use construct's js api overlapping function.

    That example was just tailored to a specific thing. It’s not really general purpose without a fair amount of modification.

  • To predict a path basically involves repeatedly simulating frames to get the path. I think previous topics tried to simulate that, but I actually haven't tried your approach of using an impulse to simulate a frame.

    Here's the idea refined, and it seems to work great.

    The setup is to set the physics stepping mode to fixed. With that the time step is always 1/60. Then to simulate the path you'd copy an objects position and velocity and then with a loop use timestep*force for the impulse, and then manually advance the position with the velocity.

    dropbox.com/scl/fi/7o7pjwaffwty9n3u8dke0/perdict_physics_path.c3p

    You can use a larger time step but since gravity forces vary by position the resulting path will be approximate and diverge pretty quick. In the same way using framerate independent stepping mode the predicted path will vary a lot.

  • You’re welcome. I was thinking a bit more and since you can get the accuracy of some gps coordinates you can probably utilize that.

    Here’s some rough pseudocode of how the logic might look. The gps vars keep track of lat,lon,alt, and accuracy. 

    Start
— prevGps=getGps()
— TotalDist=0

Update
— curGps =getGps()
— Dist= calcDist(prevGps, curgps)
— If dist>(prevGps.acuracy+curgps.accuracy)
— — totaldist = totaldist+dist
— — prevgps = curgps

    You could probably get away with just using the current gps accuracy. But regardless be careful to use the same distance units for everything or be sure to convert them to be the same.

  • Lat longs give a point on a the earth which is approximated by a sphere. You can use spherical coordinates to convert the gps to xyz vectors from the center of the earth.

    X=radius*cos(lat)*cos(lon)

    Y=radius*cos(lat)*sin(lon)

    Z=-radius*sin(lat)

    If you then do a dot product between the two vectors you can find the angle between them. A dot B = len(A)*len(B)*cos(ang)

    And finally you can use the formula for arcLength = radius*angle to get a distance.

    That should come out to the following with two lat,Lon’s.

    dist = acos(cos(lat1)*cos(lon1)*cos(lat2)*cos(lon2) + cos(lat1)*sin(lon1)*cos(lat2)*sin(lon2) + sin(lat1)*sin(lat2))*180/pi*radius

    Where the radius of the earth is 6371 km.

    You’d probably want to add the average of the altitudes of the two points too. 6371+(alt1+alt2)/2. But I’m unsure how much that would change things.

    You probably could just measure the straight distance between two points instead. That would remove the dot product and arc length step.

    Dist = radius*sqrt((cos(lat1)*cos(lon1)-cos(lat2)*cos(lon2))^2+(cos(lat1)*sin(lon1)-cos(lat2)*sin(lon2))^2+(sin(lat1)-sin(lat2))^2)

    I factored out the radius but you could be more accurate using the altitude per point if you wanted.

    You could try to find a js library to do the calculation too. No idea if they’d be doing anything beyond what’s being done here.

    And just thinking aloud, but the gps coordinates have a varying accuracy so you might need to filter or smooth things out. For example if you’re standing still the gps coordinates may drift around by the accuracy amount so you’d get distance when you didn’t actually move. To filter you could only add distances longer than say a few feet. Or to smooth you could collect multiple lat Lon’s and average them before using it.