1. Обратиться к элементу списка дольше чем к объекту, а уж тем более несколько раз (для каждой переменнтой). Исхожу из того что один человек создавал массив через объекты и вроде как было быстрее.
2. Скрипты тоже замедляют демку. Если б ты напрямую в коде обращался к списку, а не через скрипт, было бы быстрее.
3. Если тебе нужна именно оптимизация такого поведения объектов, то можно сделать код быстрее, а если ты просто набил его для нагрузки, то понятно что заниматься им не стоит, пусть это будут как бы абстрактные вычисления.

Нужно оптимизировать код самих объектов и оставаться с ними. Как вариант - выкинуть СТЕП и ДРАВ из объектов и сделать его обработу в цикле одного контрольного объекта.

Массивы должны придать скорости.

Придадут ли они скорости когда надо будет очень часто удалять и добавлять объекты. Вот в чём вопрос. Здесь кол-во объектов всегда постоянно.

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

Со скриптами (ФПС: 52):

Без них (только прямой доступ к списку, ФПС: 62):

Добавлено (23.07.2010, 13:43)
---------------------------------------------
С прямым степом ещё поднялось до 105. Размер списка тоже без скрипта ещё 20 кадров. Итого: без скриптов вообще ФПС: 125.

Ну вот, подняли в 2 раза. Неплохо вроде))

А ты как хотел:) Люди на асме делали ключевые куски кода, тоже удовольствия мало.

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

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

А мне пофиг на ФПС, пока еще не встречался с сильным проседанием в GM, во флеше - другое дело.

Ну видимо в гм да. Без скриптов вообще 125фпс, со скриптами 52. Я знал что падение есть, но не думал что такое сильное.

Да, но АСМ не используют для написания средних и тем более крупных программ. Никогда. Проще же изменить одну функцию, чем 10 мест одно и того же кода. А если не 10, а 100? 1000? Это будет долгий, нудный и совершенно бесполезный труд.

Хотелось бы повышение производительности и сохранение удобности кодирования в ущерб размерам и сложности программы.

Капец, это же ведь должен быть обычный call, что там можно такого делать, чтобы прога так лагала ?

Я и не говорю про большие. Но вычислить направления и скорости большого числа объектов можно было бы на асме.

Создай систему при которой функции будут собираться INLINE в циклах. В ГМ же можно состряпать новый скрипт прямо находу.

А вообще производительности никогда не хватает, поэтому лучше подумать как упростить игру при том же фане.

Из-за вызова -_-
Теперь понятно, почему у меня фпс начал падать, по мере добавления скриптов -_-

Подробнее, подробнее пожалуйста!
Актуальная тема

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

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

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

Люди, скрипты вызывают тормоза только при больших циклах. Я просто сказал что лучше делать

вместо

, где в max() и будет то условие, что написано выше. Единичные вызовы скриптов картину не сильно портят.

В ГМ можно цеплять скрипты в объекты находу (вроде как ) Посмотри пока справку)

Да, да, мы это обсуждали и пришли к выводу, что оно не надо -_-
Вроде из темы как создать объект в программе и напичкать его как хочешь.

З.Ы.: Ну у меня например в событии драва постоянно рисуется сетка, которая вызывается скриптом.
Так же происходит обход списка точек, потом они приобразуются в прямоугольники и рисуются, и так несколько раз.
На слабых машинах фпс (24/60), у себя же потерь нет, но видно что процесс занимает 36%.

Bercut, мож нарисовать на сурфе, а потом обновлять при изменениях? Что там за сетка?

Да, так, сетка для редактора, для привязки спрайтов, я думаю её можно подгонять под разрешение экрана, но при неокруглённом перемещении так делать нельзя, то есть без привязки.
А рисуются ли объекты, то есть выполняется ли те действия рисования, вне суфра?

Оказалось что постоянно изменяющиеся данные неэффективно делать через один объект.

Файл эксперимента (13кб).