Gildor's Forums

Author Topic: Околодевелоперские байки :)  (Read 14639 times)
vedmysh
Newbie
*
Posts: 14


View Profile
Околодевелоперские байки :)
« on: February 08, 2010, 16:01 »

Доброго дня.

Преамбула. Изначально хотел выяснить несколько вопросов для себя лично. Однако после общения с уважаемым gildor'ом было принято решение вынести общение на всеобщее обозрение. Может кому-нибудь тоже покажется интересным. А может кто поправит-дополнит-объяснит.

Почитал форум. Я так понимаю Unreal Warfare в 2007 году был выбран чисто эмпирически ? Ведь были же ещё и Doom3 с его md5, Source с его богатыми традициями еще с hl1 (не смотря на то, что ножки у hl1 растут из quake, ни о какой кейфрейм анимации в hl1 речи уже не шло вроде бы). В конце концов были и open source наработки. Помню некий проект под названием cal3d если мне память не изменяет.
Сейчас, я так понимаю, у тебя уже есть опыт работы и с md5. Есть ли принципиальные плюсы и минусы того или иного формата ?
ps Детский вопрос отвлеченно от Unreal Engine. Я когда закончил ренедер моделек md5 обратил внимание, что, скажем, при анимации ходьбы модель меняла положение в пространстве. Это так задумано или это был мой недосмотр ? Они что, компенсируют это перемещение в игре ?
Logged
Gildor
Administrator
Hero Member
*****
Posts: 7764



View Profile WWW
Re: Околодевелоперские байки :)
« Reply #1 on: February 08, 2010, 17:11 »

Почитал форум. Я так понимаю Unreal Warfare в 2007 году был выбран чисто эмпирически ? Ведь были же ещё и Doom3 с его md5, Source с его богатыми традициями еще с hl1 (не смотря на то, что ножки у hl1 растут из quake, ни о какой кейфрейм анимации в hl1 речи уже не шло вроде бы).
Я выбрал самый успешный (не только по моему мнению) движок - Unreal Engine. На тот момент это был Unreal Engine 2 (UT2004). Меня его анимация более чем устраивала, плюс я вроде преследовал цель - использовать модельки из UT2003/UT2004 в своём моде Quake2. Модельки для UT2004 очень качественные, их в самой игре довольно-таки много, да ещё и большое community. Для Doom3 такого количества моделек нет.

Source engine: я посмотрел "утёкшие исходники" - там скелетная система вроде старая, из 1го HL. Я как-то смотрел, какие бы ещё модельки поддержать в "своём" quake - от Half-Life отказался. Там одна моделька = один скин. Да и в сети моделек то ли нет, то ли мало ...

Doom3 ... 1) мне не нравится текстовый формат моделек и анимации 2) в сети мало моделек 3) в UT2004 модельки покруче Smiley

Quote
В конце концов были и open source наработки. Помню некий проект под названием cal3d если мне память не изменяет.
Да, я смотрел open-source разработки. Что-то там мне не понравилось, уже не помню. Хотелось посмотреть как работает анимация в коммерческом продукте. Конечно, видел и разные статейка на gamedev-сайтах. Это, извиняюсь, "детский лепет" по сравнению с техниками, используемыми в современном UE3.

Где-то на отечественном gamedev-сайте видел информацию, что вроде "Герои" содержат очень много анимации и её компрессия идёт несколько часов. Я, как человек, видевший исходники "Героев", могу сказать - анимация там никакущая (по коду), а "часы на компрессию" - это чисто проблема плохих идей и кодинга Smiley

Quote
Сейчас, я так понимаю, у тебя уже есть опыт работы и с md5. Есть ли принципиальные плюсы и минусы того или иного формата ?
Такого понятия, как "формат", в UE нет. От версии к версии движок дорабатывается, появляются новые возможности, иногда убираются старые. Есть определённые идеи - как хранить модель (mesh) в пямяти для быстрого рендеринга на GPU, как хранить анимацию и т.п.
В md5 формат очень неоптимальный - нет компрессии анимаций, вроде есть избыточная информация для mesh.

Quote
ps Детский вопрос отвлеченно от Unreal Engine. Я когда закончил ренедер моделек md5 обратил внимание, что, скажем, при анимации ходьбы модель меняла положение в пространстве. Это так задумано или это был мой недосмотр ? Они что, компенсируют это перемещение в игре ?
В Unreal Engine это называется Root Motion. Аниматор анимирует манеру перемещения персонажа как анимацию корневой кости, а движок потом эту анимацию изымает и отправляет в физику, а моделька анимируется на месте.
Альтернатива - делать анимацию бега на месте и задать определённую скорость бега в игровом мире.
Logged
vedmysh
Newbie
*
Posts: 14


View Profile
Re: Околодевелоперские байки :)
« Reply #2 on: February 09, 2010, 11:16 »

Т.к. от современных технологий я уже отстал, возможно где-то буду нести чепуху. Сильно не пугайся Smiley

Я выбрал самый успешный (не только по моему мнению) движок - Unreal Engine. На тот момент это был Unreal Engine 2 (UT2004). Меня его анимация более чем устраивала, плюс я вроде преследовал цель - использовать модельки из UT2003/UT2004 в своём моде Quake2. Модельки для UT2004 очень качественные, их в самой игре довольно-таки много, да ещё и большое community. Для Doom3 такого количества моделек нет.

С успешностью не поспоришь. Не смотря на то, что я не большой фанат творения Тима Суини, раньше (да и сейчас, с выходом udk) знакомым 'энтузиастам' жаждущим творчества советовал именно Unreal Warfare 2. Но успешность еще не значит предельную технологичность о которой ты столько писал Smiley Имхо это больше доступность (инструментарий, восприятие и прочее), мастшабируемость. Реклама в конце концов Smiley
К слову, а на твой мод посмотреть можно ?

Quote
Source engine: я посмотрел "утёкшие исходники" - там скелетная система вроде старая, из 1го HL. Я как-то смотрел, какие бы ещё модельки поддержать в "своём" quake - от Half-Life отказался. Там одна моделька = один скин. Да и в сети моделек то ли нет, то ли мало ...

Так глубоко 'исходники' hl2 не изучал, ничего не могу сказать. Другое дело, что там были осколки и от hl1 и от cs (не сурс). Может быть они тебя сбили с толку. На счет первого hl по моему да, один. А вот сурс не выглядит на 'один скин' Smiley

Quote
Doom3 ... 1) мне не нравится текстовый формат моделек и анимации 2) в сети мало моделек 3) в UT2004 модельки покруче Smiley

Мне наоборот это нравилось Smiley Хотя душа у меня не лежала к yacc'ам-flex'ам-bison'ам (порочная практика, знаю, даже немного стыдно Smiley), а потому простейшие анализаторы-парсеры писал сам. В Quake Wars модельки уже прекомпилированы.
Чего уж греха таить, Doom 3 мне вообще нравился. Из минусов слабая система материалов. Из плюсов быстрая унифицированная система освещения (а может грамотная работа дизайнеров ? Smiley). Стенсильные тени меня вполне устраивали Smiley
Что значит покруче ? Полигонов побольше ? Как мне кажется низкая детализация Doom 3 моделей кроется в двух словах - теневые объемы и филрейт Smiley Да и с нормал меппингом ничего так смотрятся вроде Smiley

Quote
Да, я смотрел open-source разработки. Что-то там мне не понравилось, уже не помню. Хотелось посмотреть как работает анимация в коммерческом продукте. Конечно, видел и разные статейка на gamedev-сайтах. Это, извиняюсь, "детский лепет" по сравнению с техниками, используемыми в современном UE3.

Хочется конкретики. Я не очень понимаю, что такого столь революционного можно придумать сейчас.
По возможности статические вершинные буферы в видеопамяти без зеркалирования, скиннинг на gpu ну и, возможно, распаковка входных упакованных данных в шейдере. Оно ?
Время садиться за perfhud ? Smiley

Quote
Где-то на отечественном gamedev-сайте видел информацию, что вроде "Герои" содержат очень много анимации и её компрессия идёт несколько часов. Я, как человек, видевший исходники "Героев", могу сказать - анимация там никакущая (по коду), а "часы на компрессию" - это чисто проблема плохих идей и кодинга Smiley

К своему стыду я даже не понимаю о каких героях речь Smiley
А что значит компрессия анимации ? Как это выглядит на этапе разработке и собственно в процессе рендера ?

Quote
Такого понятия, как "формат", в UE нет. От версии к версии движок дорабатывается, появляются новые возможности, иногда убираются старые. Есть определённые идеи - как хранить модель (mesh) в пямяти для быстрого рендеринга на GPU, как хранить анимацию и т.п.
В md5 формат очень неоптимальный - нет компрессии анимаций, вроде есть избыточная информация для mesh.

Пожалуй это я внес путаницу. Одно дело формат, другое дело возможности рендера исходя из данных, сохраненных в файле(ах) содержащих собственно меш и анимацию.
Как нет понятия "формата" ? Должны же быть какие то спецификации и стандарты. Не /dev/random же там Smiley
Опять тот же вопрос относительно оптимальности хранения модели. Что в ue3 такого особенного ?
Ну для хранения возможно не оптимальный. Но ведь это никак не характеризует внутренние структуры рендера.
И снова это страшное 'компрессия анимаций' Smiley

Quote
В Unreal Engine это называется Root Motion. Аниматор анимирует манеру перемещения персонажа как анимацию корневой кости, а движок потом эту анимацию изымает и отправляет в физику, а моделька анимируется на месте.
Альтернатива - делать анимацию бега на месте и задать определённую скорость бега в игровом мире.

Спасибо !
« Last Edit: February 09, 2010, 11:26 by vedmysh » Logged
Gildor
Administrator
Hero Member
*****
Posts: 7764



View Profile WWW
Re: Околодевелоперские байки :)
« Reply #3 on: February 09, 2010, 13:37 »

Но успешность еще не значит предельную технологичность о которой ты столько писал Smiley Имхо это больше доступность (инструментарий, восприятие и прочее), мастшабируемость.
Инструментарий в UE очень удобный. Но и про технологичность этого движка ... Чего в нём (UE3) нет?

Quote
К слову, а на твой мод посмотреть можно ?
Если интересно - как нибудь выложу.

Quote
Стенсильные тени меня вполне устраивали Smiley
Мне больше нравятся проекционные размытые тени в UT2004 Smiley

Quote
Что значит покруче ? Полигонов побольше ? Как мне кажется низкая детализация Doom 3 моделей кроется в двух словах - теневые объемы и филрейт Smiley Да и с нормал меппингом ничего так смотрятся вроде Smiley
Это всё личные предпочтения, спор здесь бессмысленный Smiley

Quote
Хочется конкретики. Я не очень понимаю, что такого столь революционного можно придумать сейчас.
По возможности статические вершинные буферы в видеопамяти без зеркалирования, скиннинг на gpu ну и, возможно, распаковка входных упакованных данных в шейдере. Оно ?
Про другие движки - это было около 2-3 лет назад. Сейчас конкретику уже и не вспомню.
В UE3 есть поддердка моделек с большим количеством костей (больше 256) - на GPU обычно номер кости байтом задают. Т.е. режут модельку на несколько частей. Зеркалирования не видел. Есть распаковка позиции и нормали. Есть упакованные текстурные координаты.

Quote
К своему стыду я даже не понимаю о каких героях речь Smiley
Герои Меча и Магии 5 (от Nival)

Quote
А что значит компрессия анимации ? Как это выглядит на этапе разработке и собственно в процессе рендера ?
Компрессия анимации в UE3 - удаление ключей, которые могут быть получены интерполяцией двух соседних ключей (с допустимой ошибкой) - key reduction. Также используются несколько вариантов сжатия кватернионов - в 4 или 6 байтов. Вид сжатия выбирает дизайнер в UnrealEd, он может сравнить сжатый и несжатый варианты и только после этого удаляется оригинал (во время cooking). Распаковка делается "на лету". Некоторые игры (на базе UE3) используют другие методы сжатия (например Batman). В Gears of War 2 (и UDK) появились time tracks раздельно для позиции и вращения. Собственно, до этого key reduction как такового и не было - например, в UT2004 есть трек времени, но он всегда содержит числа 0,1,2,3,...N-1.
Есть ещё компрессия в Havok - там используются более сложные алгоритмы - wavelet и т.п. Я так понимаю, что жмут кривые. Для распаковки используют буфер (кеш).

Quote
Как нет понятия "формата" ? Должны же быть какие то спецификации и стандарты. Не /dev/random же там Smiley
Опять тот же вопрос относительно оптимальности хранения модели. Что в ue3 такого особенного ?
Ну для хранения возможно не оптимальный. Но ведь это никак не характеризует внутренние структуры рендера.
Если сравнивать с Quake - то в Unreal используется совершенно иной подход для сериализации данных. В Quake: читаем большой блок памяти, переставляем байты (для big-endian), и рендерим прямо отсюда. Это не даёт возможности расширять формат (иначе все данные "съедут"). В Unreal всё по-другому: сериализуется каждое поле по-отдельности. В пакете имеется номер версии, и движок читает поля так, как они были сохранены в той версии, которая указана в пакете. Вот небольшой пример:
Code:
struct FSkinChunk3
{
int FirstVertex;
TArray<FRigidVertex3> RigidVerts;
TArray<FSmoothVertex3> SmoothVerts;
TArray<short> Bones;
int NumRigidVerts;
int NumSmoothVerts;
int MaxInfluences;

friend FArchive& operator<<(FArchive &Ar, FSkinChunk3 &V)
{
Ar << V.FirstVertex << V.RigidVerts << V.SmoothVerts << V.Bones;
if (Ar.ArVer >= 333)
{
Ar << V.NumRigidVerts << V.NumSmoothVerts;
}
else
{
V.NumRigidVerts  = V.RigidVerts.Num();
V.NumSmoothVerts = V.SmoothVerts.Num();
}
if (Ar.ArVer >= 362)
Ar << V.MaxInfluences;
return Ar;
}
};
Logged
vedmysh
Newbie
*
Posts: 14


View Profile
Re: Околодевелоперские байки :)
« Reply #4 on: February 09, 2010, 16:17 »

Инструментарий в UE очень удобный. Но и про технологичность этого движка ... Чего в нём (UE3) нет?

Я как раз и говорил об удобстве инструментария UE как о первопричине. Чего в нем нет я ответить не готов Smiley Мы в разных весовых категориях. Да и вопрос ведь не в этом Smiley

Quote
Если интересно - как нибудь выложу.

Интересно. Исходники тоже можно будет увидеть или как и с Umodel подождем ? Smiley

Quote
Мне больше нравятся проекционные размытые тени в UT2004 Smiley

Так ведь космические корабли уже бороздят просторы большого театра Smiley
UE3 поддерживает динамическое освещение и как следствие тени. А кстати, как у него с самозатенением ?

Quote
Это всё личные предпочтения, спор здесь бессмысленный Smiley

Нет-нет, никаких holy war и споров. Я уже слишком стар для этого Smiley

Quote
Про другие движки - это было около 2-3 лет назад. Сейчас конкретику уже и не вспомню.
В UE3 есть поддердка моделек с большим количеством костей (больше 256) - на GPU обычно номер кости байтом задают. Т.е. режут модельку на несколько частей. Зеркалирования не видел. Есть распаковка позиции и нормали. Есть упакованные текстурные координаты.

Под зеркалированием я имел ввиду не столько архитектурную фишку движка, сколько зависимость от апи. Ситуация, когда кроме видеопамяти (локальной или не локальной) копия ресурса хранится еще и в системной памяти. В opengl зеркалирование есть всегда. Во всяком случае раньше было. В d3d тот же эффект мы получаем при создании статики в managed пуле.
Сейчас на несколько частей многие режут. Недавно смотрел рендер Overlord 2. Там ключевые персонажи состоят из нескольких мешей. То же самое с Armed Assault 1/2.

Quote
Герои Меча и Магии 5 (от Nival)

Не видел.
А у них что за компрессия ? Или это NDA ? Smiley

Quote
Компрессия анимации в UE3 - удаление ключей, которые могут быть получены интерполяцией двух соседних ключей (с допустимой ошибкой) - key reduction. Также используются несколько вариантов сжатия кватернионов - в 4 или 6 байтов. Вид сжатия выбирает дизайнер в UnrealEd, он может сравнить сжатый и несжатый варианты и только после этого удаляется оригинал (во время cooking). Распаковка делается "на лету". Некоторые игры (на базе UE3) используют другие методы сжатия (например Batman). В Gears of War 2 (и UDK) появились time tracks раздельно для позиции и вращения. Собственно, до этого key reduction как такового и не было - например, в UT2004 есть трек времени, но он всегда содержит числа 0,1,2,3,...N-1.
Есть ещё компрессия в Havok - там используются более сложные алгоритмы - wavelet и т.п. Я так понимаю, что жмут кривые. Для распаковки используют буфер (кеш).

Интерполяция и получение недостающего кейфрейма происходит в рантайме ? Или это все таки средство оптимизации для аниматора на этапе создания модели ? Можно ли влиять на этот процесс из движка таким образом получая эдакий анимационный lod ? Затраты на такой трюк не привышают ли выгоду ?
О кватернионах не очень понял. Интернал представление же все равно в матрицах. А кватернионы используются лишь при расчетах на цпу ? Я неправ ?
Havok это вообще отдельная песня. В 'исходниках' hl2 была какая то версия хавока, правда без модуля анимации.

Quote
Если сравнивать с Quake - то в Unreal используется совершенно иной подход для сериализации данных. В Quake: читаем большой блок памяти, переставляем байты (для big-endian), и рендерим прямо отсюда. Это не даёт возможности расширять формат (иначе все данные "съедут"). В Unreal всё по-другому: сериализуется каждое поле по-отдельности. В пакете имеется номер версии, и движок читает поля так, как они были сохранены в той версии, которая указана в пакете...

Мысль понял. А большая ли польза от этого на практике ? Или десереализация идет исключительно на уровне Unreal Script'а и сам движок лишь шасси ?
« Last Edit: February 09, 2010, 16:20 by gildor » Logged
Gildor
Administrator
Hero Member
*****
Posts: 7764



View Profile WWW
Re: Околодевелоперские байки :)
« Reply #5 on: February 09, 2010, 16:48 »

Quote
Если интересно - как нибудь выложу.
Интересно. Исходники тоже можно будет увидеть или как и с Umodel подождем ? Smiley
Исходники от Q2 выкладывать не собирался, хотя Q2 и GPL. В Quake2 engine modding community очень развито (по крайней мере так было пару лет назад) встраивание вещей, разработанных другими "моддерами" в свой движок, причём как правило без спроса и даже без "credits" ... Да и движок у меня уже мало напоминает внутри оригинальный Quake2. Жаль только, что из-за umodel уже 2 года как проект заброшен Sad

Quote
UE3 поддерживает динамическое освещение и как следствие тени. А кстати, как у него с самозатенением ?
Поддерживается.

Quote
Под зеркалированием я имел ввиду не столько архитектурную фишку движка, сколько зависимость от апи. Ситуация, когда кроме видеопамяти (локальной или не локальной) копия ресурса хранится еще и в системной памяти. В opengl зеркалирование есть всегда. Во всяком случае раньше было. В d3d тот же эффект мы получаем при создании статики в managed пуле.
Сейчас на несколько частей многие режут. Недавно смотрел рендер Overlord 2. Там ключевые персонажи состоят из нескольких мешей. То же самое с Armed Assault 1/2.
Тут я ничего конкретного сказать не могу - в рендерер не залезал. Сам по себе рендерер (низкий уровень) вряд ли отличается чем-то от других движков - здесь мало что можно выдумать, сделать какое-то "know how".
"Составные" персонажи были в Unreal ещё во время 2й версии движка.

Quote
Quote
Герои Меча и Магии 5 (от Nival)
Не видел.
А у них что за компрессия ? Или это NDA ? Smiley
Увы, их код не заслуживает глубокого изучения (хотя Nival и позиционирует себя лидером в российском геймдеве). Что там используется - не помню, смотрел анимацию около полутора лет назад.

Quote
Интерполяция и получение недостающего кейфрейма происходит в рантайме ?
Да. По времени это в основном получение 2х соседних ключей из трека. Саму интерполяцию можно считать "бесплатной".
Quote
Можно ли влиять на этот процесс из движка таким образом получая эдакий анимационный lod ?
Это балансирует качество и объём занимаемой памяти. LOD только один. Во время самой игры не имеет смысла.
Quote
Затраты на такой трюк не привышают ли выгоду ?
Здесь нет затрат. Только выгода. Затраты CPU будут если неграмотно написать поиск ключей.

Quote
О кватернионах не очень понял. Интернал представление же все равно в матрицах. А кватернионы используются лишь при расчетах на цпу ? Я неправ ?
Матрицы отправляются на GPU. Интерполяция, естественно, всегда делается в кватернионах.

Quote
Havok это вообще отдельная песня. В 'исходниках' hl2 была какая то версия хавока, правда без модуля анимации.
Там был очень старый havok. О нём тогда ещё никто и не знал Smiley Анимация в нём появилась позже. Да и не все пользователи havok используют анимацию - это же прежде всего физика?

Quote
Мысль понял. А большая ли польза от этого на практике ? Или десереализация идет исключительно на уровне Unreal Script'а и сам движок лишь шасси ?
Такой механизм используется только из C++ кода. На уровне скрипта используется "сериализация свойств" - несколько иной механизм, активно использующий Unreal RTTI.
Выгода на практике - сериализуем только то, что нужно, и не привязаны к конкретным форматам данных. Мне очень нравится идея, заложенная в UE насчёт сериализации.
Logged
vedmysh
Newbie
*
Posts: 14


View Profile
Re: Околодевелоперские байки :)
« Reply #6 on: February 10, 2010, 10:35 »

Quote
Исходники от Q2 выкладывать не собирался, хотя Q2 и GPL. В Quake2 engine modding community очень развито (по крайней мере так было пару лет назад) встраивание вещей, разработанных другими "моддерами" в свой движок, причём как правило без спроса и даже без "credits" ... Да и движок у меня уже мало напоминает внутри оригинальный Quake2. Жаль только, что из-за umodel уже 2 года как проект заброшен Sad

Без исходников не интересно Wink
Почему жаль ? Была цель создать что-то законченное ?

Quote
Тут я ничего конкретного сказать не могу - в рендерер не залезал. Сам по себе рендерер (низкий уровень) вряд ли отличается чем-то от других движков - здесь мало что можно выдумать, сделать какое-то "know how".
"Составные" персонажи были в Unreal ещё во время 2й версии движка.

Именно об этом я и говорил изначально - мое непонимание, что можно нового выдумать в рендере.

Quote
Да. По времени это в основном получение 2х соседних ключей из трека. Саму интерполяцию можно считать "бесплатной".

Трек это таймлайн всех кейфремов ?
Я все таки не очень понимаю. Практическую пользу.
Имея скелет мы создает несколько ключей-положений. Интерполяция скелета выполняется между этими ключами. Дискретизировать интерполяцию можно как угодно в любой момент времени между двумя ключами. Совокупность всех интерполяций от одного ключа к другому и есть анимация скелета.
Что такого революционного сделано в уе3 ?


Quote
Это балансирует качество и объём занимаемой памяти. LOD только один. Во время самой игры не имеет смысла.

Я не об геометрическом лоде. Впрочем уже понял, что мой вопрос не имел смысла. Из чего и проистекает вышеуказанное непонимание Smiley

Quote
Здесь нет затрат. Только выгода. Затраты CPU будут если неграмотно написать поиск ключей.

Если можно, то хотелось бы некий абстрактный пример но с упоминанием ключевых моментов и исполнителей-участников (цпу, гпу, геометрии)

Quote
Матрицы отправляются на GPU. Интерполяция, естественно, всегда делается в кватернионах.

Угу, я так и понял.

Quote
Там был очень старый havok. О нём тогда ещё никто и не знал Smiley Анимация в нём появилась позже. Да и не все пользователи havok используют анимацию - это же прежде всего физика?

То что старый, да. А что не знали вот уж не правда Smiley Он уже тогда 'прогремел'. Причем был какое то время чуть ли не именем нарицательным. Серьезных конкурентов у него тогда не было.

Quote
Такой механизм используется только из C++ кода. На уровне скрипта используется "сериализация свойств" - несколько иной механизм, активно использующий Unreal RTTI.
Выгода на практике - сериализуем только то, что нужно, и не привязаны к конкретным форматам данных. Мне очень нравится идея, заложенная в UE насчёт сериализации.

Для чего используется подобный паттерн я понимаю, сам пользовался регулярно. Однако польза от такого подхода на мой взгляд есть только в том случае, если необходим механизм версионности объектов. Зачем это нужно в графическом движке не очень понятно. Анриал в состоянии отрендерить модели предшествующих версий ? Исходные тексты ведь открыты для лицензиата. Кто ему мешает использовать скажем для максимальной производительности читать используя проекции файлов (memory mapped files) и обращаться к памяти структурами. Это ведь будет быстрее.
Logged
Gildor
Administrator
Hero Member
*****
Posts: 7764



View Profile WWW
Re: Околодевелоперские байки :)
« Reply #7 on: February 10, 2010, 14:27 »

Без исходников не интересно Wink
Почему жаль ? Была цель создать что-то законченное ?
Да. Хотел сделать игру, которая позволяла бы побегать на картах их других игр. Для Quake2 как-то давно всё заглохло. Мне нравились уровни из Quake1 - в своё время накачал их порядочно Smiley И из некоторых action-модов для Q3 (Urban Terror и т.п.)
Ещё подцепил модельки игроков ...
В общем, хотел иметь возможность заюзать ресурсы из других игр. При этом - полная совместимость с оригинальным Quake2 по сети и по game.dll.

Quote
Трек это таймлайн всех кейфремов ?
В UE таймлайн для каждой кости свой. Т.е. если кость анимируется по-сложному - у неё ключей много, а если по-простому - то мало. В последнем UE3 позиция и вращение имеют раздельные таймлайны.

Quote
Я все таки не очень понимаю. Практическую пользу.
Имея скелет мы создает несколько ключей-положений. Интерполяция скелета выполняется между этими ключами. Дискретизировать интерполяцию можно как угодно в любой момент времени между двумя ключами. Совокупность всех интерполяций от одного ключа к другому и есть анимация скелета.
Что такого революционного сделано в уе3 ?
Да ничего особенного. Просто научились нормально жать анимацию Smiley И дали дизайнеру выбор - как жать.
Epic Games занимается компрессией анимации по крайней мере со времён UE2 Runtime (в UT2004 её не было, хотя в формат была заложена ... была только возможность хранить трек, содержаций одинаковые величины, как один ключ). В общем, лет 5-8 эволюции. Наверняка они знают что делают. Умудрились затолкать в приставку с памятью 512Мб игру уровня Gears of War 2.

Quote
Если можно, то хотелось бы некий абстрактный пример но с упоминанием ключевых моментов и исполнителей-участников (цпу, гпу, геометрии)
Не думаю, что могу сказать здесь что-то новое.

Quote
Для чего используется подобный паттерн я понимаю, сам пользовался регулярно. Однако польза от такого подхода на мой взгляд есть только в том случае, если необходим механизм версионности объектов. Зачем это нужно в графическом движке не очень понятно. Анриал в состоянии отрендерить модели предшествующих версий ?
Unreal умеет читать модели от предыдущих версий (естественно, в пределах одного поколения движка). Ещё в его структурах есть блоки данных, которые совпадают по содержимому в памяти и на диске - такие блоки грузятся за один вызов read. Но при этом, если мы заходим загрузить пакет от XBox360 на PC - такие структуры будут загружены "по полям" (с перестановкой байтов). Также, такие структуры могут меняться от версии к версии, и при этом загрузка файла, созданного в последней версии движка, будет сделана за 1 read, а загрузка старых версий - поэлементно (надеюсь, что я понятно излагаю мысль; если надо - могу привести примеры).

Quote
Исходные тексты ведь открыты для лицензиата. Кто ему мешает использовать скажем для максимальной производительности читать используя проекции файлов (memory mapped files) и обращаться к памяти структурами. Это ведь будет быстрее.
От того, читаю я блок 1Мб сразу в память или после чтения по нему пробегаюсь и раскидываю по полям объекта игра медленнее работать не будет. Знаю, что многие компании делают чтение большого блока в память и после этого "выправляют" указатели (так сделано например в том же Havok). IMHO это не даст выигрыша - разве что неграмотно написать чтение объекта "по полям".
Memory mapped files есть только на PC, на приставках (по крайней мере на XBox360) - нет. И вообще - такой механизм в общем случае не даёт выигрыша в скорости (если на компе зватает памяти и не используется swap file).
Также, если использовать такой подход, код чтения и сохранения объекта будет разным. В UE код сериализации один. При желании в нём можно узнать, идёт сейчас чтение или сохранение объекта.
И ещё. Memory mapped files не даёт использовать компрессию файлов - а значит, они будут грузиться с диска (особенно с какого-нибудь DVD) медленнее. Намного быстрее загрузить пожатый файл и распаковать его в памяти.
Logged
vedmysh
Newbie
*
Posts: 14


View Profile
Re: Околодевелоперские байки :)
« Reply #8 on: February 10, 2010, 15:39 »

Лирическое отступление.
Заглянул в недра source'а на примере Left 4 dead 2.
По ключевым персонажам.
Модель рендерится в 7 DIP'ов. Причем я так понял освещение от некоторых источников (вчасности от фонарика) многопроходное. Скининг явно на гпу. Есть сортировка по материалам.
Порядок рендера модели - лицо (в том числе челюсти и язык видимо), остальная часть головы (волосы, похоже зубы и 'манишка'), собственно тело (отсутствует либо кисть либо пальцы на руке нажимающей курок я так понял), отдельно кисть, глаз, глаз, кобура.
На лицо и голову свой набор текстур. На тело и руки свой. На глаза свой.
Вершинный шейдер один (кроме глаз). Мне он на вскидку ничего не скажет. Может быть ты найдешь что-нибудь интересное.

Code:
//
// Generated by Microsoft (R) D3DX9 Shader Compiler
//
// Parameters:
//
//   float4 cBaseTexCoordTransform[2];
//   float4 cDetailTexCoordTransform[2];
//   float4 cFlexScale;
//   
//   struct
//   {
//       float4 color;
//       float4 dir;
//       float4 pos;
//       float4 spotParams;
//       float4 atten;
//
//   } cLightInfo[4];
//   
//   float4x3 cModel[53];
//   float4x4 cViewProj;
//   bool g_bLightEnabled[4];
//
//
// Registers:
//
//   Name                     Reg   Size
//   ------------------------ ----- ----
//   g_bLightEnabled          b0       4
//   cViewProj                c8       4
//   cFlexScale               c13      1
//   cLightInfo               c27     20
//   cBaseTexCoordTransform   c48      2
//   cDetailTexCoordTransform c52      2
//   cModel                   c58    159
//

    vs_3_0
    def c1, -128, -64, 0.0158730168, 1
    def c2, 765.005859, 3.05175781e-005, 9.99999975e-005, 0
    dcl_position v0
    dcl_blendweight v1
    dcl_blendindices v2
    dcl_normal v3
    dcl_texcoord v4
    dcl_position1 v5
    dcl_normal1 v6
    dcl_position o0
    dcl_texcoord o1
    dcl_texcoord1 o2
    dcl_texcoord2 o3.xyz
    dcl_texcoord3 o4.xyz
    dcl_texcoord4 o5.xyz
    dcl_texcoord5 o6
    dcl_texcoord6 o7.xyz
    mul o6.w, c13.y, v5.w
    dp4 o1.x, v4, c48
    dp4 o1.y, v4, c49
    dp4 o1.z, v4, c52
    dp4 o1.w, v4, c53
    add r0, c1.x, v3
    slt r1, r0, c0.x
    add r0, r0_abs, -r1
    add r0, r0, c1.y
    mad r1.xyz, r1.xzww, -c0.z, c0.y
    slt r2, r0, c0.x
    add r0, r0_abs, -r2
    mad r3.xy, r0.xzzw, -c1.z, c1.w
    mad r3.w, r0.y, -c1.z, r3.x
    mad r4.z, r0.w, -c1.z, r3.y
    mad r2, r2, -c0.z, c0.y
    mul r0, r0, c1.z
    mov r3.xz, r0.xyyw
    nrm r5.xyz, r3.xzww
    mul r3.xy, r2, r5
    mul r3.z, r1.x, r5.z
    mov r4.xy, r0.zwzw
    nrm r0.xyz, r4
    mul r0.xy, r2.zwzw, r0
    mul r0.w, r1.y, r0.z
    mad r0.xyz, v6, c13.x, r0.xyww
    add r1.xy, c0.y, v1
    mul r1.xy, r1, c2.y
    add r0.w, r1.y, r1.x
    add r0.w, -r0.w, c0.y
    mul r2.xyz, c2.x, v2.zyxw
    mova a0.xyz, r2
    mul r2, r1.y, c60[a0.y]
    mad r2, c60[a0.x], r1.x, r2
    mad r2, c60[a0.z], r0.w, r2
    dp3 r4.z, r0, r2
    mov r5.w, v0.w
    mov r6.xyz, v5
    mad r5.xyz, r6, c13.x, v0
    dp4 r6.z, r5, r2
    mad r3.xyz, v6, c13.x, r3
    dp3 r2.z, r3, r2
    mul r7, r1.y, c58[a0.y]
    mad r7, c58[a0.x], r1.x, r7
    mad r7, c58[a0.z], r0.w, r7
    dp3 r4.x, r0, r7
    dp3 r2.x, r3, r7
    mul r8, r1.y, c59[a0.y]
    mad r8, c59[a0.x], r1.x, r8
    mad r8, c59[a0.z], r0.w, r8
    dp3 r4.y, r0, r8
    dp3 r2.y, r3, r8
    dp3 r0.x, r2, r2
    rsq r0.x, r0.x
    mul o5.xyz, r2, r0.x
    dp3 r0.x, r4, r4
    rsq r0.x, r0.x
    mul o3.xyz, r4, r0.x
    mul r0.xyz, r4.yzxw, r2.zxyw
    mad r0.xyz, r2.yzxw, r4.zxyw, -r0
    mul r0.xyz, r1.z, r0
    dp3 r0.w, r0, r0
    rsq r0.w, r0.w
    mul o4.xyz, r0, r0.w
    dp4 r6.x, r5, r7
    dp4 r6.y, r5, r8
    if b0
      add r0.xyz, -r6, c29
      dp3 r1.x, r0, r0
      rsq r2.y, r1.x
      mul r0.xyz, r0, r2.y
      dp3 r0.x, c28, -r0
      mov r1.y, c0.y
      mov r2.xz, c0.y
      mul r0.yzw, r1.xyxx, r2.xxyz
      dp3 r0.y, c31, r0.yzww
      rcp r0.y, r0.y
      add r0.x, r0.x, -c30.z
      mul r0.x, r0.x, c30.w
      max r0.x, r0.x, c2.z
      pow r1.x, r0.x, c30.x
      min r0.x, r1.x, c0.y
      mad r0.x, r0.y, r0.x, -r0.y
      mad r0.x, c28.w, r0.x, r0.y
      add r0.y, -r0.x, c0.y
      mad o2.x, c27.w, r0.y, r0.x
    else
      mov o2.x, c0.x
    endif
    if b1
      add r0.xyz, -r6, c34
      dp3 r1.x, r0, r0
      rsq r2.y, r1.x
      mul r0.xyz, r0, r2.y
      dp3 r0.x, c33, -r0
      mov r1.y, c0.y
      mov r2.xz, c0.y
      mul r0.yzw, r1.xyxx, r2.xxyz
      dp3 r0.y, c36, r0.yzww
      rcp r0.y, r0.y
      add r0.x, r0.x, -c35.z
      mul r0.x, r0.x, c35.w
      max r0.x, r0.x, c2.z
      pow r1.x, r0.x, c35.x
      min r0.x, r1.x, c0.y
      mad r0.x, r0.y, r0.x, -r0.y
      mad r0.x, c33.w, r0.x, r0.y
      add r0.y, -r0.x, c0.y
      mad o2.y, c32.w, r0.y, r0.x
    else
      mov o2.y, c0.x
    endif
    if b2
      add r0.xyz, -r6, c39
      dp3 r1.x, r0, r0
      rsq r2.y, r1.x
      mul r0.xyz, r0, r2.y
      dp3 r0.x, c38, -r0
      mov r1.y, c0.y
      mov r2.xz, c0.y
      mul r0.yzw, r1.xyxx, r2.xxyz
      dp3 r0.y, c41, r0.yzww
      rcp r0.y, r0.y
      add r0.x, r0.x, -c40.z
      mul r0.x, r0.x, c40.w
      max r0.x, r0.x, c2.z
      pow r1.x, r0.x, c40.x
      min r0.x, r1.x, c0.y
      mad r0.x, r0.y, r0.x, -r0.y
      mad r0.x, c38.w, r0.x, r0.y
      add r0.y, -r0.x, c0.y
      mad o2.z, c37.w, r0.y, r0.x
    else
      mov o2.z, c0.x
    endif
    if b3
      add r0.xyz, -r6, c44
      dp3 r1.x, r0, r0
      rsq r2.y, r1.x
      mul r0.xyz, r0, r2.y
      dp3 r0.x, c43, -r0
      mov r1.y, c0.y
      mov r2.xz, c0.y
      mul r0.yzw, r1.xyxx, r2.xxyz
      dp3 r0.y, c46, r0.yzww
      rcp r0.y, r0.y
      add r0.x, r0.x, -c45.z
      mul r0.x, r0.x, c45.w
      max r0.x, r0.x, c2.z
      pow r1.x, r0.x, c45.x
      min r0.x, r1.x, c0.y
      mad r0.x, r0.y, r0.x, -r0.y
      mad r0.x, c43.w, r0.x, r0.y
      add r0.y, -r0.x, c0.y
      mad o2.w, c42.w, r0.y, r0.x
    else
      mov o2.w, c0.x
    endif
    mov o7.xyz, r6
    mov r6.w, c0.y
    dp4 o0.w, r6, c11
    dp4 r0.x, r6, c8
    dp4 r0.y, r6, c9
    dp4 r0.z, r6, c10
    mov o6.xyz, r0
    mov o0.xyz, r0

// approximately 186 instruction slots used

ps Улыбнул рендер ui. На 1-3 буквы по DIP'у это сильно Smiley
Logged
vedmysh
Newbie
*
Posts: 14


View Profile
Re: Околодевелоперские байки :)
« Reply #9 on: February 10, 2010, 16:03 »

Да. Хотел сделать игру, которая позволяла бы побегать на картах их других игр. Для Quake2 как-то давно всё заглохло. Мне нравились уровни из Quake1 - в своё время накачал их порядочно Smiley И из некоторых action-модов для Q3 (Urban Terror и т.п.)
Ещё подцепил модельки игроков ...
В общем, хотел иметь возможность заюзать ресурсы из других игр. При этом - полная совместимость с оригинальным Quake2 по сети и по game.dll.

quake 2 в швейцарский нож ? SmileySmileySmiley

Quote
В UE таймлайн для каждой кости свой. Т.е. если кость анимируется по-сложному - у неё ключей много, а если по-простому - то мало. В последнем UE3 позиция и вращение имеют раздельные таймлайны.

Последний UE3 это тот, что использовался в GOW2 ?

Quote
Да ничего особенного. Просто научились нормально жать анимацию Smiley И дали дизайнеру выбор - как жать.
Epic Games занимается компрессией анимации по крайней мере со времён UE2 Runtime (в UT2004 её не было, хотя в формат была заложена ... была только возможность хранить трек, содержаций одинаковые величины, как один ключ). В общем, лет 5-8 эволюции. Наверняка они знают что делают. Умудрились затолкать в приставку с памятью 512Мб игру уровня Gears of War 2.

Все одно толком не осознал где компрессия Smiley Отложим тогда. Если буду заниматься предметно, тогда обращусь Smiley

Quote
Unreal умеет читать модели от предыдущих версий (естественно, в пределах одного поколения движка). Ещё в его структурах есть блоки данных, которые совпадают по содержимому в памяти и на диске -

Значит ли это, что если я захочу загрузить пакеты с моделями и анимациями скажем из Gears of war в UT3 или наоборот они будут коректно загружены и будет возможность их использовать ?

Quote
такие блоки грузятся за один вызов read. Но при этом, если мы заходим загрузить пакет от XBox360 на PC - такие структуры будут загружены "по полям" (с перестановкой байтов). Также, такие структуры могут меняться от версии к версии, и при этом загрузка файла, созданного в последней версии движка, будет сделана за 1 read, а загрузка старых версий - поэлементно (надеюсь, что я понятно излагаю мысль; если надо - могу привести примеры).

Да понятно. На надо ли такой функционал лицензиату движка ?

Quote
От того, читаю я блок 1Мб сразу в память или после чтения по нему пробегаюсь и раскидываю по полям объекта игра медленнее работать не будет. Знаю, что многие компании делают чтение большого блока в память и после

Сама игра нет. Загрузка будет выполняться медленней. Впрочем это не столь критично.

Quote
этого "выправляют" указатели (так сделано например в том же Havok). IMHO это не даст выигрыша - разве что неграмотно написать чтение объекта "по полям".

Неграмотно это не последовательно ? Cache unfriendly ? Smiley

Quote
Memory mapped files есть только на PC, на приставках (по крайней мере на XBox360) - нет. И вообще - такой механизм в общем случае не даёт выигрыша в скорости (если на компе зватает памяти и не используется swap file).

А на какой архитектуре построен xbox360 ? Сама ос на сколько я помню там модифицированный w2k.
Не согласен. mm даст прирост в любом случае по сравнению с обычными операциями чтения. Доступ с использованием mm выполняется быстрее за счет обхода каких-то привычных механизмов файловой системы ос.
Подробностей к сожалению не вспомню. Надо копать Рихтера, Руссиновича, msdn.
Отдельно скажу на счет хватает памяти или нет. Ты как человек потрошивший уе (кстати, чем ? ida ? driver studio ? Smiley) и анализировавший код q1/q2/q3 ведь понимаешь, что собственно приложение работает лишь с виртуальной памятью. Оно не знает, где именно находится страница с которой оно работает. Вспомни, как в q1 делался touch в hunk менеджере по всей выделенной памяти Wink 'Хватает' физической памяти или нет это исключительно выбор менеджера страниц в ос с его алгоритмами. Политика использования страничных файлов/девайсов в том же linux и win очень сильно отличается. Так что я бы сказал здесь просто - depends Smiley

Quote
Также, если использовать такой подход, код чтения и сохранения объекта будет разным. В UE код сериализации один. При желании в нём можно узнать, идёт сейчас чтение или сохранение объекта.

Локи есть ?

Quote
И ещё. Memory mapped files не даёт использовать компрессию файлов - а значит, они будут грузиться с диска (особенно с какого-нибудь DVD) медленнее. Намного быстрее загрузить пожатый файл и распаковать его в памяти.

Пожалуй. На самом деле можно мапить страницы с возможностью записи и copy-on-write и получить возможность записи прямо в эти страницы. Правда тогда нужно подумать об увеличении размеров замапленного региона. Если не ошибаюсь, это можно сделать. Вобщем для простоты в отдельный буфер пжалста Smiley То же самое сделает и код сериализации приведенный тобой в пример - распаковка все равно будет происходить где-то в стороне. Но вцелом я понял, что ты фанат паттерна сериализации Smiley
Logged
vedmysh
Newbie
*
Posts: 14


View Profile
Re: Околодевелоперские байки :)
« Reply #10 on: February 10, 2010, 16:24 »

Что касается выделения памяти в windows.
Рано или поздно независимо от того, что мы используем для выделения памяти мы упираемся в функции группы Virtual* (VirtualAlloc и иже с ними).

Цитата из книги Рихтера (Windows Via C/C++ by Jeffrey Richter and Christophe Nasarre Microsoft Press © 2008, 5 издание)

Quote
Committing Storage in a Reserved Region
After you have reserved a region, you need to commit physical storage to the region before you can access the memory addresses contained within it. The system allocates physical storage committed to a region from the system's paging file. Physical storage is always committed on page boundaries and in page-size chunks.

Я имею ввиду, что выделяя память windows, ты выделяешь память в страничном файле.
А дальше дело техники. Деманд пейджинг ?
Logged
Gildor
Administrator
Hero Member
*****
Posts: 7764



View Profile WWW
Re: Околодевелоперские байки :)
« Reply #11 on: February 10, 2010, 17:09 »

Вершинный шейдер один (кроме глаз). Мне он на вскидку ничего не скажет. Может быть ты найдешь что-нибудь интересное.
Увы, я шейдерами занялся начиная с GLSL  Embarrassed
Logged
Gildor
Administrator
Hero Member
*****
Posts: 7764



View Profile WWW
Re: Околодевелоперские байки :)
« Reply #12 on: February 10, 2010, 17:28 »

Последний UE3 это тот, что использовался в GOW2 ?
В принципе - да. И в UDK. В UT3 такого ещё нет.

Quote
Значит ли это, что если я захочу загрузить пакеты с моделями и анимациями скажем из Gears of war в UT3 или наоборот они будут коректно загружены и будет возможность их использовать ?
Увы, в UT3 прописана минимальная версия загружаемого пакета (есть такой параметр в движке, причём при компиляции автоматом старый код отсекается). Так вот, в UT3 она прописана на 1 больше чем версия PC Gears of War. Если бы они такого не сделали - можно бы было загрузить. Но некоторые типы ресурсов не менялись в этом промежутке - можно обмануть движок: руками подправить версию будто она новее, и тогда пакет должен подхватиться.


Quote
Да понятно. На надо ли такой функционал лицензиату движка ?
Этот функционал доступен всем.

Quote
Неграмотно это не последовательно ? Cache unfriendly ? Smiley
Нет. Неграмотно - это человеком, который имеет представление об "эффективном коде" по книжкам о программировании на C++ Wink Я частенько критический код проверяю дизассемблером.

Quote
А на какой архитектуре построен xbox360 ? Сама ос на сколько я помню там модифицированный w2k.
Да, там есть функции из Windows. Но и дофига чего убрали, ещё больше - добавили. Memory mapping там нет - потому что на xbox360 нет механизма виртуальной памяти.

Quote
Отдельно скажу на счет хватает памяти или нет. Ты как человек потрошивший уе (кстати, чем ? ida ? driver studio ? Smiley)
IDA конечно Smiley
Quote
и анализировавший код q1/q2/q3 ведь понимаешь, что собственно приложение работает лишь с виртуальной памятью. Оно не знает, где именно находится страница с которой оно работает. Вспомни, как в q1 делался touch в hunk менеджере по всей выделенной памяти Wink 'Хватает' физической памяти или нет это исключительно выбор менеджера страниц в ос с его алгоритмами. Политика использования страничных файлов/девайсов в том же linux и win очень сильно отличается. Так что я бы сказал здесь просто - depends Smiley
Если виртуальной памяти нет - считай, что виртуальный адрес совпадает с физическим.
Hunk.Touch видел. Это трюк, заставляющий физически выделить память, а не просто зарезервировать.
Вообще - я не понял, в чём здесь вопрос? Да, механизмы виртуальной памяти в DOS32, Windows и Linux отличаются. На XBox360 её нет. Честно Smiley

Quote
Локи есть ?
В UE3 есть стриминг и асинхронное чтение. Ты об этом?

Quote
Пожалуй. На самом деле можно мапить страницы с возможностью записи и copy-on-write и получить возможность записи прямо в эти страницы. Правда тогда нужно подумать об увеличении размеров замапленного региона. Если не ошибаюсь, это можно сделать. Вобщем для простоты в отдельный буфер пжалста Smiley То же самое сделает и код сериализации приведенный тобой в пример - распаковка все равно будет происходить где-то в стороне.
Я считаю, что memory mapping прироста скорости не даст. Если я читаю весь файл за 1 вызов read или через memory mapping - время будет потрачено одинаковое, но кода во 2м случае будет намного больше.

Quote
Но вцелом я понял, что ты фанат паттерна сериализации Smiley
Паттерны не использую и не знаю. Я не любитель умных книжек по C++ Smiley
Мне нравится архитектура UE. Она очень грамотно написана, очень удобна и расширяема (например, UE3 всё ещё содержит код из UE1). И судя по тем исходникам, что есть в сети (например, ut436pubsrc) движок писался не по Стоуструпу, а по уму Smiley
Logged
vedmysh
Newbie
*
Posts: 14


View Profile
Re: Околодевелоперские байки :)
« Reply #13 on: February 10, 2010, 18:12 »

Quote
Увы, в UT3 прописана минимальная версия загружаемого пакета (есть такой параметр в движке, причём при компиляции автоматом старый код отсекается). Так вот, в UT3 она прописана на 1 больше чем версия PC Gears of War. Если бы они такого не сделали - можно бы было загрузить. Но некоторые типы ресурсов не менялись в этом промежутке - можно обмануть движок: руками подправить версию будто она новее, и тогда пакет должен подхватиться.

Хитро придумано Smiley Функционал есть, но заблокирован Smiley

Quote
Этот функционал доступен всем.

В доступности сомнения нет. Есть сомнение в его практической нужности команде, реализующей что-то на unreal warfare.

Quote
Нет. Неграмотно - это человеком, который имеет представление об "эффективном коде" по книжкам о программировании на C++ Wink Я частенько критический код проверяю дизассемблером.

Ну это когда уже станет ясно, где он, критический код.
preemptive optimization is evil (c) Smiley Как то так.

Quote
Если виртуальной памяти нет - считай, что виртуальный адрес совпадает с физическим.
Hunk.Touch видел. Это трюк, заставляющий физически выделить память, а не просто зарезервировать.
Вообще - я не понял, в чём здесь вопрос? Да, механизмы виртуальной памяти в DOS32, Windows и Linux отличаются. На XBox360 её нет. Честно Smiley

Про xbox360 нет никаких сомнений. Кроме того я как то и не думал о xbox360, потому как дела с консолями вообще то не имел. Странно, что ты акцентировал внимание на коробке. Есть опыт разработки под него ?
В чем вопрос ? Там был не вопрос был Smiley Только сомнения на счет твоих слов сравнительной неэффективности и по сути не нужности mm механизма, при всем при том, что даже если физической памяти будет достаточно это совсем не отменяет пейджинг для этого приложения Smiley

Quote
В UE3 есть стриминг и асинхронное чтение. Ты об этом?

Не совсем, ну да не суть.

Quote
Я считаю, что memory mapping прироста скорости не даст. Если я читаю весь файл за 1 вызов read или через memory mapping - время будет потрачено одинаковое, но кода во 2м случае будет намного больше.

Я склоняюсь, что все же depends... И больше плюсов в сторону mm Smiley Впрочем это легко "померять" Smiley
Возни с инициализацией несколько больше, да. Но совсем не страшно Smiley

Quote
Паттерны не использую и не знаю. Я не любитель умных книжек по C++ Smiley
Мне нравится архитектура UE. Она очень грамотно написана, очень удобна и расширяема (например, UE3 всё ещё содержит код из UE1). И судя по тем исходникам, что есть в сети (например, ut436pubsrc) движок писался не по Стоуструпу, а по уму Smiley

Хорошо что я не c++ geek Smiley А то бы сжег тебя на костре за такие слова Smiley
Лично для меня играет роль прежде всего результат. Производительность, стабильность, затраты. А как это было достигнуто уже не важно. Победителей не судят Smiley
ps А что такого плохого у Страуструпа ? Smiley Как по мне Джеф Элджер гораздо приятнее пишет Smiley
pps Как то плавно мы скатились с анимации в UE на... гхм... на околодевелоперские байки SmileySmileySmiley
Logged
Gildor
Administrator
Hero Member
*****
Posts: 7764



View Profile WWW
Re: Околодевелоперские байки :)
« Reply #14 on: February 10, 2010, 18:26 »

Ну это когда уже станет ясно, где он, критический код.
preemptive optimization is evil (c) Smiley Как то так.
Я против того, чтобы некритичный код писался гм ... "через одно место"

Quote
Про xbox360 нет никаких сомнений. Кроме того я как то и не думал о xbox360, потому как дела с консолями вообще то не имел. Странно, что ты акцентировал внимание на коробке. Есть опыт разработки под него ?
Я акцентировал внимание потому, что UE3 работает кроме PC ещё и на консолях. Поэтому они обязаны использовать то, что пойдёт везде.
А опыт разработки - да, есть Smiley

А про memory mapping ... Я считаю, что в игрушках его использовать нет смысла.
Logged
Jump to:  

Powered by SMF | SMF © 2006-2009, Simple Machines LLC
Leviathan design by Bloc | XHTML | CSS