R0J0hound's Forum Posts

  • Give it a try. Engines help you out in a lot of ways, and each engine is a bit different. Construct has a lot of useful features and the editor saves a lot of time. Knowing JavaScript is really a small portion of it. Construct has a certain JavaScript api to interact with the engine, and if you used another library it would have a different one. Or you could even make your own engine directly working with the web apis, but having it work the same across different browsers becomes something to handle.

    Anyways, it’s always a good exercise to try. You’ll learn a lot even if it doesn’t work out. You’ll learn how to to use different libraries, how to do some things that construct handled for you and give an appreciation of some complex things that construct does that aren’t simple to do on your own. But overall it’s all good. I don’t think it’s likely to be faster, especially at first. Overall you’re trading issues you have to deal with in construct with different ones. Although many may be the same.

  • Using mesh distort you can make a collision shape that approximates any image.

    construct.net/en/forum/construct-3/how-do-i-8/manipulate-mesh-points-175978

    It was a preliminary example. It uses the first shape found.

  • I'm probably missing the mark about what you're after again. But this has an object move with a force applied to an object (I went with a gravity based force). The predicted path is found by just doing multiple steps.

    This just does the physics manually so we don't have to simulate what the physics behavior does and deal with the value differences. It uses a fixed timestep to avoid the inconsistencies of a variable timestep since the acceleration is continuously changing.

    dropbox.com/scl/fi/3zw8r9yo86oh0xpef5akl/perdict_path.capx

    Maybe it could be useful for some ideas.

  • You could try something like this. Speed would be updated per second. You’d just tune the 100 to a speed you’d like. The lerp is to make the change more gradual. 

    Global number presses=0
Global number speed=0
On key pressed
— add 1 to presses

Every 1 second
— set speed to lerp(speed, 100*presses, 0.5)
— set presses to 0

    Another idea that’s more continuous could be to have an array of say width 60 and 

    Global number presses=0
Global number speed=0

Start of layout
— array: set size to 60,1,1

Every tick
— array: set at ticks%60 to 0
— set presses to 0

Key is down
Trigger once
— array: set at ticks%60 to 1

Repeat 60 times
— add array.at(loopindex) to presses

Every tick
— set speed to 100*presses

  • When you use a density of 0 it probably just sets it to 1. Otherwise there would be divides by 0.

    Anyways look at the 2nd capx to see the conversion factors between what the behavior uses and calculating it manually.

    You asked about velocity? It’s the same either way. Pixels per second.

    Box2d uses meters for the distance unit internally not pixels so it’s typically scaled. So likely they picked 50 pixels = 1 meter in the behavior. The behavior tries to convert the values to be in pixel units but misses the mark with the conversion for anything but velocity. A fix would be simple but would break all existing projects with physics.

    Anyways units aside I’ll mess with it later.

  • It’s 30*30*1/50 = 18. Notice the /50 is needed. That’s what I mean by the units of the physics behavior being off. That second capx figures out the conversions between units in the behavior and what it should be. 50 comes up a lot. I think it was mainly due to an oversight when the behavior was made. Position and speed are spot on but most other values are off by some factor. This really only becomes an issue when trying to apply physics based calculations.

  • Ah gotcha. I get what you’re after now I think. The examples at this point are predicting the path as of the acceleration remains constant. But with what you’re after the force will vary based on the objects position.

    Glancing at your file the force you apply with physics is different that the force variables. But that’s as far as I got.

    If the fps is 60 and the physics is set to fixed timestep (which is 60 i think no matter what) then it’s just the process of simulating a frame at a time to get the path. Unfortunately the predicted path will vary if the the frame times vary. It’s trickier to make it frame rate independent since the force varies by position.

    Anyways, just some thoughts. I’ll be away for the computer for a while so there won’t be any soon solutions from me.

    I use the free version of c3 sparingly. I typically am not connected to the internet so I prefer c2. Someone gifted me c3, hence the icon I guess. It was nice of them, but I really don’t use use c3 to need it. I’m not even logged in. The free version is fine for my purposes.

  • I think I read what you wanted wrong. It sounds like its mostly a matter of calculating the force so that the object lands on the target after a duration.

    dropbox.com/scl/fi/bikvo6eg66yyzf4p18o2v/physics_force_calc_and-trajectory_plot.capx

    I skipped the physics behavior entirely so I wouldn't have to deal with the units.

  • I haven’t messed with it. It’s not an editor. It’s a way to package changes to css you make into an Addon. And maybe give some starting points on where to start editing the css.

    To do the actual editing you’d use your browser. Open up the dev console and then you can fiddle around with the css. I guess that’s not really coding. In chrome at least you can click on any element and it will jump to that portion in the css where you can change the color and such. That theme sdk probably makes it easier by letting you change some color variables that is used all over. Anyways that’s my impression at least from skimming that page.

    You could also try some dark mode browser addons. It may work. No idea. I’m not that into it. The most I’ve messed with css is to get rid of the pink text on the forums. Otherwise I stay away from it.

    Doesn’t construct come with a dark theme though?

  • construct.net/en/make-games/manuals/addon-sdk/guide/themes

    Sounds like you can fiddle about with the css to do whatever you like. Or maybe you can find an existing theme on the store.

  • There isn’t a super big demand for it but I’m sure it would be nice if they had a setting for the default size.

    For prototypes I generally resize to 32x32. Or if I’m quickly drawing stuff the default is fine since I usually crop at the end.

    In c2 you could replace the default image which I did once or twice.

  • If math can be equated to cooking, it’s easier to list good recipes than list recipes that contain a certain ingredient. Maybe you’re more after some useful math formulas that aren’t covered with the expressions provided in construct.

    Here’s a partial list of the ones I find useful on a regular basis. They aren’t covered by expressions normally. Admittedly a fair amount have to do with physics and a few geometry problems. But they can be useful. 

     // speed and angleOfmotion from vx,vy
speed = distance(0,0,vx,vy)
angleofmotion = angle(0,0,vx,vy)

// vx,vy from speed and angle of motion a. 
vx = speed*cos(a)
vy = speed*sin(a)

// it is also possible to represent directions as a unit vector (an xy vector with a length of 1) instead of with angles. so with a general velocity of vx,vy you can get the speed and direction vector with:
speed = distance(0,0,vx,vy)
dirX = vx/speed
dirY = vy/speed
// doing that gives the advantage of eliminating sin and cos from the formulas if you so desire.

// bounce angle a along normal n
a = 2*(n+90)-a

// velocity along a direction a
vx*cos(a)+vy*sin(a)

// stop velocity along an angle a. 
vrel = vx*cos(a)+vy*sin(a)
vx = vx - vrel*cos(a)
vy = vy - vrel*sin(a)
// multiply vrel by 2 to to make it bounce instead. 1.5 would be a half bounce...etc

// velocity of a point px,py on a spinning object with position x,y velocity vx,vy and angular speed w. 
velocityX = vx - (py-y)*w*pi/180
velocityY = vy + (px-x)*w*pi/180

//distance from line to point. with start sx,sy and angle a and point px,py
abs((px-sx)*cos(a-90)+(py-sy)*sin(a-90))
// remove the abs and the sign will give what side of the line youre on. 

// closest point on line segment. from point px,py to line segment x0,y0 x1,y1
t = clamp(((px-x0)*(x1-x0)+(py-y0)*(y1-y0))/((x1-x0)^2+(y1-y0)^2), 0, 1)
position = lerp(x0,x1,t), lerp(y0,y1,t)
// remove the clamp to treat the segment as an infinite line. 

// normalize an angle to the -180 to 180 range. 
angle(0,0,cos(a),sin(a))

// convert any angle to the 0 to 360 range
(a%360+360)%360

// signed angle differece between a and b. number of degrees between angles, but the sign gives the direction. negative for counter clockwise. More useful than constructs angleDiff expression. 
angle(0,0,cos(a-b),sin(a-b))

// rotate object a degrees around center cx,cy
set position to (x-cx)*cos(a)-(y-cy)*sin(a)+cx, (x-cx)*sin(a)+(y-cy)*cos(a)+cy
rotate a degrees clockwise

  • I think there is a split screen example/tutorial floating about that could be helpful.

    What you can do is use a canvas and paste stuff onto it. For performance the pasting is delayed till the frame draws, which leads to having to do juggling where you have to moving things into place, paste, and then wait a frame. At least last time I tried using it. Could have been updated since then.

    Another probably simpler idea is to just have the tv be its own layer and you’d just need to change the scale/scroll offset to move the rest of the game to fit onto the tv. You could do that with some trial and error I should think.

  • This old one still works, although it could be cleaned up more.

    construct.net/en/forum/construct-2/how-do-i-18/parabolatracjectory-tracing-55313

    Here's a cleaned up version. The y acceleration is the gravity*50. Why? because the units with the physics behavior are wonky aka scaled. It will still be off slightly from the physics behavior's path and I figure the only way to make match perfectly would be to use js to load box2d, set it up identical to how the physics behavior uses box2d, run n amount of simulation steps.

    dropbox.com/scl/fi/htkostz6pa29v65ytxzh6/perdicted_path.capx

    Here's a test to figure out the differences of the physics behavior units.

    dropbox.com/scl/fi/f8pecd2r8hrltfh2z3zhn/physics_units_compare.capx

    Finally if you want to set the acceleration from a force you'd do it like this:

    mass = density*area /50

    acceleration = force*50*50/mass

    The density is the mass property in the editor.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There isn’t really any specific 2d game related uses of those math functions. It’s easy to shotgun possible uses but it won’t cover all cases.

    For leveling up you could go with whatever strikes your fancy. The player won’t care if you use exp(), some simple multiplication level to level or some other curve.

    Generally there are more than one way to do things.

    Most of the functions such as exp(), ln(), and log10() aren’t needed unless you are using some formulas you found online.

    Unlerp() isn’t really used much. Last place I’ve seen it used was with a scroll bar but in general I’ve mostly just used the math behind it.

    Anyways. Most math functions and operators have too many possible uses to list. I usually go the other way, decide what I want to do and figure out how math can be utilized to do that.