Сделал меню с регулировкой различных настроек постпроцессинга в реалтайме. В будущем будет специальная энтити, в которой маппер будет прописывать эти настройки, и по активации они будут плавно применяться игрокам. Неплохой художественный инструмент.
Появились кое какие интересные данные.
Где-то приблизительно 1-2 недели назад, мне Креозот зарепортил о проблемах при компиляции карты. Компилятор падает с out of memory, это притом что свободной памяти в системе есть как минимум несколько гигабайт, чего более чем достаточно. Путём недолгих разбирательств выяснилось, что дело в фрагментации памяти. В качестве эксперимента, я решил прикрутить менеджер памяти mimalloc, что успешно сделал. Осталось его хорошо протестировать. Но есть еще один момент. На системах, начиная с Windows Vista, есть такой механизм как ASLR, который при запуске процесса рандомизует базовые адреса модулей, в т.ч. системных библиотек. И вот я решил поглядеть, что же такое половинит огромные куски свободной памяти в адресном пространстве. Это оказались системные библиотеки . И если для 64-разрядных процессов это не сыграет никакой роли в плане фрагментации, ибо адресное пространство там огромнейшее, то на 32-разрядных процессах оно вставляет палки в колёса. Причём, системе не важно, собран ли файл старым компилятором, который про ASLR понятия не имеет, либо же новым, и там включен ASLR - система все равно, по умолчанию, будет грузить библиотеки по рандомным адресам. Хотя это поведение отключаемое. А вывод какой: если бы была возможность собрать приложение под 64 бита безо всяких переделок, то не пришлось бы с этим всем возиться. То есть в будущем надо все таки обязательно весь код портировать под 64 бита, чем я когда-то начал заниматься, но пока не закончил. Переделать всё, это ещё ладно, надо ещё всё тщательно протестировать.
Для использования ASLR исполняемые файлы требуется собирать со специальными флагами. В результате в коде не будут использоваться постоянные адреса, но при этом:
увеличится размер кода исполняемых файлов;
увеличится время загрузки в память каждого исполняемого файла;
возникнет дополнительная несовместимость с ПО и библиотеками, разработанным под версии ОС без ASLR.
Чтож, по предварительной информации, mimalloc не дал значимых преимуществ в преодолении фрагментации в 32-разрядных процессах. А поскольку выключать ASLR во всей системе только ради того чтобы работали компиляторы это не вариант, остаётся лишь портировать компиляторы под 64 бита. Иных вариантов нет.
SNMetamorph писал: Чтож, по предварительной информации, mimalloc не дал значимых преимуществ в преодолении фрагментации в 32-разрядных процессах
У тебя память на уровне системы случайно фрагментирована в момент запуска. Какого чуда ты ожидаешь от пользовательской приблуды, основанной на всё том же маллоке?
Цитата:
SNMetamorph писал: поскольку выключать ASLR во всей системе
Ты точно читал, то что я привёл?
Цитата:
Дядя Миша писал: Для использования ASLR исполняемые файлы требуется собирать со специальными флагами
Пересобери исходники без ASLR. Или ты полагаешь что принудительный распил памяти для всего софта не похоронил бы новую винду в глазах её пользователей уже в момент выхода?
SNMetamorph писал: Причём, системе не важно, собран ли файл старым компилятором, который про ASLR понятия не имеет, либо же новым, и там включен ASLR - система все равно, по умолчанию, будет грузить библиотеки по рандомным адресам. Хотя это поведение отключаемое.
Я ж писал про это уже
Добавлено 30-10-2022 в 00:56:
Цитата:
Дядя Миша писал: Пересобери исходники без ASLR.
Это влияет только на модуль самой программы. На остальные модули, типо системных библиотек, это никакого влияния не оказывает. Они так и будут грузиться в рандомные адреса. Я это уже проверил
Добавлено 30-10-2022 в 01:04:
Чтобы не быть голословным, я запустил HLMV который был собран шестой студией, разумеется она понятия никакого не имеет об ASLR. И что же мы видим:
Оригинальный p2rad тоже падает с нехваткой памяти на системе с ASLR?
Я помню строго обратное поведение. Там где на той же XP не хватало памяти, на 64-х битной системе это же 32-х битное приложение вполне комфортно себя чувствовало. Пример - Stalker. Lost Alpha. Очевидно в данном случае все эти распилы ей шли только на пользу.
Добавлено 30-10-2022 в 12:38:
Кстати. Вот еще что вспомнил. Кто как не знаю, но лично я с незапамятных времён укрепился в мысли, что ни одну винду без предварительного твикинга юзать вообще невозможно. Поэтому после установки запускаю подходящий твикер и долго-долго отключаю там всякую пердь. Вполне вероятно что и ASLR я тоже таким образом отключал, но он скрывался под какой-то общей галкой, оптимизация потребления памяти может.
Это очень много на самом деле. Соптимизировать бы. Я просто знал, что у меня впереди XashNT, поэтому не стал возиться с ним бесконечно.
Там-то лайтмапер в десятки раз лучше оптимизирован. Он у меня радиосити на сталкеровских картах рассчитывает, причём с luxel_size = 8, chop=64.
По предварительным данным тестов, праймовские 64-битные компиляторы собрали карту ЧАЭС за 10 минут, а оригинальные p2st собирают её за 1 час 7 минут. Причём, в p2st генерация kD-trees происходит намного быстрее, чем в прайм-компиляторах. Но зато прайм-компиляторы гораздо быстрее считают саму лайтмапу (именно на этот процесс уходит больше всего времени в случае с p2st).
Добавлено 31-10-2022 в 22:04:
Но это не имеет значения, до тех пор пока я не убедюсь что результат в обоих случаях валидный.
Дядя Миша писал: Насколько я помню, он с ней управлялся за несколько минут. Но это конечно только прямой свет.
Жуть. Когда будет поддержка GPU?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Что ж, попробовал я в прайме запустить карту ЧАЭС. И при запуске вылетает с out of memory где-то в коде создания кэша коллизии. Вообще точно та же проблема, что была с компиляторами карт, и тут ясно было что причина в фрагментации памяти. После чего портировал код под 64 бита - тщательных тестов пока не проводил, но и ни на какие проблемы не наткнулся за всё время. На 64 битах карта всё-таки запускается где-то 1-2 минуты. Из проблем, пожалуй, коллизия криво сгенерилась местами, но тут как я понял вина старого PhysX SDK. Оперативной памяти отожрало ровно 2 гигабайта. Ещё не очень понравилась лайтмапа на моделях, местами есть разного рода артефакты, местами всё ок. Уж не знаю, в чём причина, это сама карта так скомпилирована (я запускал карту из тестового пака для P2) или же это какие-то косяки в рендере. Скриншоты я приложу
| IP: 
19-09-2022 21:09
. И если для 64-разрядных процессов это не сыграет никакой роли в плане фрагментации, ибо адресное пространство там огромнейшее, то на 32-разрядных процессах оно вставляет палки в колёса. Причём, системе не важно, собран ли файл старым компилятором, который про ASLR понятия не имеет, либо же новым, и там включен ASLR - система все равно, по умолчанию, будет грузить библиотеки по рандомным адресам. Хотя это поведение отключаемое. А вывод какой: если бы была возможность собрать приложение под 64 бита безо всяких переделок, то не пришлось бы с этим всем возиться. То есть в будущем надо все таки обязательно весь код портировать под 64 бита, чем я когда-то начал заниматься, но пока не закончил. Переделать всё, это ещё ладно, надо ещё всё тщательно протестировать.
