Roden Croft, спасибо конечно , но OpenAutomate я пересобирал уже. Но всё же попробовал твои либы: не помогло

x64 компиляторы для ЗП: https://yadi.sk/d/WCDt_Q_MbbwtV

Изменения xrLC + xrDO_light:
~ сохранение текстур переделано с nvdxt на nvtt
! убрана надпись LevelBuilder из лога
! процессор детектируется правильно
+ добавлен ряд новых ключей запуска (-norgb, -nosun)
+ при отсутствии текстур (tga, thm) xrLC слетает не сразу, а по окончании фазы загрузки
+ поддержка x64

xrLC также обходит инвалид-фейсы (ключ -skipinvalid), есть настройка качества компиляции лайтмапов (ключ -lmap_quality).
В архиве имеется xrAI, понимающий build.cform от нового xrLC.

количество потоков (3/4/8...) все также не зависит от имеющегося числа ядер?

K.D., спасибо! Теперь модмейкерам будет проще!

HikeR, в ЗП - зависит. По числу ядер берется, если разговор про просчет геометрии. На освещение фиксировано 6 потоков, на adaptive ht - зависит от объема геометрии, может быть до 8.

а смысл? 8 потоков на 4-х ядерном проце работают медленнее, чем 3 потока на том же проце (если не считать время на "досчитывание", когда в конце остается 1-2 задачи).
правда я на маленьких картах проверял, на бОльших, возможно, эта разница нивелируется за счет общего времени.

Обновление компиляторов для ЧН: https://yadi.sk/d/A5jXXuyibbyLk
Исправил нерабочий ключ -norgb и еще что-то мелкое.


Спрашивай у авторов.

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

По компилятору ЗП
не обходит инвалид-фейсы хотя ключ -skipinvalid прописывал

БолотныйДоктор, пардон, действительно. Обновил по ссылке выше, вот компилятор отдельно: https://yadi.sk/d/NYDDRx0zbc2Ds

K.D., pdb файлы зачем в архиве? Без них и так работает...

Мало ли кому отлаживать вздумается ..

K.D., спасибо , а можно приложить (и к будущим ревизиям) ещё свои исходники конкретно компиляторов? Под будущие сторонние правки, если таковые вдруг будут.

ЗЫ: Вообще потенциально очень пригодилась бы ещё возможность останавливать компиляцию в любом месте (с сохранением текущего результата, хотя бы в рамках уже завершённых стадий), с возможность продолжить компиляцию при следующем запуска.

Насколько структура xrLC позволяет реализовать такую задумку?

Интересно, а ребята из GSC хоть раз собирали и тестировали X-Ray на XBoX 360?

В общем скомпилил вчера оригинальные болота компилятором x64, компилилось 7 часов, так же и на 2010 компиляторах. Винда x64. Почему нету разницы? Трава xrdo x64 компилилась 6 часов 0_0

K.D.
Проверил компилятор, по моему как был так и остался, локация в лям полигонов, компилилась 40 минут, так же было и на обычном компиляторе, следил все время за процессом, компилятор больше 1.8 гига оперативки не кушал, хотя у меня все 8

Мне тут люди говорили, мол, ПЫС говорили, что в ЗП был полностью играбельный затон на этом ящике.

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

как раз такие все это присутствует

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

Поставь -lmap_quality 99, например.

А почему должна быть-то?


В логе пишется сначала, какая текстура обрабатыватся ("processing "), далее, при ее отсутствии "cannot find thm/tga".


Нет, нужна локация с 1,8 и более статических вершин (не MU).

K.D., кстати, а какой диапазон в ключе -lmap_quality? 0-100?

Специально не ограничивал.

K.D., есть предложение все собранные тобой компиляторы запостить где надо с описанием и ссылками.
Хотя-бы, тут.

Shoкer +1
64 разрядные сборки компиляторов позволяют собирать большие пространства, если код компилятора позволяет. Там вроде не просто нужно собрать, там нужно всё подробно пересмотреть на предмет типов данных. Вроде использования 64 разрядных чисел за место 32 разрядных и так далее(можно заменить на итераторы(здравствуй работа с шаблонами), если уже не заменены).

Ну у ТЧ компилятора увеличивается, и намного)

В 4 раза с -norgb

krovosnork,

Да и без ключа не слабо, не по 3 дня и три ночи компилил, а за сутки и меньше.

Билдоман, да, время экономит конкретно. Ещё бы сдк х64, что-бы с большими локами нормально работать

krovosnork,
И движок X64, чтобы эти локи кушал)

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

Shoкer,
у меня

Крашит игру, а у вас? , в оригинале норм...

Что за чудеса

Другие говорят ничего сложного. Тут в общем нужен комментарий человека знающего матчасть.

Подождём К.Д.

компилировал локацию тестовую 64х компилятором ЗП, запускаю вылет



Думал что то с материалами, глянул проверил, все дефлаут.
Скомпилил по новой вылет такой же только цифра другая



Компил эту локу обычным компилятором все работает.

БолотныйДоктор,

ключ -lmap_quality юзал? Без него возможны вылеты, в ТЧ x64 вылеты на локах были.

x32-ТЧ-компиль вообще древний и слабо оптимизированный, наверняка в x64-исполнении добавились новые оптимизации, поэтому и быстрее. А ЗП-шный x32 и так оптимизирован еще пысами, поэтому по скорости с x64 серьезных отличий быть не должно.


А какие преимущества даст x64-движок? Из минусов - что игра пойдёт только на win7 x64. Даже на древней XP в игре любой локе на полной динамике хватает 2gb памяти. А если когда-нибудь создадут нечто мегакрутое не идущее на XP, то запустив x32-движок на win7x64, процессу будет доступно уже 4gb памяти. То есть, по памяти x32-движка пока хватает выше крыши.

Это ещё почему? XP и Vista же ведь тоже были под x64.

А вообще, реально нет смысла делать движок под x64, он и без того тянет все склеенные в одну локации.
Правда пустые, но я не думаю что кто-то когда-то будет делать нечто такое большое с сюжетом и заселением.
Ибо будет долго грузится, да и чтоб нечто такое запилить придётся делать x64 СДК...

Достал скелет из шкафа - засунь обратно.

Материала не хватает, обычное дело.


Код изначально непереносимый - взять хотя бы классы, в которых хранятся указатели и экземпляры которых при этом сохраняются в файлах байт-в-байт. Не говоря о том, что древние версии луа-говна типа LuaJIT 1.1.4 не рассчитаны на компиляцию под x64 "из коробки".

Я тут покрутил малость потоки, получилось немного ускорить xrLC. На i5-3570 прирост был процентов 5-10, на двух "спаренных" Xeon X5650 - в два раза ускорилось. Вывод - компиляйте, дети, на дофигаядерных процессорах

https://yadi.sk/d/gyb1Z5_Abd8kN

ну тогда сам хрей тоже надо... Он постарше winXP будет.

К.D. я тебе говорю не при чем тут материал, дело в компиляторе, я на своем стандартном компилирую, твой новы 64х компилит ну игра не запускается, компилятор выдумывает какие то материалы под разными цифрами и пишет что у меня их нет.

Я встречал такие же вылет пару лет назад и они всегда были из-за недостающего материала в gamemtl.xr

На Win7 x64 Live компили не завелись (как в свое время и x64 для ТЧ), выдают ошибку 0xc000007b. Зато xrAI.exe даже на XP запускается. Нет возможности заделать xrlc под msvc*80 и d3dx9_31? Или хотя бы только под d3dx9_31, чтобы протестить.

Не хватает какой-то библиотеки, наверное, рантайма какого-то.


Это от 2005 студии, что ли? Пожалуй, можно, но точно не сегодня.

Подобный вылет, как у товарища Болотный Доктор.



В gamemtl.xr прописывал данный материал, безрезультатно.

Может, у нового xrlc проблемы с путями/fs*.ltx, и он не видит gamemtl.xr? Попробуй fs*.ltx засунуть к нему в bin.