LÖVE

Posted: **Tue Nov 23, 2021 8:26 pm**

[btw not sure if this is the right category, pls tell me if i should put this somewhere else thx]

so i am making a game with a procedurally generated random path. my code so far is:

Code: Select all

pathoffset[1] = (pathoffset[1] + (dt * (love.math.randomNormal() + 1/4) / 3)) % 2
    pathoffset[2] = (pathoffset[2] + (dt * pathoffset.multiplier/2)) % 2
    local newpathval = math.sin(pathoffset[1] * math.pi * pathoffset.multiplier)*pathoffset.multiplier + math.sin(pathoffset[2] * math.pi)
    newpathval = 175 + lume.round(newpathval * player.width)
    local temppath = lume.concat({newpathval}, path)
    path = lume.slice(temppath, 1, 350)

(for function reference: lume.round() is just regular rounding, lume.concat() joins multiple arrays together and lume.slice() work exactly the same as string.sub(), except with arrays)

while this does work well, there are 2 thigs i dont like:
1. at the start there is just a random big "spike" in the path (everytime, no idea why)
2. the path is somewhat "shaky" in some parts, would like to make it "smoother"

does anyone know how to help pls thanc very much

EDIT:
in the attachments is a picture from the actual game that pretty much shows both of the problems

EDIT2:
ive realized ive explained how it works a bir too vaguely, so here it is:
the 2 pathoffset variables are for 2 separate sinus functions controlling the curve
the path variable is a list of all the points in the path (basically the key is the y-coordinate and the value itself is the x-coordinate)
so i update the curve, create a new point, then add it to the beginning and delete the last point to essentially move the path forward
hope this helps any *awesome* person who tries to help me!

Posted: **Tue Nov 23, 2021 9:18 pm**

Can you show that code in a minimal program that demonstrates the problem? I've written this wrapper to check the code:

Code: Select all

local lume = {
  round = function(n) return n+(2^52+2^51)-(2^52+2^51) end,
  concat = function(x, y) table.insert(y, 1, x[1]) return y end,
  slice = function(t, a, b) for i = b + 1, #t do t[i] = nil end return t end
}
local pathoffset = {5, 5, multiplier=1}
local player = { width = 5 }
local path = {}

local dt = 1/60
for i = 1, 200 do
    <insert your code here>

    print(string.rep(" ",path[1]-135) .. "#")
end

And the output was fairly normal:

Code: Select all

Posted: **Tue Nov 23, 2021 10:28 pm**

pgimeno wrote: ↑Tue Nov 23, 2021 9:18 pm
Code: Select all
return n+(2^52+2^51)-(2^52+2^51) end

I still don't really understand how that even work
Have some spare to explain that?

Posted: **Tue Nov 23, 2021 11:23 pm**

Maybe helpful: 5.5 Wander Steering Behavior - The Nature of Code

https://natureofcode.com/book/chapter-6 ... 20Velocity

https://youtu.be/ujsR2vcJlLk

Posted: **Wed Nov 24, 2021 12:35 pm**

GVovkiv wrote: ↑Tue Nov 23, 2021 10:28 pm
pgimeno wrote: ↑Tue Nov 23, 2021 9:18 pm
Code: Select all
return n+(2^52+2^51)-(2^52+2^51) end
I still don't really understand how that even work
Have some spare to explain that?

It works only for numbers < 2^51. All functions in the lume table I wrote were pretty much custom made for the snippet in question, for simplicity. Obviously the snippet didn't need bigger numbers, just as it didn't need concatenating arrays with more than 1 element in the first argument etc.

Numbers in the range 2^52..2^53 have no decimals but preserve all integer bits. If you try `print(2^52+0.5 == 2^52)` you'll get true. When adding 2^52 to a positive number less than 2^52, the FPU needs to apply rounding, and it rounds using the OS's default rounding mode, which for every modern computer is round to nearest, ties to even.

There are 2^52 numbers in that range. Half that is 2^51, so adding 2^51 places them near the middle of the range; that makes it also work for negative numbers as long as they don't go out of it.

Posted: **Wed Nov 24, 2021 6:31 pm**

pgimeno wrote: ↑Tue Nov 23, 2021 9:18 pm It works only for numbers < 2^51. All functions in the lume table I wrote were pretty much custom made for the snippet in question, for simplicity. Obviously the snippet didn't need bigger numbers, just as it didn't need concatenating arrays with more than 1 element in the first argument etc.

Numbers in the range 2^52..2^53 have no decimals but preserve all integer bits. If you try `print(2^52+0.5 == 2^52)` you'll get true. When adding 2^52 to a positive number less than 2^52, the FPU needs to apply rounding, and it rounds using the OS's default rounding mode, which for every modern computer is round to nearest, ties to even.

There are 2^52 numbers in that range. Half that is 2^51, so adding 2^51 places them near the middle of the range; that makes it also work for negative numbers as long as they don't go out of it.

Huh, so that how that works
Thanks

LÖVE

making randomized path less "shaky"

making randomized path less "shaky"

Re: making randomized path less "shaky"

Re: making randomized path less "shaky"

Re: making randomized path less "shaky"

Re: making randomized path less "shaky"

Re: making randomized path less "shaky"