Чому ігри працюють набагато краще в Windows, ніж в OSX?


11

Наприклад, на моєму Mac Mini з Bootcamp команда Team Fortress 2 працює з швидкістю 20 кадрів в секунду в OSX і 80 кадрів в секунду в Windows. Здається, це звичайний випадок. Чому це?


Це одна і та ж машина, подвійна завантажена в будь-яку операційну систему.
sans

подвійний завантажений як у "не віртуальній машині" правильно?
horatio

1
Так, завантаження безпосередньо в будь-яку ОС.
sans

1
Я завжди вважаю ці питання цікавими - до тих пір, поки вони не перетворюються на безглузді виклики / горіння - тому що, як користувач Mac (10 місяців), я можу побачити помилкові уявлення користувачів Windows.
Ricket

Відповіді:


15

Драйвери Direct3D в Windows смішно оптимізовані, іноді під конкретні ігри, і розробляються окремими постачальниками обладнання.

Драйвери OpenGL від Apple написані та підтримуються (AFAIK) Apple, і призначені для "загального" використання ОС, складання інтерфейсу користувача та іншого. Не так багато оптимізації для ігор та високопродуктивної пропускної здатності.

В основному, багато ресурсів з багатьох джерел пішло на те, щоб зробити DirectX швидким у Windows, тоді як набагато менше ресурсів доступно для того, щоб зробити те ж саме на Mac.


Я би схилявся ще конкретніше до компілятора шейдерів у драйвері, як частину різниці. altdevblogaday.com/2011/07/20/… говорить, що для популярних ігор NV / AMD навіть вручну оптимізує шейдери для свого обладнання.
Адам

5
Це не тільки драйвери .. це ще й розробники ігор. Зазвичай вони вкладають більше ресурсів в оптимізацію для Direct3d / DirectX замість OpenGL. Інший випадок, коли гра спочатку була розроблена саме для Windows і отримала її перенесення згодом. Це має бути справді хорошим портом (наприклад, це може призвести до перезапису коду), якщо він повинен досягти подібних показників ... що, як правило, не так.
bummzack

Отже Team Fortress 2 відображається в OpenGL на OSX, але D3D в Windows?
sans

sans, так, Direct3D призначений лише для Windows, тому будь-яка гра на будь-якій іншій платформі відображається за допомогою OpenGL (або програмного забезпечення ..). Windows також підтримує OpenGL; але більшість версій ігор Windows використовуватиме Direct3D, оскільки, як було сказано, драйвери для Windows, як правило, значно оптимізовані для D3D.
Ricket

13

Хоча я не знижую оптимізацію, яку Майкрософт може вкласти в Windows та / або DirectX, я твердо вірю, що більшість програм краще працює в Windows, просто тому, що розробники зосереджуються саме на цьому (саме там і гроші). Вони приймають дизайнерські рішення, маючи на увазі Windows, а потім намагаються змусити його працювати в інших ОС (Mac, Linux тощо). Я постійно стикаюся з цим на роботі: інші проекти мають стільки проблем з переносом на системи, які не є Windows, тому що розробники розглядали це як задум. Я неодноразово писав програми, які будують на декількох ОС з дуже невеликими зусиллями, тому що я планував це таким чином з самого початку. Після того, як ви дійсно спробували це зробити (на відміну від того, що прикро роблять порт після факту), ви дізнаєтесь, що потрібно, і це вимагає зовсім небагато додаткових зусиль.


Цікавість некодера тут: Що відбувається з продуктивністю, коли ви розробляєте багатоплатформну форму? Наприклад, чи буде ваша багатоплатформна гра працювати так швидко в Windows, як і у Windows-орієнтованій версії?
Джейсон Пінео

@Jason: Це більше про витрачений час та специфіку платформи. Ніщо не зупиняє розробника від написання коду, повністю оптимізованого для Windows, написання окремого коду, повністю оптимізованого для OSX, а потім просто перемикання, яке використовується на базі платформи. Однак час і, таким чином, ресурси, витрачені на це, часто переважають користь від цього.
Jordaan Mylonas

@Jason: У цьому випадку, це дійсно залежить від того, наскільки добре ви створили свою гру (а коли я кажу дизайн, я маю на увазі планування, а не власне кодування) та наскільки розбіжні різні ОС. Якщо вони сильно різняться, то коментар Йордана підходить там, де потрібно окремо звертатися до кожної ОС. Але при поширених інтерфейсах, таких як OpenGL, і з часом різні API запозичують поняття один у одного, всі вони стали досить схожими. Тож сьогодні це більше вправа у відповідності функцій та розробці програмного забезпечення, щоб мати можливість використовувати кожну з функцій, не виключаючи ОС.
Klox

7

Як інший користувач Mac, я хотів би запропонувати додатковий фактор: планувальник процесора в OS X більш "справедливий", ніж в Windows.

Це свого роду складна тема інформатики, тому ось простий спосіб продумати планувальник процесора: ваш процесор повинен перемикати багато завдань одночасно (усі ваші відкриті програми, а також фонові системні процеси). Він може насправді робити відразу декілька речей (наприклад, кількість ядер, кількість разів на кількість ядер; двоядерний i7 може робити 4 завдання одночасно). Тож вона розбиває всю роботу на частини і чергує їх, так що схоже, що насправді робить багато справ одночасно. Коли ви запускаєте дві програми, процесор насправді просто чергує обробку цих двох програм, дуже швидко (наприклад, кілька мікросекунд тут, а потім кілька мікросекунд там).

Шаблон, для якого речі виконуються в якому порядку і протягом якого часу, визначається "алгоритмом планування". Наприклад, планувальник круглих роботів просто упорядковує завдання по колу і обробляє кожне по порядку. Інший планувальник може організувати завдання, як мінімум, до останнього часу - невеликі завдання будуть виконані швидко, а для великих завдань, можливо, доведеться почекати деякий час, перш ніж вони будуть виконані.

Windows і OS X дуже різні, і їх алгоритми планування дещо відрізняються також. Windows трохи «розумніший» щодо розстановки пріоритетів, тому він надає додатковий пріоритет видимим програмам для того, щоб комп'ютер виглядав швидше. ОС X, однак, більш справедлива до фонових процесів. Загальні алгоритми майже однакові між двома операційними системами (вони обидва багаторівневі черги зворотного зв’язку ), але ця невелика деталь призводить до різного користувальницького досвіду.

Обидві сторони мають свої переваги. Як я вже сказав, видимі програми в Windows з’являться швидше, оскільки вони отримують більший пріоритет; але якщо одна видима програма вирішує зайняти багато енергії, весь комп'ютер страждає трохи більше. Більш справедливий планувальник OS X призводить до більш передбачуваних та стабільних швидкостей, що добре для аудіо та відео операцій. Наприклад, якщо ви граєте пісню у фоновому режимі, менше шансів заїкатись, коли ви робите інші речі одночасно, ніж у Windows.

Отож, точка вибору полягає в цьому: гра в повноекранному режимі в Windows має високий пріоритет на процесорі, і все, що працює у фоновому режимі, доведеться просто почекати. У OS X це менше.

Тут наведена деяка технічна інформація про планувальників ; решта цієї відповіді - від моєї освіти з інформатики та мого використання OS X протягом останніх 10 місяців, після використання Windows протягом 10 років (і Linux періодично). Мене іноді засмучує більш справедливий планувальник, але в інших випадках я ціную його переваги.

Linux, до речі, має ще більш справедливу реалізацію планувальника; це те, що робить його чудовим сервером, але, на мою думку, користувацький досвід погіршується. Наприклад, коли ваш комп’ютер завалений завданнями, ваш курсор перестане плавно реагувати, оскільки йому надається такий же пріоритет, як і всім іншим. Це в основному ніколи не відбувається в Windows або OS X.


-2

Деякі ігри, «перенесені» на MacOSX, є насправді іграми Windows, що працюють в емуляторі. Хоча у мене немає повного списку прикладів, здається, що існує принаймні SPORE, який був таким:

SPORE ніколи не був офіційно випущений на GNU / Linux, а версія Mac погано старіла. Порт Mac - це фактично випуск Windows, упакований із Cider, який є амортизованою технологією, що обертає (тепер уже стару) версію WINE навколо ігор. ( Джерело )

Запуск програмного забезпечення в емуляторі, за визначенням, повільніше, ніж його запуск на власному рівні.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.