Hiệu suất trò chơi XNA

Question

Tôi đang viết một trò chơi bằng C# 2010 và XNA 4.0. Tôi muốn nó trở thành một trò chơi hay và không phải là một thứ "chỉ là một crap" và vì vậy một trong những mục tiêu của tôi là tốc độ khung hình tốt. Đối với điều này tôi muốn hỏi bạn một số lời khuyên, có thể là XNA liên quan hoặc C# liên quan - những gì tôi có thể làm để tăng tốc độ mã của tôi và do đó cải thiện FPS.

Dưới đây là một số nội dung tôi phát hiện ra:

• (C#) sử dụng array insted của list<> sẽ cải thiện hiệu suất rất nhiều, trong trường hợp bạn muốn truy cập số lượng lớn dữ liệu (hoặc thậm chí rất nhiều: có một mảng 20.000 mặt hàng đã gần như 180% FPS của danh sách 20000.
• (C#) sử dụng for thay vì foreach sẽ cải thiện hiệu suất. Vào cùng 20000 yếu tố nó giống như 5-10% sự khác biệt.
• (XNA và C#) phương pháp gọi hiệu suất chi phí, vì vậy khi tôi phân đoạn mã của tôi thành meth ods những gì được gọi là phương pháp khác và như vậy, và tất cả mọi thứ đã được như vậy mát mẻ và đối tượng theo định hướng nó đã được trên chi phí 1-3 FPS mỗi cuộc gọi.
• (xna) cập nhật so với vẽ: không có sự khác biệt về hiệu suất khi tôi đặt mã vào bản cập nhật() và vẽ(), vì vậy nếu bạn không quan tâm nhiều, bạn không phải đặt một số phương thức đang cập nhật() thay vì giữ tất cả mọi thứ với nhau trong draw() với hy vọng FPS tốt hơn.
• (xna) không có ý tưởng nếu đó là tôi hoặc chỉ 4.0, nhưng khi bạn tải một .X với rất nhiều kết cấu trong nó và khá phức tạp mắt lưới, phải mất rất nhiều thời gian để tải. Tôi đã phải viết trình nạp .X của riêng tôi và trình kết xuất lưới/mô hình chỉ vì XNA bắt đầu tải kết cấu cho mỗi và mỗi tam giác bất kể kết quả trước đó có cùng kết cấu với nó hay không. Ngay cả khi viết trình tải nội dung của riêng tôi mà lưu trữ kết cấu cho bạn là không có giải pháp, bởi vì nó vẫn được sử dụng rất nhiều lần. Nếu bạn làm một cái gì đó tốt đẹp và mịn, tôi đề nghị sử dụng drawuserprimitives và không phải Model lớp học. (không có ý tưởng nếu nó là 4.0 chỉ, hoặc 3.1 có vấn đề hiệu suất như vậy quá)
• (xna và C#) Cố gắng tránh sử dụng "mới" khi nó là về bản vẽ. Tôi thấy một số mã xung quanh trên web, những gì đã được sao chép/dán lại với nhau và đã có "basicEffect = new BasicEffect (graphicsDevice);" và sự xấu xí như vậy trong bản vẽ() và thậm chí tệ hơn: trong các lần lặp bên trong draw(). Như vậy sẽ giết hiệu suất. Thay vì điều này có một lớp như vậy trong "trò chơi" hoặc trong một lớp tĩnh. Điều này cũng áp dụng cho các "temp-objects" khác: xấu xí nhưng tôi nghĩ tốt hơn là tạo ra một cái gì đó toàn cầu và sử dụng nó với sự chú ý sau đó để tạo ra một mã đẹp và mượt mà sẽ làm cho trò chơi của chúng ta vì bộ thu gom rác.

Ok, vậy để làm cho câu chuyện dài ngắn, xin vui lòng gửi một số lời khuyên tốt ở đây, vì vậy tôi/chúng tôi có thể làm cho trò chơi tốt, nhanh chóng và tối ưu hóa;)

Cảm ơn trước: Zéiksz

Answer 1

UberGeekGames có một bài viết hay về tối ưu hóa XNA. Nó chủ yếu nhắm vào Xbox và WP7, nhưng nhiều thứ cũng áp dụng cho PC.

http://www.sgtconker.com/2011/05/high-end-performance-optimizations-on-the-xbox-360-and-windows-phone-7/

trang web gốc đã chết, nhưng là có sẵn trong Internet Archive:

Archived version of High end performance optimizations on the xbox 360 and windows phone7

Nguyên tắc hàng đầu là "hồ sơ trước khi tối ưu hóa".

Answer 2

Tối ưu hóa phần mềm là một nghề thủ công. Các loại tối ưu hóa tốt nhất là bằng chứng dựa trên số liệu thống kê được thu thập.

Cho đến khi bạn gặp sự cố không tối ưu hóa. Bạn không nghĩ rằng chơi trò chơi là quan trọng hơn số liệu này hay số liệu khác? Đề nghị của tôi là làm cho trò chơi đầu tiên và sau đó xem xét nơi nó không thực hiện như bạn muốn.

Sau đó đăng một số câu hỏi cụ thể và tôi chắc chắn bạn sẽ nhận được một số trợ giúp ở đây về các vấn đề cụ thể.

Đồng thời, tôi khuyên bạn nên nhận thêm thông tin từ sách phát triển trò chơi như những sách được liệt kê tại đây: http://forums.create.msdn.com/forums/p/8642/45646.aspx.

XNA Extereme 101 - có vẻ là một hướng dẫn thú vị

Answer 3

My 2 cents có giá trị:

Đừng đặt tất cả các mã của bạn trong một phương pháp bởi vì bạn nghĩ rằng chi phí để gọi một phương thức. Nếu bạn nghĩ rằng bạn mất 1-3 FPS bằng cách gọi một phương thức trống, có lẽ bạn chưa hoàn thành việc nghiên cứu mất 1-3. Đối với sự mất mát đó là đúng trong một cuộc gọi phương thức trống, bạn sẽ phải có một FrameRate trong hàng ngàn MANY .... nơi bạn sẽ không quan tâm đến bản thân mình về một giọt 1-3.

FPS là cách tồi để đánh giá hiệu suất trong XNA. Khi bạn đã bật bước thời gian thay đổi, các quy trình khác mà hệ điều hành có liên quan có thể ảnh hưởng đến tốc độ khung hình của bạn. Bạn thực sự cần phải hồ sơ để thay thế. Chỉ cần tập trung vào lượng thời gian thực sự cần để hoàn thành Cập nhật &/hoặc Phương thức Vẽ bằng cách định thời chúng với đối tượng System.Diagnostic.Stopwatch. thời gian chúng riêng lẻ, không cùng nhau (rất quan trọng).

Từ khóa 'mới' không chỉ nên tránh trong cuộc gọi vẽ mà ở bất kỳ đâu trong cả bản cập nhật & ... chỉ dành cho các loại tham chiếu. Sử dụng từ khóa mới bất cứ lúc nào và bất cứ nơi nào bạn cần với các loại giá trị.