Скорее всего меня тоже броня спасала от чумы, вот.
Новости по проекту.
а. Король карлов не хочет умирать на Судном Дне, поэтому попытается построить себе надёжный бункер. Так что если он вообще будет избран, и доживёт, есть шанс встретить его после апокалипсиса.
б. Также оптимизировал немного быстродействие рассчёта мира.
Пара гиф-записей, из симулятора внутри редактора.
На ускоренной симуляции жизни видна типичная ячейка общества.
Он добывает дерево, руду, строит дома, куёт экипировку и конструирует Эту Свою Бомбу.
Она рожает ему ребёнка.
На второй записи на той же лабораторной арене можно наблюдать некоего червяка. Большого и сильного. Он сражается за свою жизнь и за своё потомство!
Обе записи сняты с экрана как есть, однако симуляция жизни была пущена со значительным ускорением. Видно, что мир не стоит на месте. Он меняется, жизнь борется за жизнь, сильнейшие дают потомство.
Немного поныть:
Думаю, бессмысленно пытаться сделать "еще одну игру мечты", потому что мечта - она ведь одна. Я не имею в виду вернуться к Двадцатке, но вернуться к Tgomd. Не знаю насколько эта мысль полезна с т.з. разработки, но она всё никак не дает мне покоя.
sb3d
>> а найденого гранита 0, что ж, может увеличить его количество
> Да, наверное нужно будет добавить.
Можно сделать все интереснее и добавить червя (или нескольких?), который ползает по всей карте и иногда какает гранитом, а после смерти оставляет целый блок.
Мне понравился графический стиль (в главном первом посте).
Есть фан-арт, выкладывать?
я как считал мигающий меч плохим визуальным решением (со времён... вора в ангбанде?), так и считаю.
0cd2bdbaac
> Не знаю насколько эта мысль полезна с т.з. разработки, но она всё никак не дает
> мне покоя.
Как в стартпосте сохранилась фраза, "есть желание что то делать". Этого достаточно, на самом то деле. Остальное это не нужные философии. Игра мечты она, или не мечты, как двадцатка, или не как, это всё на результат не влияет.
keks546
> Есть фан-арт, выкладывать?
Конечно, почему нет. Только под спойлер.
batment
> Можно сделать все интереснее и добавить червя (или нескольких?), который
> ползает по всей карте и иногда какает гранитом, а после смерти оставляет целый
> блок.
Так и хотел вначале сделать, но как то получается несвязно. Гранит вроде древняя порода, а не кал червя. Так и не сделал.
мул
> я как считал мигающий меч плохим визуальным решением (со времён... вора в
> ангбанде?), так и считаю
А какие альтернативы есть?
Плывущие вверх циферки урона? Фубляпопса.
Мигание сражающихся сторон? Слабо наглядно, не понять сразу, чего они мигают.
Красивые какие нибудь эффектики взрывчиков? Но я же не vap, мне это не интересно сейчас.
Расскажи про альтернативы, годные для рога.
Короч я все последние дни упарываюсь оптимизацией.
Скрины с профайлера.
Замеры сделаны примерно на 60-секундном участке работы.
Поэтому если время выполнения функции более 60-ти секунд, она либо многопоточная, либо системная, а их профайлер не ловит нормально.
Интереснее всего, конечно, замеры во время выполнения AI, рассчёта жизни мира. Тут видно, что чёртов поиск пути, а вернее подготовка к поиску пути занимает неприлично много. А всё почему? Всё потому, что слишком тяжёлый анализ доступности клетки мира для существа. Тут вид сбоку, многие существа ходят по стенам, многие и по потолку. Поэтому анализ блока, может ли существо на него вступить, он долгий. Проверяем, есть ли рядом стены, есть ли потолок, пол. Лестница как отдельная проверка, с неё ведь не падаешь, как с обычного блока задника.
Я у тебя вижу в коде в некоторых местах повторяющиеся выражения, идущие подряд. Не пробовал их оптимизировать, записывая промежуточные результаты во временные переменные? Или они не критичные?
А почему определенным клеткам не прописываешь флаги типа рядом стена/пол/потолок, и при изменении ландшафта на одной ячейке менять флаги на 8 вокруг, а поиск пути будет брать инфу напрямую с уже просчитанных ячеек.
VoidSpirit
> Я у тебя вижу в коде в некоторых местах повторяющиеся выражения, идущие подряд.
> Не пробовал их оптимизировать, записывая промежуточные результаты во временные
> переменные?
Если ты о тех, что на нижнем скриншоте, то это только замедлит.
Вот тот участок:
for (int x_lo=0; x_lo<sizx_lo; x_lo+=2){ // _body of the area pixels loop *( Dst_lo+stx_lo+x_lo+0)=*( picPal+*( Src_lo+x_lo+0)); // get and unpac paletted colour, and store to dest *( Dst_lo+stx_lo+x_lo+1)=*( picPal+*( Src_lo+x_lo+1)); // get and unpac paletted colour, and store to dest }
Потому что компиляторы сегодня все слишком умные, и повторяющиеся выражения такого рода и без моего напоминания стараются рассчитывать один раз. А вот если им явно указать, что надо сначала рассчитать адрес, запомнить его, то это компиляторам может помешать. Они не смогут оптимально распределить всё по регистрам и по своим там правилам.
Так что на самом деле одна из задач низкоуровневой оптимизации - не мешать компилятору. Давать ему такой код, который не сломает его оптимизационную думалку. В большинстве случаев это код минималистичный и простой, что называется в лоб. Его компилятор сразу поймёт, а значит хорошо соптимизирует.
SR000
> А почему определенным клеткам не прописываешь флаги типа рядом
> стена/пол/потолок, и при изменении ландшафта на одной ячейке менять флаги на 8
> вокруг, а поиск пути будет брать инфу напрямую с уже просчитанных ячеек.
Интересная мысль, не проверял.
Но блоки меняются очень часто по самым разным алгоритмам. Игрок, монстры могут менять их, лава течёт, одни блоки превращаются в другие, обрушение там всякое. Поэтому придётся такую проверку вставлять везде и повсюду, при каждом изменении блока.
Навскидку, это лишь замедлит: смотри, сейчас физика блоков уже тяжелее. Строчка выше, 7.00 против 6.74. Это можно толковать так, что физика блоков уже меняет их чаще, чем они проверяются при поиске пути. Поэтому перенеся нагрузку определения в физику блоков, вероятно только замедлим.
sb3d
> В большинстве случаев это код минималистичный и простой, что называется в лоб.
> Его компилятор сразу поймёт, а значит хорошо соптимизирует
Было бы интересно посмотреть, что в итоге в ассемблерном виде. И да - сказанное тобой относится к тому, что основную массу операций в данном случае вообще можно вынести за пределы цикла?
А также - x_lo+1 заменяется на x_lo|1 учитывая, что x_lo всегда четное.
VoidSpirit
> Было бы интересно посмотреть, что в итоге в ассемблерном виде.
Вот этот цикл в версии от визуал студии 2012.
--
for (int x_lo=0; x_lo<sizx_lo; x_lo+=2){ // _body of the area pixels loop *( Dst_lo+stx_lo+x_lo+0)=*( picPal+*( Src_lo+x_lo+0)); // get and unpac paletted colour, and store to dest *( Dst_lo+stx_lo+x_lo+1)=*( picPal+*( Src_lo+x_lo+1)); // get and unpac paletted colour, and store to dest }
--
$LL43@GBputAllDi: ; 2611 : *(Dst_lo+stx_lo+x_lo+0)=*(picPal+*(Src_lo+x_lo+0)); // get and unpac paletted colour, and store to dest movzx eax, BYTE PTR [ecx-1] lea edx, DWORD PTR [edx+8] mov eax, DWORD PTR [ebx+eax*4] mov DWORD PTR [edx-8], eax ; 2612 : *(Dst_lo+stx_lo+x_lo+1)=*(picPal+*(Src_lo+x_lo+1)); // get and unpac paletted colour, and store to dest movzx eax, BYTE PTR [ecx] lea ecx, DWORD PTR [ecx+2] mov eax, DWORD PTR [ebx+eax*4] mov DWORD PTR [edx-4], eax dec esi jne SHORT $LL43@GBputAllDi
Как видим, всё красиво, аккуратно. Глаз радуется.
--
--
> А также - x_lo+1 заменяется на x_lo|1 учитывая, что x_lo всегда четное.
А теперь проверим это.
Получился адов надмозг. Компилятор не смог его понять и сгенерировал кашу.
Протестировал и скорость. Быстродействие упало со 195 до 288 (условных единиц времени).
То есть такой маленький выверт убил скорость вывода спрайтов на треть!
--
$LL43@GBputAllDi: ; 2611 : *(Dst_lo+stx_lo+x_lo+0)=*(picPal+*(Src_lo+x_lo+0)); // get and unpac paletted colour, and store to dest movzx eax, BYTE PTR [edx+esi] mov ebx, DWORD PTR _picPal$1$[esp+108] ; 2612 : *(Dst_lo+stx_lo+(x_lo|1))=*(picPal+*(Src_lo+(x_lo|1))); // __MODIFIED__ get and unpac paletted colour, and store to dest mov ecx, edx mov eax, DWORD PTR [ebx+eax*4] or ecx, 1 mov DWORD PTR [edi], eax movzx eax, BYTE PTR [esi+ecx] add ecx, ebp mov eax, DWORD PTR [ebx+eax*4] mov ebx, DWORD PTR _Dst_lo$1$[esp+108] add edx, 2 mov DWORD PTR [ebx+ecx*4], eax mov ebx, DWORD PTR _sizx_lo$1$[esp+108] lea edi, DWORD PTR [edi+8] cmp edx, ebx jl SHORT $LL43@GBputAllDi
sb3d
> Потому что компиляторы сегодня все слишком умные, и повторяющиеся выражения
> такого рода и без моего напоминания стараются рассчитывать один раз. А вот если
> им явно указать, что надо сначала рассчитать адрес, запомнить его, то это
> компиляторам может помешать. Они не смогут оптимально распределить всё по
> регистрам и по своим там правилам.
Утверждение само по себе голословное, стоит сравнить с помощью
Project settings -> C/C++ -> Output Files -> ASM List Location
или в GCC
gcc -S -o my_asm_output.s helloworld.c
Тема в архиве.
Тема закрыта.