Điểm cập nhật kết xuất độc lập trong một vòng lặp trò chơi là gì?

Có hàng tá bài báo, sách và thảo luận về các vòng lặp trò chơi. Tuy nhiên, tôi thường xuyên bắt gặp một cái gì đó như thế này:

while(running)
{
    processInput();
    while(isTimeForUpdate)
    {
        update();
    }
    render();
}

Điều cơ bản làm phiền tôi về cách tiếp cận này là kết xuất "không phụ thuộc vào cập nhật", ví dụ như kết xuất khung khi không có thay đổi nào cả. Vì vậy, câu hỏi của tôi là tại sao phương pháp này thường được dạy?

Có một lịch sử lâu dài về cách chúng tôi đến hội nghị chung này, với rất nhiều thử thách hấp dẫn trên đường đi, vì vậy tôi sẽ cố gắng thúc đẩy nó theo từng giai đoạn:

1. Vấn đề: Thiết bị chạy ở tốc độ khác nhau

Bạn đã bao giờ thử chơi một game DOS cũ trên PC hiện đại và nó chạy rất nhanh - chỉ là một vệt mờ?

Rất nhiều game cũ có vòng cập nhật rất ngây thơ - họ thu thập dữ liệu đầu vào, cập nhật trạng thái trò chơi và kết xuất nhanh như phần cứng cho phép, mà không tính đến thời gian đã trôi qua. Có nghĩa là ngay khi phần cứng thay đổi, lối chơi thay đổi.

Chúng tôi thường muốn người chơi của chúng tôi có trải nghiệm và cảm giác trò chơi nhất quán trên một loạt thiết bị, (miễn là họ đáp ứng một số thông số tối thiểu) cho dù họ đang sử dụng điện thoại năm ngoái hoặc model mới nhất, máy tính để bàn chơi game hàng đầu hoặc một máy tính xách tay trung cấp.

Đặc biệt, đối với các trò chơi có tính cạnh tranh (nhiều người chơi hoặc qua bảng xếp hạng), chúng tôi không muốn người chơi chạy trên một thiết bị cụ thể có lợi thế hơn những người khác vì họ có thể chạy nhanh hơn hoặc có nhiều thời gian hơn để phản ứng.

Giải pháp chắc chắn ở đây là khóa tốc độ chúng tôi thực hiện cập nhật trạng thái trò chơi. Bằng cách đó chúng tôi có thể đảm bảo kết quả sẽ luôn giống nhau.

2. Vì vậy, tại sao không chỉ khóa tốc độ khung hình (ví dụ: sử dụng VSync) mà vẫn chạy các bản cập nhật trạng thái trò chơi & kết xuất theo bước khóa?

Điều này có thể làm việc, nhưng không phải lúc nào cũng ngon miệng cho khán giả. Đã có một thời gian dài khi chạy ở tốc độ 30 khung hình / giây vững chắc được coi là tiêu chuẩn vàng cho các trò chơi. Giờ đây, người chơi thường mong đợi 60 khung hình / giây là thanh tối thiểu, đặc biệt là trong các trò chơi hành động nhiều người chơi, và một số tựa game cũ giờ trông đáng chú ý vì kỳ vọng của chúng tôi đã thay đổi. Ngoài ra còn có một nhóm người chơi PC đặc biệt phản đối việc khóa khung hình. Họ đã trả nhiều tiền cho phần cứng vượt trội của mình và muốn có thể sử dụng cơ tính toán đó để có được kết xuất mượt mà nhất, độ trung thực cao nhất mà nó có khả năng.

Trong VR nói riêng, tốc độ khung hình là vua và tiêu chuẩn tiếp tục tăng lên. Vào đầu sự hồi sinh gần đây của VR, các trò chơi thường chạy khoảng 60 khung hình / giây. Bây giờ 90 là tiêu chuẩn hơn, và các phần mềm như PSVR đang bắt đầu hỗ trợ 120. Điều này có thể tiếp tục tăng. Vì vậy, nếu một trò chơi VR giới hạn tốc độ khung hình của nó với những gì có thể thực hiện và được chấp nhận ngày hôm nay, thì nó có thể bị bỏ lại phía sau khi phần cứng và kỳ vọng phát triển hơn nữa.

(Theo quy định, hãy cảnh giác khi nói "người chơi không thể nhận biết bất cứ điều gì nhanh hơn XXX" vì nó thường dựa trên một loại "nhận thức" cụ thể, như nhận ra một khung theo trình tự. Nhận thức về tính liên tục của chuyển động nói chung là xa hơn nhiều nhạy cảm.)

Vấn đề cuối cùng ở đây là một trò chơi sử dụng tốc độ khung hình bị khóa cũng cần phải thận trọng - nếu bạn từng gặp một khoảnh khắc trong trò chơi khi bạn đang cập nhật và hiển thị số lượng đối tượng cao bất thường, bạn không muốn bỏ lỡ khung hình của mình thời hạn và gây ra một sự tắc nghẽn đáng chú ý hoặc quá giang. Vì vậy, bạn cần đặt ngân sách nội dung của mình đủ thấp để rời khỏi phòng đầu tư hoặc đầu tư vào các tính năng điều chỉnh chất lượng động phức tạp hơn để tránh gắn kết toàn bộ trải nghiệm chơi với hiệu suất trong trường hợp xấu nhất trên phần cứng tối thiểu.

Điều này có thể đặc biệt có vấn đề nếu các vấn đề về hiệu năng xuất hiện muộn trong quá trình phát triển, khi tất cả các hệ thống hiện tại của bạn được xây dựng & điều chỉnh với giả định tốc độ kết xuất khung hình mà bây giờ bạn không thể luôn gặp phải. Tốc độ tách rời cập nhật & kết xuất cho phép linh hoạt hơn để xử lý sự thay đổi hiệu suất.

3. Không cập nhật tại một dấu thời gian cố định có cùng các vấn đề như (2) không?

Tôi nghĩ rằng đây là cốt lõi của câu hỏi ban đầu: nếu chúng tôi tách rời các bản cập nhật của chúng tôi và đôi khi kết xuất hai khung hình không có cập nhật trạng thái trò chơi ở giữa, thì nó không giống như kết xuất khóa ở tốc độ khung hình thấp hơn, vì không có thay đổi rõ ràng nào màn hình?

Thực tế, có một số cách khác nhau mà các trò chơi sử dụng việc tách rời các bản cập nhật này để có hiệu quả tốt:

a) Tốc độ cập nhật có thể nhanh hơn tốc độ khung hình được hiển thị

Như tyjkenn lưu ý trong một câu trả lời khác, đặc biệt là vật lý thường được đặt ở tần số cao hơn kết xuất, giúp giảm thiểu các lỗi tích hợp và cho các va chạm chính xác hơn. Vì vậy, thay vì có 0 hoặc 1 cập nhật giữa các khung được hiển thị, bạn có thể có 5 hoặc 10 hoặc 50.

Giờ đây, trình phát kết xuất ở tốc độ 120 khung hình / giây có thể nhận được 2 bản cập nhật trên mỗi khung hình, trong khi trình phát ở phần cứng thông số kỹ thuật thấp hơn ở tốc độ 30 khung hình / giây có 8 bản cập nhật trên mỗi khung hình và cả hai trò chơi của họ đều chạy ở cùng tốc độ trò chơi-tick-per-realtime-giây. Phần cứng tốt hơn làm cho nó trông mượt mà hơn, nhưng không thay đổi hoàn toàn cách hoạt động của trò chơi.

Có một rủi ro ở đây là, nếu tốc độ cập nhật không khớp với tốc độ khung hình, bạn có thể nhận được "tần số nhịp" giữa hai . Ví dụ. hầu hết các khung hình chúng tôi có đủ thời gian cho 4 bản cập nhật trạng thái trò chơi và một chút còn sót lại, sau đó, thường thì chúng tôi có đủ tiết kiệm để thực hiện 5 bản cập nhật trong một khung hình, thực hiện một cú nhảy hoặc nói lắp trong chuyển động. Điều này có thể được giải quyết bằng ...

b) Nội suy (hoặc ngoại suy) trạng thái trò chơi giữa các bản cập nhật

Ở đây chúng ta sẽ thường để trạng thái trò chơi sống theo một dấu thời gian cố định trong tương lai và lưu trữ đủ thông tin từ 2 trạng thái gần đây nhất mà chúng ta có thể đưa ra một điểm tùy ý giữa chúng. Sau đó, khi chúng tôi sẵn sàng hiển thị một khung hình mới trên màn hình, chúng tôi sẽ hòa trộn vào thời điểm thích hợp cho mục đích hiển thị (nghĩa là chúng tôi không sửa đổi trạng thái chơi trò chơi cơ bản ở đây)

Khi được thực hiện đúng, điều này làm cho chuyển động có cảm giác trơn tru, và thậm chí giúp che giấu một số biến động trong tốc độ khung hình, miễn là chúng ta không giảm quá thấp.

c) Thêm độ mượt cho các thay đổi trạng thái không chơi trò chơi

Ngay cả khi không nội suy trò chơi, chúng ta vẫn có thể có được một số chiến thắng mượt mà.

Thay đổi hoàn toàn bằng hình ảnh như hoạt hình nhân vật, hệ thống hạt hoặc VFX và các yếu tố giao diện người dùng như HUD, thường cập nhật riêng biệt với dấu thời gian cố định của trạng thái trò chơi. Điều này có nghĩa là nếu chúng tôi đánh dấu trạng thái chơi trò chơi của mình nhiều lần trên mỗi khung hình, chúng tôi sẽ không trả chi phí cho mỗi lần đánh dấu - chỉ trên lượt kết xuất cuối cùng. Thay vào đó, chúng tôi chia tỷ lệ tốc độ phát lại của các hiệu ứng này để phù hợp với độ dài của khung hình, để chúng chơi mượt mà như tốc độ khung hình cho phép, mà không ảnh hưởng đến tốc độ trò chơi hoặc sự công bằng như đã thảo luận trong (1).

Chuyển động của máy ảnh cũng có thể làm điều này - đặc biệt là trong VR, đôi khi chúng ta sẽ hiển thị cùng một khung hình nhiều lần nhưng lại điều chỉnh nó để tính đến chuyển động đầu của người chơi ở giữa , vì vậy chúng ta có thể cải thiện độ trễ và sự thoải mái, ngay cả khi chúng ta có thể Tự nhiên khiến mọi thứ trở nên nhanh chóng. Một số hệ thống phát trực tuyến trò chơi (nơi trò chơi đang chạy trên máy chủ và người chơi chỉ chạy một máy khách mỏng) cũng sử dụng phiên bản này.

4. Tại sao không chỉ sử dụng phong cách (c) đó cho mọi thứ? Nếu nó hoạt động cho hoạt hình và giao diện người dùng, chúng ta có thể đơn giản mở rộng các cập nhật trạng thái trò chơi của mình để phù hợp với tốc độ khung hình hiện tại không?

Có * điều này là có thể, nhưng không, nó không đơn giản.

Câu trả lời này đã hơi lâu rồi nên tôi sẽ không đi sâu vào tất cả các thông tin chi tiết, chỉ là một bản tóm tắt nhanh:

• Nhân với deltaTimecác công việc để điều chỉnh các cập nhật có độ dài thay đổi để thay đổi tuyến tính (ví dụ: chuyển động với vận tốc không đổi, đếm ngược thời gian hoặc tiến triển theo dòng thời gian hoạt hình)

• Thật không may, nhiều khía cạnh của trò chơi là phi tuyến tính . Ngay cả một cái gì đó đơn giản như trọng lực đòi hỏi các kỹ thuật tích hợp tinh vi hơn hoặc các bước phụ có độ phân giải cao hơn để tránh kết quả chuyển hướng trong các khung hình khác nhau. Đầu vào và điều khiển của người chơi tự nó là một nguồn phi tuyến tính khổng lồ.

• Cụ thể, kết quả phát hiện và giải quyết va chạm riêng biệt phụ thuộc vào tốc độ cập nhật, dẫn đến lỗi đường hầm và lỗi jitter nếu khung hình quá dài. Vì vậy, một tốc độ khung hình biến đổi buộc chúng ta phải sử dụng các phương pháp phát hiện va chạm liên tục phức tạp / đắt tiền hơn trên nhiều nội dung của chúng tôi hoặc chịu đựng sự biến đổi trong vật lý của chúng tôi. Ngay cả việc phát hiện va chạm liên tục cũng gặp phải những thách thức khi các vật thể di chuyển trong vòng cung, đòi hỏi thời gian ngắn hơn ...

Vì vậy, trong trường hợp chung cho một trò chơi có độ phức tạp trung bình, việc duy trì hành vi nhất quán & công bằng hoàn toàn thông qua deltaTimeviệc mở rộng quy mô là một nơi nào đó rất khó khăn và bảo trì chuyên sâu đến hoàn toàn không khả thi.

Chuẩn hóa tỷ lệ cập nhật cho phép chúng tôi đảm bảo hành vi nhất quán hơn trong một loạt các điều kiện , thường là với mã đơn giản hơn.

Giữ tốc độ cập nhật được tách rời khỏi kết xuất cho phép chúng tôi linh hoạt để kiểm soát độ mượt và hiệu suất của trải nghiệm mà không làm thay đổi logic trò chơi .

Ngay cả sau đó chúng ta không bao giờ có được sự độc lập thực sự "hoàn hảo" nhưng giống như rất nhiều cách tiếp cận trong các trò chơi, nó cho chúng ta một phương pháp có thể kiểm soát để quay số theo hướng "đủ tốt" cho nhu cầu của một trò chơi nhất định. Đó là lý do tại sao nó thường được dạy như một điểm khởi đầu hữu ích.

Các câu trả lời khác là tốt và nói về lý do tại sao vòng lặp trò chơi tồn tại và nên tách biệt khỏi vòng lặp kết xuất. Tuy nhiên, như ví dụ cụ thể về "Tại sao kết xuất khung khi không có bất kỳ thay đổi nào?" Nó thực sự chỉ đến phần cứng và phức tạp.

Thẻ video là máy trạng thái và chúng thực sự giỏi làm đi làm lại nhiều lần. Nếu bạn chỉ kết xuất những thứ đã thay đổi, nó thực sự đắt hơn chứ không phải ít hơn. Trong hầu hết các kịch bản, không có bất kỳ thứ gì tĩnh, nếu bạn di chuyển sang trái một chút trong trò chơi FPS, bạn đã thay đổi dữ liệu pixel của 98% nội dung trên màn hình, bạn cũng có thể hiển thị toàn bộ khung hình.

Nhưng chủ yếu, phức tạp. Theo dõi mọi thứ đã thay đổi trong khi thực hiện cập nhật tốn kém hơn rất nhiều vì bạn phải làm lại mọi thứ hoặc theo dõi kết quả cũ của một số thuật toán, so sánh nó với kết quả mới và chỉ hiển thị pixel đó nếu thay đổi khác nhau. Nó phụ thuộc vào hệ thống.

Thiết kế của phần cứng, vv phần lớn được tối ưu hóa cho các quy ước hiện tại và một máy trạng thái đã là một mô hình tốt để bắt đầu.

Kết xuất thường là quá trình chậm nhất trong vòng lặp trò chơi. Con người không dễ dàng nhận thấy sự khác biệt về tốc độ khung hình nhanh hơn 60, do đó, việc lãng phí thời gian để kết xuất nhanh hơn thường ít quan trọng hơn. Tuy nhiên, có những quy trình khác sẽ được hưởng lợi nhiều hơn từ tốc độ nhanh hơn. Vật lý là một. Quá lớn sự thay đổi trong một vòng lặp có thể khiến các vật thể bị trục trặc ngay qua các bức tường. Có thể có các cách khắc phục các lỗi va chạm đơn giản trên các mức tăng lớn hơn, nhưng đối với nhiều tương tác vật lý phức tạp, bạn sẽ không có được độ chính xác tương tự. Nếu vòng lặp vật lý được chạy thường xuyên hơn, ít có khả năng xảy ra sự cố, vì các đối tượng có thể được di chuyển theo gia số nhỏ hơn mà không được hiển thị mỗi lần. Nhiều tài nguyên hơn dành cho công cụ vật lý nhạy cảm và ít lãng phí hơn khi vẽ nhiều khung hình hơn mà người dùng không thể nhìn thấy.

Điều này đặc biệt quan trọng trong các game chuyên sâu về đồ họa. Nếu có một kết xuất cho mỗi vòng lặp trò chơi và người chơi không có máy mạnh nhất, có thể có điểm trong trò chơi mà khung hình / giây giảm xuống còn 30 hoặc 40. Mặc dù đây vẫn sẽ là tốc độ khung hình không hoàn toàn khủng khiếp, Trò chơi sẽ bắt đầu khá chậm nếu chúng tôi cố gắng giữ mỗi thay đổi vật lý nhỏ một cách hợp lý để tránh bị trục trặc. Người chơi sẽ khó chịu khi nhân vật của mình chỉ đi được một nửa tốc độ bình thường. Tuy nhiên, nếu tốc độ kết xuất độc lập với phần còn lại của vòng lặp, người chơi sẽ có thể giữ tốc độ đi bộ cố định mặc dù tốc độ khung hình giảm.

Một cấu trúc giống như trong câu hỏi của bạn có thể có ý nghĩa nếu hệ thống con kết xuất có một số khái niệm về "thời gian trôi qua kể từ lần kết xuất cuối cùng" .

Ví dụ, hãy xem xét một cách tiếp cận trong đó vị trí của một đối tượng trong thế giới trò chơi được thể hiện thông qua các (x,y,z)tọa độ cố định với một cách tiếp cận lưu trữ thêm vectơ chuyển động hiện tại (dx,dy,dz). Bây giờ, bạn có thể viết vòng lặp trò chơi của mình để thay đổi vị trí phải xảy ra trong updatephương thức, nhưng bạn cũng có thể thiết kế nó để thay đổi chuyển động phải xảy ra trong thời gian đó update. Với cách tiếp cận thứ hai, mặc dù trạng thái trò chơi của bạn thực sự sẽ không thay đổi cho đến lần tiếp theo update, mộtrender-Chức năng được gọi ở tần số cao hơn có thể đã vẽ đối tượng ở vị trí được cập nhật một chút. Mặc dù về mặt kỹ thuật này dẫn đến sự khác biệt giữa những gì bạn nhìn thấy và những gì được thể hiện trong nội bộ, sự khác biệt là đủ nhỏ để không quan trọng đối với hầu hết các khía cạnh thực tế, nhưng cho phép hoạt hình trông mượt mà hơn nhiều.

Dự đoán "tương lai" của trạng thái trò chơi của bạn (mặc dù có nguy cơ sai) có thể là một ý tưởng hay khi bạn lấy ví dụ về độ trễ của đầu vào mạng vào tài khoản.

Ngoài những câu trả lời khác ...

Kiểm tra sự thay đổi của nhà nước đòi hỏi xử lý đáng kể. Nếu phải mất thời gian xử lý tương tự (hoặc hơn!) Để kiểm tra các thay đổi, so với thực tế xử lý, bạn thực sự đã không làm cho tình hình tốt hơn. Trong trường hợp hiển thị hình ảnh, như @Waddles nói, một thẻ video thực sự rất tốt khi thực hiện cùng một việc ngu ngốc hết lần này đến lần khác, và việc kiểm tra từng đoạn dữ liệu để thay đổi sẽ tốn kém hơn so với việc chuyển nó qua vào card màn hình để xử lý. Ngoài ra nếu rendering là gameplay thì nó thực sự khó cho màn hình không như đã thay đổi trong đánh dấu cuối cùng.

Bạn cũng cho rằng việc kết xuất cần nhiều thời gian xử lý. Điều này phụ thuộc rất nhiều vào bộ xử lý và card đồ họa của bạn. Trong nhiều năm nay, trọng tâm là giảm tải dần dần công việc kết xuất tinh vi hơn cho card đồ họa và giảm đầu vào kết xuất cần thiết từ bộ xử lý. Lý tưởng nhất là render()cuộc gọi của bộ xử lý chỉ cần thiết lập chuyển DMA và đó là cuộc gọi. Sau đó, lấy dữ liệu vào card đồ họa được ủy quyền cho bộ điều khiển bộ nhớ và việc tạo ra hình ảnh được ủy quyền cho card đồ họa. Họ có thể làm điều đó trong thời gian riêng của họ, trong khi bộ xử lý song songtiếp tục với vật lý, công cụ chơi trò chơi và tất cả những thứ khác mà bộ xử lý làm tốt hơn. Rõ ràng thực tế phức tạp hơn thế rất nhiều, nhưng việc có thể giảm tải công việc cho các bộ phận khác của hệ thống cũng là một yếu tố quan trọng.