Variable time step bug with Box2D

Question

아래 코드를 잘못 이해할 수 있습니까? 이전 TIME_STEPS 프레임 수의 프레임 간격 (dt)을 평균 한 것으로 가정합니다.

저는 Box2d와 cocos2d를 사용하고 있습니다 만, 나는 cocos2d 비트가별로 관련이 없다고 생각합니다.

-(void) update: (ccTime) dt 
{ 
    float32 timeStep; 
    const int32 velocityIterations = 8; 
    const int32 positionIterations = 3; 

    // Average the previous TIME_STEPS time steps 

    for (int i = 0; i < TIME_STEPS; i++) 
    { 
     timeStep += previous_time_steps[i]; 
    } 

    timeStep = timeStep/TIME_STEPS; 

    // step the world 
    [GB2Engine sharedInstance].world->Step(timeStep, velocityIterations, positionIterations); 

    for (int i = 0; i < TIME_STEPS - 1; i++) 
    { 
     previous_time_steps[i] = previous_time_steps[i+1]; 
    } 

    previous_time_steps[TIME_STEPS - 1] = dt; 
} 

before_time_steps 배열은 처음에는 애니메이션 간격도 설정됩니다.

이것은 내가 예상하는대로하지 않습니다. 프레임 속도가 낮은 장치에서는 시뮬레이션 속도가 빨라지고 프레임 속도가 높은 장치에서는 속도가 느려집니다. 나는 그것이 바보 같다고 생각한다.

나는 box2D가 고정 시간 단계로 작업하는 것을 좋아하지만 실제로 선택의 여지가 없음을 알고 있습니다. 내 게임은 다양한 장치에서 매우 다양한 프레임 속도로 실행되므로 고정 시간 정지는 작동하지 않습니다. 이 게임은 평균 40fps로 실행되지만, 1 세대 iPad와 같은 더 까다로운 기기의 경우 초당 30 프레임 밖에 안됩니다. 세 번째 세대 ipad는 초당 50/60 프레임으로 실행합니다.

이 문제를 다루는 다른 방법에 대한 제안도 있습니다. 어떤 조언을 주시면 감사하겠습니다.

뭔가 이상한 점 누군가가 어떤 디버그 최적화를 실행해도 위의 사항에 큰 영향을 미친다는 사실에 대한 통찰력이 있습니다. 디버그 최적화가 -Osvs -O0으로 설정된 경우 프레임 속도는 많이 변경되지 않습니다. 그러나 데뷔 최적화가 -O로 설정되면 위의 코드가 활성화 될 때 물리 시뮬레이션이 -O0보다 훨씬 빠르게 실행됩니다. 위의 코드 대신 dt를 간격으로 사용하면 디버그 최적화가 아무런 효과가 없습니다.

저는 완전히 혼란 스럽습니다. 낮은 프레임 속도와 장치에

Answer 1

는 시뮬레이션 속도와 높은 프레임 속도 장치에 그것을 속도가 느려집니다.

가변 시간 단계를 사용하는 것이 전부입니다. 10fps 만 얻으면 물리 엔진은 델타 시간이 더 크기 때문에 세계를 더 빠르게 반복합니다.

추신 : 이러한 성능 테스트를 수행하는 경우 릴리스 빌드로 실행하십시오. 또한 (대부분의) 로깅이 비활성화되고 코드 최적화가 설정됩니다. 이전 장치에서 코드를 디버깅함으로써 성능에 훨씬 큰 영향을 미칠 수 있습니다.

또한 TIME_STEPS 값은 얼마입니까? 그것은 10 이하, 어쩌면 20 이하 여야합니다. 평균화의 대안은 델타 시간을 직접 사용하는 것입니다. 그러나 델타 시간이 특정 임계 값 (30fps)보다 큰 경우 고정 델타 시간 (cap)으로 전환하십시오. 30 fps 미만의 가변 시간 단계는 실제로보기 흉하게 들릴 수 있기 때문에 물리 엔진이 프레임 속도로 속도를 줄이는 것이 좋을 수도 있습니다. 그렇지 않으면 낮은 fps에서 재생할 수없는 경우 게임이 더 어려워집니다.