Погрешности вычисления

[orcpochta]

проблема погрешностей не так заметна, если логика вычислений отделена от свойств экранных объектов, т.е. в вычислениях применяются свои какие-то переменные, которые не берутся из св-в экранных объектов, и значения этих переменных присваиваются свойствам экранных объектов

если еще проще, то для минимизации погрешностей нельзя использовать свойства экранных объектов, но свойствам экранных объектов присваивать результаты вычислений

Добавлено через 3 минуты
а ну и конечно всегда по завершении какого-то сложного движения, когда из точки А надо попасть в точку B каким-то хитрым способом или сложным путем, всегда присваивать координатам объектов запомненные при начале движения координаты точки B

[gloomyBrain]

Можно и через координаты объекта сделать. Просто заоверрайдить геттеры/сеттеры

private var _x:Number;
 
...
 
override public function get x():Number {
			return this._x;
		}
 
		override public function set x(value:Number):void {
			this._x = value;
			super.x = value;
		}

Потому как координаты округляются при присвоении

[orcpochta]

ну в итоге-то вы все равно не используете свойства экранных объектов в логике вычислений, а уж как это организовано - дело десятое)))

[gloomyBrain]

ну в итоге-то вы все равно не используете свойства экранных объектов в логике вычислений, а уж как это организовано - дело десятое)))

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

[orcpochta]

У экранных объектов есть, например, свойства x и y, через них строится все расположение объектов на плоскости (как эти свойства организованы внутри - тоже вопрос десятый). Как и что вы там сделаете с расширениями стандартных классов - это уже ваше дело, но по факту получается, что вы свойства х и y экранных объектов не используете в вычислениях, а только назначаете им данные.
А на счет удобства организации, наравне с другими мнениями бытует мнение, что движения надо описывать в отдельных классах, не связанных с конкретными объектами.

[gloomyBrain]

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

Как это движение может быть не связано с конкретным объектом? А что мы тогда двигать будем?
Может, имелось ввиду разделение логики и отображения? Но тогда мой пример вполне себе разделяет позицию объекта для вычислений и позицию для отображения. И все это привязано к одному объекту, ибо именно его мы отображаем и двигаем.

[Psycho Tiger]

Глум, орк нам намекает о MVC. Описывать движение можно где угодно, вьюшке надо знать только координаты, чтобы отобразить. Описание != задание, в общем случае. Твой вариант вполне катит, только честно, не встречал в своей практике нужду в сверхточном позиционировании, или заботе о какой-то погрешности.

[orcpochta]

Может, имелось ввиду разделение логики и отображения?

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

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

[gloomyBrain]

Глум, орк нам намекает о MVC

Ну я тоже сначала так подумал. Только вот подходить к этому можно по-разному.
Я обычно делаю object, у которого есть свойства model и view
А (как я подумал) orcpochta предлагал нечто вроде objectViews[i] и objectModels[i]

в течение жизни какой-то сущности движения вы можете подставлять в нее разные объекты

Вы можете привести пример, когда это необходимо?

[orcpochta]

Сообщение от gloomyBrain

Вы можете привести пример, когда это необходимо?

возможность не означает необходимость)))

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

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