R0J0hound's Forum Posts

  • You can do this to rotate around any center. 

    Var a, centerX, centerY

Set position to (self.x-centerX)*cos(a)-(self.y-centerY)*sin(a)+centerX, (self.x-centerX)*sin(a)+(self.y-centerY)*cos(a)+centerY
Rotate clockwise by a degrees

  • You probably could get pretty close with the physics behavior. Make a joint between the player and apply a torque to the sword. The only downside is you’ll want to do all the motion with the physics behavior since it doesn’t work with other behaviors.

  • In general most behaviors the motion is good enough, but seldom 100% precise. I think what happens is the moveto behavior discards the overshoot.

    Anyways, here's a way to do near perfect path motion so the object's stay spaced the same. They are transparent and next to each other so if it would show desync if it happens. Additionally you can toggle that disabled action to avoid even more numeric drift.

    The gist is it moves in direction of a waypoint, and when the waypoint is passed it carries over the extra motion when it moves toward the next node.

    dropbox.com/s/5bg83cgrpv9k8tn/node_path_follow2.capx

    Edit:

    And the idea can be taken further. This one supports any speed.

    dropbox.com/s/vow1i2x2rcteee6/node_path_follow3.capx

  • There are a lot of ways to do that. I've seen the timeline used to make the paths, or the pathfinder behavior to move through waypoints. Here's a way that just moves the objects toward node sprites. Once it hits a node it moves to the next one and so on. I use the group instance variable to have multiple paths.

    dropbox.com/s/ig67mil486eh9ou/node_path_follow.capx

  • Hmm, well I'm sure it's probably similar to any other js library. But you can do it with events. One number for the significant digits and one for the exponent. Then just some functions to do math between them.

    Possible example.

    dropbox.com/s/n7vzo5y4q9mdhzz/bigNum.capx

    Something like:

    bigSet("2e1000")

    bigAdd("9e1000")

    will result in "1.1e1001"

  • Probably some edge case as you say. Behaviors can run before or after the event sheet, or both. That is done per behavior.

    If you are really curious about what the platform behavior is doing you can look at the source of it in c2 as it’s similar. Or you can find it in c3 when you preview. Open the browser debug console, sources tab and it’s one of the files.

  • I mean the gist of method 3 is it updates the position first with gravity, then the velocity. What you’re doing seems to be undoing a velocity update and it would be 100% accurate if the next frame has the same dt.

    Can’t say why that’s needed.

  • I think your first post is mainly due to how the time of collision will vary according to the framerate. With a low framerate the objects can be overlapping a fair bit when a collision is triggered. With a high framerate the collision will be triggered closer to when the object just come into contact.

    Framerate independence mainly just ensures the motion is consistent between collisions for any framerate.

    Here's a test of different ways to do the integration for projectile motion, aka jumping. It also tests what they do at some different timesteps. The first method undershoots at lower fps, the second overshoots, the third is perfect at all fps, and the last is wrong.

    I also compared it with the platform behavior, and it is using the perfect method when jumping off the ground, and actually is improved over how it was in C2.

    The difference between jumping in the air, and jumping on the ground could have something to do with the logic to handle moving platforms but that's just a guess.

    Actually looks like it's using method 3 when on the ground and method 4 when in the air.

    dropbox.com/s/a5qzfvv7y18c3hy/plat_dt_test.capx

  • The blocks are in contact with each other so they count as overlapping.

    The triple loop isn’t bad since the amount of iteration get lower rather fast.

  • You can do a flood fill on the grey blocks. Start at a random block, then flood to the connected. Repeat until you have each group of blocks marked. Then It's mostly the matter of picking that group, and using picked count for the factor.

    There may be other ways to do it too.

    dropbox.com/s/l8p8sngj1wu5etx/flood_fill_blocks.capx

  • It seems to work. It renders half as many frames per second in a consistent manner, and according to the task manager the cpu usage is cut in half more or less as well. It was made completely separate from construct though. But render loops are often similarly done, so it was meant as a possible reference if the devs should want to revisit the idea. If not, it's no worry, I'll likely use it later.

  • I do remember the jank encountered in previous attempts, but I think it might be possible to avoid that. Dt seems to vary a bit per frame. At 60fps it should be 0.0166 but I've seen it lower to around 0.0163 in my tests as an example. My idea is we can skip frames if dt is less than some target framerate, but instead of checking if dt<1/30, we let it be approximate with say dt<0.3. I coded up a complete test to check my idea and on my 60hz screen I was able to get this. Super janky with dt<1/30, but smooth with an approximate value for 1/30 like dt<0.03.

    It gives the high and low dt, the average dt of the last 128 drawn frames, and a little graph of the dt times for the drawn frames.

    And here's the relevant animation loop. The only remarkable part is the frame skip. 

    let prevTime=0;
function gameLoop(newTime)
{
	requestAnimationFrame(gameLoop);
	newTime/=1000;
	let dt = Math.min(0.05, newTime-prevTime); //20fps min to account for tabbing away
	if (dt<0.3) // skip frame if dt isn't at least approximately 1/30.
		return;
	prevTime=newTime;
	tick(dt);
	draw();
}
requestAnimationFrame(gameLoop);

    It should work the same when cpu/gpu load causes frames to be skipped. The only thing that would need testing is how it would behave with other screens with higher refresh rates. Anyways, just an idea.

    Edit:

    0.3 is fairly arbitrary as a lower value than 1/30. dt<1/maxFPS-1/480 may work better, at least should work for refresh rates up to 240.

    dt<1/30-1/480

  • The only place I’ve seen anything to limit the fps is on the construct discord the user mikal made something to do that. Haven’t used it and not sure if there’s any limitations with that plug-in.

    Officially I think the devs tried to do that before but weren’t able to get anything that worked well. Maybe they will revisit it since it seems to be requested more as of late.

    I don’t think there’s anything that can be done with scripting to limit the fps. The render loop is controlled by the construct runtime and that part isn’t exposed to the scripting api as far as I can tell.

    I can think of one roundabout way to limit the fps but it’s more of a trick and doesn’t work with most of construct. The idea is the screen will only redraw if things change, so you could only move or change things every other frame or so. But as stated above that won’t work with most behaviors or other things that normally update every frame.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Here are some ideas:

    construct.net/en/forum/construct-3/general-discussion-7/better-text-input-170179/page-2

    One is to just use a bit of JavaScript to get keyboard input. It gives a bit more than what construct offers.

    A second idea is to use a textbox with 0 opacity. It will act just like a normal edit box but you draw manually.