Редактирование движка X-Ray

[Tron 53]

Архитектуру никогда не поздно менять

Вспомните, что Сталкер это клиент-серверная игра, там нужны общие ддлки. А еще есть SDK. Наверное GSC знали, как делить, или нет?

Никто не запрещает линковать зависимости статически.

 

[Tron 53]

Как мне кажется, Elz имел в виду то, что при разбиении движка на модули, сильно ускорится не сам движок, а процесс разработки, поиска ошибок и создания модов.

Хотя при должной оптимизации можно сильно ускорить и сам движок

Не имеет смысла по ряду причин:

1)Скорость работы не вырастет

2)Если бить на dll'ки могут возникнуть различные проблемы(например порча кучи. В теме про райнтайм,на gamedev.ru были дельные примеры этого,но потерли.-Так же там приводился пример когда гоняют различные stl объекты между модулями)

3)Бить на стат.либы смысла нет,кроме визуального.Линковаться будет столько же. Т.К по сути lib'файл это просто архив obj файлов,которые генерит компилятор для линкера.

Вот мне лично удобнее не смотреть в 100500 строк кода, а редактировать отдельные модули.. Так меньше шанс наделать ошибок да и проверять гораздо быстрее можно.

Хуже от разбития на модули быть не должно... А на сколько будет лучше... Вот сделаем, посмотрим)

Ну я даже не знаю,что сказать... про системы контроля версий слышали?

А вот если слинковать все статически,то финальный бинарник,может быть даже меньше всей папки bin.-т.к компилятор оптимизирует,и часть неиспользованного кода,как бы "выбрасывает". 

 

Яркая иллюстрация моим словам:-возьмите Ogre и какой-либо простой пример,слинкуйте сначала динамически,затем статически и сравните результат релиз конфигураций(в дебаге оптимизации отключены)

Изменено 25 Июня 2015 пользователем Tron

[Tron 53]

Тогда скажите в чём преимущество одной большой dll движка?

Чуть выше имелось ввиду,что на выходе будет только .exe файл(xrEngine который). 

при его создании как раз и пройдут те самые оптимизации(выбросится неиспользуемый код)

[Tron 53]

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

Может быть даже чуть-чуть быстрее(именно компиляция,т.к не надо запускать много раз cl.exe[это компилятор]).Но релизная линковка(link.exe[это линковщик]),да будет долгой

Можно еще быстрее сделать компиляцию(именно ее),если применить технику unity-build

[Tron 53]

Про unity-build:
http://habrahabr.ru/post/117663/

[Tron 53]

В идеальности было бы и быстрая постройка и оптимизация работы движка, но для всего этого ушла бы масса времени, да и кто за такое возьмётся? 

Я уже говорил,что в 1ую очередь можно попробовать избавиться от boost'a. т.к чаще всего именно он сильно влияет на время компиляции(от него зависит luabind). 

 

Для этого я уже приводил ссылку на luabind-deboosted. 

 

Кажется,кто-то из этого форума работал над обновлением luabind'a

[Tron 53]

О таком я не слышал. Можешь рассказать поподробнее? 

Выше ссылочку скинул.

В двух словах:

Пишется cpp файл(пусть будет unity.cpp),куда инклудятся другие cpp файлы. 

И вот этот unity.cpp включается в проект,остальные файлы исключаются из проекта(что бы не было множественно определенных символов)

[Tron 53]

Если речь про время сборки xrGame,то можно попробовать ускорить сборку,если экспорт в lua(где идет работа с luabind) вынести в отдельную длл'ку-именно он и занимает львиную долю.

Но тут наложатся следующие ограничения:
Нельзя редактировать хедеры xrGame-надо будет делать ребилд  и script-exports.dll
*Надо будет написать си функцию,которую поместить в dllmain для script-exports.dll,а потом делать LoadLibrary.

*-это пример реализации придуманный за 5 минут,можно придумать и более красивый способ

@krovosnork, часов шесть точно компилился, но до конца так и не собрал, ибо на гейм вечно терпения не хватает. 

а что за процессор?
Просто у меня следующие были замеры:
1)i7 4790K- ребилд ~10 минут

2)i7 4500U- ребилд ~30-40 минут

3)Core2Duo E6600- 3 часа

Сколько я собирал его на Athlon64 3500+ я не помню(возможно 3 часа,а на core2 1.5-не помню)

Для всех случаев,кроме Core2Duo и A64 ключ /MP сильно ускорял сборку.

Изменено 25 Июня 2015 пользователем Tron

[Tron 53]

@svarog2741,

 

На картинке часть уже отключено:
Чтобы полностью отключить:
​/O1 и /Os поменяй их на /Od(отключение оптимизации) и Nothing(кажется так)

Изменено 25 Июня 2015 пользователем Tron

[Tron 53]

@Tron, спасибо. Там уж разберусь, всё равно русская версия. 

 

Изменено 25 Июня 2015 пользователем Tron

[Tron 53]

Напиши,что за процессор,может тебе там действительно выгоднее использовать /Gm(Минимальное перепостроение) вместо /MP

@Tron, собирал два часа с отключенной оптимизацией, вырубили свет, психанул. Желание разбить гейм увеличилось... 

И сборка на каком этапе закончилась?Компиляция или линковка(если линковка,то проверь параметр /GL-он должен быть выключен для Debug)

Изменено 26 Июня 2015 пользователем Tron

[Tron 53]

http://prntscr.com/7ll6vj

Так это же Intel Core Solo,_не удивительно что так долго..

С долгой линковкой тут ничего не поделаешь_(особенно при Unity Build).

Попробуй сделать Unity-Build,_этап компиляции будет быстрее

Так же смысла в /MP тут особого нет,_отключай этот параметр и заменяй его на /Gm.

 

Если лень читать википедию,_то вот видео_(смотри с 5.56)

Изменено 26 Июня 2015 пользователем Kirgudu

[Tron 53]

 

Сравнение процессоров различных архитектур невозможно

 

Да,_не совсем корректно,_но можно сравнивать по производительности GeekBench_-_я сам им правда не пользовался,_но на CPU Boss им сравнивают

http://cpuboss.com/cpus/Qualcomm-Snapdragon-600-vs-Intel-Core-Solo-T1400

http://cpuboss.com/cpus/Qualcomm-Snapdragon-600-vs-AMD-Athlon-64-X2-5000

За пример взят Htc One M7.

 

Правда,_сам GeekBench ставит в некий ступор:

http://cpuboss.com/cpus/Intel-Core-i7-4790K-vs-Intel-Core-i7-3770K_-_тут ведет 4790K

А по Top10 уже ведет 3770K

 

Edit:_Разобрался_-_там сортировку по счету надо было включить_-_ведет 4790k

Но это все оффтоп

Изменено 26 Июня 2015 пользователем Kirgudu

[Tron 53]

Вопрос, память полностью высвободится?

Да, так удаляются массивы

https://ru.wikipedia.org/wiki/Delete_(C%2B%2B)

Как бы мало где. Нормальная сборка будет только на 2005, 2008 и 2010. Хочешь на 2013 - возись. 

https://bitbucket.org/nick_galko/callofpripyat/commits/branch/master

Давно было сделано, делается по аналогии с адаптацией под ЧН

https://bitbucket.org/stalker/clearsky/commits/branch/master  1ый коммит

 

Единожды исправив под 10(12)ку будет собираться везде

Изменено 3 Июля 2015 пользователем Tron

[Tron 53]

На сколько я знаю,

Во-первых, Havok платный.

Во-вторых, сталкер уже не тот будет, если так хочется такого, то тебе нужен юнити, анрил и прочие.

В-третьих, ты задолбешься Havok впиливать в двиг сталкера. При том, что, для начала, надо разобраться как был "впилен" ODE и выпилить его.

 

В общем начинка вычинки не стоит...

 

Но если интересно, то дерзай.

Из годных свободных физ. движков: 

Nvidia PhysX, Bullet Physics Library, а потом уже ODE...

 

Можно основные механизмы переписать только.

Там же ODE не дергается напрямую - там есть враппер(xrPhysics).

 

Интеграция хавока не сильно отличается от той же интеграции от PhysX.

 

 

Хавок для студентов как и все остальные, по законам США, для исследования движки должны предоставляться бесплатно.

Там очень много ограничений, и как по лицензии, так и по функционалу.

Тот, что лежит бесплатно доступным - это только модуль физики твердых тел

 

 

AnarchyDownloadManager_20150217.exe вот сам Хавок, только качнуть надо 900Мб осталось, нет трафика

Это Trinity Vision, а не Havok Physics

 

 

От Хавока надо провал в грунт, что бы, по самые помидоры, сталкер брёл в болоте и следы оставались.

Я переписывался с автором в 2009 году.

Он говорил использовать Hk5 ( не 2015, а именно 5ую версию ). - Это если будешь разбираться в Spin Tires, в любом случае код будет сильно отличаться в новых версиях (КЭП)

[Tron 53]

 

 

Ругается что луа_стейт не определен, инклуды все есть.

Если заметишь,то в каждом модуле есть свой lua_state(рендер, игра)
А Luabind,типичная темплейтная обертка - она существует только для 1 модуля, для других надо инициализировать заново.
Как альтренатива - поместить его и луа в отдельную длл,и обращаться к ней

 

 

Viнt@rь, ты втираешь мне какую-то дичь.

Да нет, дичь тут втираешь ты - все перепутал.

Havok, принадлежит интелу
PhysX, NV
Bullet, опенсорсный

В RAGE Engine, используется Bullet, а не PhysX
PhysX имеет неплохую CPU часть, которая выигрывает в производительности у Bullet (Полгода назад, на кружках видел ссылку на тест от тимлида EA). Но где там находится Havok по производительности не помню, а врать не хочется.

В Unity используется PhysX, просто в отличии от UE, он линкуется/линковался статически
Bullet очень далеко ушел от ODE
 

[Tron 53]

@Карлан, нет, нисколько.

Попробуй обратиться к этим методам - скорее, всего этого не получится(хотя они и будут экспортированы). - я с подобным столкнулся, когда писал скриптинг для своего движка.

По другому и не получится. Точнее есть один способ.. но он не комильфо...
Собираем как статик либу, но оставляем макросы export/import, в результате можно биндить и в других модулях.
Можно сделать как сделал я - поместить lua/luabind в Core и линковать ее (по сути отдельная длл у меня это она).

Или вот еще один пример:
Есть модуль Engine, есть gui(mygui. Прилинкован статически. Есть Get методы которые возвращают уже инициализированный указатель), базовая инициализация происходит в нем, но конструировать элементы gui, мы хотим в game.
Пытаемся обратиться - элементы по 1 вложенности доступны и работают... но последующие нет(например, система шрифтов).
(В myGUI все построено с использованием теймплейтной реализации синглетона.)

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

 

Изменено 25 Июля 2015 пользователем Tron

[Tron 53]

Трон, а кому движок писал? Ты чисто промышляешь под Сталкера или уже самостоятельное что то забабахал, не основываясь на сталкеровских наработках?

И где можно оценить твой труд?

Да все гораздо проще - тема диплома (и курсовых), в следующем году защищать.

(Безусловно, первый рабочий опыт в GD у меня был, проект можно найти в showcase)

В паблик, редко когда скидывал - тестил определенный функционал. В этом году сильно дебажил, попутно переписав часть подсистем.

 

Вообще с этими курсовыми странная ситуация произошла:

В 2014 тема трижды менялась - разработать главное меню (по аналогии с CS), потом сделай его на флеше (тыц1, тыц2), недоделав его (не была сделана отработка событий и загрузка из VFS движка) тему опять меняют -  на этот раз физика твердых тел (прикрутил physx).

В этом году должен был внедрить поддержку анимации, но засел дебажить и переписал рендер (с opengl2 FFP (фиксированный конвейер+шейдеры) -> =>GL4.3(на чисто шейдеры))

 

 

Самую старую демку(еще со старым автором), можно найти здесь

 

 

ты решил приобщиться к обществу на АМК?)

Ну можно и так сказать. Пока есть возможность, отдыхаю таким своеобразным образом.

 

 

Как там успехи с х64?

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

Вся ситуация осложняется еще тем, что иногда движок и не стартует. (раз из ~20 случаев, на другой конфигурации, с запакованной геймдатой)

А вообще было пару подозрительных мест.

 

И я вот не сильно пойму, зачем ты удалил кучу классов, артефакты там, монстры, кошаки?

Хотел разобраться как оно работает (что куда добавлять и т.д). Уже восстановил.

Изменено 26 Июля 2015 пользователем Tron

[Tron 53]

 

 

типа такого: запускаешь двиг, а он как зависший процесс висший процесс в диспетчере задач висит?

Нет,сразу крашится. - Я убрал bugtrap о чем жалею, но там выбора не было.

 

 

 

Написал бы об этом в коммитах на репо)))

Да,надо было бы. Я вечером все сделаю

[Tron 53]

Я смотрю тут либу одну, для Task-Based Threading

https://github.com/RichieSams/FiberTaskingLib

там есть и книжка, и презентация с GDC

EA STL отпиливается легко(Сам уже отпилил)

Так же есть подобная либа в составе физикса (см. в исходниках)

P.S привел пример,что бы не изобретать велосипед(TBB уже предлагали)