Косметическая проблема ScaleFactor

[MikroAcse]

Хах, интересный вариант - отказаться от констант, "запихнув" их в геттеры.
Возьму на заметку, но посмотрю на варианты других участников форума.

Есть ли минусы у подхода, который предложил Nooob в конце своего поста?

Добавлено через 6 минут

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

И Вы даже не геттер, а обычный метод называете константой.

Вы неправильно прочитали мои сообщения или я неправильно выразился

Опишу еще раз:
Есть константа const BUTTON_OFFSET = 30 например.
Но вдруг оказывается что у пользователя экран в два раза меньше чем нужно!
Изменяем размер всех кнопок, соответственно и расстояние между ними (offset).
Для этого вначале работы приложения рассчитывается scaleFactor (defaultWidth/stageWidth например).
Соответственно нам нужно "поделить константу" на scaleFactor, но суть константы от этого теряется.
Значит нам нужно красиво обойти эту преграду, чтобы константа формально оставалась константой, но при этом задавалась не при компиляции, а в рантайме (один раз при рассчёте scaleFactor).
Метод Nooob кажется подходит. Но интересны еще вариант

[MikroAcse]

Так что же ты предлагаешь?

[elder_Nosferatu]

Я уже предложил: ресайз - пересчет.
Это же как загрузка ресурсов в начале уровня или на входе в локацию. Какой бы железной начинкой не располагал целевой исполнитель (десктоп, ноут, моб-девайс или даже микроконтроллер), следует помнить, что рано или позно его возможности исчерпаются... И тратя их попусту Вы, ка минимум, лишний раз садите батарею исполняющего девайса. Ну а в худшем случае - отсекаете потенциальных пользователей со слабыми девайсами (свою Nokia 2700 я сильно нагружал в игровом плане, но мало что смог после запуска играть, а из того что играл, не все смог пройти - ошибка нехватки памьяти).
Короче, выпендреж на форумах, гитхабе и гуглокодах это одно, но целевую железку кормите тем, что попроще - такая себе цифровая диета

[MikroAcse]

Если не думать о качестве кода, то рано или поздно эффективность его написания и скорость упадут вниз.

[in4core]

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

function resizeAll () :void
{
здесь имеем массив всех элементов, которые будут ресайзится. И делаем по алгоритму, resize(a[i])
где в методе ресайз расписывается алгоритм. o / 30 * scaleFactor к примеру.
}

В одной игре делал таким образом скинование, очень удобно оказалось. Прям наглядно пишу
[ a , b ,c ,d ] элементы которые скинуются ( по цвету всего лишь, hue ) и запускаю цикл по всем. В течении нескольких лет в зависимсти от задач заказчика стали появлятся все новые и новые элементы, и мне не составляет труда просто ручками вписать в массив еще один элемент, быстро и понятно, не надо никаких МВС и МММ )))

[elder_Nosferatu]

Как раз суть в том чтобы ДУМАТЬ О КАЧЕСТВЕ КОДА! Иными словами: "Что нужно - делай, что не нужно - не делай." Речь идет о том, чтобы в каждой строчке кода таилась ПРАВИЛЬНАЯ мысль, а не штамповалась целая канва на одном дыхании. К тому же я не агитирую за г***окод, а всего лишь предлагаю сделать все потенциально востребованые расчеты за один присест, когда юзверь вынужден подождать (будь то загрузка или перерисовка экрана под новый размер), а не дегать классы за методы при каждом чихе, лишь бы красиво код смотрелся.

ЗЫ: Если говорить о порядке, то его нарушают и разбросаные пивные банки с сигаретными бычкаи и разбросаные слитки золота с доларовыми банкнотами.
ЗЗЫ: Вот неполный путь того, что я прошел:

Turbo Pascal (Delphi) -> Javascript -> Actionscript 3.0

И что я там увидел из числовых типов данных? А вот что:

Pascal: Byte, ShortInt, Word, Integer, LongInt, Single, Real, Double, Extended, Comp
javascript: Number
Actionscript 3.0: Number, int, uint

Как по мне, так этот, хоть и слабый, возврат к корням, это один из сигналов о том, что есть смысл выбирать оптимальный инструмент для решения конкретной задачи, а не списывать все на то, что железо нынче крутое и все потянет. В противном же случае продукты типа Winfows 8, Adobe %чтото там% CS/CC... станут нормой.
ЗЗЗЫ: Если найдутся кадры с мнением о вреде преждевременной оптимизации - отвечу сразу. Такое мнение может быть у любого, кто хоть раз писал код, НО!!! Высказывать такое мнение имеет моральное право только тот, кто на оптимизации остановил лбом ворох граблей и съел стаю собак. Такой человек заведомо мыслит оптимизированым кодом и если в его черновых набросках и остаются узкие места, то это уже очень специфические ситуации. Для всех других мнеие о пагубности преждевременной оптимизации - оправдание собственной лени и неосведомленности!

[Nooob]

качество кода = (((понятность кода * память и желание объяснять) / количество сотрудников) * (удобная архитектура / количество изменений задачи)) * ЧСВ / деньги / время

[MikroAcse]

Iнфокор, ты не понял задачу
У меня все текстуры при инициализации УЖЕ заресайзены.
Например, у меня есть меню уровней игры. В нем есть много уровней, между которыми есть небольшое расстояние BUTTON_OFFSET (например 30).
Кнопки у меня уже заресайзились, а вот BUTTON OFFSET остался таким как был, но его ведь тоже нужно подкорректировать соответствии с экраном!
Для этого я и делю везде BUTTON_OFFSET / Content.scaleFactor.
Но тогда код разрастается и становится неэстетичным.

[nubideus]

package  
{
	public class test 
	{
		public static const tet:uint = Main.value; // твоя константа
		public function test() 
		{
 
		}
	}
 
}

public class Main extends Sprite
{
	public static var value:uint; // твоя не-константа
	public function Main ()
	{
		value = stage.stageWidth;
		trace(test.tet); // 800
	}
}

profit

[in4core]

Как раз суть в том чтобы ДУМАТЬ О КАЧЕСТВЕ КОДА!

Как два программиста хлеб пекли...