Việc mở khóa tốc độ khung hình trong XNA / MonoGame sẽ cho tôi biết mã của tôi hiệu quả đến mức nào?

12

Tôi đã được mở khóa tốc độ khung hình trong MonoGame thông qua:

this.graphics.SynchronizeWithVerticalRetrace = false;
base.IsFixedTimeStep = false;

Và sử dụng nó làm cơ sở cho việc tôi cập nhật và vẽ hiệu quả trong trò chơi như thế nào.

Ở độ phân giải 240 x 160 mà không có gì được vẽ hoặc cập nhật ngoại trừ bộ đếm khung hình, tôi nhận được giá trị FPS từ 9.000 đến 11.000 FPS.

Nếu tôi thêm tất cả mã của mình trở lại, nó sẽ giảm xuống còn khoảng 1.100 FPS.

Đây có phải là một dấu hiệu tốt cho thấy mã của tôi đang làm chậm đáng kể GPU (10 lần) và tôi có nên lo lắng không? Trò chơi sẽ chạy ở tốc độ 60 FPS vì vậy tôi vẫn còn khá xa, nhưng tôi nên quan tâm đến điểm nào trong tốc độ khung hình được mở khóa?

GPU: AMD FirePro W5000 (FireGL V)

monogame frame-rate

— kiểm tra
nguồn

1

Như một lưu ý phụ: Trong lộ trình phát triển của bạn, tôi sẽ đề nghị bạn giữ FPS mục tiêu của mình trong việc gỡ lỗi cũng như phát hành; một cái gì đó có thể chạy tốt trong bản phát hành nhưng có thể chậm như địa ngục trong gỡ lỗi, điều này thực sự không hữu ích :)

— Vaillancourt

Không hẳn vậy. Các câu trả lời khác trả lời tốt điều này, nhưng điểm chính là hầu hết các công việc nặng sẽ được thực hiện bởi card đồ họa của bạn bằng cách sử dụng tăng tốc phần cứng. Trừ khi bạn đang làm việc trong cùng một luồng với đồ họa (bạn không nên), thì không có lý do gì để FPS bị ảnh hưởng bởi mã của bạn - hoàn toàn là lý do -

— Dan Pantry

30

Chỉ thô lỗ.

Đầu tiên, FPS không phải là thước đo tuyến tính . Sự khác biệt giữa 11k FPS và 9k là cực kỳ nhỏ (0,0000201 giây mỗi khung hình). Nhưng sự khác biệt giữa 60 và 2060 FPS (đồng bằng 2k FPS, tương tự tồn tại giữa 11k và 9k) là 0,0161 giây ... lớn hơn nhiều. Do đó, nó có thể nguy hiểm như một chỉ số hiệu suất đơn giản vì sự khác biệt lớn có thể hoặc không tệ đến thế.

Thay vào đó, sử dụng thời gian trên mỗi khung hình sẽ dễ dàng hơn một chút, nhưng ngay cả khi đó nó vẫn là một cái nhìn rất rộng về tình huống. Nó chỉ cho bạn biết bao nhiêu giây một khung hình của trò chơi. Nó không cho bạn biết lý do tại sao , trừ khi bạn nhìn vào sự gia tăng lớn về thời gian khung hình ngay sau khi thêm hoặc bật một tính năng cụ thể.

Nó có thể là một phong vũ biểu cơ bản để quyết định đã đến lúc phải làm hồ sơ chuyên sâu hơn. Thật tệ khi sử dụng FPS để xác định xem bạn có bị ràng buộc bởi CPU hay GPU hay không; Cấu hình GPU không dễ dàng như đo thời gian trên CPU (đó là nơi có thể mã thời gian và mã tính toán FPS của bạn).

Về thời điểm bạn nên quan tâm ... tốt, bạn đã tự nói rằng trò chơi đã nhắm mục tiêu 60 FPS. Nếu bạn bắt đầu ngâm gần hoặc dưới mức đó, thì có lẽ bạn cần bắt đầu suy nghĩ kỹ hơn về các vấn đề hiệu suất của mình. Cho đến lúc đó, tôi tập trung vào làm mọi thứ hoạt động và sau đó lo lắng về việc làm cho nó nhanh .

6

+1 cho câu cuối cùng. Tối ưu hóa hiệu suất sớm là, theo tôi, là một thực tế khá tệ (nói từ kinh nghiệm).

— sirdank

1

c2.com/cgi/wiki?PrematureOptimization - Đề nghị đọc về chủ đề

— Machinarius

Không phải lúc nào, nếu bạn có một máy cao cấp và nó đạt khoảng 80 FPS, thì nó sẽ đủ tốt trên máy của bạn, nhưng nếu bạn muốn nhắm mục tiêu vào các máy tính cấp thấp hơn, họ có thể chỉ nhận được 15 FPS, lý tưởng nhất là tốt nhất để thực hiện thử nghiệm của bạn trên một máy có thông số kỹ thuật tối thiểu bạn muốn nhắm mục tiêu, nhưng không thành công, việc tối ưu hóa nó cho máy của bạn cũng có thể tối ưu hóa nó cho máy của họ. Tất nhiên, nếu nó chạy đủ nhanh trên các máy cấp thấp của bạn, thì không có lý do gì để bỏ thêm công sức để tối ưu hóa hơn nữa, đặc biệt là có nguy cơ lỗi tăng lên.

— Chương trình

5

Tôi không thấy lý do tại sao bạn không thể sử dụng nó! Hãy nhớ rằng bạn có thể phải viết mã khác nhau để tính đến sự khác biệt giữa dấu thời gian cố định / biến đổi, vì vậy nếu bạn dự định làm cho nó cố định khi bạn phát hành, bạn sẽ cần phải điều chỉnh. Xem bài viết này: http://rbwhitaker.wikidot.com/time-steps

Đây có phải là một dấu hiệu tốt cho thấy mã của tôi đang làm chậm đáng kể GPU

Có thể là CPU là tốt. Tôi khuyên bạn nên chạy định kỳ trình biên dịch tích hợp của Visual Studio (hoặc bất cứ khi nào bạn thấy một tốc độ khung hình lớn) để tìm các điểm nóng trong mã của bạn.

Tôi có nên quan tâm không?

Điều đó rõ ràng phụ thuộc vào phần cứng bạn đang nhắm mục tiêu. Bạn sẽ cần kiểm tra mã của mình với các máy yêu cầu tối thiểu thấp nhất mà bạn sẵn sàng hỗ trợ. Nếu nó chạy ít nhất 60 ở đó, thì tôi sẽ không quá lo lắng.

— tandersen
nguồn