Refeuh's Forum Posts

  • You do not have permission to view this post

  • — great art work, btw, I checked the links in your signature, very nice !

    Unrolling the x & y you end up with :

    dir.x = Player.ImagePoint.X - Gun.Pos.X

    dir.y = Player.ImagePoint.Y - Gun.Pos.Y

    dirLength = sqrt(dir.x^2 + dir.y^2)

    v.x = dir.x / dirLength

    v.y = dir.y / dirLength

    Gun.pos.x = Gun.pos.x + Gun.speed*dt*v.x

    Gun.pos.y = Gun.pos.y + Gun.speed*dt*v.y

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • — Correct, I just wrote Object.pos , but you'll need to apply this to both dimensions, x and y. That would remain true in 3d where you'd only need to add z component to your vectors as well.

    But make sure you don't dissociate x and y components, you *need* a (x, y) vector when normalising what I called vector "v". If you move separately on each axis independently, you will move along a non-normalised vector, the speed non-uniform and the simulation breaks horribly.

    Check the C2 maths expressions, there might be some helpers to save time with vectors, with norms, length, etc. Maybe.

    Let me know if you get stuck, I'll try to put a quick capx example together !

    Alternatively if that makes things even simpler for you : use a bullet behaviour on the Gun ; if the Gun is far from the destination (using an arbitrary small threshold value), enable the Bullet behaviour and every tick set it's direction toward the Player.ImagePoint. When close enough, disable. Done !

  • —

    Thanks for the details ! It is an interesting case indeed. Having re-read the whole thing, I understand much better know. I initially missed the fact that we're lerping from the current pos for a chase-behaviour.

    And no need to apologise ! I hope I didn't make you feel you had to, because I didn't mean to be hard or aggressive or anything. My apologies, instead

    If you don't like the lerps, why not breakdown the computations and do something you understand and you're comfortable with ; something you can re-use and tweak in future projects, and not rely on black-voodoo-magic. Is it important that your gun catches up exactly in x frames ? If not, maybe something like :

    Every tick, if the Gun.pos is far from Player.ImagePoint

    compute direction dir towards the destination : dir = Player.ImagePoint - Gun.pos

    compute normalised vector v towards the destination : v = dir/dir.length (so that this vector has a length of 1)

    move Gun along v depending on its speed and dt : Gun.pos = Gun.pos + Gun.speed*dt*v

    for good effect, add a clamp() to make sure you don't overshoot if the gun is already close to the mount point

    It's a bit less fancy, but if that makes more sense to you, maybe it'll be easier to get it to work the way you want. This ensure uniform speed, but doesn't guarantee the time for the Gun to catch up with the destination.

    (for people interested in this kind of problems and modelisation, a spline arc-length reparametrisation would be a good fit. Out of the context of C2 built-in behaviours, but maybe a useful plugin )

  • OK, 'read the article, I got the example and maths, but ... something bothers me ; the question is :

    Why would we ever want to interpolate from the starting value ? (accumulating the progress made as the new starting position). I fail to see a case where that's useful

    I see mainly 3 scenarios :

    1. Pinning an object to an other - no interpolation involved, just static offset in the local object's frame

    2. Moving between two known positions ; pos = lerp(pos1, pos2, s) , with s updated every tick based on speed (and therefore going 0 -> 1 over the course of the movement). The known positions can be static or represent other objects

    3. Moving from the current position towards another position, e.g. chase or catch-up behaviour. lerp(pos0, pos1, whatever) will always give a (pos1 - pos0)-aligned vector. Just use that with : pos += (pos2 - pos)/|pos2 - pos|*speed*dt (= normalised unit-length aligned vector*speed*dt), or just let velocity_dir = (pos2 - pos) and let the discrete integration update the position

    I don't see what we're trying to solve by lerp from the current pos every tick newt can you please explain what you're doing with weapon, for example, so that I can understand the desired behaviour ; I'm clearly misunderstanding the use case here

  • Thanks for the link, I'll check that article !

  • — If setting an object like a weapon to an image point of another sprite, why lerp-ing at all ?

    And unless I'm missing something, lerp(x1, x2, s) with s = 26*dt doesn't make any sense ? "s" being the interpolation value, at s=0 we are at x1, at s=1 we are at x2. At a framerate of 30fps, 26*dt = ~0.87. That's a fixed position, fluctuating a bit back and forth around that position due to dt varying between frames

    With this :

    Set Positions to X | lerp(self.X,player.ImagePointX(1),1-0.00000000026^dt)

    you end with (very small magical number)^(1/fps) ; at 30fps, that's the 30th square root of a magical number, which is another magical number

    I haven't followed the full example, so I might be getting this wrong, but I fail to see the math logic between these formulas

  • Elliott G-Sync monitors are a novelty, and it's pushed forward by NVidia (with competitors having alternatives in the starting blocks already) ; it makes sense that they are the one promoting their new tech as differenciation factor, and it's good marketing and com to associate this with their most powerful GPU products, i.e. "our stuff is what you need for the best gaming experience". They also provide gaming rigs for shows, conferences, demos, etc. to showcase their hardware and innovations.

    But for the end-user, there is virtually no difference ; g-sync monitors are not more expensive to manufacture, and lots of devices can be made compatible with just a firmware update if they already have the right controllers on-board. It's novelty, but it's definitely not exclusive to people with powerful desktop rigs and high gaming budgets. As Aphrodite said, all that it means is that we're moving more and more away from the idea of a fixed refresh rate, and learning "now" to design applications with this in mind is the only way to be ready when it will be the standard. Just like with multi-threading a decade ago when multi-core and virtualised CPUs started to become common consumer products.

    newt I'm not sure what the formula refers to, but x^dt would seem fishy in any kind of discrete integration approach. But why work in pixels per second ? This couples your logic tightly to a specific type of devices ; say you run your application on a normal device, and then on a Retina display - how does it remain consistent ? I would argue that we should always work in arbitrary units (whatever fits the projects, "1 tile = 1 meter" or something like that), except for specific situations e.g. aligning a HUD to safe zones, to abstract the world representation from it's rendering.

  • Aphrodite The change should be almost transparent for higher-level apps like browsers ; this should be handled almost entirely at the driver level, though there will be some impact on the schedulers of multi-threading game kernels to maximise the efficiency of the frame structure (esp. pre/post-render stages and boundaries for animation/physics/rendering consistency)

    I wouldn't worry too much honestly, I have seen games in development working on g-sync monitors with very little extra work.

    Also this fits nicely with the philosophy of the new upcoming rendering APIs (MS/NVidia DX12, AMD Mantle, Apple Metal) which give more control of the rendering and GPU resources to the software.

  • As for adoption trend, this might come sooner than expected : various monitors can already be compatible with just a firmware update, and new monitors are already available with this new design in mind. But I don't think it will be a "must have" until consoles and consumer TVs make it an actual standard ; which unfortunately means yet more configurations for developers to support : consumer TVs, v-sync monitors, and g-sync monitors, all of these are bound to overlap at some point.

    Developing proper update rate-independent logic is the only way for developers to cope with all this in a sensible way. It's not more difficult, but it's got to be done right, and as this thread (and many others) proves, it requires to educate users to good practices.

    Also, I see here and there various arguments stating things along the line of "but consoles cap their games at 30fps, why can't we make the same to make things easy and neat ?!" . First, capping at x fps doesn't ensure the game will run at a stable update rate ; many new consoles games have areas where things drop below 30 and the game still needs to work without time dilation. Second, having a main game loop with a capped frequency doesn't mean we don't need other systems running at different update rates in parallel internally (e.g. physics!). And third, on consoles we *know* the hardware in the machine, therefore it is possible to make low-level specific optimisation choices that are completely invalidated by distributing an application on mobile or PC/Mac where the hardware differs wildly from one use to the next.

    Developers needs to learn and understand discrete integration, there's no easy way around it.

  • Aphrodite Correct ! Relying on a stable display framerate will not be possible any more. At the moment with v-sync the monitor has a fixed stable refresh rate and the gpu waits for the monitor to be in the correct state (i.e. between drawing two frames) to cycle the swap-chain and present the new pictures. With g-sync it's exactly the opposite ; a new image is still displayed between two updates to prevent tearing, but this time the monitor is the one waiting for the GPU. This is a bit simplified, but that's roughly the idea.

    This means a g-sync monitor can display an animated image without tearing at any rate up to its maximum refresh rate (which is likely to remain 60 or 120). Therefore with g-sync the dt between two frames will change and is not guaranteed to be a multiple of 30/60, and applications and games will be expected to cope with update times anywhere between ~60ms and 16ms.

  • Just to add to the discussion regarding monitors and 60/120Hz, I am reminding people that very soon, with G-Sync monitors and similar technologies, we won't have 60/120Hz refresh rates enforced by the display hardware any more ; we'll have monitors that have refresh rates *up to* 60/120Hz, but that will wait for the GPUs to shows frames at lower rates without tearing (16ms here, 19ms there, maybe 22ms here, 17ms there, etc.)

    Relying on specific magic values or capped dt is always a bad idea (just like it already was 20 years ago with PAL/NTSC/SECAM and the 50/60Hz difference), and very soon new hardware will completely invalidate these approaches. Given the adoption trend, people have a bit of time to make sure they understand all there is to understand about update frequencies, image frame rates, discrete integrations, and so on.

  • Also consider expanding the hitboxes of "fast" objects (relative to their size) ; you might not get accurate collisions, but you'll get collisions. It's good enough for hitchecks / damage, etc. but not necessary rebounds, localised damage (hard to detect front/back, etc.)

  • Hi !

    Have a look at this thread, it might be of some help :

    The problem you're facing is called tunneling, and it's a "non-issue" (as in, it can be a problem, but it works as designed, and it's not solved by forcing objects to update their data more often)

    It's a reoccuring topic, but you might have specific questions !

  • I'll try that as well, in case that helps in my case too !