Курилка программистов

[Desertir 202]

@Dennis_Chikin, дели на 10000, но про тысячные наносекунды я не буду говорить. Совместимость - имеется ввиду существующие моды. На самом деле ничего не будет с пары глобальных переменных. Вообще про совместимость лучше не начинать, под одну гребенку все не причесать.

Спор вроде ни о чем. Уже выяснили, что оптимизировать надо другие вещи. А рефакторингом пусть занимаются сами разрабы модов, в некоторых случаях нету однозначного ответа, что надо писать именно вот так, а не иначе. Кому-то вообще венгерка по вкусу...

Изменено 2 Декабря 2014 пользователем Desertir

[Desertir 202]

Ууу, для чего ООП? А может тогда сначала ответите, что такое ООП? А вы не ответите, потому что точного определения нет.

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

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

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

[Desertir 202]

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

Долго вчитывался в этот абзац. Предположим, что твои таймеры написаны на C++. Получается, что приведенные методы (ну кроме конструктора), должны быть виртуальными, мы же хотим вызвать метод потомка, имея объект приведенный к базовому типу (таймеры же гдето регистрируются и по ним идет итерация, там будет использоваться базовый класс). А как Луа "догоняет" это? Ну или ЛуаБинд, что мы вызываем метод наследника, что методы виртуальные.

[Desertir 202]

но кому оно надо мне разжевывать элементарные вещи

Для этого есть тема по крестам, ктото да ответит (пока всем отвечали).

описание устройства и принципа работы какого-нибудь типичного механизма

Слишком абстрактно. Типичный механизм? Для меня это паттерны (шаблоны проектирования). Может для кого то нечто иное.

[Desertir 202]

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

Пожалуй, именно с этих слов надо начинать посты в данной ситуации.

Нужно четко понимать всю систему на которой ты работаешь.

Эта фраза имеет смысл в следующих случаях.

1. Ты ее сам разработал, тогда надо разбираться именно в твоем коде, если работаешь в команде.

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

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

4. Ты этого хочешь сам.

5. Тебя заставили (например исправить баг).

 

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

 

Больше причин не знаю, можешь начать изучать, как работает твоя ОСь и твой ПК (да да, с транзисторов и разделов ЖД), ты же на ней работаешь?

[Desertir 202]

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

[Desertir 202]

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

Вообще это чем то похоже на систему логики - evaluators and actions. И ИМХО такую систему "execution by condition" можно занести в двиг, так же как сделано с логикой.

1. Происходили неоднократно.

2. Иррегулярно.

3. Через точно заданное время от момента x.

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

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

Изменено 31 Января 2015 пользователем Desertir

[Desertir 202]

Простая очередь, вешающаяся на самый медленный апдейт из всех

Моя не понимать, что за очередь и медленный апдейт. Имеется ввиду такая шняжка?

local upd1, upd2, upd3 = 0, 0, 0
function bind_stalker:update(delta)
    upd1 = upd1 + delta
    upd2 = upd2 + delta
    upd3 = upd3 + delta
    if (upd1 > 200) then upd1 = 0 call_upd1() end
    if (upd2 > 1000) then upd2 = 0 call_upd2() end
    if (upd3 > 3000) then upd3 = 0 call_upd3() end
end

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

[Desertir 202]

есть ли ожидающие своей очереди арты

Само собой, пустоту мы и проверить "на пора" не сможем.

вариант "насыщения" аномалии

Опять же, что такое "насыщение"?

if global_time_ms >= t5000t then

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

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

Если так немного отстраниться, то в этом случае можно запилить "каскад", т.е. вызвали первую функцию по срабатыванию на global_time_ms >= t5000t, далее перед последним эндом вызываем следующую (асинхронно, это вообще возможно в луа?), и так далее. Кстати, есть шанс того, что таймер может вновь сработать еще до завершения каскада.

[Desertir 202]

К слову о рефакторинге

Изменено 1 Февраля 2015 пользователем Desertir

[Desertir 202]

Смотря откуда "рефрактор" растет

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

[Desertir 202]

@Viнt@rь, о производительности приложения надо думать, когда оно либо написано, и можно заняться полезной оптимизацией (переписать запросы к БД например), либо уже тормозит на столько, что код пишется со скоростью выполнения программы.

это потеря в скорости выполнения программы

Это потеря потерь. (с)

[Desertir 202]

@Dennis_Chikin, тормозами могут являться не только 20 вызовов функций в полусотне скриптов. Не во всех приложениях есть "скрипты", не везде есть "апдейты", а "приложение" это не только ценный мех Сталкер. Кстати, для профилирования существуют различные тулзы, которые нам наглядно показывают, где "узко" (dotTrace к примеру для донета). Но, если уж брать наше поле брани (то бишь скрипты), то я видел две обертки для профайлера, но вслепую весьма трудно найти, какие же участки кода действительно съедают много времени, либо смотреть на поведение игры, либо засекать каждую функцию, либо уповать на свой профессионализм и быть уверенным, что вот такая-то функция будет тормозить. А можно еще глобальный профайлер сделать, который будет собирать статистику со всех скриптов.

 

И еще одно кстати, про время приложения в целом. Игрок ждет по сути два раза, первое - когда же выйдет игра, и второе - когда она загрузится и будет игратцо, время на приобретение не в нашей власти (торрент или покупка в магазине). Я иногда "воображаю" такую формулу: общее_время = время_разработки + время_вычислений * кол-во_пользователей. И я могу жертвовать либо временем разработки, тогда, скорее всего, пострадает время вычислений - пользователь получит свое приложение скажем через месяц, но еще будет ждать час, пока оно заведется + тормоза при самом использовании. Либо наоборот, жрем много времени на разработку, пользователь получит быстрое приложение, но только через пол года. В чем суть - я бы не рассматривал только время вычислений, а старался бы найти некий баланс.

[Desertir 202]

Всегда пишите комменты к коду, гы-гы-гы.

А никто не видел какие нибудь луавские модули для реализации аля LINQ. Ну всякие аггрегаторы, итераторы, иногда забавно.

level.objects:where(function(cobj)
    return is_bandit(cobj) and distance_between(db.actor, cobj) < 20.0
end):foreach(function(cobj) remove_head(cobj) end)

[Desertir 202]

но переборы - действительно зло

Ну в дотнете они есть, все таки там больше за надежность нежели за скорость, да и потом всякие запросы к БД, потом это обрабатывать, иногда ЛИНКу тащит и код выглядит симпатичнее.

call chaining

Не ну эт мы в курсе Просто суть ушла в сторону того, как код выглядит. Сначала я хотел написать не методы, а функции (table.where/table.foreach), но потом передумал, ибо выглядит для меня не очень. Изменено 2 Февраля 2015 пользователем Desertir

[Desertir 202]

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

С другой стороны, клиентский объект у нас еще есть, часть... В общем эта клиент-серверная система для сингла всегда меня поражала своей гениальностью (в клиентском событии выпиливаем серверный объект, или как там).

 

На самом деле систему ивентов надо делать на уровне движка, я считаю. Пусть он кидает сообщения, что объект затёрли, и вешать на него все удаления из таблиц\счётчиков и т.п.

Изменено 4 Февраля 2015 пользователем Desertir

[Desertir 202]

Подписчики на safe гарантируют сохранность "объекта доставки"

Это должен гарантировать скриптер, что цепляет на это сообщение функцию, которая не будет редактировать аргументы. Это было не оспаривание такого варианта решения.

Моя думает это сложно - универализировать под все-все хотелки. В винформах есть такой класс KeyEventArgs. Там всякие данные по событию храниться, и там же есть свойство Handled, типа событие обработано и все, дальше не идем. Это аналог e:stop()/return true. И таких классов под каждое событие.

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

[Desertir 202]

и проверяет наличие свойства need_release

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

[Desertir 202]

О !!! Неужто договорились ?

Ну как бэ система ивентов подразумевает и подписку и отписку от события, кто то говорил, что она сугубо статическая? Типа запалил гдето свой номер мобильника и получаешь ежедневно СеМеСески с рекламой Да собстно подписка это тоже динамика.

 

У мине вопрос, об чем спор уже сейчас? Если на странице ранее еще было понимание сабжа, то сейчас не очень.

 

Забавно читать посты о системе ивентов, когда имеешь с ней дело каждый день, только на js. Попробуйте отследить, кто слушает конкретный ивент и что то портит в каком нибудь store, хрен что найдешь!

 

- Эй, вы о каких ништяках ваще?

Ништяки? Изменено 4 Февраля 2015 пользователем Desertir

[Desertir 202]

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

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

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

---

@xStream, я не сомневаюсь. Изменено 5 Февраля 2015 пользователем Desertir