FPS lớn so với FPS nhất quán

Khi tối ưu hóa tốc độ khung hình của trò chơi, khi nào tôi nên tập trung vào FPS lớn và khi nào tôi nên tập trung vào tốc độ khung hình nhất quán.

Đây thường là một vấn đề gây tranh cãi, vì vậy xin lưu ý tôi không hỏi cái nào tốt hơn.

Những ưu và nhược điểm của mỗi là gì?
Trong những tình huống được ưu tiên hơn các tình huống khác?

Cũng lưu ý: tỷ lệ bỏ phiếu / xử lý, vật lý và cập nhật trò chơi đầu vào của tôi không phụ thuộc vào tốc độ khung hình của tôi. Điều duy nhất FPS ảnh hưởng là tần suất hiển thị màn hình.

Tất nhiên, điều này là chủ quan, nhưng tôi nghĩ rằng tính nhất quán quan trọng hơn nhiều so với chơi trò chơi so với tốc độ.

Về cơ bản, người chơi sẽ đưa ra tốc độ khung hình chậm hơn nếu trò chơi phù hợp, thú vị để chơi và không bị chói tai. Tuy nhiên, ngay cả khi trò chơi hoàn toàn rung chuyển, nếu nó khiến mọi người đau đầu nhìn vào vì nó bùng nổ và / hoặc họ không thể kiểm soát mọi thứ, họ sẽ trở nên khó chịu và ngừng chơi.

Vì thế...

Tập trung vào FPS nhất quán trong suốt quá trình thiết kế & phát triển.

Tập trung vào FPS nhanh hơn (nhưng vẫn nhất quán) khi trò chơi gần hoàn thành và bạn có thời gian để cải thiện hiệu suất mà không phải lo lắng về sửa lỗi, v.v.

Một cách để có hiệu suất tốt hơn là sử dụng các cuộc gọi lại / đại biểu / ngắt (tùy thuộc vào ngôn ngữ / nền tảng của bạn) thay vì bỏ phiếu.

Bạn nên làm gì:

• Khóa logic trò chơi với tốc độ khung hình cố định
• Kết xuất đồ họa nhanh nhất có thể

Bằng cách đó, nếu tốc độ khung hình giảm xuống, bạn sẽ không bị lag đầu vào (Tôi đang nhìn bạn, Chỉ vì 2) và nếu tốc độ khung hình trở nên quá cao (nghĩ rằng các trò chơi từ những năm 90), trò chơi sẽ không thể chơi được.

Đây là cách tôi làm điều đó:

s_PhysicsCurrent = GetTickCount();
float delta = (float)(s_PhysicsCurrent - s_PhysicsStart);
s_PhysicsStart = s_PhysicsCurrent;

s_PhysicsTime += delta;

while (s_PhysicsTime > ONEFRAME)
{
    // Update
    Game::Tick(ONEFRAME);

    // Clear input
    Keyboard::Clear();
    Mouse::Clear();

    s_PhysicsTime -= ONEFRAME;
}

s_Window->Clear();

Game::Render();

s_Window->Swap();

Về cơ bản, bạn thu thập một "chồng" các khung để làm logic và bạn có thể nội suy giữa chúng một cách hoàn hảo.

Có vẻ như bạn đã có ít nhất hai luồng thực hiện, với kết xuất của bạn trên luồng của chính nó. Nếu đó là trường hợp, thì bạn thực sự có hai tốc độ khung hình để lo lắng. Bạn sẽ muốn cả hai nhanh nhất có thể. Tuy nhiên, nó cũng phụ thuộc vào loại trò chơi bạn đang xây dựng.

Bạn đang xây dựng một game bắn súng góc nhìn thứ nhất, trong đó tốc độ khung hình nhỏ có thể mang lại lợi thế cho đối thủ? Nếu vậy, bạn sẽ muốn đảm bảo rằng khung hình / giây trung bình của bạn đủ cao, nhưng cũng lo lắng về thời gian khung hình xấu nhất của bạn. Bạn đang xây dựng một trò chơi hội đồng quản trị? Nếu vậy, việc tăng đột biến khung thời gian không thường xuyên sẽ không giết chết trải nghiệm người dùng.

Trong các trò chơi của riêng tôi, quy trình của tôi thường giống như thế này:

• Chạy một hồ sơ trên mã
• Nhìn vào tốc độ khung hình trung bình. Nếu trung bình quá thấp, hãy tăng số khung hình trung bình lên bằng cách tối ưu hóa các công cụ chậm.
• Khi khung hình / giây trung bình đủ cao, hãy tìm thời gian khung hình xấu nhất (khung hình mà bạn thấy các xung đột lớn trong thời gian tính toán hoặc kết xuất). Cố gắng tối ưu hóa các tình huống xấu nhất để cải thiện thời gian khung hình xấu nhất.

Nếu bạn ở tốc độ 30 khung hình / giây hầu hết thời gian, nhưng bạn tăng vọt lên 200ms cứ sau 10 giây, điều đó sẽ gây ra vấn đề. Nhưng nếu bạn đạt trung bình 15 khung hình / giây, hãy đưa khung hình trung bình của bạn lên trước.

Vì vậy, câu trả lời ngắn có lẽ sẽ là: tối ưu hóa bất cứ điều gì tạo ra sự cải thiện lớn nhất cho trải nghiệm người dùng trước tiên.

Khóa FPS của bạn thành một số nhất quán cho phép bạn:

• Duy trì vẻ ngoài mượt mà
• Giữ cho hình ảnh động chạy trong thời gian tuyến tính, các đối tượng vật lý rơi ở một tỷ lệ nhất quán giữa các khung, v.v.
• Tuy nhiên, phần hữu ích nhất trong việc khóa FPS của bạn là trên các khung mà bạn có thời gian rảnh bạn có thể thực hiện công việc khác - thu gom rác, làm việc phát trực tuyến trong khu vực tiếp theo của bản đồ, v.v. và bạn sẽ có một khoảng trống khi kết xuất một cái gì đó lớn và sáng bóng hoặc khi hạ gục một đống hộp.

Cả hai. Tôi muốn nói một cách lý tưởng, nhất quán hơn 60 khung hình mỗi giây. Thực tế, nhất quán hơn 30 khung hình mỗi giây. Dưới 30 khung hình mỗi giây và nó bắt đầu ảnh hưởng đến mức độ người chơi có thể thực hiện tốt như thế nào (Tôi đang nghĩ về các trò chơi dựa trên FPS / twitch, các trò chơi chiến lược có thể có thể đạt được thấp hơn).

Nếu bạn thực sự phải nói cái này hay cái kia, tôi sẽ đi với sự nhất quán. Nếu bạn có thể đảm bảo tốc độ khung hình, thì bạn có thể tập trung vào việc di chuyển tốc độ khung hình được đảm bảo cao hơn.

Lớn hơn luôn luôn tốt hơn, nhưng:

Tốc độ khung hình không nhất quán có thể dẫn đến say tàu xe.

(Chúng tôi đã có một người kiểm tra nội bộ ném lên khi tốc độ khung hình của anh ta tăng từ 20 đến 60 trong 10 giây.)

Tôi nghĩ bạn sẽ muốn cả FPS phù hợp và lớn hơn. Đồ họa càng mượt (do tốc độ làm mới) thì càng tốt. Nếu nó bắt đầu giảm xuống dưới 30FPS, người dùng của bạn sẽ bắt đầu nhận thấy sự bồn chồn và sẽ trở nên thất vọng vì thiếu thời gian phản hồi hành động.

Nếu bạn muốn tránh rách , bạn nên sử dụng đồng bộ hóa V sẽ khóa FPS ở tốc độ làm mới màn hình hoặc thấp hơn (nếu bạn tăng cao hơn thì sẽ không hiển thị, vì vậy sẽ rất lãng phí).

Chỉ có một câu trả lời, và đó là .. luôn luôn phát triển cao trong suốt quá trình phát triển và khi bạn hạ thấp nó xuống mức thấp nhất, điều này sẽ đưa trò chơi vào một dòng chảy ổn định. Tôi đang ngồi trên mã, và nó sẽ ở đó vì đó là cách bí mật của tôi về con rồng mã hóa. / Mắt