Основы оптимизации

[skypo]

Сильно сомневаюсь (практически уверен, что не), что этот движок с примерами по нему вообще пойдет под GMS.
Надо будет посмотреть айдишники в танкисте.

[MusNik]

GMS очищает айдишники после перезагрузки.

[likstalkera]

Если записывать код из шага в рисование, то сильно ли это повлияет на производительность?

[Dmi7ry]

Если записывать код из шага в рисование, то сильно ли это повлияет на производительность?

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

[nectarine]

Спасибо за статью, очень познавательно :)

В связи с прочитанным, у меня такой вопрос: допустим, нужно нарисовать гуй, в котором довольно много кода получится в событии draw. Что будет быстрее, оставить весь код draw в одном объекте, контролирующем гуй (в котором помимо draw есть и другие события), или же вынести код draw в, скажем, 100500 1-2 дополнительных объекта, в которых кроме draw ничего не будет?
P.S. код из draw иногда обращается к значениям переменных внутри других событий.

[skypo]

Спасибо за статью, очень познавательно :)

В связи с прочитанным, у меня такой вопрос: допустим, нужно нарисовать гуй, в котором довольно много кода получится в событии draw. Что будет быстрее, оставить весь код draw в одном объекте, контролирующем гуй (в котором помимо draw есть и другие события), или же вынести код draw в, скажем, 100500 1-2 дополнительных объекта, в которых кроме draw ничего не будет?
P.S. код из draw иногда обращается к значениям переменных внутри других событий.

меньше объектов - лучше.
в draw лучше ничего помимо собсно отрисовки не держать (т.е. все расчеты - в step'ах).
в случае ГУИ можно обойтись без объектов вообще - сделать тайлами и организовать их замену через скрипт

[Briginas]

Интересует такой вопрос. Какой вариант лучше в плане оптимизации?

Код: (1 Вариант)

if a = b {c += d}

Код: (2 Вариант)

c += d*(a = b)

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


И второй вопрос.
Есть ли разница использования + и * вместо || и && ?

Код: (1 Вариант)

if (a = b) + (c = d) {e += f}

Код: (2 Вариант)

if (a = b) || (c = d) {e += f}

Т.к. любое число выше 0.5 возвращает true, то условие истинно, но есть ли разница со вторым вариантом? Аналогичный вопрос с && и *

[Fantom]

1. Первое лучше, и читается удобнее, чем второй вариант. Следуя второму варианту, рано или поздно появятся такие выражения, в которых не будет понятно, где "главное" равно, а где складываемые (или где левая часть выражения, а где правая)
Во втором варианте тоже используется сравнение, как и в первом, поэтому у первого меньше нагрузка.

(к переменной каждый шаг прибавляется 0).

Еще и умножение выполняется. Одна-две операции в первом варианте против трех во втором.

2. || - логическое сложение, && - логическое умножение. Разница в слове "логическое"
В приведенных примерах (и с умножением если тоже привести) разницы в результате нет, но практика таких выражений опять же может привести к запутыванию кода (обфускация, с одной стороны плюс, с другой минус) и к привыканию. Одно дело - GML это спокойно принимает, другое дело - другие языки не смогут, разрешая выполнять только логические операции с логическими переменными, и ожидая только логическую переменную после if.

[Briginas]

Понятно, значит лучше использовать "классические" методы.
Как я понял

Код:

if a = b {c = d} else {c = 0}

Будет так же выполняться быстрее, чем

Код:

c = d*(a = b)

Ведь else не является сравнением, а всего лишь выполняется при ложном значении условия. Я прав?

[AlexBel]

Привет всем!

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

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