R0J0hound's Recent Forum Activity

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 155 followers

Connect with R0J0hound

buymeacoffee.com

Trophy Case

  • 15-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

28/44
How to earn trophies