Lev писал: ncuxonaT С водой то как? Фпс ощутимо выше, чем со старыми отражениями?
В среднем процентов на 15. В каких-то адовых случаях может быть в полтора раза. Вообще для оптимизации можно много чего сделать. Например, делать окна одним куском, а не десятком
Дядя Миша что нужен будет делать с этим кодом? Внедрить в паранойю и компилятор и карты пересобрать?
ncuxonaT писал: Например, делать окна одним куском, а не десятком
Ну выгадаешь пару фпс в лучшем случае. А может и того не будет.
Там диллема. С одной стороны - оверхед на пересечённых областях, сделаешь одним куском - AABB захватит куда больший участок, чем сейчас.
Шило на мыло.
Цитата:
ncuxonaT писал: что нужен будет делать с этим кодом? Внедрить в паранойю и компилятор и карты пересобрать?
нет, карты пересобирать не нужно, этот код налету оптимизирует любое дерево. На сложнейших картах, типа сипульчера время работы около одной секунды, на маленьких, практически неощутимо. На выходе получается оптимизированное дерево, из 100 тысяч узлов получается 2-3 тысячи. Ну зависит от того сколько детайлов было использовано, но по факту можно оптимизировать деревья оригинальных карт, где некоких детайлов не было.
Смысл в том, чтобы потом использовать именно это дерево, а не оригинальное. Т.е. код сам по себе ничего не ускоряет, он просто даёт оптимальные дерево. Ключевой тормоз, который убивает фпс - это функция ENGINE_CHECK_VISIBILITY. Поясню почему так происходит.
дерево слишком подробное, там адское кол-во лифов. А стандартная энтить может вмещать только первые 16 лифов. В квейке на эту проблему вообще забили, типа ну влезло 16 и ладно. В халфе при оверфлове эти же лифы помечаются отрицательными значениями.
И при вызове функции ENGINE_CHECK_VISIBILITY вызывается Mod_HeadnodeVisible (название из ксаша). Для дерева в котором десятки тысяч лифов... И так - для каждого монстра, для каждой энтити, каждый кадр. Фпс убивает со страшной силой. Вопрос только в том, как бы этот симплификатор адекватно встроить в движок, я его на С++ писал.
Дядя Миша писал: Если вы с Психопатом настроены серъезно, относительно работ над игрой и рендерером, я потом с вами поделюсь кодом симплификации дерева, который фпс подымает в несколько раз. Правда совместимость пойдет к чёрту, но для вас оно некритично.
А что понимается под совместимостью? Халфовские монстры перестанут работать или оригинальные бсп из хл не запустятся? Если только второе, то этот магический код не помешало бы в ксаш-мод добавить, мне бы пригодился (карты открытые местами, приходится ограничиваться). Вот только я использую халфовских монстров.
Дядя Миша писал: Ну выгадаешь пару фпс в лучшем случае. А может и того не будет.
Там диллема. С одной стороны - оверхед на пересечённых областях, сделаешь одним куском - AABB захватит куда больший участок, чем сейчас.
Шило на мыло.
Думаешь, несколько вызовов glCopyTexSubImage2D вместо одного, а также сопутствующие расходы на передачу юниформов, биндинг текстур каждому куску и т.д. на фпс влияют незначительно?
Цитата:
Дядя Миша писал: Вопрос только в том, как бы этот симплификатор адекватно встроить в движок, я его на С++ писал.
Моих навыков для этого точно не хватит. Полагаю, как и навыков кого-либо из присутствующих.
SNMetamorph писал: Можно будет загружать карты голдсурсовского BSP формата и их симплифицировывать?
Дерево придётся куда-то сохранять, потом загружать - в два раза больше работы. Но можно и так. В компилятор встроить.
Цитата:
Aynekko писал: А что понимается под совместимостью?
бинарная совместимость с халфовскими библиотеками.
Цитата:
ncuxonaT писал: Думаешь, несколько вызовов glCopyTexSubImage2D вместо одного, а также сопутствующие расходы на передачу юниформов, биндинг текстур каждому куску и т.д. на фпс влияют незначительно?
Юниформы, текстуры биндятся один раз в начале секвенции отрисовки.
Если бы каждое стекло целиком копировало весь экран - там было бы что оптимзировать. Но вызывается subImage, и копируется только тот кусочек, который дебаг ограничивает жёлтым квадратиком. Поэтому вопрос только в том, насколько дорог сам вызов subImage. Второй момент - объединять имеет смысл только там, где ровный полигон порезало на части, например шаг лайтмапы. Это чисто мапперский косяк, надо в настройках подкрутить шаг разбиения лайтмапы. А рисовать смежные стёкла с одной копией экрана - так себе идейка. Потому что во первых финальный скиссор скорее всего будет больше площади отдельно взятых окошек, а во вторых тебе еще придётся гарантировать что эти поверхности относительно взгляда игрока ВСЕГДА лежат на одной плоскости, что для полупрозрачных поверхностей неразрешимая задача.
Т.е. ты на эту аналитику потратишь больше ресурсов чем выгадаешь.
Но дело твоё конечно - пробуй, потом расскажешь.
Цитата:
ncuxonaT писал: Моих навыков для этого точно не хватит
ну ты же как-то с Дельфи перескочил на С++? Значит способности есть.
Я вот к примеру Петон вряд ли смогу освоить, мне его автора придушить хочется.
Питон как будто нарочно делали, чтобы выбесить:
1. выбросили точку с запятой
2. выбросили фигурные скобки
3. комментарии начинаются с #
Но при этом основные ключевые слова по большому счёту остались теми же - return, if, else. Добавили лямбды, убрали типизацию. Вот нахрена так делать, спрашивается?
В Сишарпе наоборот ударились в другую крайность - зачем-то добавили из явы магическое заклинание public static void.
Как будто за каждым разрабом языка стоит дьявол-маркетоид и нашёптывает ему - испорти синтаксис, испорти.
В GLSL\HLSL подобной задачи не стояло, на удивление. И никто ничего не ломал.
Она опциальна, так-то ставь сколько хочешь. Так-то, как правило синтаксическая единица пишется в одну строку и эти точки с запятыми только загромождают текст.
Цитата:
выбросили фигурные скобки
Тоже спорный момент, загромождают текст сильно, но при этом дублируются отступами. Так-то они для словарей по назначению используются.
Цитата:
убрали типизацию. Вот нахрена так делать, спрашивается?
Не совсем убрали. Но вообще, python это не совсем язык, это скорее фрэймворк для прототипирования и рабочая среда. Что-то вроде очень продвинутой версии консоли с блекджеком и библиотеками на все случаи жизни. Заменяет собой матлабы, и прочие лабвью.
чем песочница лучше языка низкого уровня? Очевидно у каждого свои задачи.
Цитата:
thambs писал: Так-то, как правило синтаксическая единица пишется в одну строку и эти точки с запятыми только загромождают текст.
нет такого правила. Я к примеру инициализацию однобуквенных переменных в конструкторе очень часто пишу в одну строку.
C++ Source Code:
x = _x; y = _y; z = _z;
В любом случае полагаться на непечатный невидимый символ - так себе идейка. Особенно если учесть, что он бывает /r/n или просто /n
Цитата:
thambs писал: Тоже спорный момент, загромождают текст сильно, но при этом дублируются отступами.
А представь, что у тебя где-то вместо серии пробелов - табуляция. И что? Код не соберётся? Мне Ксер рассказывал за какой-то язык, где надо было прям жостка табулировать, иначе ошибка компиляции.
А загромождают код не фигурные скобки, а ключевые слова "конецЕсли".
Цитата:
thambs писал: скорее фрэймворк для прототипирования и рабочая среда
Я вот какую вещь заметил. Если на языке предполагается писать что-то большое, он скорее всего будет иметь Си-подобный синтаксис.
А если какие-то мелкие саброутины, там да в таикх языках каждый извращается как только может.
| IP: 
16-10-2020 16:42
