• Create Account

### #ActualN01

Posted 06 September 2013 - 12:26 AM

I guess the ultimate point of these snippets is to keep the physics timestep fixed while graphics run at higher fps interpolating frame results. There are obviously
better solutions than this piece of code and those will be more relevant at later development stages... Since your graphics run at constant 30fps, you could perhaps replace that code with just simulate(1.0f/30.0f) and fetchResults(true) and keep looking until you find the actual problem. fetchResults can be called right after simulate as long as that first parameter remains true. I suppose it's also possible to "hack" some speed by making that dt > 1/30 (or even better call twice those functions), did you try the direct approach?

well, actually, my graphics run at 60 FPS in a separate thread, and logics\physics are at 30 FPS. yes, i've tried simplifying time-step function to just "simulate(1.0f/30.0f) and fetchResults(true)", it didn't make any difference. as i already said, making dt bigger, doesn't really matter. i also tried calling functions multiple times. yes, it does speed things up. in order to get something resembling normal speed, i need to call them 3-4 times.  it works, but it doesn't seem like a proper solution. and it's probably expensive as hell.

dt always means delta-time, which is the time spent last frame

so, each time you accumulated more than mStepSize time, you integrate (or simulate if you will)

it's hard to say why your scene is slow, since if you provided real time to the function, it would just integrate each and every time forever

you are missing a while loop though

while (mAccumulator >= mStepSize)
{
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);

}

throw that boolean return value to the fishes

anyways, the fix might just be to reduce mStepSize and all will be well

yep, i knew what dt means, that's why in my code(post #6) it's deltaTime. but i have no idea, how it is calculated properly, to fit timestep.

i've added a while cycle, removing "if" statement. so it looks like that:

void update() {
float deltaTime = (clock() - mLastTime) * mStepSize;
mAccumulator  += deltaTime;
mLastTime = clock();

while(mAccumulator > mStepSize) {
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);
mScene->fetchResults(true);
}
}

i moved mLastTime = clock(); before simulation, and now it's super fast(5x speed. speed is normal, if i multiply deltaTime by 0.2f). i can just multiply deltaTime, but i'd like to figure out the reason.

and if i use fetchResults(false), speed is normal.  but calling it with a false argument seems a bit undetermined.

*changed last bit of post a lot.

### #7N01

Posted 06 September 2013 - 12:22 AM

I guess the ultimate point of these snippets is to keep the physics timestep fixed while graphics run at higher fps interpolating frame results. There are obviously
better solutions than this piece of code and those will be more relevant at later development stages... Since your graphics run at constant 30fps, you could perhaps replace that code with just simulate(1.0f/30.0f) and fetchResults(true) and keep looking until you find the actual problem. fetchResults can be called right after simulate as long as that first parameter remains true. I suppose it's also possible to "hack" some speed by making that dt > 1/30 (or even better call twice those functions), did you try the direct approach?

well, actually, my graphics run at 60 FPS in a separate thread, and logics\physics are at 30 FPS. yes, i've tried simplifying time-step function to just "simulate(1.0f/30.0f) and fetchResults(true)", it didn't make any difference. as i already said, making dt bigger, doesn't really matter. i also tried calling functions multiple times. yes, it does speed things up. in order to get something resembling normal speed, i need to call them 3-4 times.  it works, but it doesn't seem like a proper solution. and it's probably expensive as hell.

dt always means delta-time, which is the time spent last frame

so, each time you accumulated more than mStepSize time, you integrate (or simulate if you will)

it's hard to say why your scene is slow, since if you provided real time to the function, it would just integrate each and every time forever

you are missing a while loop though

while (mAccumulator >= mStepSize)
{
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);

}

throw that boolean return value to the fishes

anyways, the fix might just be to reduce mStepSize and all will be well

yep, i knew what dt means, that's why in my code(post #6) it's deltaTime. but i have no idea, how it is calculated properly, to fit timestep.

i've added a while cycle, removing "if" statement. so it looks like that:

void update() {
float deltaTime = (clock() - mLastTime) * mStepSize;
mAccumulator  += deltaTime;
mLastTime = clock();

while(mAccumulator > mStepSize) {
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);
mScene->fetchResults(true);
}
}

i moved mLastTime = clock(); before simulation, and now it's super fast.

and if i use fetchResults(false), speed is normal.  but calling it with a false argument seems a bit undetermined.

*changed last bit of post a lot.

### #6N01

Posted 06 September 2013 - 12:22 AM

I guess the ultimate point of these snippets is to keep the physics timestep fixed while graphics run at higher fps interpolating frame results. There are obviously
better solutions than this piece of code and those will be more relevant at later development stages... Since your graphics run at constant 30fps, you could perhaps replace that code with just simulate(1.0f/30.0f) and fetchResults(true) and keep looking until you find the actual problem. fetchResults can be called right after simulate as long as that first parameter remains true. I suppose it's also possible to "hack" some speed by making that dt > 1/30 (or even better call twice those functions), did you try the direct approach?

well, actually, my graphics run at 60 FPS in a separate thread, and logics\physics are at 30 FPS. yes, i've tried simplifying time-step function to just "simulate(1.0f/30.0f) and fetchResults(true)", it didn't make any difference. as i already said, making dt bigger, doesn't really matter. i also tried calling functions multiple times. yes, it does speed things up. in order to get something resembling normal speed, i need to call them 3-4 times.  it works, but it doesn't seem like a proper solution. and it's probably expensive as hell.

dt always means delta-time, which is the time spent last frame

so, each time you accumulated more than mStepSize time, you integrate (or simulate if you will)

it's hard to say why your scene is slow, since if you provided real time to the function, it would just integrate each and every time forever

you are missing a while loop though

while (mAccumulator >= mStepSize)
{
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);

}

throw that boolean return value to the fishes

anyways, the fix might just be to reduce mStepSize and all will be well

yep, i knew what dt means, that's why in my code(post #6) it's deltaTime. but i have no idea, how it is calculated properly, to fit timestep.

i've added a while cycle, removing "if" statement. so it looks like that:

void update() {
float deltaTime = (clock() - mLastTime) * mStepSize;
mAccumulator  += deltaTime;
mLastTime = clock();

while(mAccumulator > mStepSize) {
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);
mScene->fetchResults(true);
}
}

i moved mLastTime = clock(); before simulation, and now it's super fast.

and if i use fetchResults(false), speed is normal.  but calling it with a false argument seems a bit undetermined.

### #5N01

Posted 06 September 2013 - 12:21 AM

I guess the ultimate point of these snippets is to keep the physics timestep fixed while graphics run at higher fps interpolating frame results. There are obviously
better solutions than this piece of code and those will be more relevant at later development stages... Since your graphics run at constant 30fps, you could perhaps replace that code with just simulate(1.0f/30.0f) and fetchResults(true) and keep looking until you find the actual problem. fetchResults can be called right after simulate as long as that first parameter remains true. I suppose it's also possible to "hack" some speed by making that dt > 1/30 (or even better call twice those functions), did you try the direct approach?

well, actually, my graphics run at 60 FPS in a separate thread, and logics\physics are at 30 FPS. yes, i've tried simplifying time-step function to just "simulate(1.0f/30.0f) and fetchResults(true)", it didn't make any difference. as i already said, making dt bigger, doesn't really matter. i also tried calling functions multiple times. yes, it does speed things up. in order to get something resembling normal speed, i need to call them 3-4 times.  it works, but it doesn't seem like a proper solution. and it's probably expensive as hell.

dt always means delta-time, which is the time spent last frame

so, each time you accumulated more than mStepSize time, you integrate (or simulate if you will)

it's hard to say why your scene is slow, since if you provided real time to the function, it would just integrate each and every time forever

you are missing a while loop though

while (mAccumulator >= mStepSize)
{
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);

}

throw that boolean return value to the fishes

anyways, the fix might just be to reduce mStepSize and all will be well

yep, i knew what dt means, that's why in my code(post #6) it's deltaTime. but i have no idea, how it is calculated properly, to fit timestep.

i've added a while cycle, removing "if" statement. so it looks like that:

void update() {
float deltaTime = (clock() - mLastTime) * mStepSize;
mAccumulator  += deltaTime;
mLastTime = clock();

while(mAccumulator > mStepSize) {
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);
mScene->fetchResults(true);
}
}

i moved mLastTime = clock(); before simulation, and now it's super fast.

and if i use fetchResults(false), speed is normal with just (clock() - mLastTime) * mStepSize. but calling it with a false argument seems a bit undetermined.

### #4N01

Posted 06 September 2013 - 12:19 AM

I guess the ultimate point of these snippets is to keep the physics timestep fixed while graphics run at higher fps interpolating frame results. There are obviously
better solutions than this piece of code and those will be more relevant at later development stages... Since your graphics run at constant 30fps, you could perhaps replace that code with just simulate(1.0f/30.0f) and fetchResults(true) and keep looking until you find the actual problem. fetchResults can be called right after simulate as long as that first parameter remains true. I suppose it's also possible to "hack" some speed by making that dt > 1/30 (or even better call twice those functions), did you try the direct approach?

well, actually, my graphics run at 60 FPS in a separate thread, and logics\physics are at 30 FPS. yes, i've tried simplifying time-step function to just "simulate(1.0f/30.0f) and fetchResults(true)", it didn't make any difference. as i already said, making dt bigger, doesn't really matter. i also tried calling functions multiple times. yes, it does speed things up. in order to get something resembling normal speed, i need to call them 3-4 times.  it works, but it doesn't seem like a proper solution. and it's probably expensive as hell.

dt always means delta-time, which is the time spent last frame

so, each time you accumulated more than mStepSize time, you integrate (or simulate if you will)

it's hard to say why your scene is slow, since if you provided real time to the function, it would just integrate each and every time forever

you are missing a while loop though

while (mAccumulator >= mStepSize)
{
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);

}

throw that boolean return value to the fishes

anyways, the fix might just be to reduce mStepSize and all will be well

yep, i knew what dt means, that's why in my code(post #6) it's deltaTime. but i have no idea, how it is calculated properly, to fit timestep.

i've added a while cycle, removing "if" statement. so it looks like that:

void update() {
float deltaTime = (clock() - mLastTime)/5.5f * mStepSize;
mAccumulator  += deltaTime;
mLastTime = clock();

while(mAccumulator > mStepSize) {
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);
mScene->fetchResults(true);
}
}

it works acceptable. now deltaTime actually does something. but you might wonder, what is "(clock() - mLastTime)/5.5f * mStepSize", what is "5.5f"? just a magic number. i don't know, why it works. at 30 FPS, (clock() - mLastTime) = 33.3ms, and mStepSize = 0.0333f, so average deltaTime with my code, should be 0.2f. what does this value mean to me? nothing, it's 1/5 of something rather.

and if i use fetchResults(false), speed is normal with just (clock() - mLastTime) * mStepSize. but calling it with a false argument seems a bit undetermined.

### #3N01

Posted 06 September 2013 - 12:16 AM

I guess the ultimate point of these snippets is to keep the physics timestep fixed while graphics run at higher fps interpolating frame results. There are obviously
better solutions than this piece of code and those will be more relevant at later development stages... Since your graphics run at constant 30fps, you could perhaps replace that code with just simulate(1.0f/30.0f) and fetchResults(true) and keep looking until you find the actual problem. fetchResults can be called right after simulate as long as that first parameter remains true. I suppose it's also possible to "hack" some speed by making that dt > 1/30 (or even better call twice those functions), did you try the direct approach?

well, actually, my graphics run at 60 FPS in a separate thread, and logics\physics are at 30 FPS. yes, i've tried simplifying time-step function to just "simulate(1.0f/30.0f) and fetchResults(true)", it didn't make any difference. as i already said, making dt bigger, doesn't really matter. i also tried calling functions multiple times. yes, it does speed things up. in order to get something resembling normal speed, i need to call them 3-4 times.  it works, but it doesn't seem like a proper solution. and it's probably expensive as hell.

dt always means delta-time, which is the time spent last frame

so, each time you accumulated more than mStepSize time, you integrate (or simulate if you will)

it's hard to say why your scene is slow, since if you provided real time to the function, it would just integrate each and every time forever

you are missing a while loop though

while (mAccumulator >= mStepSize)
{
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);

}

throw that boolean return value to the fishes

anyways, the fix might just be to reduce mStepSize and all will be well

yep, i knew what dt means, that's why in my code(post #6) it's deltaTime. but i have no idea, how it is calculated properly, to fit timestep.

i've added a while cycle, removing "if" statement. so it looks like that:

void update() {
float deltaTime = (clock() - mLastTime)/5.5f * mStepSize;
mAccumulator  += deltaTime;

while(mAccumulator > mStepSize) {
mAccumulator -= mStepSize;
mScene->simulate(mStepSize);
mScene->fetchResults(true);
}
mLastTime = clock();
}

it works acceptable. now deltaTime actually does something. but you might wonder, what is "(clock() - mLastTime)/5.5f * mStepSize", what is "5.5f"? just a magic number. i don't know, why it works. at 30 FPS, (clock() - mLastTime) = 33.3ms, and mStepSize = 0.0333f, so average deltaTime with my code, should be 0.2f. what does this value mean to me? nothing, it's 1/5 of something rather.

and if i use fetchResults(false), speed is normal with just (clock() - mLastTime) * mStepSize. but calling it with a false argument seems a bit undetermined.

PARTNERS