0

現在、オブジェクトが移動するポイントを決定するゲームがあります。次に、そのポイントへのパスを計算し、そのポイントCCMoveToに到達するための 1 つの長いアニメーションを作成します。この方法では、アニメーションは非常に滑らかで連続的に見えます。

私は現在、定期的に呼び出されるメソッドを利用して、これCCMoveToを複数に分割しようとしています。これを行うのは、オブジェクトが通過するパスの各ノードで注意散漫になる可能性があり、オブジェクトがそれに基づいて動作できるようにするためです。だからこれは私がやっていることです：CCMoveToupdate

- (void) update: (ccTime) dt
{
    if(![self isWalking]){
        CGPoint nextNode = [_path objectAtIndex:(_currentPathIndex%[_path count])];
        _currentPathIndex++;
        NSMutableArray *actions = [[NSMutableArray alloc] init];
        [actions addObject:[CCCallBlockO actionWithBlock:^void(id obj) {
            [(Monkey *) obj setIsWalking:NO];
        }                                         object:self]];
        [self moveTo: nextNode withCallbacks: actions];
    }
}

注:オブジェクトが宛先ノードに完全に到達したときのコールバックとしてを設定isWalkingしました。NOこれにより、次に移動するノードを計算し、そのアニメーションを構築できます。runActionこれがないと、オブジェクトは進行中のCCMoveToアクションの途中でしようとします。この方法の問題点は、動きが滑らかで連続していないように見えることです。CCMoveTo各アニメーションの最後にラグがあるようです

誰でもこれを修正する方法についての手がかりを持っていますか?

4

1 に答える 1

1

これは、cocos2d の CCAction システムと CCScheduler の副作用です。

アクションが停止すると、現在のフレームでは何の作業も行われないため、常に 1 フレームの遅延が発生します。前のフレームで最後の位置の更新が行われ、現在のフレームではもはや存在しません。ランニングアクション。

スケジュールされたメソッドで別の移動アクションを実行すると、そのアクションは次のフレームまで更新を開始しません。これは、更新を受信するようにスケジュールされるためです。また、cocos2d の CCScheduler が更新を実行している間にスケジュールされた更新は、列挙中に配列を変更できないため、次のフレームまで実行されません。

ゲームプレイの目的で CCMove* アクションを使用することは常に避け、代わりにゲーム オブジェクトの位置を手動で更新することをお勧めします。実行するのは簡単です。コード例が必要な場合は、CCMoveTo クラスの内部を調べてください。

回避策は、CCMoveTo の距離を延長し、アクションが完了する直前にアクションを置き換えることです。それはハックであり、実際には手動の位置更新よりも正しく実装するのが難しいかもしれません.

PS: これはKoboldTouchのアクション モデルで対処した問題です。より軽量で再利用可能なアクションを備えた独自のアクションシステムを実装しています。

于 2013-01-22T09:22:21.257 に答える