Здравствуйте, LuciferSingapore, Вы писали:

LS>так же как и на винде, каждая игра требует установленный стим и пока в стиме не залогинишься, ничего работать не будет

У меня дьябла без всякого стима работает И я сильно сомневаюсь, что близы когда-нибудь ее или ВОВ добавят в стим.
Стим, хоть и стремится стать стандартом, но во многом у него это не получается (а с 8-кой и ее маркетом может и вообще коньки отбросить), в лялихе же, с его зоопарком, шансов на подобное еще меньше.

Здравствуйте, Sheridan, Вы писали:

S>id тоже сотрудничала? у меня гдето тут от 7го года еще валяется тестирования ку3 под виндами и под линухом. Те же пооему 16%

Ку3 уже все, ее, или дрова под нее, никто в здравом уме оптимизировать не будет, железо давно покрывает все необходимые FPS. Показательны только тесты на чем-то свежем, под современные видеокарты, хотя и это спорно. Если игра выдает 200-250 кадров, то пилить ее дальше никому, кроме энтузиастов-перфекционистов, не надо.

Здравствуйте, Jesmus, Вы писали:

ЛЧ>>303 VS 315 frames per second(я правильно расшифровал?) — а какая разница для глаза человека с ~30 fps?

J>Для данной конкретной игры, с данной конкретной графикой — никакой. Собственно потому я и предположил, что на виндовс с определенного момента оптимизацией графики прекратили заниматься. А так глядишь еще что в драйверах под виндовс подправили тоже

Для любой игры 300+ кадров разницы никакой. Скорее даже 200+ разницу не заметить.

LS>Left4dead2 на windows7 x64 дает 270 fps.
LS>На линуксе (Ubuntu 12.04 32-bit) после начального порта было 6 fps, после оптимизаций получили 315.
Несомненно, это решающий фактор. На 270 фпс же не видно ни че ж.

Здравствуйте, Muxa, Вы писали:

LS>>На линуксе (Ubuntu 12.04 32-bit) после начального порта было 6 fps, после оптимизаций получили 315.
M>Несомненно, это решающий фактор. На 270 фпс же не видно ни че ж.
А на 2560x1920 это будет уже 60 против 50 fps. Уже заметно.

В более графически требовательных играх — аналогично.

LS>>>На линуксе (Ubuntu 12.04 32-bit) после начального порта было 6 fps, после оптимизаций получили 315.
M>>Несомненно, это решающий фактор. На 270 фпс же не видно ни че ж.
C>А на 2560x1920 это будет уже 60 против 50 fps.
не факт

Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, mrTwister, Вы писали:

T>>Я бы сказал, что это выглядит, как будто у автора статьи проблемы с логикой. Если я напишу программу на C++, портирую её на C# и она на C# заработает быстрее, значит ли это, что C# быстрее С++? Нет, не значит.

N>Аналогия неверная.
верная.

N>Многое зависит от ОС и от драйверов под эту ОС.
значительно больше зависимость от кривизны рук портирующего.

Здравствуйте, Философ, Вы писали:

N>>Аналогия неверная.
Ф>верная.

Демагогия. Как раз результаты в цифрах говорят за то, что одинаковая OpenGL версия работает быстрее на Линуксе.

N>>Многое зависит от ОС и от драйверов под эту ОС.
Ф>значительно больше зависимость от кривизны рук портирующего.

Это не отменяет фактов.

Здравствуйте, Muxa, Вы писали:

LS>>>>На линуксе (Ubuntu 12.04 32-bit) после начального порта было 6 fps, после оптимизаций получили 315.
M>>>Несомненно, это решающий фактор. На 270 фпс же не видно ни че ж.
C>>А на 2560x1920 это будет уже 60 против 50 fps.
M>не факт
Цифры реальные

Здравствуйте, alpha21264, Вы писали:

A>А вообще, че бы не делать Лайв-СД для игрушки?
A>Чтобы пофигу на ОС.

Из-за дров. ОС представляет из себя среду для взаимодействия железа и софта, с неким более-мене универсальным АПИ для стороннего софта.

Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, Философ, Вы писали:

N>>>Аналогия неверная.
Ф>>верная.

N>Демагогия. Как раз результаты в цифрах говорят за то, что одинаковая OpenGL версия работает быстрее на Линуксе.

N>>>Многое зависит от ОС и от драйверов под эту ОС.
Ф>>значительно больше зависимость от кривизны рук портирующего.

N>Это не отменяет фактов.
Из фактов можно разные выводы делать.

"кривизна рук" здесь null

"кривизна рук" & что угодно --> null
т.е. никаких выводов здесь сделать нельзя

Здравствуйте, Философ, Вы писали:

N>>Это не отменяет фактов.
Ф>Из фактов можно разные выводы делать.

Ф>"кривизна рук" здесь null

Ф>"кривизна рук" & что угодно --> null
Ф>т.е. никаких выводов здесь сделать нельзя

Ничего не понял. Аргументируй, пожалуйста, на русском литературном.
Ещё раз повторю: одна и та же версия игры (на OpenGL) на Линуксе работает быстрей, чем на Винде. Вывод вполне однозначный: проблема в дровах под Винду или в архитектуре самой ОС. О какой кривизне рук говоришь ты?

Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, Философ, Вы писали:

N>>>Это не отменяет фактов.
Ф>>Из фактов можно разные выводы делать.

Ф>>"кривизна рук" здесь null

Ф>>"кривизна рук" & что угодно --> null
Ф>>т.е. никаких выводов здесь сделать нельзя

N>Ничего не понял. Аргументируй, пожалуйста, на русском литературном.
N>Ещё раз повторю: одна и та же версия игры (на OpenGL) на Линуксе работает быстрей, чем на Винде. Вывод вполне однозначный: проблема в дровах под Винду или в архитектуре самой ОС. О какой кривизне рук говоришь ты?

о кривизне рук людей, которые писали то, что находится между #ifdef и #endif

Достаточно взглянуть на сорцы кваки, чтобы понять, что код, после препроцессора будет немного разный.
Некорректно говорить об одной и той же софтине, "портирование" будет в любом случае.
всего 2 примера только из одного файла:

	Скрытый текст
	00211 #ifdef WIN32 00212 #include <process.h> 00213 #else 00214 #define _P_WAIT 0 00215 extern int fork(void); 00633 #ifdef linux 00634 case 's': 00635 if (strcmp(arg,"-static") == 0) { 00636 if (!option(arg)) 00637 fprintf(stderr, "%s: %s ignored\n", progname, arg); 00638 return; 00639 } 00640 #endif

так как кривизна портирования мне неизвестна (обозначу её для краткости Q3), можно записать: Q3 = null;
соотвественно кривизну линукса объединю с кривизной драйверов и обозначу L.

конечная кривизна (QL) выводится из этих двух исходных, и получается неизвестной практически при любых действиях:

Q3 = null;
QL = func(Q3, L)
----------
=> QL = null