Ресурсы в ECS

[дворник]

А как ты оставишь её без изменений?

Буду возвращать значение в зависимости от критериев.
Либо вычислять, либо хранить в регистре.

Потому что он жрёт до .... CPU. CB 27 можно использовать только тогда, когда иначе никак. В нашем случае можно обойтись.

Читаем:

anim_speed 0 .. 16 Decide the time an animation frame should last. Return value is interpreted as (num_ticks = 2^anim_speed), which each tick lasting 30 ms. Avoid using this callback if possible, since it has to be called each tick for every animated tile. This can be used to create animation frames that last between 30 ms and 33 minutes.

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

Другое дело, если задать anim_speed близкое к 0, тогда не только в anim_speed будет проблема, проблема будет в частом вызове других cb, в т.ч. для отрисовки.

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

Что значит с 2 на 3? Если ты про PROP 10 то ты просто замедлил анимацию и всё.

Поясню. Бульдозерная анимация у тебя на 8 фреймов, а задавал ты в 2 раза больше - 16. Т.е. с в два раза большей точностью ты делал вызовы, но внешний вид менял в 2 раза реже. Я эту ступеньку убрал, у меня 8 фреймов, и вызываются они реже. Визуально ничего не изменилось -- бульдозеры елозят так же, с той же скоростью. Но вызов anim_next_frame/anim_speed происходит в 2 раза реже.

С дымом я действительно снизил скорость в 2 раза. Он теперь как у стандартной электростанции мельтешит. А был смысл мельтешить дымом чаще?

В мире TTD зимой деревья покрыты снегом, но листья не опадают. Не надо это менять, лес будет выделяться из окружающего леса. Это неправильно. Лес, на котором нет производства, если не смотреть на домик лесника, должен быть совершенно незаметен.

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

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

Не надо. Это приём пассажиров. Если невдалеке будут домики, то груз принимается.
Это как у многих домов. Отдельно стоящий дом может не принимать пассажиров/почту/товары, и только группа домов принимает груз.

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

Хорошо, а как тогда менять счётчики? Даже в самом последнем коде (bauxite mine) CB26 используется как таймер. Более эффективных таймеров я не нашёл. Твои предложения?

Не понял вопроса.
Смена индекса фрейма означает смену внешнего вида. Вхолостую менять индекс фрейма смысла нет.
По сути, если мы знаем, что следующий тик должен произойти через N единиц времени, то мы меняем animation_speed под это N, и не делаем холостых вызовов ожидания.

Это похоже на таймер Windows - мы задаём время следующего вызова anim_next_frame вызовом anim_speed, и до истечения возвращенного anim_speed времени вызова не случится.

[George]

А как ты оставишь её без изменений?

Буду возвращать значение в зависимости от критериев.

Каких?

Либо вычислять,

Как?

либо хранить в регистре.

у тебя всего 64 байта в регистрах. если предприятие 8Х8, то все 64 байт угрохаешь. Если сделать компрессию и запихнуть 2 клетки в 1 байт, то 32. Допустимо, но не айс.

anim_speed 0 .. 16 Decide the time an animation frame should last. Return value is interpreted as (num_ticks = 2^anim_speed), which each tick lasting 30 ms. Avoid using this callback if possible, since it has to be called each tick for every animated tile. This can be used to create animation frames that last between 30 ms and 33 minutes.

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

Нет. Он вызывается каждые 30ms вне зависимости от значения.

Другое дело, если задать anim_speed близкое к 0, тогда не только в anim_speed будет проблема, проблема будет в частом вызове других cb, в т.ч. для отрисовки.
Я хочу чего сказать - что надо разумно задавать длительность фрейма, подходящую для анимации. Слишком часто вызывать не стоит. Величина 3 вполне оптимальна.

По мне оптимальна 2. Почему 3?

Что значит с 2 на 3? Если ты про PROP 10 то ты просто замедлил анимацию и всё.

Поясню. Бульдозерная анимация у тебя на 8 фреймов, а задавал ты в 2 раза больше - 16. Т.е. с в два раза большей точностью ты делал вызовы, но внешний вид менял в 2 раза реже. Я эту ступеньку убрал, у меня 8 фреймов, и вызываются они реже. Визуально ничего не изменилось -- бульдозеры елозят так же, с той же скоростью. Но вызов anim_next_frame/anim_speed происходит в 2 раза реже.

Лучше бы сделал вдвое больше видов бульдозеров, сделав их движение более плавным.

С дымом я действительно снизил скорость в 2 раза. Он теперь как у стандартной электростанции мельтешит. А был смысл мельтешить дымом чаще?

Ты уверен что у стандартной 3?

В мире TTD зимой деревья покрыты снегом, но листья не опадают. Не надо это менять, лес будет выделяться из окружающего леса. Это неправильно. Лес, на котором нет производства, если не смотреть на домик лесника, должен быть совершенно незаметен.

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

Так меняй графику деревьев. А у леса должно быть так же, как у деревьев вокруг.

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

Это графика. К коду отношения не имеет

Не надо. Это приём пассажиров. Если невдалеке будут домики, то груз принимается.
Это как у многих домов. Отдельно стоящий дом может не принимать пассажиров/почту/товары, и только группа домов принимает груз.

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

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

Хорошо, а как тогда менять счётчики? Даже в самом последнем коде (bauxite mine) CB26 используется как таймер. Более эффективных таймеров я не нашёл. Твои предложения?

Не понял вопроса.
Смена индекса фрейма означает смену внешнего вида.

Не означает. Она иногда используется для хранения информации о состоянии (в том числе разная графика - частный случай). Пример - лес, состояния 4 и 5. Выглядят одинаково, означают разное.

Вхолостую менять индекс фрейма смысла нет.

Есть. См. лес. состояния 4-5. Предложи другое решение. Сможешь - спор продолжим. Нет - значит иначе никак. У tiles нет регистров.

По сути, если мы знаем, что следующий тик должен произойти через N единиц времени, то мы меняем animation_speed под это N, и не делаем холостых вызовов ожидания.

Ты внимательно читал описание CB27? Лучше прогнать 2 фрейма, чем увеличить интервал вдвое. В своё время frocsh делал тесты нагрузки на cpu. Различие не в разы, а на полтора порядка.

Это похоже на таймер Windows - мы задаём время следующего вызова anim_next_frame вызовом anim_speed, и до истечения возвращенного anim_speed времени вызова не случится.

у anim_speed случится. каждые 30 ms.

[дворник]

cb anim_speed (я буду называть cb и пр. в терминах NML) требует вернуть число и как можно быстрее. При этом доступны все переменные в видимости SELF для клетки и PARENT для предприятия, вот их и можно анализировать, чтобы вычислить это число. Самый очевидный способ - отталкиваться от animation_frame. Но вычисления могут быть и посложнее.

Нет. Он вызывается каждые 30ms вне зависимости от значения.

Тогда это архитектурная ошибка разработчиков игры. Я не знаю, зачем они на ровном месте себе создают доп. нагрузку. Как ты там писал по поводу тайлов на несколько клеток? Борешься с ними, чтобы рисовать было проще. Это уж точно из этой оперы и повысит производительность.

Лирическое отступление. Я конечно деталей openttd не знаю, хотя и видел исходники, но считаю частый вызов этого cb архитектурной ошибкой. Примеры того, что есть в природе - это таймеры в браузерах (тот же firefox), и таймеры Windows (которые через очередь сообщений). Мы задаём интервал и метод срабатывания, для MNL это cb anim_speed и cb anim_next_frame. По логике их надо вызывать именно в таком порядке. Нет никакого смысла вызывать anim_speed чаще, чем задано в предыдущий вызов. Нет никакого смысла вызывать анимацию для тайлов, которые не видны на экране, но м.б. стоит менять их внутренние переменные, чтобы не было "замираний" при скроллинге. Окно видимости м.б. чуть больше того, что помещается на экран, просто для эдакого кеширования на случай если играющий слегка скроллирует экран мышью.

Но ладно, с "божественной силой" разработчиков бороться - только ресурсы на ветер тратить. Будем использовать то, что есть. А есть у нас ещё start/stop анимации через cb anim_control. Т.е. избежать частого вызова cb anim_speed мы не можем, но можем останавливать анимацию. У тригера есть флажки, которые позволят нам возобновить анимацию при определённых условиях. Или в этом случае тоже будет вызываться cb anim_speed? Тогда у них уже две архитектурные ошибки.

По мне оптимальна 2. Почему 3?

Потому что дым в стандартных электростанциях идёт на 3. У тебя на 2, т.е. в 2 раза чаще мельтешит. Это заметно в игре.

Лучше бы сделал вдвое больше видов бульдозеров, сделав их движение более плавным.

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

Сможешь - спор продолжим.

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

Не означает. Она иногда используется для хранения информации о состоянии (в том числе разная графика - частный случай). Пример - лес, состояния 4 и 5. Выглядят одинаково, означают разное.

Согласен, что animation_frame правильнее назвать состоянием конкретной клетки, и не каждое состояние приводит к смене анимации. Но сейчас есть аж три cb про анимацию: anim_next_frame, anim_control и anim_speed, а пользоваться нормально можно только anim_next_frame, предварительно выставив скважность в свойстве animation_info: [ANIMATION_LOOPING, #]; , где # - в диапазоне 1..253. Причём из-за того, что скважность регулировать не рекомендуют (из-за архитектурной ошибки, имхо) anim_speed звать низзя, а amin_control имеет ограниченное кол-во флагов активации.

[дворник]

У тебя есть блок с комментарием - "// Synchronisation of tiles every 512 ticks".
Подскажи, что именно синхронизируется, что-то не доходит..

[George]

У тебя есть блок с комментарием - "// Synchronisation of tiles every 512 ticks".
Подскажи, что именно синхронизируется, что-то не доходит..

Качание деревьев. Если этого более нет, то можно это всё убрать

[George]

cb anim_speed (я буду называть cb и пр. в терминах NML) требует вернуть число и как можно быстрее. При этом доступны все переменные в видимости SELF для клетки и PARENT для предприятия, вот их и можно анализировать, чтобы вычислить это число. Самый очевидный способ - отталкиваться от animation_frame. Но вычисления могут быть и посложнее.

Формулу предложи

Но ладно, с "божественной силой" разработчиков бороться - только ресурсы на ветер тратить. Будем использовать то, что есть. А есть у нас ещё start/stop анимации через cb anim_control. Т.е. избежать частого вызова cb anim_speed мы не можем, но можем останавливать анимацию. У тригера есть флажки, которые позволят нам возобновить анимацию при определённых условиях. Или в этом случае тоже будет вызываться cb anim_speed? Тогда у них уже две архитектурные ошибки.

Нет. Если тебе тригеров хватает - тогда можно.

По мне оптимальна 2. Почему 3?

Потому что дым в стандартных электростанциях идёт на 3. У тебя на 2, т.е. в 2 раза чаще мельтешит. Это заметно в игре.

Тогда исправлять везде надо. У всех дымов. А это значит у всех бульдозеров. А это значит надо проверить все остальные места с анимацией.
Нетривиальные грабли ты выкопал

Сможешь - спор продолжим.

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

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

[Wowan]

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

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

Оставьте. Это хорошо для игры, что предприятия генерируют пассажиропоток, пусть и в крайне малом количестве. В самом деле, на предприятиях работают люди. Ненормально, если игра их не будет замечать.
В свете xUSSR Set это, например, оправдывает наличие в наборе автомотрис и прочих коротких пасс. составов - как раз обслуживать такие ветки, где 10 пассажиров в сутки. Можно делать грузопассажирские составы. Для красоты и реалистичности - то, что надо.

[дворник]

Формулу предложи

Ну, хорошо, вот пример с качалкой насосов Нефтяной скважины (тайл 1D). Имеем:
1. пустой огороженный изгородью ландшафт с учётом заснеженности, без анимации на construction_state == 0..1.
2. 8 фреймов (animation_frame от 0) бульдозерной анимации на скорости 3 на construction_state == 2
3. при ином construction_state (т.е. 3 и выше, фактически 3) имеем качалку насосную на 10 фреймов полного цикла (animation_frame от 0), графика идёт от 0 до 5 по возрастающей, затем по убывающей к 0 (id спрайтов)
Скорость тоже 3.

Заведён дополнительный фрейм 11 (id 10), где производится останов качалки с некоторой вероятностью. Он зацикливается, из него можно выйти на фрейм 0, начав цикл заново.

Так вот, логично кажется для останова качалки использовать смену скорости animation_speed
if construction_state > 2 and animation_frame == 9, то с долей вероятности по extra_callback_info2 возвращаем не 3, а скажем от 5 до 9 случайно. Чтобы не было холостых тактов ожидания.

Можно сделать 2 доп. состояния: 10 - когда мы с долей вероятности входим в ожидание (визуально не качаем), 11 - когда с вероятностью выходим в 0.

А можно даже 3, добавив между ними 10.5, когда ждём.

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

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

[дворник]

Даже когда анимации нет (на construction_state == 0..1) cb anim_next_frame тикает. А зачем?
Можно задействовать cb anim_control , включая/выключая тикалку при смене construction_state.

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

Есть интервал зацикливания, определяемый тем, как мы задали в свойствах "[ANIMATION_LOOPING, 15]" для тайла, такой же для всех тайлов предприятия, событие получения груза и событие отправки груза.

Грубо говоря, получив событие отправки груза мы можем проверить переменные SELF/PARENT и запустить анимацию тайла. А в конце каждого цикла проверять, не остановиться ли, и если что не простаивать, а останавливать анимацию. Вот так мы реально будем беречь процессорное время.

[George]

Даже когда анимации нет (на construction_state == 0..1) cb anim_next_frame тикает. А зачем?
Можно задействовать cb anim_control , включая/выключая тикалку при смене construction_state.
Но вот когда construction_state уже устаканился, то выключить/включить можно будет только по воздействию, в число которых не входит прошествие какого-то интервала в понимании anim_speed.
Есть интервал зацикливания, определяемый тем, как мы задали в свойствах "[ANIMATION_LOOPING, 15]" для тайла, такой же для всех тайлов предприятия, событие получения груза и событие отправки груза.
Грубо говоря, получив событие отправки груза мы можем проверить переменные SELF/PARENT и запустить анимацию тайла. А в конце каждого цикла проверять, не остановиться ли, и если что не простаивать, а останавливать анимацию. Вот так мы реально будем беречь процессорное время.

Т.е. нет вывоза, так насосы вообще никогда ничего не качают? Некрасиво.
У меня холостые для того, что бы гарантировать, что если насос остановился, он некоторое время простоит. Ровно как и если начал качаться, то некоторое время будет качаться. Иначе уродливо выглядит. А в случае вероятностных решений всегда есть не 0 вероятность, что уже на следующей проверки оно изменится (перестанет качать или начнёт). А так не красиво. Должен быть минимальный гарантированный интервал как работы, так и стоянки.

[дворник]

Ага, некрасиво.

Кроме событий по грузу и construction_state есть ещё два события (всего 5):

ANIM_TRIGGER_INDTILE_TILE_LOOP the tile is processed in the periodic processing loop
ANIM_TRIGGER_INDTILE_INDUSTRY_LOOP the industry of the tile is processed in the periodic processing loop (synchronized for all tiles)

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

А так, при вызове anim_control есть случайное число в extra_callback_info1 и причина вызова в extra_callback_info2.

[zlavick]

Падение OTTD при открытии производств в ECS

[George]

Падение OTTD при открытии производств в ECS

http://bugs.openttd.org/task/4969

[zlavick]

О, замечательно! И практически сразу же фикс сделали. Какие добрые люди!

Благодарствую!

[zlavick]

Кстати, то что надо кликнуть несколько десятков раз (лаг как в версии 1.1.4 с вылетающей ошибкой) прежде чем создастся производство, это так и задумано?

Посмотрел в чэнджлогах: newgrf textstack was not properly used when storing parameters for the error message window и, судя по всему, окно с ошибкой должно возникать? (раз yexo это не пофиксил). Но почему?