Чёто Вы меня совсем запутали. Может, выложите свфку хотя бы посмотреть, как у Вас плиты двигаются

А нельзя плиты просто загонять в отдельный клип и двигать один раз только его.... тогда все плиты сдвинутся на одно и то же расстояние...

Wolsh
swf-ку посмотреть тут, повозите карту туда-сюда кнопками клавиатуры. чем дольше потягаете - тем больше деформация будут заметна.

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

Ага, посмотрел. Ну и чем Вам мой метод не понравился - не верите что всё будет ОК?
Вычисляйте координату нижней плиты, а все остальные - относительно нее. Поймите что сбой происходит при считывании координаты плиты, которая всегда округляется до сотых. И этот сбой будет всегда накапливаться, потому что новое значение Вы берете опять от неправильного. А так сбой будет, но только неизбежный и для первой плиты, а все остальные плиты будут вставать ровно с нижней.

метод хороший и я понимаю, что всё будет ок, но ведь это сколько операций будет выполнено, чтоб сместить все плиты:( если так 2 операции(присвоение х, у), то там еще и расчет х,у... сейчас попробую:напишу расчёт, увеличу карту и посмотрю на производительность метода.

Добавлено через 35 минут
если бы карта была не изометрической, то метод выглядел бы так?

Я подобными вещами давно занимаюсь и вам бы рекомендовал, так же как рекомендовалось в посте №12. Загоните все плитки в один клип и двигайте клип. Так у вас будет только пять точек вычисления, это верхний-левый, верхний-правый, нижний-левый, нижний-правый и сам пресонаж, а если есть npc на карте, то они сами по себе относительно карты будут двигаться.
Если подумать, то можно еще дальше пойти.Например, что бы карта не вся была загружена, то можно невидимую часть держать в tile._visible и только тогда, когда за одну клетку до попадения ввидимую зону тайл ставим в положение tile._visible=true. и вычисляем всё это общей формулой TempX=Math.floor(this._x/размеры тайла).Так же и по Y. Это не сложно сделать и карта не нагружена. А что бы сделать карту громадных размеров, то просто стоит разделить её на сегменты, на сектора, на зоны(как вам удочней это называть).Например если у вас видимое поле скажим 20х20, то сектор можно сделать размером 40х40 или 60х60, как удобней. И соответственно вычислять например, если длина сектора в 60 клеток,то при достижении видимой области 58-ой клетки подгружаем другой сектор либо другой клип.
Вот так.

Да, что-то вроде того, только я бы оптимизировал это дело, чтоб не дергать каждый раз массив.
И, если не секрет, какая разница - изометрическая, не изометрическая... Я даже какие-то косинусы у Вас там видел... Зачем это? Я было подумал, что у Вас угол меняется, ну типа высоту камеры менять можно))) А если не меняется, то изометрия == 2D и не мучайте себя тригонометрией, она тут не нужна. И конечно, в таком случае проще было бы все засунуть в один мувик (если не учитывать будущее взаимодействие героя с плитами)
Вы меня заразили, сижу рисую ячейки)))))))

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

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

Wolsh
а как бы Вы это оптимизировали, если не секрет?
изометрическая, ибо движения вверх, вниз, влево, вправо надо ведь проводить в соответствии с положением карты(наклон на 30градусов и поворот на 45) "Косинусы" как раз вычисляют как объекты должны двигаться по основным направлениям с учётом положения карты. возможно я реализую, также пол разной высоты(ступеньки, горки и прочее), для этого и нужны эти расчёты. я удовлетворил Ваш интерес? или неправильно вопрос по поводу изометрии понял...?

Посмотрите на свой код в 15-ом посте.
Сколько раз там повторяется выражение mapList[i] и mapList[0]?
На протяжении витка цикла mapList[i] это один и тот же объект, как и mapList[0] - какой резон каждый раз плееру обращаться к массиву, отыскивать там свойство с индексом i и возвращать его, если этот объект известен? Сохраните ссылку на него в переменной и используйте в функции. И достаточно просто сохранить в переменных сами значения _x и _у для mapList[0], а не лазить каждый раз в массив, чтобы найти объект и узнать его параметры - когда такое делается несколько раз за виток цикла, это очень не оптимально. В конечном итоге Вы совершите несколько сотен совершенно лишних операций.
Что касается изометрии - повторюсь, тригонометрия не имеет к ней никакого отношения, по крайней мере здесь уж точно. Для того, чтобы, сдвинув объект на 10 пикселей вправо, сдвинуть его на 10/2 = 5 пикселей вверх, косинусы не нужны. Здесь отношение X к Y постоянное, все углы зафиксированы. Нет НИКАКОЙ необходимости их пересчитывать. Если бы динамически менялся хоть один угол - обзора камеры, или угол движения объекта, был бы смысл. А так это просто константы.

Пример бага подсветки для админов. К сообщению НЕ ИМЕЕТ НИКАКОГО ОТНОШЕНИЯ!!!!)))

Код AS1/AS2: