UPS và FPS - Tôi nên hạn chế những gì và tại sao?


11

Tôi hiện đang viết một trò chơi bằng C ++ và SDL2 và có một điều mà tôi băn khoăn - liệu có giới hạn khung hình của tôi mỗi giây (FPS) và / hoặc cập nhật của tôi mỗi giây không?

Tôi có ý tưởng rằng nếu bạn giới hạn UPS, về cơ bản bạn sẽ kiểm soát tốc độ của trò chơi - nếu người chơi di chuyển 1px mỗi lần cập nhật và bạn luôn cập nhật 30 lần mỗi giây, anh ta sẽ di chuyển với tốc độ 30px / s và bạn Có lẽ cũng sẽ giảm CPU vì số lượng tính toán mỗi giây giảm. Nếu bạn giới hạn FPS, số lượng rút tiền mỗi giây sẽ giảm, do đó bạn giảm GPU của mình. Tôi hy vọng tôi hiểu tất cả những điều đó một cách chính xác, nếu không, hãy thoải mái sửa tôi.

Câu hỏi của tôi là - tôi nên hạn chế điều gì trong trò chơi của mình? FPS? UPS? Cả hai? Cũng không? Có cách khác, cách tiếp cận tốt hơn cho điều này? Làm thế nào điều này được thực hiện trong hầu hết các trò chơi và tại sao?

Câu trả lời được đánh giá rất cao!


2
Không thực sự là một câu trả lời, nhưng bạn có thể thấy điều này hữu ích: gafferongames.com/game-physics/fix-your-timestep
Cypher

Câu trả lời:


10

Vâng, nó có ý nghĩa.

Như bạn đã nói, nó sẽ tải ít hơn trên hệ thống, điều này tốt cho nhiệt và các ứng dụng khác.

Tuy nhiên .... logic trò chơi của bạn KHÔNG nên phụ thuộc vào các cập nhật mỗi giây. Do đó tôi khuyên bạn nên xem qua deltatime, điều này sẽ khiến trò chơi của bạn độc lập với các bản cập nhật mỗi giây.

Tôi khuyên bạn nên xem câu hỏi này. Nó giải thích khá tốt cách tính toán và sử dụng nó. Cách lấy và sử dụng thời gian delta

Hy vọng nó sẽ giúp!


Vì vậy, tôi nên hạn chế cả hai hoặc chỉ một trong số họ?
DocCoock

Cả hai, nhưng thêm một tùy chọn trong cài đặt để điều chỉnh.
KaareZ

5
Một lời cảnh báo: nếu bạn sử dụng một động cơ vật lý, làm không dựa vào thời gian đồng bằng / khung cập nhật biến vì đây là những hiếm khi được hỗ trợ; họ yêu cầu cách tiếp cận khung cố định. Và nếu khung của bạn dao động nhiều, điều này có thể có nghĩa là bạn có vấn đề với phần mềm của mình và nên tự hỏi tại sao điều này xảy ra. Với những điều này, bạn có thể xem xét lại bằng cách sử dụng phương pháp DT.
Vaillancourt

1
Lưu ý rằng việc sử dụng các bản cập nhật dựa trên thời gian delta có thể dẫn đến mất ổn định vật lý và các lỗi rất khó tái tạo. Trong một số trò chơi, có những thủ thuật chỉ có thể có ở tốc độ khung hình nhất định. Đây là lý do tại sao vật lý thường chạy ở tốc độ khung hình cố định. Bạn luôn có thể nội suy ở tốc độ cập nhật thấp hơn, nhưng nếu mô phỏng của bạn không ổn định, không có gì có thể giúp bạn.
Dietrich Epp

1
Thành thật mà nói, tôi nghĩ rằng deltatime không phải là một ý tưởng tốt. Tôi đã sử dụng nó trong nhiều năm, và nó đi kèm với hai vấn đề lớn. Rất nhiều bài viết nhiều người chơi khác nhau khuyên bạn nên sử dụng các bước thời gian cố định và nếu độ trễ quá cao, thì bạn có thể dịch chuyển qua các bức tường hoặc các lỗi tương tự trừ khi bạn tính đến điều đó.
Chương trình

6

Câu trả lời tốt nhất là: Nó phụ thuộc .

Bạn không phải giới hạn một trong hai

Cập nhật : Nếu các cập nhật của bạn không bị ràng buộc ở giới hạn trên, thì logic trò chơi sẽ phụ thuộc vào thời gian delta lượng , để tránh chạy trò chơi nhanh hơn hoặc chậm hơn tùy thuộc vào máy chạy ở đâu. Đây là một cách tiếp cận rất phổ biến được sử dụng bởi nhiều trò chơi, nhưng nó không phải là cách duy nhất.

Kết xuất : Nếu kết xuất không bị giới hạn ở giới hạn trên, bộ đệm khung có thể được trình bày ở trạng thái không hoàn chỉnh hoặc sai, gây ra các hiện vật bị rách . Đây là lý do tại sao nhiều trò chơi sử dụng Đồng bộ hóa dọc (v-sync)

Bạn có thể giới hạn cả hai

Cập nhật : Một số trò chơi sử dụng dấu thời gian cố định cho một số hoặc tất cả các hệ thống chơi trò chơi của nó. Cách tiếp cận này hoạt động đúng như bạn đã mô tả. Số lượng Cập nhật mỗi giây được giới hạn ở giới hạn trên để đảm bảo mọi thứ không di chuyển quá nhanh trên một máy đỉnh cao. Điều này loại bỏ sự cần thiết cho thời gian delta. Một số ứng dụng tốt hơn với dấu thời gian cố định, một số ứng dụng có thời gian delta. Chọn cách tiếp cận nào sẽ phụ thuộc hoàn toàn vào chính xác những gì bạn đang cố gắng đạt được. Cuốn sách trực tuyến GameProgrammingPotypes có một chương dành riêng cho các vòng lặp trò chơi chạm vào cả hai kiến ​​trúc.

Kết xuất : Khung hình mỗi giây nên được đặt ở giới hạn trên để tránh sự cố xé rách được đề cập ở trên, tuy nhiên, ứng dụng của bạn không nên cố gắng thực hiện thủ công với một số khóa CPU. Thay vào đó, hãy bật v-sync và để phần cứng bên dưới đồng bộ hóa với tốc độ làm mới màn hình. Bằng cách đó, trò chơi của bạn sẽ tương thích với các màn hình trong tương lai có thể hoạt động ở tần số cao hơn nhiều so với tần số 60Hz hiện tại. Điều đáng chú ý là nhiều game thủ, đặc biệt là những người tham gia điểm chuẩn, vẫn thích chạy mà không có v-sync để cho phép tốc độ khung hình cao nhất có thể. Vì vậy, việc cho phép bật hoặc tắt tính năng trong thời gian chạy là điều hợp lý.

Những gì bạn không nên giới hạn

Nếu trò chơi của bạn sử dụng cách tiếp cận dựa trên bỏ phiếu cho đầu vào của người dùng, ví dụ: gọi một getInput()loại để cập nhật trạng thái bộ điều khiển trong bước cập nhật, thì điều này tốt hơn nếu không bị giới hạn. Hoặc nếu có giới hạn, sau đó đặt thành giới hạn trên rất cao. Bạn càng thường xuyên truy vấn đầu vào của người dùng và hành động theo nó, trò chơi sẽ càng "nhạy" và mượt mà hơn. Các trò chơi được gọi là 60Hz mà chúng ta nghe thấy hiện nay không cập nhật AI và tất cả các trạng thái trên thế giới với tốc độ đó, một số thậm chí không hiển thị nhanh như vậy, nhưng chúng truy vấn bộ điều khiển nhập ít nhất 60 lần mỗi giây và cập nhật hình đại diện cho người chơi. Cho rằng điều này chỉ thực sự phù hợp với các trò chơi hành động nhịp độ nhanh.


Mặc dù vậy, các cập nhật của tôi cũng tự động bị giới hạn khi bật VSync. Vì vậy, rõ ràng tôi phải quyết định giữa vấn đề xé và vấn đề cập nhật-bỏ phiếu, đúng không?
DocCoock

@DocCoock, nếu trình kết xuất và logic trò chơi của bạn chạy trên cùng một luồng, vâng, bật v-sync cũng sửa tần số cập nhật. Đó là một lý do khiến một số trò chơi tách biệt kết xuất đồ họa và logic trò chơi theo các luồng khác nhau.
glampert

1

Có hai bài viết bạn có thể muốn xem qua:

Sửa dấu thời gian của bạn

Kết xuất vật lý nội suy

Tôi thấy các cuộc thảo luận trên các bài đăng thực sự vô giá, nhưng theo tôi nó có ý nghĩa nhất khi có một lượng mô phỏng vật lý quan trọng trong trò chơi. Tóm lại, ý tưởng là mô phỏng nên có một bước thời gian cố định (nếu không thì vật lý có thể phát nổ tại một thời điểm mà đồng bằng quá lớn), trong khi kết xuất nên được tự do chạy ở tốc độ tối đa có thể. Để đồng bộ hóa cả hai (mô phỏng và kết xuất), trạng thái kết xuất được nội suy bởi một yếu tố phụ thuộc vào mức độ mô phỏng từ bản cập nhật sau (nhớ rằng mô phỏng được cố định).

Hy vọng nó giúp.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.