Sidebar

Новые компиляторы уровней для Xash3D

FiEctro

Супер Модератор
Команда форуму
Супер Модератор
28.07.06
17 167
33
  • Золотая медаль 213
  • Neh
Дядя Миша сказав(ла):
Между прочим, если я всё же соберу компиляторы в один экзешник, то они будут называться bsplib. А если оставлю в разных, то пока не придумал.
А почему lib? Ведь это исполняемый файл. Кстати в параноевских компиляторах тоже ошибка с названиями есть, когда компилятор не находит папку с моделями, он сообщает Error в консоль, хотя логичнее бы было написать там Warning, ведь это не обрывает компиляцию. Впрочем это всё мелочи.
 

nemyax

тндайпц тра
Команда форуму
Модератор
30.07.15
643
25
18
Дядя Миша сказав(ла):
в каждом окошке можно будет указать
compiler.exe -csg mapname
compiler.exe -bsp mapname
compiler.exe -vis mapname
Ты сделаешь csg отдельным шагом? Что у него будет на выходе?
 
Команда форуму
VIP
28.03.10
15 566
315
83
Кубань
  • Золотая медаль 215
  • Серебряная медаль 214
  • Золотая медаль 221
  • Cat
2 ZhekA: пока не решил, вот у вас спрашиваю.

Post automatically merged:

2 nemyax: ну мне отдельный csg не нужен, но может всякие оболочки для компиляции и редакторы неадекватно это воспримут?
Да и потом на данный момент я не могу это объединть, тут выяснилось, что до зонеров многое сломала сама вальва. Причём некоторые баги настолько критичные, что вообще удивительно как ей удалось собрать столько уровней для халфы.
 
Останнє редагування:

FiEctro

Супер Модератор
Команда форуму
Супер Модератор
28.07.06
17 167
33
  • Золотая медаль 213
  • Neh
Дядя Миша сказав(ла):
тут выяснилось, что до зонеров многое сломала сама вальва. Причём некоторые баги настолько критичные, что вообще удивительно как ей удалось собрать столько уровней для халфы.
Ну вон вспомни как в хл:альфе полигоны из под носа пропадали :)
 

mittorn

Active member
22.04.10
1 229
22
38
Для кривых хаммеров можно создать 4 батника. Так что делай а 1 по возможности.
 
  • Like
Reactions: Qwertyus
Команда форуму
VIP
28.03.10
15 566
315
83
Кубань
  • Золотая медаль 215
  • Серебряная медаль 214
  • Золотая медаль 221
  • Cat
Оказывается я был неправ по поводу Зонеров. Ну то есть прав конечно, но лишь отчасти. Половину багов в компиляторах посадила сама вальва.

Post automatically merged:

И эта. Походу совмещённая тулза "всё-в-одном" отменяется. Дело тут в следующем: csg и bsp собраны с двойной точностью флоата, а vis и rad - с одинарной. Если отключить двойную точностью в двух первых - перестанут собираться всякие микробраши и микрофейсы на ваших картах. Если включить двойную точность в двух последних, то на первый взгляд не произойдет ничего особенного, но в халфе радиосити считается через патчи, которых очень-очень много, на больших картах. И если там все вектора сконвертятся в даблы, то размер патча вырастет вдвое, а значит и потребление памяти, следовательно мы быстрее приблизимся к лимиту в 2GB. Да и сами даблы работают медленее флоатов. Можно конечно заморочиться, позаменять все vec3_t на float[3], но у меня нет такой самоцели, непременно запихнуть компиляторы в один экзешник.
Так что наверное откажусь.
 
Останнє редагування:
Команда форуму
VIP
28.03.10
15 566
315
83
Кубань
  • Золотая медаль 215
  • Серебряная медаль 214
  • Золотая медаль 221
  • Cat
Нимножка новостей с буржуйских фронтов: https://forums.svencoop.com/showthread.php/44536-Modified-version-of-VHLT-34
Во первых они создали на базе моего кастом-билда ветку на джит-хабе и назвали иё UMHLT :) А во вторых, они подтверждают, что в 34-м билде очень тормозной рад.
От себя добавлю, не только тормозной, но и интерполяция слегка поломана. Впрочем надо сравнить с более ранними билдами. Поскольку китаец не юзал SSE, у меня подозрения что ни один его рад не будет быстрее вальвовского оригинала. Вскрытие покажет.
А китаец умер :(
Знаете, вот был фильм какой-то или даже несколько фильмов, про то как чувак находит батылку с джином, тот ему исполняет желания, а потом он конечно загадывает самому научиться исполнять желания и его помещают в батылку, а джин наоборот освобождается. Я к чему - может не надо было делать кастомных билдов. Китаец слинял, а они теперь меня будут доставать.

Post automatically merged:

Просто нет цензурных слов.
Я скачал разные версии кетайских канпиляторов, начиная с билда v28, совсем старые версии качать смысла не вижу - я помню, там беднова китайца в 10-11м годах буквально засыпали жалобами что всё глючит, плющит, там практически багхантинг в диалоговом режиме шёл. К тому же слабая динамика различий между номерами версий даёт основания полагать, что и там особо ничего не менялось. Итак наслождаемся. Каждый скрин называется по версии vhlt, qrad - это то, над чем я щас работаю.

Post automatically merged:

На что обратить внимание. Резкое изменение картинки между vhlt30 и vhlt31 - это китаец ввёл блур-фильтр конечной лайтмапы и даже немного замылил разрывы.
Обратите внимание, как пятно от сурфлайта лезет назад - это скорее всего попытки сгладить дот через ремаппинг. Но полоска вверху имеет всего 6 пикселей, а значит лайтмапа будет всего однопиксельной полоской и между соседними полигонами будет нарушено сглаживание. Это не решается на уровне рада, это скорее работа для CSG, не допускать появления полигонов с однопиксельными лайтмапами, иначе подобных уродливых артефактов не избежать. И потом никаким блуром это уже не загладить.
Но в общем и целом положительная динамика изменений практически отсутствует. Вот только блур ввели и всё загладили. "Звёздочки" на местах попадания света обусловлены отсутствием умножения на 2, как в оригинальном раде. А потом их просто размулякали блуром.
Теперь по быстродействию: скорость работы китайского рада колеблется от 26 (лучший результат), до 35(наихудший результат) секунд. Вальвовский рад работает 9 секунд...
Выводы пока делать рано, но кое-какие подозрения начинают получать подтверждение. Кстати, прощу обратить внимание на выпуклую колонну, ту часть возле потолка. Лайтмапа флипнута.

Post automatically merged:

А мы продолжаем. Как вы понимаете, глупо надеяться создать самые лучшие компиляторы в мире, не изучив подробно все существующие аналоги. Но поскольку все аналоги берут начало от ZHLT, то чем-то особенным похвастаться не могут.
Я протестировал ZHLT 3.4, SHLT 3.9 и ajrad от немца (глухого?). К тому же, представилась возможность проверить SSE2-версии.
Правда версия ZHLT 3.4 SSE2 не завелась, но SHLT 3.9 SSE2 заработал как надо.
Итак результаты: fpu zhlt 3.4 - 36 секунд, SHLT 3.9 SSE2 - 30 секунд, SHLT 3.9 with AO - 60 секунд :shock: SHLT 3.9 + ajrad - 1 минута 36 секунд, абсолютный слоупок. Это время работы рада, если кто вдруг не понял. Теперь по скриншотам. Фирменная фишка ZHLT и её наследников - это грязь. Грязь там скорее всего из-за использования sparse визматрицы, но ребята с какого-то перепуга уверены, что она лучше. Оригинальная визматрица 1.3 мегабайта, sparse - 14 мегабайт и даёт вот такую грязь. Китаец, вместо того чтобы выбросить sparce - начал бороться с грязью и даже почти победил. Но время компиляции так и осталось на уровне 26-36 секунд. Правда есть еще MHLT (Merl Half-Life Tools) и (XP-Cagey Custom Build), причём от последнего у меня сугубо приятные впечатления, но возможно это синдром туалетного утёнка, т.к. ощущения относятся к 2005-му году, когда я еще вставлял код после ретарна.
Если вы поможете мне найти эти компиляторы, то я их конечно тоже взапроверю с удовольствием. Теперь ответ на вопрос, который у вас вероятно возник - нахрена я тестирую компиляторы на простейшей геометрии c1a0d? То-то и оно, что на простейшей геометрии эти сраные компиляторы выдают тонну багов, которую так никто и до сих пор не поправил. То есть спервоначалу надо на элементарной геометрии эту срань починить, причём не разблуривая результат, для маскировки артефактов, а на фундаментальном уровне. а уж потом тестировать что-то серъезное. Потому что в текущем виде, это немое кино и глухие немцы, а не компиляторы.

Post automatically merged:

PS. Случайно узнал, что SHLT расшифровывается как Super Half-Life Tools. Ну да, по время обсчёта освещения - абсолютный чемпион.

Post automatically merged:

Нашёл в старых билдах ксаша версию MHLT 1.7. Впрочем могу напутать, возможно что это MHLT XP-Cagey. Время работы достаточно быстрое, может потому что я сам их компилил шестой студией?. Ну вообщем рад управился всего-навсего за 29 секунд. XP-Cagey я найти так и не смог, да наверное уже и незачем. Всё что я хотел - я уже увидел. Теперь посмотрим что можно сделать с этим дерьмом.
 

Вкладення

Останнє редагування:

mittorn

Active member
22.04.10
1 229
22
38
вряд ли 6 студия может давать хорошо оптимизированный код. Компилятор без векторизации не может работать быстрее чем на векторном процессоре. Несчастный vhlt rad собранный с векторизацией под sse2/sse3/sse4/avx у меня работает в 3-4 раза быстрее оригинального qrad. Просто ты наверно даже не пробовал портировать компиляторы современными компиляторами с векторизацией.
А то что на sse-компиляторах прирост незначительный - либо тогда ещё векторизация хуже работала, либо её не было и векторизировали вручную. Там в исходниках прям sse код или просто скомпилировано было другим компилятором?
В 2017 году компилятор больше знает о SIMD процессорах чем человек пытающийся выполнить его работу. Компилятор оценит размер блока и определит, вычислять этот блок через SIMD тратя на загрузку туда время или обычным способом.
Ещё можно попробовать задействовать openmp вместо реальной многопоточности - такой компилятор позволит обрабатывать большие карты не на одном ядре, но не увеличивать при этом потребление памяти в n раз. Скорость компиляции будет ниже чем при штатной многопоточности, но выше чем на одном ядре. gcc умеет автораспарралеливание, достаточно просто добавить специальную опцию, может даже не надо будет код править
 

ncuxonaT

Well-known member
05.05.13
1 221
51
48
2 Дядя Миша:
Оффтоп
 

FiEctro

Супер Модератор
Команда форуму
Супер Модератор
28.07.06
17 167
33
  • Золотая медаль 213
  • Neh
2 mittorn:
Кстати да, даешь многопоточную компиляцию на CPU и компиляцию освещения на GPU :D
 

Slux

Well-known member
20.06.06
5 922
38
  • Золотая медаль 311
  • Tux
  • Серебряная медаль 311
Правда есть еще MHLT (Merl Half-Life Tools) и (XP-Cagey Custom Build), причём от последнего у меня сугубо приятные впечатления, но возможно это синдром туалетного утёнка, т.к. ощущения относятся к 2005-му году, когда я еще вставлял код после ретарна.
Если вы поможете мне найти эти компиляторы, то я их конечно тоже взапроверю с удовольствием.
Есть такие.
http://rgho.st/6Mj8kWkGY
 

mittorn

Active member
22.04.10
1 229
22
38
2 FiEctro:
добавь опцию -fopenacc при сборке и оберни самые жручие функции в соответствующие директивы. Правда, это будет работать только на linux и nvidia.
https://ru.wikipedia.org/wiki/OpenACC
[hide]
Post automatically merged:

2 Дядя Миша:
Вот лучше не говорить что китаец умер, если он не умер. А то шутили у нас в беседах, мол одного человека сомалийские пираты наверно распиратили, а через пару месяцев выяснилось...
[/hide]
 
Останнє редагування:
Команда форуму
VIP
28.03.10
15 566
315
83
Кубань
  • Золотая медаль 215
  • Серебряная медаль 214
  • Золотая медаль 221
  • Cat
В аттаче приложил lights.rad

Post automatically merged:

2 slux: благодарю

Post automatically merged:

2 mittorn: давай ты эту свою ахинею где-нибудь в другом месте будешь распространять, ок?
 

Вкладення

Останнє редагування:

GNU/Hurt

Maïté
05.03.14
1 092
25
38
>Скорость компиляции будет ниже чем при штатной многопоточности
Это с чего это? OpenMP при компеляции разворачивается в обычные команды для порождения тредов, более того, вроде-как создаёт тред-пуулы, а не порождает потоки каждый раз.
 

ncuxonaT

Well-known member
05.05.13
1 221
51
48
2 Дядя Миша: благодарю.
У меня вот так выходит. Со швами пока всё печально.
 

Вкладення

Game Server

Доноры Красавчики

Користувачі онлайн