Язык Lua. Общие вопросы программирования

Dennis_Chikin · 4 Января 2015

С чего начинать и где взять.

Установка Lua:
http://www.amk-team.ru/forum/index.php?showtopic=11584&p=629106

Руководство «Программирование на языке Lua», третье издание:
http://www.amk-team.ru/forum/index.php?showtopic=11584&p=905308

Изменено 2 Марта 2015 пользователем Kirgudu

xStream · 28 Декабря 2011

Ну почему-же... Замыкания очень полезны, другое дело, что ты про них не знал Мне по работе приходится с ними работать в двух языках - и как раз в основном в колбеках (но не только!).

А пример я приводила как вариант замены твоим любимым 'uo' - вместо пачки переменных один объект-функтор. А) данные никак случайно не потеряешь, Б) защищены от изменения извне.

Для организации различных колбеков связка "безымянная функция + замыкание" вообще полезна очень. И не говори, что это теория. Это из практики. Все зависит от того, что ты хочешь реализовать.

А что касается "изюминки" - так в этом и есть суть топика: чем больше приемов знаешь, тем более эффективно можешь писать код. Пример один я привела.

Второй пример - диалоги имеют прекондишны, экшены и т.п. Фишка в том, что функции - first-class значения, их можно присваивать. Таким образом можно менять без каких либо мегаскриптов диалоги, меняя функции, например, так (все названия от балды):

dialog_functions.mega_dialog_1_rpg_precond = function () 
    ...
end

в файле dialog_functions функция mega_dialog_1_rpg_precond заменяется на другую.

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

ЗЫ "в файле" - физически текст не изменится Просто в рантайме такая замена сработает. При каждой загрузке, правда, надо восстанавливать.

Изменено 28 Декабря 2011 пользователем xStream

Artos · 28 Декабря 2011

xStream,

Раскрывающийся текст (Показать)

Прекрасно понимаю, что доказывать что ты (в смысле я) не верблюд - совершенно не зачем, но и не могу, почему ты все время предполагаешь в собеседнике худшее?

Если ты считаешь, что я вешаю лапшу на уши, стараясь побольше надуться - то ... переубедить конечно могу, но стОит ла тратить время на это и в очередной раз накалять градус диалогов?

Повторяю, про замыкания попался на глаза материал где-то полгодика назад. Заинтересовало, но, как часто бывает и не в тему было и не нашел полезного применения и, как то промелькнуло мимо енто дело ... Как в прчем и по таймерам, которые ты сейчас оформила в виде класса, а мною (плоский код) был заброшен до лучших времен. Но об этом может быть чуть позже ...

По "изюминкам":

Раскрывающийся текст (Показать)

Полностью тут согласен, чем больше будут появляться от участников форума/топика различные "изюминки" - тем конечно же и интереснее и полезнее для всех нас. Поэтому и сам порою подбрасываю такие "изюминки" ...

Но моя мысль была ранее о том, что (не принимай на свой счет полностью!) негоже превращать изюминки в панацеи и стараться навязывать их применение везде и всегда и в неизменном виде. Также не следует голословно и/или демагогично отвергать то, что предлагает другой.

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

Т.о., считаю, что делиться своими находками в дебрях Lua (иль кодов игры) - стОит как можно чаще, не увлекаясь мелочевкой и не хая 'не свое и не по-вкусу'.

Осмелился все же пристроить предложенный вариант твоего таймерного класса к своим кодам (помимо класса событийных таймеров на базе ивент-класса). Сейчас как раз, закончив адаптацию всего мода, ударился в исследования связки безымянных функций и замыканий (как ты приписываешь мне - в теорию). Получаются порой довольно интересные варианты использования ... если что-то откопаю действительно заслуживающее внимания относительно игры или кодинга - обязательно поделюсь.

По 'uo': любовь к этому варианту привили как раз АМК-коды ;-), но, по большому счету, вообще то не очень то мною любимы (именно в форме разно-колличественных кучек значений), т.к. по-возможности я их переделывал в таблицы с нужыми по-случаю параметрами. Так что, то, что ты сейчас называешь 'заменой пачки', собственно уже ранее в плоском коде было оформлено во многих вариантах как массив. сейчас мне очень просто было портировать все это под ООП.

Но в отличии от тебя, я не считаю 'защиту извне' таким уж преимуществом ... Не спорю, это порой очень востребовано, но порою и мешает. Тут как говорится - зависит от контекста и задачи/цели.

Вот по применимости безымянок к диалогам - спасибо(!) В очередной раз даешь пинок в сторону искоренения различных аттавизмов в кодах мода/игры. Как то задался целью перевести многие диалоги на скриптовые формы, уйдя от закостенелых html-ек, но ... трудоемкость надолго уронила желание ковыряться с портированием диалогов.

Вот если бы еще найти вариант вмешетельства в дерево уже сформированного при загрузке диалога ... было бы совсем интересно перелопатить диалоги и писать по-новому (но это уже больше к игре относится а не к Lua).

Кстати, вариант с таймерами на базе родительского класса ивентов очень и очень неплохо показал себя в кодинге и в игре. Если учесть, что у меня под него все уже было ранее реализовано (сохранения/загрузки, оптимизации и пр.) то удобство и фукциональность возрасли, с сохранением надежности и малой ресурсоемкости. Несмортя на твое отрицательное к этому (к связке) отношение - все же большое спасибо за начальную идею! :-)

Изменено 28 Декабря 2011 пользователем Artos

xStream · 28 Декабря 2011

Хочу только одно сказать: ты мне пытаешься приписать категоричность утверждений. Например про "защиту" переменных. Это неправда. Я просто перечисляю все вытекающие последствия при таком подходе. И пожалуйста, давай не будем вспоминать, что АМК (ввели эту хрень как раз мы с Ред75) используют юзер-обжекты. Ибо это было давно и мы ведь как раз говорим об уходе от старых решений, громоздких, как паровая машина на фоне ДВС или дизеля. При любом раскладе функторы компактнее, лаконичнее и удобнее, чем массивы и организация синхронизации этих самых юзер-обжектов.

Остальное не буду комментировать, ибо это возвращение к закрытой теме.

Изменено 28 Декабря 2011 пользователем xStream

Artos · 28 Декабря 2011

xStream, предлагаю прекратить комментировать и транслировать высказывания не по теме топика. Не пытаюсь ничего приписать или задеть. Я просто дал некоторое уточнение по теме (о защите из вне), которое на мой взгляд имеет для меня значение и по истории появления 'uo'. Не более ...

Но и опять готов не согласиться с категоричным с твоей стороны утверджением о:

Цитата
При любом раскладе функторы компактнее, лаконичнее и удобнее, чем массивы и организация синхронизации этих самых юзер-обжектов

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

Добавлено через 19 мин.:

Хотел бы опять уточнить небольшой момент по применению выбранного варианта получения идентификаторов для реализации в таймерах:

В текущем исполнении идентификаторы будут линейно возрастать до бесконечности (до ограничения по разрядности в движке). Так же для чего в таблицу заносить идентификаторы строкою, а не числом?

Ведь этот вариант вполне пригоден:

код (Показать)

timers_holder = {}

function check_timers(e)
  for _,tmr in pairs(timers_holder) do
    if t.trigger_time and t.trigger_time <= time_global() then
      event("timer_"..t.id):trigger()
    end
  end
end

--/ ---------------
class "timer"
--/ ---------------
function timer:__init()
  self.__once = true
  self.id = self:gen_id()
  timers_holder[self.id] = self
end

function timer:gen_id()
  local id = 1
  while timers_holder[id] ~= nil do
    id = id +1
  end
  return id --/> текущий индекс (для имени таймера)
end

...

и позволяет держать значения индексов в разумных пределах, переиспользуя уже использованные индексы.

Или я опять некий нюанс упускаю? (не считая небольшой потери производительности при выборе очередного идентификатора)

Изменено 28 Декабря 2011 пользователем Artos

kamikazze · 28 Декабря 2011

Artos

Цитата
Данное решение как раз и создает единый счетчик-распределитель, который ты предлагаешь встроить в каждый вызов. Мда ... уж.
Ну похвастай как это у вас на евентах реализовано, утри нос неумехе! ;-)

Во-первых, не в каждый вызов, а только в те что на апдейте - их на самом деле никогда не бывает особо много. Во-вторых, это у нас уже реализовано ещё с версии 0692 было без всяких евентов. А с евентами это реализуется просто до ужаса, Артос. Берется обработчик евента апдейта в скрипте, в самое его начало ставится увеличение счетчика на 1. А после него - деление величины счетчика на нужное число. Если делится без остатка - прогоняем, если нет - return. Настройка частоты прогона производится легко и непринуждённо сменой делителя, сам код - две строки. Можно этот малюсенький код в функцию выделить и проверять вернёт она true или false. И всё. Ничего не надо ни изобретать ни перестраивать. Какие события должны быть на каждом апдейте - там не ставим сей код. Где надо ставим и настраиваем делитель. И никаких заумных "распределений по времени" с помощью единого "счетчика-распределителя". Тебе же нужно будет ещё и неписям апдейт распределить и монстрам (это кстати гораздо сильнее разгрузит игру чем актор). И что, под каждый поток евентов ты собираешься мастырить отдельный диспетчер с рассчетом времени исполнения и динамической регистрацией/отрегистрацией? А не боишься что итоге этот твой диспетчер будет работать медленнее самих событий? И что в отладке утонуть будет просто можно.

P.S.

Артос, умерь пыл. Я битву за производительность начал ещё несколько лет назад, и могу тебя уверить - нагромождения диспетчеров тебе не помогут. Только ухудшат ситуацию. Используй только самые простые из возможных решений, не городи огромный доп. функционал - потом самому придется резать.

xStream · 28 Декабря 2011

2Artos

То ты призываешь давать конкретные примеры в конкретных ситуациях, то ударяешься в общие случаи. Ты уж определись. Панацеи не бывает. И я не навязываю никому ничего. Есть техника, я попробовала пример привести (лично тебе, я так поняла, вообще никакие примеры не работают, увы).

Все

Ты одновременно и частность охватить пытаешься и все сразу. Нельзя идти во все стороны разом. Есть техника, есть конкретный пример. Данные из функтора не нужно вынимать, так как они, в первую очередь, если вспомнить назначение юзер-обджекта, используются только внутри него же. Ты сейчас пытаешься спорить в общем... Не надо. Я спорить не собираюсь ни с кем. Это слишком нервный процесс.

Про замыкания сказала, про безымянные функции - тоже. Про классы - очень большой и отдельный разговор. Тут примеры надуманные вряд ли приведешь. ООП в скриптах сталкера не было никогда. Только для наследования, но мы это не берем в расчет. Я на этом внимание акцентировала. Потому что объекты таких классов не используются нигде. Только как сами по себе.

-----------------

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

Другое дело, что в реализации, которую я представила, создаются ивенты с уникальными именами. Это неправильно. Но на то и пример. Он акцентирует внимание на другом.

Изменено 28 Декабря 2011 пользователем xStream

Artos · 28 Декабря 2011

xStream, именно "засорение" таблицы итемов и имел ввиду (в первую очередь) говоря о разрастании значений индексов, а не про оптимизацию (ведь наоборот произвоительность при выборе падает).

Т.е. выбранный вариант - это только тех-оснастка примера, как я понял. Хотя цель записывать в таблицу таймеров именно по строчным ключам (""..id) - осталась непонятна, что отвлекает от основной цели примера.

Изменено 28 Декабря 2011 пользователем Artos

xStream · 28 Декабря 2011

Строчные ключи для "страховки". Специфика работы ЛУА... (изначально я реализовывала на table.remove, а это приводит к перенумерации числовых индексов) Я перестраховалась в данном случае. Вот откуда строковые ключи.

Цели примера: таймеры как объекты (ну не нужны им методы ивентов, не соглашусь с тобой, хоть убей), вложенные события - одни "выстреливают" другие, безымянные функции и замыкания (в принципе функторы - см. переменную local proxy = self и колбек с использованием этой переменной).

Кстати, очень хороший вопрос подняли - производительность. У "уберштуцернагибателей" есть существенная проблема - просадка производительности, если служебный код (менеджеры всякие, диспетчеры) обвешен кучей проверок и исполняется дольше, чем полезный, рабочий код. Вот это - действительно важный вопрос. Его бы обсудить, но тут примеров то и нет, и быть не может.

Изменено 28 Декабря 2011 пользователем xStream

Artos · 28 Декабря 2011

По строковым понятно. Пытаюсь сейчас найти приемлемый вариант, чтобы и не мусорить и производительно ...

Ну а по производительности - то как раз почему же примеров нет. ;-)

Даже далеко ходить не нужно, те же таймеры, хотя и не совсем то, о чем ты говоришь ( ... обвешен кучей проверок и исполняется дольше, чем полезный, рабочий код), но и кол-во многочисленных коротких проверок вместо одной общей - тоже имеет отношение к производительности.

Взять тот же цикл для примера и представить что таймеров не один десяток/сотня:

Раскрывающийся текст (Показать)

function check_timers(e)
  for _,tmr in pairs(timers_holder) do
    if t.trigger_time and t.trigger_time <= time_global() then
      event("timer_"..t.id):trigger()
    end
  end
end

получаем, что все таймеры перепроверяются на достижение своего зачения.

На СП это уже обсуждалось и Gun12 тогда заметил (общий смысл): "А зачем каждый раз проверять все? Не достаточно ли вычислить ближайщее и ждать его? После чего определять следующее ближайшее и т.д.".

Этот вариант и реализован и вполне неплох. Так что экономить стОит и в таких мелочах (ИМХО).

Вот пример для указанного случая:

Раскрывающийся текст (Показать)

local nearest_time = nil

function check_timers(e)
  if nearest_time ~= nil then
    local current_time = time_global()
    if current_time <= nearest_time then
      nearest_time = nil
      for _,tmr in pairs(timers_holder) do
        if t.trigger_time then
          if t.trigger_time <= current_time then
            event("timer_"..t.id):trigger()
          elseif t.trigger_time < (nearest_time or 9^9) then
            nearest_time = t.trigger_time
          end
        end
      end
    end
  end
end

--/ ---------------
class "timer"
--/ ---------------
function timer:__init()
  self.__once = true
  self.id = self:gen_id()
  timers_holder[self.id] = self
end

function timer:gen_id()
  local id = 1
  while timers_holder[id] ~= nil do
    id = id +1
  end
  return id --/> текущий индекс (для имени таймера)
end

function timer:run(time_seconds)
  if self.trigger_time then
    return
  end
  nearest_time = 0 --/ reset!
  ...

Примечание: Тот же ранее приведенный пример с распределенным 1-о секундным апдейтом - из разряда аналогичных мелких оптимизаторов.

В принципе, этот вопрос (по производительности) скорее из категории незнания/не желания многих модмейкеров/кодеров вникать в глубину кода, и довольствуются наспех написанным, но рабочим ... Тут как раз брать примеры и тыкать бы носом, но ... результат будет скрее обратным. Т.е. вместо учебы - получаем обиды ...

Изменено 28 Декабря 2011 пользователем Artos

xStream · 28 Декабря 2011

Не надо пример с таймерами брать как жизненный, плиз :-D На то и пример, написанный за 10 минут, доведенный до рабочего состояния более-менее и имеющий чисто академическое назначение.

А в остальном я согласна - бесполезно, хотя это и очень важный вопрос.

Artos · 28 Декабря 2011

(обновил верхний пост, т.к. не успел до падения форума подправить)

xStream, пример с таймерами взят как один из типовых, а не некий написанный наспех и не имеющий целью быть включенным в рабочие коды как есть ... Мы же в топике по программированию, который читают и те, кто как раз и пишут в своих модах так, что еще похлеще с производительностью выходит ...

Кстати, думаю, что такие примеры тоже служат помимо хорошего дела и ... в виде медвежьей услуги. Поясню: ведь немало тех, кто заглянув и мало что поняв, хватают вот такие упрощенные коды и начинают их вовсю использовать ... У них заимствуют другие и ... так и расползаются технологические примеры-времянки в моды. :-(

Добавлено через 29 мин.:

P.S. Что-то у нас достаточно беспредметный разговор пошел ... Вроде как о важном/нужном, но ... только об общем. :-(

Вот ты говоришь, важно про произвоительность, а примеров нет. Н у а что мешает поговорить именно на примерах, только не на академических, на на реальных?!

Брать чьи-то давно вышедшие коды/моды - наверное достаточно буссмысленно. Ну так и давайте говоить о текущих!

Что мешает выкладывать на разбор полетов наработки? Мои текущие коды-наработки постоянно доступны и актуализируются не реже раза в месяц. Что мешает взять их в качестве примеров и врезать по полной программе за гриворукость иль за разгильдяйство? :-)

Что мешает выложить вам (вроде как и kamikazze сюда заглядывает и кидает реплики) выложить для обсуждения то, что отнисится к теме? Хотя бы ту же песочницу, чтобы не голословно утверждать иль намекать, а получить по полной программе за хороший иль корявый алгоритм? ;-) Вот и будет и тема и реальные примеры ...

Изменено 28 Декабря 2011 пользователем Artos

Artos · 28 Декабря 2011

kamikazze,

Раскрывающийся текст (Показать)

Вот никак уже полдня не могу понять как относиться к твоим словам:

Цитата
Артос, умерь пыл. Я битву за производительность начал ещё несколько лет назад, и могу тебя уверить - нагромождения диспетчеров тебе не помогут. Только ухудшат ситуацию. Используй только самые простые из возможных решений, не городи огромный доп. функционал - потом самому придется резать.

Неужели тебе не ведомо, что в отличии от вас (практически все моды), кто делает в онлайне по пол-года очередную версию мода, я делаю это на ходу и все, о чем говорю проверяется не только мною на практике? Твои слова звучат как некий совет начинающему моддмейкеру, который тольк оначинает что-то делать ... Уверяю тебя, за производительность я взялся не позже тебя и во многом и тебя могу уверить, но ... не голословно, а кодами на практике.

У нас вероятно разные взгляды и предпочтения в модинге. Если тебя устраивают тиражирование простеньких строчек, то мне интереснее именно избавляться от такого тиражирования и концентрировать в одном месте. И резать мне пока ничего не приходилось, а только наоборот, все более расширять роль общего центра-координатора и единых узловых менеджеров и снижать роль межмодульных взаимодействий, оставляя им тоько их функционал, а не общую для всех рутину.

И, смею тебя заверить, в отладке как раз гораздо все проще, т.к. лазить и ловить по разным скриптам/строкам гораздо менее продуктивно, чем все делать в одном месте.

Не находишь лы ты свои слова/советы сродни с тем, что например вместо одного компьютера - использовать десятка два простеньких калькуляторов? Может и в какой-то ситуации это и разумно, но ... и мне это не интересно и на "заумном" можно не только простенькое творить.

И при чем тут распределение апдейтов неписям? У тебя что на их апдейты и общие таймеры понавешаны и иные обще-игровые коллбэки?

Вот тут то как раз разумна аналогия с котлетами и мухами. Именно апдейт актора нуждается в максимальном внимании и максимальной разгрузке.

Ты хотя бы когда последний раз заглядывал в коды Симбиона? Пойми, все что ты говоришь - для меня уже давно пройденный этап и это во всех почти модах, и что я не считаю эталоном и тем более истиной в последней инствнции. И если для тебя, вероятно, решение с ивентами стало откровением и ты до сих пор в восторге от него, то я уже несколько лет использую, если и не ООП исполнение этого алгоритма, но на 90% схожее с ним и наработал опыт и по производительности и по отладке.

kamikazze · 29 Декабря 2011

Artos

Раскрывающийся текст (Показать)

Цитата
Неужели тебе не ведомо, что в отличии от вас (практически все моды), кто делает в онлайне по пол-года очередную версию мода, я делаю это на ходу и все, о чем говорю проверяется не только мною на практике?

А у нас ещё и штатом тестеров проверяется, потому что не даёт самостоятельное тестирование адекватного результата, он не репрезентативен.

Цитата
Уверяю тебя, за производительность я взялся не позже тебя и во многом и тебя могу уверить, но ... не голословно, а кодами на практике.

Ну давай в качестве примера, чтобы не быть голословным - выложи код функций IsStalker и IsMonster. Посмотрим что там у тебя - если что сразу подскажу одну очень важную фишку.

Цитата
Если тебя устраивают тиражирование простеньких строчек, то мне интереснее именно избавляться от такого тиражирования и концентрировать в одном месте.

Никакого "устраивает" или не "устраивает", Артос. Мы не NLC делаем, которое не мод, а арт-объект, который нельзя трогать, в который ни в коем случае нельзя играть, потому что это искусство - им надо любоваться, восхищаясь замыслом и видением художников. Я просто очень прагматичен в коддинге. Дело не в тиражировании и не в личных предпочтениях. Если есть два пути - первый это небольшой копипаст, зато кода минимум, он быстр и прост настолько насколько это вообще возможно, и второй - это огромная обработка с регистрациями/отрегистрациями и тому подобным барахлом - я выберу первый вариант. Потому что скорость его работы будет в 100-200 раз быстрее чем второго, это раз и он избавит от излишка писанного кода, это два. Голый рационализм.

Цитата
И резать мне пока ничего не приходилось, а только наоборот, все более расширять роль общего центра-координатора и единых узловых менеджеров и снижать роль межмодульных взаимодействий, оставляя им тоько их функционал, а не общую для всех рутину.

Прийдётся рано или поздно. Потому что нельзя систему усложнять бесконечно - рано или поздно будет достигнут предел энтропии, после которого это всё начнёт зверски сыпаться либо ужасающе тормозить. Ты начнёшь кодить очередной внутренний диспетчер-растормаживатель, ещё увеличивая комплексность кода и так до бесконечности - это замкнутый круг, неужели сам не видишь. Децентрализованные системы, в которых компоненты не зависят так сильно друг от друга гораздо стабильнее и быстрее чем одна монструозная, зато выполняющая все возможные функции.

В качестве простого примера - помнишь тогда разошлись в подходах на менеджер вооружений, с потерей оружия. Ты тогда начал изобретать телепорты ящиков с оружием и т.п. Я это решение сразу отмел как нерациональное и чересчур громоздкое. Так вот, я таки переделал менеджер. Теперь он вообще не использует ящики, совсем. И в нём нет ни одного оператора трансфера вещей, а сам код похудел на 30%. Итого - пропали вылеты e_parent && e_entity, скорость работы менеджера выросла в разы, все косяки с пропажей оружия решились. Всё это с полным сохранением функционала, ничего не отрезалось, работает всё отлично.

Цитата
И, смею тебя заверить, в отладке как раз гораздо все проще, т.к. лазить и ловить по разным скриптам/строкам гораздо менее продуктивно, чем все делать в одном месте.

Мне это вообще сейчас делать не нужно, у нас по факту вообще всё сейчас отлаживается автоматически.

Цитата
Не находишь лы ты свои слова/советы сродни с тем, что например вместо одного компьютера - использовать десятка два простеньких калькуляторов? Может и в какой-то ситуации это и разумно, но ...

Вот когда это разумно - надо именно этим и ограничиваться. Твоя, Артос, большая проблема в том, что ты упорно продолжаешь плодить сущности тогда когда надо бы уже остановиться, превращая наращивание комплексности кода в самоцель, отбрасывая рациональные решения как ересь. Научись использовать принцип Бритвы Оккама - не плоди лишних сущностей.

Цитата
И при чем тут распределение апдейтов неписям? У тебя что на их апдейты и общие таймеры понавешаны и иные обще-игровые коллбэки?
Вот тут то как раз разумна аналогия с котлетами и мухами. Именно апдейт актора нуждается в максимальном внимании и максимальной разгрузке.

Артос, биндер актора в игре ОДИН! А у неписей - у каждого по личной копии биндера. Личной, отдельной. Каждый апдейт запускающейся. Ты об этом не задумывался, не? Я когда ввёл распределение нагрузки для биндеров неписей, быстродействие игры выросло на 30%. Хотя там было всего 6 добавленных вызовов в этом биндере, не больше. На базе Свободы на АС, где до этой операции фпс на мощной машине держался в районе 25-27 кадров с секунду, резким скачком вырос до 35-37. Это всего лишь было сделано распределение нагрузки на биндер неписей. Аналогичное действие с биндером актора дало не более 10% прироста скорости. Хотя в нём намного больше вызовов. Вот и думай теперь. Ты за своим "максимальным вниманием" не видишь очевиднейших вещей.

Цитата
И если для тебя, вероятно, решение с ивентами стало откровением и ты до сих пор в восторге от него, то я уже несколько лет использую, если и не ООП исполнение этого алгоритма, но на 90% схожее с ним и наработал опыт и по производительности и по отладке.

Какое там откровение, подобная реализация в очень примитивном виде ещё в АМК была. Я её не использовал потому, что не-ООПшная её версия меня как-то ну вообще не радует и ни малейшего энтузиазма не вызывает. Ибо рогло унылое.

Изменено 29 Декабря 2011 пользователем kamikazze

xStream · 29 Декабря 2011

Давайте я еще хвост распущу Артос, то, что ты хвалишь, было придумано мной хз сколько времени назад и я, автор, заявляю об убогости решения, а ты со мной до упора пытаешься спорить

Ладно, скатываюсь в оффтоп. Пойду к НГ готовиться, чего и вам желаю.

Artos · 29 Декабря 2011

kamikazze, жаль, что все еще продолжаем достаточно беспредметный разговор на отвлеченные темы ... :-(

1. Что мешает тебе выложить свой вариант решения (если нашел изюминку) для других и сравнить/указать на недостатки иных?

Как уже сказал, свежие коды над которыми работаю всегда доступны и мог бы не просить выкладывать то, что быстрее взять, посмотреть и сделать выводы ... Ведь это у вас все недоступно из-за "секретности разработки" ...

Вот то, чем пользуюсь касательно IsStalker и пр.:

IsStalker (Показать)

tStalkerClasses = {
    [clsid.stalker]              = true,
    [clsid.script_stalker]       = true,
    [clsid.actor]                = true
    --[clsid.script_actor]         = true --/ STCS|SCoP
  }
  tMonsterClasses = {
    [clsid.bloodsucker_s]        = true,
    [clsid.boar_s]               = true,
    [clsid.burer_s]              = true,
    [clsid.cat_s]                = true,
    [clsid.chimera_s]            = true,
    [clsid.controller_s]         = true,
    --[clsid.crow_]                = true, --/#?#
    [clsid.dog_s]                = true,
    [clsid.flesh_s]              = true,
    [clsid.fracture_s]           = true,
    [clsid.gigant_s]             = true,
    [clsid.poltergeist_s]        = true,
    --[clsid.pseudo_gigant]        = true, --/#?#
    [clsid.pseudodog_s]          = true,
    --[clsid.psy_dog_phantom_s]    = true, --/#?#
    [clsid.psy_dog_s]            = true,
    [clsid.rat]                  = true, --/#+# SM_RAT
    [clsid.psy_dog_s]            = true,
    [clsid.snork_s]              = true,
    [clsid.tushkano_s]           = true,
    [clsid.zombie_s]             = true
  }

function get_clsid(obj)
  return obj and obj.clsid and obj:clsid() --/> iClassId
end

function IsStalker(object, iClassId)
  return tStalkerClasses[iClassId or get_clsid(object) or -1] == true
end
function IsMonster(object, iClassId)
  return tMonsterClasses[iClassId or get_clsid(object) or -1] == true
end

  tStalkerClasses = {
    [clsid.stalker]              = true,
    [clsid.script_stalker]       = true,
    [clsid.actor]                = true
    --[clsid.script_actor]         = true --/ STCS|SCoP
  }
  tMonsterClasses = {
    [clsid.bloodsucker_s]        = true,
    [clsid.boar_s]               = true,
    [clsid.burer_s]              = true,
    [clsid.cat_s]                = true,
    [clsid.chimera_s]            = true,
    [clsid.controller_s]         = true,
    --[clsid.crow_]                = true, --/#?#
    [clsid.dog_s]                = true,
    [clsid.flesh_s]              = true,
    [clsid.fracture_s]           = true,
    [clsid.gigant_s]             = true,
    [clsid.poltergeist_s]        = true,
    --[clsid.pseudo_gigant]        = true, --/#?#
    [clsid.pseudodog_s]          = true,
    --[clsid.psy_dog_phantom_s]    = true, --/#?#
    [clsid.psy_dog_s]            = true,
    [clsid.rat]                  = true, --/#+# SM_RAT
    [clsid.psy_dog_s]            = true,
    [clsid.snork_s]              = true,
    [clsid.tushkano_s]           = true,
    [clsid.zombie_s]             = true
  }

function get_clsid(obj)
  return obj and obj.clsid and obj:clsid() --/> iClassId
end

function IsStalker(object, iClassId)
  return tStalkerClasses[iClassId or get_clsid(object) or -1] == true
end
function IsMonster(object, iClassId)
  return tMonsterClasses[iClassId or get_clsid(object) or -1] == true
end

просвяти нас по "фишке", плз.

Моя "фишка" в том, что там, где другие ею пользуются я в 90% случаем уже не пользую, обходясь точечной проверкой или заведомо исключающим алгоритмом.

2. Почему то изначально в твоих постах делается вывод, что если у другого не так как у тебя - то это значит никак или не правильно.

О какой непрезентабельности тестирования не "штатными тестерами" ты гутаришь?

Иль штатный тестер вставит в коды счетсчики времен выполнения циклов ветвей и т.п и увидит цифры? Иль все те, кто не являясь штитными тестерами и постоянно гоняют в сборку симбиона не способны дать свою оценку?

Если ты нашел вариант для менеджера оружия "без ящика" то почему считаешь что у другого (у кого и не так как у тебя заведомо было сделано) все осталось так плохо?

У меня и не было ранее ошибок в менеджере оружия по парентам. И "ящик" у меня используется не столь для оружейного менеджера, сколь для иных алгоритмов и именно это так же снижает и затраты на коды/ресурсы и позволяет использовать отлаженные наработанные моменты не только в одном месте.

3. Предлагаю довольно простую вещь, собственно что и предложил ранее - возьми коды Симбиона (это всего менее 200 Mb), предоставь возможность взглянуть на хотя бы куски ваших текущих кодов по затронутым тут вопросам - и можно не голословно и с пафосом дать оценку или покритиковать.

Думаю, что это будет во 100 крат полезнее всем, и тебе и мне и всем читающим, т.к. и ошибки/недостатки могут вскрыться и поучиться будет чему ...

Иль жаба душит, что мол кодами может кто-то воспользоваться? Ну тогда вообще зачем вести подобные разговоры в публичном топике?

Обсуждать то, чего не знаю или осуждать/критиковать то, чего не видел - пустословие и критиканство ...

P.S. Года два назад, выйдя на рубеж не менее 50 FPS в любой ситуации в игре, мне остается только продолжать поддерживать новые коды в том же стиле и подчищать оставшееся.

Изменено 29 Декабря 2011 пользователем Artos

kamikazze · 29 Декабря 2011

Artos

1. Не из-за секретности, а просто потому что код, находящийся в состоянии разработки не имеет смысла выпускать. Ибо там могут быть грабли, по которым могут прогуляться другие, неосмотрительно за него взявшиеся.

Цитата
Вот то, чем пользуюсь касательно IsStalker и пр.

Всё верно, табличка. Что я и надеялся увидеть - эту фишку ты тогда точно знаешь. Просто в ТЧ там, равно как и в множестве других мест был быдлокод. Выполнение кучи if-else гораздо медленнее чем проверка по ключу таблицы и надо стараться использовать это везде где только можно.

Цитата
Почему то изначально в твоих постах делается вывод, что если у другого не так как у тебя - то это значит никак или не правильно.

Это ты такой вывод делаешь, Артос, не я. Я не говорю что "никак или неправильно". Я говорю что опасно, громоздко и медленно, за счет переусложнения. Переусложнение, излишняя комплексность - это зло. Проще надо быть.

Цитата
О какой непрезентабельности тестирования не "штатными тестерами" ты гутаришь?

Да банально... Артос, тестер это тоже профессия на которую нужен талант и навыки. У нас нехилый отбор в тестерскую команду, и ребята реально полезны. Плюс я точно уверен что у них всё в порядке с железом, машины не населены зверьём и результат не зависит от посторонних факторов. Простые юзеры тебе не дадут вменяемых результатов. В лучшем случае от них можно дождаться отчета в стиле "как-то медленно" или "стало лучше". Штатному тестеру не надо расставлять счетчики - я ему сам выдаю отладочный пакет с заданием на тестирование, он тестирует и скидывает мне аккуратные результаты.

Цитата
У меня и не было ранее ошибок в менеджере оружия по парентам.

Они там by design эти вылеты. Их можно победить опять же как двумя путями - нагородить кучу кода, либо использовать иной алгоритм, о котором Бак был не в курсе когда менеджер писал. Во втором случае всё очень сильно упрощается и сильно растёт производительность. Если ты использовал это добро с ящиками в другом месте с допиленной скриптовой обвязкой - ну что делать, пусть остаётся. Но я попозже зарелижу переделанный менеджер вооружений - оно того стоит, народу пригодится.

Цитата
Предлагаю довольно простую вещь, собственно что и предложил ранее - возьми коды Симбиона (это всего менее 200 Mb), предоставь возможность взглянуть на хотя бы куски ваших текущих кодов по затронутым тут вопросам - и можно не голословно и с пафосом дать оценку или покритиковать.

Уже думал об этом, но пока нет. Слишком много там ещё недопиленных решений находящихся ещё в разработке. Я не люблю светить такой код, сам прекрасно знаешь. На тему песочницы - у нас их сейчас вообще две. Одна xStream, другая, написанная ранее от Саши Маландринуса. Сейчас он работает над тем чтобы совместить плюсы первой и второй и сделать единую. Пока оно не будет готово ещё нет смысла спорить особо.

Цитата
Иль жаба душит, что мол кодами может кто-то воспользоваться? Ну тогда вообще зачем вести подобные разгворы в публичном топике?

Артос, если бы меня душила жаба за сырцы, то OGSE и компаньоны были бы вообще в компилированном байткоде Lua Я просто никогда не раскрываю разрабатываемый код - с проблемами в нём я могу в 99% случаев разобраться самостоятельно, а подкидывать лишние грабли народу ни к чему. Мне пока вообще не до песочниц... я сейчас вообще другим занят - создал на основе старого скрипта очень удобный инструмент - практически полный визуальный отладчик неписей - и отладил полностью стейтменеджер, а так же схему реакции на опасности. Итого победились (тьфу-тьфу) все родные проблемы игры с затупливанием неписей в одну точку после боя, с шухером по непонятным причинам, зависаниям схем поведения и тому подобной хренью. Впечатление теперь такое будто играешь в совершенно новую игру, настолько непривычно.

Изменено 29 Декабря 2011 пользователем kamikazze

Artos · 29 Декабря 2011

kamikazze, посмотри на название/шапку темы!

Тут все же не обсуждениенаших с тобою частностей, а топик по программированию и вопросам касательно этого.

Никому (кроме нас с тобою) не интересны неинформативные реплики "правильно иль неправильно", интересен сам код + комменты что и где правильно или что плохо и как это исправить!

Ну и что, что в IsStalker мною уже годика четыре используется именно выборка из таблиц? Ты дал другим информацию чем плоха выборка по условиям? Нет.

Ну привел я кусок кода, где и безопасность затронута (исключены вылеты при некорректных аргументах вызова) и оптимизирован сам процесс выборки - другим без пояснений это мало что говорит.

Давай давать комментарии по сути кодов, а не реплики "хорошо/плохо" ...

Ну и вот опять пошла демагогия:

Цитата
kamikazze: Я говорю что опасно, громоздко и медленно, за счет переусложнения. Переусложнение, излишняя комплексность - это зло. Проще надо быть.

Приведи конкретный пример того о чем ты уже не первый раз говоришь и все только тезисно. Ну ткни носом туда, где по твоему безпричинно переусложнено и/или привоидт к негативным последствиям! Хочешь, например, потрачу время на получение цифирек по поводу твоей фразы о некольких строчках в кучке посекундных апдейтов и моего предложения аккумулировать это в единую проверку? Если ты голословно это подвергаешь сомнению - остается или продолжать бубнить "ты не прав а я правее" или сравнить цифры/факты и сделать выводы, признав правоту того или иного!

И не нужно мне про профессиоальных тестеров зубы заговаривать. Когда идет черновая разработка - только сам кодер может себе помочь иоценить. На выходе же кода, ни один тестер не сможет отделить мух от котлет и дать информацию кодеру по работе именно этого куска алгоритма. Но ... это уже слишком специфический разговор и те в тему. Хочешь подискутировать - лучше это сделать в скайпе, а пока - прекращаем оффтопить на эту тему.

По менеджеру оружия: Взяв его за основу, я как и всегда, перелопатил коды и естественно убрао различные коллизии и недоработки (возможно привнеся свои). Что опять мешает тебе не голословно утверждать тут о хорошести твоего решения и плохости иного, а указать и мне и другим на ошибки в исходых кодах и дать пояснения?

Говоришь "Слишком много там ещё недопиленных решений находящихся ещё в разработке" - ну так и никто пока не просит давать готовеньое (под ключ)! Тут топик не для этого, достаточно и огрызка кода, на котором понятна ошибка иль решение ошибки.

Что мешает приводить не целые модули, а только выжимки из них?

Ну а без этого - весь разговор напоминает или похвалбушками или критиканство.

Цитата
... работает над тем чтобы совместить плюсы первой и второй и сделать единую. Пока оно не будет готово ещё нет смысла спорить особо.

Предлагаешь нам тут сидеть и ждать месячишко-тройку-годик, пока нас е осчасливят готовым решением?

Если цель застолбить за собою и зазвездиться - то опять зачем тут эти разговоры?

Я по своей друмучести считаю, что гораздо проще не одной головою думать ... Общую концепцию/алгоритм можно и в несколько обдумывать и искать недостатки или изюминки, ну а конкретный код - об этом тут нет речи.

Мне, например не сам готовый код нужен/интересен, а поиск решения ... А когда мне только намекают на то, что это мол плохо, а это будет хорошо - то это только и время отнимает и раздражает, т.к. ни ответить не могу ни покритиковать.

Цитата
kamikazze: то OGSE и компаньоны были бы вообще в компилированном байткоде Lua

Ой, даже е советую трарить на подобное время ... Как то в запале один из NLC-ников пообещал закрыть код/фишки (и даже попробовали бяку сделать) - я пообещал, что буду тем, кто вскроет и вернет игрокам все возможности ...

Не мне тебе говорить, что и закрыть практически нереально и, единожды вскрыв, весь твой труд по закрытию канет в небытие ...

Ну а я вообще-то не об этом. А о том, что порой хорошие находки по программированию/кодам "пыляться" в закрытых по полгода-году-трем в командах и толку от них все - ноль. Но зато потом можно похвастаться мол во как мы круто сделали.

Еще раз призываю, давайте на конкретике говорить о найденых ошибках в кодах, неудачных решениях, найденных изиминках и т.п. Это позволит ежедневно совершенствовать свои знания и навыки, а не раз в "пол-года" знакомиться с очередным вбросом шедеврального "мода".

Nazgool · 31 Декабря 2011

Поздравляю всех с Новым Годом.

2Artos

По поводу упомянутых тобою таймеров - есть дополнения и улучшения.

На днях выложу (когда приду в сознание).

Viнt@rь · 1 Января 2012

Возможно не в тему пишу(не в тему обсуждения), но все же хотел узнать, xStream, согласен с тобой, возможно АМК 2.0, как ты выразилась, "говно", но все же скрипты там довольно интересные, вот собственно по этому и спрашиваю, если писать скрипты-схемы организовывая их классами(на подобии АМК 2.0) это влияет на производительность и тп, если влияет, то чем, и как именно? Заранее спасибо...

Изменено 1 Января 2012 пользователем Viнt@rь

xStream · 1 Января 2012

К АМК 2.0 я не имею никакого отношения. Однако скрипты в нем, "переписанные с нуля", чуть более чем полностью такие же по сути, как в 1.4. Однако за 2.0 я ответственности не несу

На производительность, не важно в каком моде, при ОО подходе затраты идут на создание объектов. Но, зачастую, эти накладные расходы ничто по сравнению с временем выполнения рабочего кода. Главное не делать цикл на 100к итерций и не создавать там объектов Это раз.

В АМК 2.0 то, что я раньше по топику называла псевдо-ооп. Это когда набор функций объединяют внутри класса. По сути толку от этого ноль целых ноль десятых. Так как эти псевдо-объекты не используются в сочетании с другими, как аргументы методов других классов, хотя бы. Это все тот же старый добрый процедурный подход. Это два.

Вывод - как в АМК 2.0 делать не надо. Надо знать ООП, а это уже явно выходит не только за пределы топика, но и форума

Изменено 1 Января 2012 пользователем xStream

Войти

Язык Lua. Общие вопросы программирования

Рекомендуемые сообщения

Dennis_Chikin 3 663

Ссылка на комментарий

xStream 86

Ссылка на комментарий

Artos 99

Ссылка на комментарий

xStream 86

Ссылка на комментарий

Artos 99

Ссылка на комментарий

kamikazze 266

Ссылка на комментарий

xStream 86

Ссылка на комментарий

Artos 99

Ссылка на комментарий

xStream 86

Ссылка на комментарий

Artos 99

Ссылка на комментарий

xStream 86

Ссылка на комментарий

Artos 99

Ссылка на комментарий

Artos 99

Ссылка на комментарий

kamikazze 266

Ссылка на комментарий

xStream 86

Ссылка на комментарий

Artos 99

Ссылка на комментарий

kamikazze 266

Ссылка на комментарий

Artos 99

Ссылка на комментарий

Nazgool 250

Ссылка на комментарий

Viнt@rь 50

Ссылка на комментарий

xStream 86

Ссылка на комментарий

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Создать аккаунт

Войти

Недавно просматривали 0 пользователей

AMK Склад