這是一個合適的Android遊戲循環嗎？

我從我學習的書中抓住了這一點。這是一個合適的Android遊戲循環嗎？

public void run() 
{ 
    // this is the method that gets called when the thread is started. 

    // first we get the current time before the loop starts 
    long startTime = System.currentTimeMillis(); 

    // start the animation loop 
    while (running) 
    { 
     // we have to make sure that the surface has been created 
     // if not we wait until it gets created 
     if (!holder.getSurface().isValid()) 
      continue; 

     // get the time elapsed since the loop was started 
     // this is important to achieve frame rate-independent movement, 
     // otherwise on faster processors the animation will go too fast 
     float timeElapsed = (System.currentTimeMillis() - startTime); 

     // is it time to display the next frame? 
     if (timeElapsed > FRAME_RATE) 
     { 
      // compute the next step in the animation 
      update(); 

      // display the new frame 
      display(); 

      // reset the start time 
      startTime = System.currentTimeMillis(); 
     } 
    } 

    // run is over: thread dies 
}

它是否正確地解釋滯後並且是否最優？

我的意思是，如果視頻不能每秒更新60次，update（）會被稱爲每秒60次？

感謝

來源

2012-10-12 jmasterx

你能更具體嗎？ –

看到我的編輯.... – jmasterx

如果視頻無法更新每秒60次將更新（）被調用60X每秒？

對此的答案是否定的。在每個遊戲循環開始時，您計算自上一次遊戲循環以來的時間。您將其存儲在「timeElapsed」中。

從這裏，你比較這個「FRAME_RATE」。「FRAME_RATE」是一個誤導性的名字，因爲在你的情況下，它不是你的幀速率。您希望幀速率爲60.爲了等待適當的時間量，FRAME_RATE應該爲1000（毫秒）/ 60（幀/秒）。

現在，在每次迭代開始時，您會花費經過的時間並測試以確定是否是下一幀的時間。如果不是，則跳過任何實際的處理或渲染，然後再次運行循環。

當經過的時間終於超過FRAME_RATE（實際上是延遲），您將執行處理並渲染幀。理想情況下，執行此操作所需的時間將少於幀延遲，從而使您的下一次迭代能夠按計劃開始。只要情況如此，update（）和display（）就會被調用大約每秒60次。

但是，如果它需要渲染和處理幀的時間更長比的幀延遲，那麼下一個框架將在第二天的迭代處理，這將是末。在這種情況下，update（）和display（）將被稱爲每秒不到60次。

來源

2012-10-12 02:48:10 mafian911

只有在這裏添加的東西是，你也應該''timeElapsed'到你的更新函數來獲得幀獨立的時間。這種方式即使你低於理想的60fps，遊戲邏輯也不會放慢速度。 – Geobits

同意Geobits，更新需要時間，否則無法確定自上次更新以來Mario運行的距離.... – dorjeduck

這是一個合適的Android遊戲循環嗎？

回答

相關問題