Everquest 2

[Эрбиан]

Ты очень упрощаешь. Хотя и на таком уровне оптимизация имеет место быть. Тот же полигон или даже линию можно отрисовать сотней разных алгоритмов отличающихся производительностью в десятки раз. И сильно сомневаюсь, что виндовые библиотеки предлагают наилучший. Соответственно просто заменив стандартную функцию своей ты можешь в разы ускорить движок. Просто? Но будь уверен этого никто не делает.

Если рассматривать более сложные вещи - такие как структуры хранения данных или алгоритмы освещения и т.п., то их можно оптимизировать бесконечно. Реально бесконечно. Вопрос в том сколько это будет стоить для компании разработчика.

[rain]

я же не говорю что это плохо? вон например в Guildwars движок песня.
ток пока ты напишешь таким методом движок, другой напишет 2. на его основе напишут несколько игрушек и снимут бабла соответственно в 2 раза больше.

это для конечных пользователей игрушка - способ поиметь кайф. а для разработчика способ поиметь пользователя в смысле денег с него.

[Эрбиан]

Угу об том и речь. Никакой культуры. Лишь бы поиметь друг друга и бабла срубить

[Buba]

Парни а в eq2-то играть будем?

[Эрбиан]

А это как в том баяне про проститутку и холодильник.

При чем тут ваще Eq? =))

[Субутар]

Сообщение от Эрбиан

Ты очень упрощаешь. Хотя и на таком уровне оптимизация имеет место быть. Тот же полигон или даже линию можно отрисовать сотней разных алгоритмов отличающихся производительностью в десятки раз. И сильно сомневаюсь, что виндовые библиотеки предлагают наилучший. Соответственно просто заменив стандартную функцию своей ты можешь в разы ускорить движок. Просто? Но будь уверен этого никто не делает.

Если рассматривать более сложные вещи - такие как структуры хранения данных или алгоритмы освещения и т.п., то их можно оптимизировать бесконечно. Реально бесконечно. Вопрос в том сколько это будет стоить для компании разработчика.

В отличие от тебя я эти алгоритмы знаю, также как и подлежащую под ними математику.

Что что-то можно оптимизировать бесконечно говорят только люди которые этим сами никогда не занимались. Заниматься оптимизацией можно бесконечно, вот только на каждом шаге прибавки к производительности будут все меньше.

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

[Эрбиан]

Спорить мне об алгоритмах просто не в кайф, поэтому будем считать что ты прав *зачеркнуто. А ваще чегоб не поспорить, за тем на форум и пришел.

Я действительно давно не практиковал. Но в глубокой молодости у меня на кафедре АСВК ВМиК МГУ была специализация компьютерная графика. Но ты судя по пафосному тону твоего сообщения писатель движков для топовых игр мирового уровня. Падаю на колени и внемлю твоей мудрости!

Если взять только суть, отбросив понты, то ты сейчас сказал "чем проще структура виртуального мира, тем проще его оптимизировать". Ессно старые алгоритмы не подходят для новых реальностей. Но новые придумывать не обязательно, можно фигачить абы как, а пока игру допишешь уже и железо подходящее наштампуют. Все рассчитано манагерами, а не кодерами. Знанием псевдоумных слов типа полигон и фпс ты в этом вопросе ничего не докажешь. Тут надо жизнь знать, а не матчасть

[Субутар]

Сообщение от Эрбиан

Если взять только суть, отбросив понты, то ты сейчас сказал "чем проще структура виртуального мира, тем проще его оптимизировать". Ессно старые алгоритмы не подходят для новых реальностей. Но новые придумывать не обязательно, можно фигачить абы как, а пока игру допишешь уже и железо подходящее наштампуют. Все рассчитано манагерами, а не кодерами. Знанием псевдоумных слов типа полигон и фпс ты в этом вопросе ничего не докажешь. Тут надо жизнь знать, а не матчасть

Я сказал немного другое: легко ускорить визуализацию наложив ограничения на мир, или качество визуализации. А ускорить что-либо без потерь качества (т.е. получая ту же самую картинку как и в алгоритме до оптимизации) очень сложно, и результат в увеличении производительности на 20% в таком случае это просто прорыв. Ни о каких 10 разах при том же качестве как правило и речь не идет.

З.Ы. комп графика которую нам давали в СПбГУ не покрывала даже прочитанного в 7-8 классе ради демомакинга.

[Эрбиан]

З.Ы. не знаю как там у вас в СПбГУ, а нам бабло на исследования давал чиста интел, а основная работа научрука была в ИПМ им Келдыша, если тебе это о чем-то говорит http://www.keldysh.ru/departments/dpt_20/Bayak.html

Но это к делу не относится. Поскольку ты скромно промолчал, то я так предполагаю, что серьезные движки ты как и я не программил никогда Поэтому давай как дилетанты разговаривать, а не интерполировать (или экстраполировать? блин, хотел тоже выпендрится, неполучилось, забыл что слова значат. только вертится в голове "интерполяция сплайнами") тенденции мирового 3д на основе собственных куцых знаний.

Под большинство ММОРПГ движки покупаются готовые. То есть не пишутся под конкретную задачу. Программерам при постановке задачи про оптимизацию никто вообще ничего не говорит. Поменьше глюков, побольше строчек кода. Где я соврал? А если не соврал, то почему ты думаешь, что нельзя ускорить отрисовку в 10 раз? Никто ведь даже не пытался.

[Эрбиан]

Это мы только о графических алгоритмах говорим. А еще есть хранение данных. Всякие стандартные объекты и т.п. Ты представь какая помойка современная библиотека под винды. В 70хх ее бедную портировали с иксовых С на Линукс, в 80хх перехерачили под ДОС, потом в 85м какого-то долбо.ба осенило полиморфизмом и туда зафигачили объекты, в 91м чуток перезаточили под Вин 3.1.... ну и т.п. оптимизировать нет смысла, железо крутеет быстрее, чем ты почистишь мусор и не дай бог придумаешь какой-то оригинальный алгоритм.

Я тебе честно скажу мой бенефис в 3д это несколько крутящихся кубиков-рубиков в далеком 93м году. И то до освещения дело не дошло, за...ло. Так вот еще тогда когда все писалось на чистых С++ просторов для оптимизации было до.уя. Например чисто ради прикола я переписал стандартную функцию линии. На ассемблере, взяв из книжки алгоритм какого-то еврея Бризингейма, хейма, не помню точно. Кубики стали крутиться быстрее не в 10 раз, а хз в 50 наверно. И ты говоришь, что современные помоишные тулзы не возможно оптимизировать. ХА*3!!!

[Bzik]

а я сегодня пытался воставить висту. долго ржал когда меня на этапе установки инасталлер послал нафиг потамушта у меня меньше 512 оперативы. а вы говорите движки...

[Эрбиан]

а мы и не говорим http://www.udaff.com/image/371/37142.jpg

[Bzik]

эта картинка совсем не выражает то что я увидел переставив две планки оперативки с другого компа, 6 или 7 раз ребутнув комп из-за того что он повис, установив левые ХР дрова под вист и увидев как ЭТО жутко тормозит. Мне просто интересно куда катиться этот мир если ресурсов среднестатистического компа не хватает чтобы банально установить операционку. Ненавижу мелкомягких

[Субутар]

Сообщение от Эрбиан

Это мы только о графических алгоритмах говорим. А еще есть хранение данных. Всякие стандартные объекты и т.п. Ты представь какая помойка современная библиотека под винды. В 70хх ее бедную портировали с иксовых С на Линукс, в 80хх перехерачили под ДОС, потом в 85м какого-то долбо.ба осенило полиморфизмом и туда зафигачили объекты, в 91м чуток перезаточили под Вин 3.1.... ну и т.п. оптимизировать нет смысла, железо крутеет быстрее, чем ты почистишь мусор и не дай бог придумаешь какой-то оригинальный алгоритм.

"Линукс в 70хх" - жжошь неподетски... Почитай вот тут: Linux и тут: Linus Torvalds. Бедный мальчик написал свое ядро в 6+-5 лет .

А структуру данных + методы ее обработки оптимизировать обычно еще сложнее. Что же следует думать когда это возможно - см. комментарий к следующей цитате (1-е предложение).

Я тебе честно скажу мой бенефис в 3д это несколько крутящихся кубиков-рубиков в далеком 93м году. И то до освещения дело не дошло, за...ло. Так вот еще тогда когда все писалось на чистых С++ просторов для оптимизации было до.уя. Например чисто ради прикола я переписал стандартную функцию линии. На ассемблере, взяв из книжки алгоритм какого-то еврея Бризингейма, хейма, не помню точно. Кубики стали крутиться быстрее не в 10 раз, а хз в 50 наверно. И ты говоришь, что современные помоишные тулзы не возможно оптимизировать. ХА*3!!!

Это говорит только о том что исходно у тебя все было написано действительно через задницу. Не думаю что этот пример свидетельствует о том как же пишут движки сегодня.

Судя по всему было там у тебя чего-то вроде:

dx = x2 - x1
dy = y2 - y1
for x from x1 to x2 {
        y = y1 + (dy) * (x - x1)/(dx)
        plot(x, y)
}

(взято из из A naïve line-drawing algorithm)

что было заменено на

 function line(x0, x1, y0, y1)
     int deltax := abs(x1 - x0)
     int deltay := abs(y1 - y0)
     real error := 0
     real deltaerr := deltay / deltax    // Assume deltax != 0 (line is not vertical)
     int y := y0
     for x from x0 to x1
         plot(x,y)
         error := error + deltaerr
         if error ≥ 0.5 then
             y := y + 1
             error := error - 1.0

(алгоритм Bresenham-a, ниже можно найти более обще-продвинутые версии, цитировать длинное не хочется)

Естественно все это дополняется проверками направления (несколько условий в самом начале кода).

В первом случае на каждый пиксель требуется 1 floating-point умножение и деление. Во втором случае с некоторыми модификациями можно обойтись только целочисленным сложением. Не на всех машинах образца 1993 года был арифметический сопроцессор. А если он и был, то как правило был на отдельной микросхеме. В результате floating-point операции занимали несравненно больше времени чем целочисленные. А умножение, и особенно деление - гораздо больше чем сложение. Верно это и сегодня уже не в той степени как тогда. Использование тогда деления в критическом цикле иначе как кощунством не назовешь. Сегодня такого выигрыша по скорости уже не получится.

З.Ы.: Бараны были, есть и будут (есть), однако не ими одними полон мир. Не пользуйте помоешные тулзы - когда в мире есть нормальные.

[Субутар]

Сообщение от Эрбиан

Под большинство ММОРПГ движки покупаются готовые. То есть не пишутся под конкретную задачу. Программерам при постановке задачи про оптимизацию никто вообще ничего не говорит. Поменьше глюков, побольше строчек кода. Где я соврал? А если не соврал, то почему ты думаешь, что нельзя ускорить отрисовку в 10 раз? Никто ведь даже не пытался.

Ты достаточно точно изложил требование к программисту какого-нить Гуя к уже существующей библиотеке/проге. В случае если пишут критические по времени участки, за скорость спросят - ибо от этого ой как зависит конечная функциональность продукта. А ускорить отрисовку пробуют, пробовали и будут пробовать. Особенно успешные будут рубить рл куны и славу. То что ты не пытался не значит что не "никто не пытался" (квантор общности означает очень сильное утверждение).

З.Ы. вместе со следующим постом можешь выложить еще и копию диплома - тогда тебя точно все будут уважать и боятся .