Tại sao các trò chơi chạy Windows tốt hơn nhiều so với OSX?


11

Ví dụ: trên Mac Mini của tôi với Bootcamp, Team Fortress 2 chạy ở tốc độ khoảng 20fps trong OSX và 80fps trong Windows. Đây dường như là một trường hợp phổ biến. Tại sao lại thế này?


Đó là cùng một máy được khởi động vào một trong hai hệ điều hành.
sans

khởi động kép như trong "không phải máy ảo" đúng không?
horatio

1
Có, khởi động trực tiếp vào hệ điều hành.
sans

1
Tôi luôn thấy những câu hỏi này rất thú vị - miễn là chúng không tập trung vào những lời tán tỉnh / rực lửa - bởi vì, với tư cách là một người dùng Mac (10 tháng), tôi nhận thấy những quan niệm sai lầm của người dùng Windows.
Ricket

Câu trả lời:


15

Trình điều khiển Direct3D trên Windows được tối ưu hóa một cách lố bịch, đôi khi cho các trò chơi cụ thể và được phát triển bởi các nhà cung cấp phần cứng riêng lẻ.

Các trình điều khiển OpenGL của Apple được Apple viết và bảo trì (AFAIK) và được dành cho sử dụng HĐH "chung", kết hợp UI và không có gì. Không có quá nhiều tối ưu hóa cho chơi game và thông lượng hiệu suất cao.

Về cơ bản, rất nhiều tài nguyên từ nhiều nguồn đã đi vào làm cho DirectX nhanh trên Windows, trong khi có ít tài nguyên hơn có sẵn để làm điều tương tự trên Mac.


Tôi đặc biệt nghiêng về trình biên dịch shader trong trình điều khiển như là một phần của sự khác biệt. altdevblogaday.com/2011/07/20/. Nói rằng đối với các trò chơi phổ biến, NV / AMD thậm chí sẽ tối ưu hóa các shader cho phần cứng của họ.
Adam

5
Không chỉ các trình điều khiển .. mà còn là các nhà phát triển trò chơi. Họ thường đầu tư nhiều tài nguyên hơn vào việc tối ưu hóa cho Direct3d / DirectX thay vì OpenGL. Một trường hợp khác là khi một trò chơi ban đầu được phát triển chỉ dành cho windows và được chuyển sau đó. Đó phải là một cổng thực sự tốt (ví dụ: có thể dẫn đến việc viết lại rất nhiều mã) nếu nó sẽ đạt được hiệu suất tương tự ... điều này chủ yếu không phải là trường hợp.
bummzack

Vậy Team Fortress 2 được hiển thị trong OpenGL trên OSX nhưng D3D trên Windows?
sans

sans, vâng, Direct3D chỉ dành cho Windows, vì vậy mọi trò chơi trên bất kỳ nền tảng nào khác đều được hiển thị bằng OpenGL (hoặc phần mềm ..). Windows cũng hỗ trợ OpenGL; nhưng hầu hết các phiên bản trò chơi Windows sẽ sử dụng Direct3D vì như đã đề cập, trình điều khiển cho Windows thường được tối ưu hóa hơn nhiều cho D3D.
Ricket

13

Mặc dù tôi sẽ không giảm giá tối ưu hóa mà Microsoft có thể đã đưa vào Windows và / hoặc DirectX, tôi tin tưởng mạnh mẽ rằng hầu hết các chương trình hoạt động tốt hơn trên Windows chỉ vì đó là những gì các nhà phát triển tập trung vào (đó là tiền). Họ đưa ra quyết định thiết kế với Windows, và sau đó cố gắng làm cho nó hoạt động trong các HĐH khác (Mac, Linux, v.v.). Tôi liên tục gặp phải vấn đề này tại nơi làm việc: các dự án khác gặp quá nhiều rắc rối với việc chuyển sang các hệ thống không phải Windows vì các nhà phát triển coi nó như một suy nghĩ sau. Tôi đã nhiều lần viết các chương trình xây dựng trên nhiều HĐH với rất ít nỗ lực vì tôi đã lên kế hoạch ngay từ đầu. Một khi bạn đã thực sự cố gắng để làm điều đó (trái ngược với việc miễn cưỡng thực hiện cổng sau thực tế), bạn tìm hiểu những gì nó cần và nó đòi hỏi rất ít nỗ lực.


Sự tò mò của một người không lập trình ở đây: Điều gì xảy ra với hiệu suất khi bạn thiết kế cho đa nền tảng? Ví dụ: trò chơi đa nền tảng của bạn có chạy nhanh trên Windows như phiên bản tập trung vào Windows không?
Jason Pineo

@Jason: Đó là nhiều hơn về thời gian sử dụng và tính cụ thể của nền tảng. Không có gì ngăn cản nhà phát triển viết mã được tối ưu hóa hoàn toàn cho Windows, viết mã riêng biệt được tối ưu hóa hoàn toàn cho OSX, sau đó chỉ chuyển đổi được sử dụng dựa trên nền tảng. Tuy nhiên, thời gian và do đó các nguồn lực dành để làm như vậy thường lớn hơn lợi ích của việc đó.
Jordaan Mylonas

@Jason: Trong trường hợp đó, nó thực sự phụ thuộc vào mức độ bạn đã thiết kế trò chơi của mình (và khi tôi nói thiết kế tôi có nghĩa là lập kế hoạch, không phải mã hóa thực tế) và mức độ khác nhau của các hệ điều hành khác nhau. Nếu chúng rất khác nhau, thì nhận xét của Jordaan là phù hợp khi bạn phải giải quyết từng hệ điều hành một cách riêng biệt. Nhưng với các giao diện phổ biến như OpenGL và các API khác nhau theo thời gian mượn các khái niệm lẫn nhau, tất cả chúng đều trở nên khá giống nhau. Vì vậy, ngày nay nó là một sự bổ sung trong việc kết hợp các tính năng và thiết kế phần mềm của bạn để có thể sử dụng từng tính năng mà không loại trừ HĐH.
Klox

7

Là một người dùng Mac đồng nghiệp, tôi muốn cung cấp một yếu tố bổ sung: bộ lập lịch CPU trong OS X "công bằng" hơn trong Windows.

Đây là một chủ đề khoa học máy tính phức tạp, vì vậy đây là một cách đơn giản để nghĩ về bộ lập lịch CPU của bạn: bộ xử lý của bạn phải xử lý nhiều tác vụ cùng một lúc (tất cả các chương trình mở của bạn, cộng với các quy trình hệ thống nền). Nó chỉ thực sự có thể thực hiện một vài việc cùng một lúc (ví dụ số lõi nhân với số luồng trên mỗi lõi; i7 lõi ​​kép có thể thực hiện 4 nhiệm vụ cùng một lúc). Vì vậy, nó chia tất cả các công việc thành từng mảnh, và xen kẽ giữa chúng để có vẻ như nó thực sự đang làm rất nhiều việc cùng một lúc. Khi bạn chạy hai chương trình, bộ xử lý thực sự chỉ xen kẽ qua lại giữa việc xử lý hai chương trình đó, rất nhanh (như, một vài micro giây ở đây, và sau đó là vài micro giây).

Mẫu mà mọi thứ được thực hiện theo thứ tự và trong bao lâu được quyết định bởi một "thuật toán lập lịch". Ví dụ, bộ lập lịch luân chuyển vòng chỉ sắp xếp các nhiệm vụ trong một vòng tròn và xử lý từng thứ tự theo thứ tự. Một người lập lịch khác có thể sắp xếp các nhiệm vụ từ ít nhất đến hầu hết thời gian còn lại - các nhiệm vụ nhỏ sẽ được thực hiện nhanh chóng và các nhiệm vụ lớn có thể phải chờ một lúc trước khi hoàn thành.

Windows và OS X rất khác nhau và thuật toán lập lịch của chúng cũng có một chút khác biệt. Windows hơi "thông minh" hơn về việc ưu tiên mọi thứ, vì vậy nó ưu tiên thêm cho các chương trình hiển thị để làm cho máy tính xuất hiện nhanh hơn. OS X, tuy nhiên, công bằng hơn với các quy trình nền. Các thuật toán tổng thể rất giống nhau giữa hai hệ điều hành (chúng đều là hàng đợi phản hồi đa cấp ), nhưng chi tiết nhỏ này dẫn đến trải nghiệm người dùng khác nhau.

Cả hai bên đều có lợi thế của họ. Giống như tôi đã nói, các chương trình hiển thị trong Windows sẽ xuất hiện nhanh hơn vì chúng được ưu tiên hơn; nhưng nếu một chương trình có thể nhìn thấy quyết định mất nhiều năng lượng, toàn bộ máy tính sẽ chịu đựng thêm một chút. Bộ lập lịch công bằng hơn của OS X dẫn đến tốc độ ổn định và dễ dự đoán hơn, rất tốt cho các hoạt động âm thanh và video. Ví dụ: nếu bạn đang phát một bài hát ở chế độ nền, nó sẽ ít bị nói lắp hơn khi bạn làm những việc khác cùng lúc so với trong Windows.

Vì vậy, điểm đáng chú ý là đây: một trò chơi toàn màn hình trong Windows sẽ được ưu tiên cao trên CPU và mọi thứ chạy trong nền sẽ chỉ phải chờ. Trong OS X, đây là trường hợp ít hơn.

Một số thông tin kỹ thuật về lịch trình được đưa ra ở đây ; phần còn lại của câu trả lời này là từ giáo dục khoa học máy tính của tôi và việc sử dụng OS X của tôi trong hơn 10 tháng qua, sau khi sử dụng Windows trong hơn 10 năm (và thỉnh thoảng là Linux). Đôi khi tôi cảm thấy thất vọng bởi người lập lịch công bằng hơn, nhưng những lần khác tôi đánh giá cao những lợi thế của nó.

Linux, nhân tiện, có một triển khai lập lịch trình thậm chí công bằng hơn; đây là những gì làm cho nó trở thành một máy chủ tuyệt vời, nhưng theo tôi thì trải nghiệm người dùng bị suy giảm. Ví dụ: khi máy tính của bạn bị sa lầy với các tác vụ, con trỏ của bạn sẽ ngừng phản hồi trơn tru vì nó được ưu tiên giống như mọi thứ khác. Điều này về cơ bản không bao giờ xảy ra trong Windows hoặc OS X.


-2

Một số trò chơi đã được "chuyển" sang MacOSX thực sự là các trò chơi Windows chạy trong trình giả lập. Mặc dù tôi không có một danh sách đầy đủ các ví dụ, có vẻ như có ít nhất SPORE giống như vậy:

SPORE chưa bao giờ được phát hành chính thức trên GNU / Linux và phiên bản Mac kém. Cổng Mac thực sự là bản phát hành Windows được đóng gói với Cider, đây là một công nghệ không dùng nữa bao gồm phiên bản WINE (nay đã cũ) xung quanh các trò chơi. ( Nguồn )

Chạy một phần mềm trong trình giả lập theo định nghĩa chậm hơn so với chạy phần mềm nguyên bản.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.