XNA và C # so với 360 của bộ xử lý theo thứ tự

Đọc xong câu nói này , tôi cảm thấy rằng họ có lẽ đúng (xem Xenon và CELL BE đều rất nhạy cảm với mã không biết phân nhánh và bộ đệm ), nhưng tôi đã nghe nói rằng mọi người cũng làm game tốt với C #.

Vì vậy, có đúng là không thể làm bất cứ điều gì chuyên nghiệp với XNA hay là poster chỉ thiếu điều gì khiến XNA trở thành API sát thủ để phát triển trò chơi?

Theo chuyên môn, tôi không có nghĩa là bạn có thể kiếm tiền từ nó, nhưng theo nghĩa là các trò chơi chuyên nghiệp hơn có các mô hình tâm lý và hệ thống hoạt hình dường như nằm ngoài tầm với của một ngôn ngữ với những rào cản rõ ràng như vậy đối với nội tại . Nếu tôi muốn viết một hệ thống va chạm hoặc động cơ chất lỏng cho trò chơi của mình, tôi không cảm thấy C # mang đến cho tôi cơ hội để làm điều đó khi trình tạo mã thời gian chạy và thiếu nội tại cản trở hiệu suất.

Tuy nhiên, nhiều người dường như vẫn làm việc tốt trong những hạn chế này, làm cho các trò chơi thành công của họ nhưng dường như tránh được bất kỳ vấn đề nào do thiếu sót. Tôi đã không nhận thấy bất kỳ trò chơi XNA nào làm bất cứ điều gì phức tạp ngoài những gì đã được các thư viện cung cấp hoặc được xử lý bởi các shader. Đây có phải là sự tránh các động lực trò chơi phức tạp hơn vì những hạn chế của C # , hay chỉ những người tập trung hoàn thành nó ?

Thành thật mà nói, tôi không thể tin rằng chiến tranh AI có thể duy trì nhiều đơn vị AI mà không có cách tiếp cận hướng dữ liệu hoặc một số hack C # bẩn để làm cho nó chạy tốt hơn so với cách tiếp cận tiêu chuẩn và tôi đoán đó cũng là một phần câu hỏi của tôi Mọi người đã hack C # để có thể làm những gì các lập trình viên trò chơi làm một cách tự nhiên với C ++?

OK, chỉ để chọc một số lỗ hổng trong câu nói mà bạn đã liên kết:

• "C # dựa vào trình thông dịch" Just in Time " - sai - đó là trình biên dịch JIT . Sau một phương thức là JITted một lần , mã được biên dịch được sử dụng lại cho mỗi lần gọi. Mã được biên dịch rất gần với mã gốc được biên dịch trước.
• "Xenon CPU là bộ xử lý" tại chỗ " - có nghĩa là" theo thứ tự "? - Và: "CPU Xenon không có dự đoán nhánh" . Ông ngụ ý những điều này có nghĩa là việc biên dịch JIT tự nhiên tạo ra mã xấu phải được CPU sắp xếp lại và gây ra nhiều phân nhánh - đó là hoàn toàn vô nghĩa . Lời khuyên hiệu năng tương tự để chạy trên kiến ​​trúc CPU này áp dụng cho cả C ++ và C #.
• "[JIT] yêu cầu xả liên tục trên 360" - sai, mã được biên dịch có thể được giữ trong bộ đệm như mọi mã được biên dịch thông thường. (Nếu anh ta có nghĩa là tuôn ra đường ống, xem điểm trên.)
• "Generics [...] sử dụng tạo mã" - Generics được JITted như mọi thứ khác và, giống như mọi thứ khác, mã JITted rất nhanh. Không có hình phạt hiệu suất cho việc sử dụng thuốc generic.
• "Tất cả các bit gợi cảm của ngôn ngữ [...] đều yêu cầu dự đoán nhánh ..." - làm thế nào điều này cũng không áp dụng cho C ++? - "... hoặc [...] tạo mã tại chỗ" - ý anh ấy là JITting? Tôi đã đề cập rằng nó nhanh? (Tôi sẽ không đi vào tất cả những nơi mà CLR máy tính để bàn sử dụng thực tế tạo mã - một tính năng không được Xbox 360 hỗ trợ!)
• "[C # không có] các thư viện đồ sộ [của C ++]" - ngoại trừ, chính XNA? Và nhiều hơn nữa . (Tuy nhiên, đây là một điểm khá công bằng.)

XNA trên Xbox 360 chạy trên phiên bản sửa đổi của .NET Compact Framework CLR. Tôi chắc chắn rằng nó không theo tiêu chuẩn của phiên bản máy tính để bàn. JITter có thể không tốt như vậy - nhưng tôi cũng không nghĩ nó tệ . Tôi ngạc nhiên, ông không đề cập đến thu gom rác mà là khủng khiếp so với CLR desktop.

(Dĩ nhiên - bạn không nên nhấn thu gom rác trong một trò chơi chuyên nghiệp phát triển nào , cũng giống như bạn phải cẩn thận với phân bổ trong bất kỳ trò chơi chuyên nghiệp.)

(Đối với thảo luận kỹ thuật thực tế về .NET Compact Framework, có lẽ bắt đầu với loạt bài viết này: Tổng quan , Trình biên dịch JIT và GC và heap .)

Cách anh ta hoàn toàn không đặc biệt về thuật ngữ của anh ta khiến cho việc hiểu ý anh ta là gì. Hoặc là anh ta đang ở chế độ giận dữ tối đa, hoặc không biết anh ta đang nói về cái gì.

Bây giờ chúng ta đã có điều đó ra khỏi con đường, đây là một số điều mà bạn làm bỏ lỡ bằng cách sử dụng XNA trên 360, thay vì đi mẹ đẻ :

• Truy cập vào đơn vị SIMD / Vector để thực hiện các phép toán dấu phẩy động CPU thực sự rất nhanh
• Khả năng sử dụng mã ngôn ngữ bản địa có thể sẽ nhanh hơn một chút so với C #
• Khả năng trở thành một chút chút lazier với cách bạn phân bổ bộ nhớ
• Các trò chơi XBLIG chỉ có quyền truy cập vào 4 trong số 6 lõi (nhưng chúng tôi vẫn có cả 3 CPU và chúng cũng không phải là lõi đầy đủ, vì vậy chúng tôi không bỏ lỡ nhiều) - không chắc điều này có áp dụng cho XNA không phải XBLIG không Trò chơi
• Truy cập DirectX đầy đủ để thực hiện thủ thuật đồ họa thực sự tối nghĩa

Cũng đáng chỉ ra rằng đây chỉ là những hạn chế về phía CPU. Bạn vẫn có quyền truy cập hoàn toàn miễn phí khi chạy trên GPU.

Tôi đã mô tả những điều này trong câu trả lời này cho câu hỏi tương tự như câu hỏi này. Như tôi đã đề cập trong câu trả lời đó, XNA hoàn toàn phù hợp để phát triển "chuyên nghiệp" .

Lý do duy nhất bạn tránh là vì bạn không thể thuê nhân tài C #, cấp phép cho công cụ C # và sử dụng lại mã C # hiện tại giống như cách bạn có thể với kiến ​​thức C ++ hiện có. Hoặc bởi vì bạn cũng có thể nhắm mục tiêu một nền tảng không hỗ trợ C #.

Tất nhiên, đối với nhiều người trong số chúng tôi không phải là nhà phát triển "chuyên nghiệp", XNA là lựa chọn duy nhất của chúng tôi để có được trên Xbox 360, tạo ra điểm nhấn.

Để trả lời các câu hỏi khác của bạn:

Không có gì trong C # dừng bạn sử dụng cách tiếp cận dữ liệu theo định hướng cơ bản chính xác giống như cách bạn muốn sử dụng chúng trong C ++.

C # thiếu khả năng tự động mã nội tuyến tại thời gian biên dịch và (không cần tắt để kiểm tra) Tôi khá chắc chắn rằng JITter nhỏ gọn của CLR không thể phương thức nội tuyến (CLR trên máy tính để bàn). Vì vậy, đối với mã quan trọng về hiệu năng, bạn có thể phải nội tuyến theo cách thủ công trong C #, trong đó C ++ cung cấp một số trợ giúp.

Có lẽ là một lý do lớn hơn tại sao bạn không thường thấy những thứ chuyên sâu về toán học CPU như phát hiện va chạm và mô phỏng chất lỏng trong C # là thiếu quyền truy cập vào đơn vị vectơ (như đã đề cập ở trên).

Bạn sẽ phải xác định 'chuyên nghiệp'. Bạn có thể làm Angry Birds, Plants vs Zombies, v.v.? Chắc chắn rồi. Bạn có thể làm Crysis 2, COD, Halo? Tôi nghi ngờ điều đó. Sử dụng C # chỉ thực sự sẽ tác động đến các trò chơi rất tốn CPU và cũng cần phải nén từng byte bộ nhớ cuối cùng (bạn mất bộ sưu tập rác), vì vậy bạn vẫn có thể làm được rất nhiều điều.

Là một công cụ học tập cho mọi người bắt đầu, công cụ tạo mẫu, nền tảng để viết các trò chơi có thể giải quyết sự đánh đổi, v.v., thật tuyệt vời và có nhiều sức mạnh và đơn giản, nó không được thiết kế để tạo ra những gì bạn nhất thiết phải gọi các trò chơi 'AAA'. Nó cũng lấy đi rất nhiều nỗi đau và sự đau khổ mà mọi người phải lo lắng với khả năng tương thích và chuyển đổi đa nền tảng.

Nếu bạn nghĩ ra một trò chơi tuyệt vời và bạn gặp phải những hạn chế của những gì bạn có thể làm với XNA thì tôi khuyên bạn nên liên hệ trực tiếp với MS, nếu ý tưởng đó thực sự đủ tốt, họ có thể giúp bạn phát triển toàn diện bộ dụng cụ.

Một thực tế đơn giản là bạn không cần số lượng đa giác cao, ánh sáng HDR đầy đủ hoặc vật lý thú vị nhất thế giới để tạo ra một trò chơi thú vị và nếu kế hoạch trò chơi của bạn không bao gồm bất kỳ trong số đó, thì tại sao không đi nhanh hơn Giải pháp thời gian phát triển?

trò chơi chuyên nghiệp hơn có mô hình tâm lý và hệ thống hoạt hình

Thật tồi tệ. Trò chơi chuyên nghiệp có những gì họ cần phải thực hiện lối chơi của họ và đạt được cái nhìn nghệ thuật của họ, và không có gì hơn và thực sự, không có gì hơn. Một trò chơi không chuyên nghiệp hơn vì nó trông thực tế hơn hoặc có vật lý chi tiết hơn. Một trò chơi chuyên nghiệp đạt được mục tiêu về trò chơi và hình ảnh, đúng thời gian, ngân sách, v.v., và vận chuyển và kiếm lợi nhuận.