to post messages and comments.

try { throw new Error(); } catch (e:Error) { var result:String = e.getStackTrace(); trace("Call stack dump (not an error!):\n" + result); }
Объекты должны выполнять свое предназначение. Если ошибку не бросить — ее дух будет преследовать разработчика даже после того, как ее заберет сборщик мусора.

Кому интересно чем закончилась история с утечками памяти в BitmapData почитайте ответы на StackOverflow: stackoverflow.com В кратце есть два вывода:
1. GC очистит эту память потом... Если конечно вся память системы не забъётся настолько, что случится крах приложения.
2. Если изображения сделать побольше, а ячеек в массиве соответственно поменьше, то GC очистит всю ненужную память сразу после отмашки, абсолютно корректно.

Интересная хуйня наблюдается в идее. Pure actionscript проект, использую embed ttf-фонт. Не билдится из-за того, что пытается регистрировать фонт через mx.core. Какого хуя — не ясно. Прямое указание регистрировать через flash.text.Font.registerFont() нихуя не помогает. Помогает только отключение фишки "pure actionscript" в инструкциях билда. Ладно, хер с ним, с размером конечной либы. Но блять фонт так и не ембедится.

Попытка клонирования мувиклипа через всеми юзаемый new Object(mc).constructor() обламывается, если у символа нет явно заданного линкейджа или хотя бы строчки кода на таймлайне. Потому что в этом случае в качестве constructor возвращается просто MovieClip.

Чтобы вы не сомневались, что я такой весь охуенный и что я херачу даже в пять утра, т.к. весь день на работе — сделал рейКаст для менеджера столкновений. doctorstal.itx.com.ua
Такими темпами можно будет свое примитивное физдвигло ваять. Что самое клевое в просчетах за счет графики — они все легко переносятся на Stage3D, так что при потребности можно разогнать выше крыши.
TODOList растет как новорожденный засранец.

Какие фичи нужны в путевом менеджере столкновений? Что настраивать нужно? Какую инфу про столкновение хотелось бы иметь? Я вот наваял койчего, хочу поделиться.
doctorstal.itx.com.ua
doctorstal.itx.com.ua
Вторую демку нагло спионерил у CDK, только со своим менеджером столкновений. Там можно рисовать и набирать скорость кнопочками вправо и влево.
Могу сказать, что код получился в разы шустрее и вобще лучше, чем в CDK. Например, если первую демку навесить на двигло CDK, получится фпс на уровне 3-5. Даже не знаю почему. Может кружочек слишком большой для CDK, или еще чего...
Короче да — укажите мне путь.

У Away3D так вкусно реализован hitTest и поиск локальных координат хиттеста, что прямо кипятком писать хочется. Пойду делать что-то похожее для Proscenium'a, пока заняться нечем. Хотя нет, сначала поспать, а потом извращаться.

Печаль, как же удобно то, что в Java можно иметь доступ к приватным полям — тулы писать проще. Мне это важно при написании дизайнера для флекса. Ладно, модификация байт-кода наше все.

Есть класс, с метадатой:
/**
* Menu state, an instance of <code>App</code> will display available for edition maps, or allow user to create own.
*
* @langversion 3.0
* @playerversion Flash 10
* @playerversion AIR 2.6
* @productversion Flex 4.5
*/
[SkinState("menu")]
/**
* Editor state, an instance of <code>App</code> will display map editor.
*
* @langversion 3.0
* @playerversion Flash 10
* @playerversion AIR 2.6
* @productversion Flex 4.5
*/
[SkinState("editor")]

Есть скин с нодами:
<s:State name="menu" />
<s:State name="editor" />

Но, при этом в меня кидаются ошибкой:
ArgumentError: Undefined state 'menu'.
at mx.core::UIComponent/getState()[E:\dev\hero_private\frameworks\projects\framework\src\mx\core\UIComponent.as:10596]
at mx.core::UIComponent/findCommonBaseState()[E:\dev\hero_private\frameworks\projects\framework\src\mx\core\UIComponent.as:10616]
at mx.core::UIComponent/commitCurrentState()[E:\dev\hero_private\frameworks\projects\framework\src\mx\core\UIComponent.as:10370]
at mx.core::UIComponent/setCurrentState()[E:\dev\hero_private\frameworks\projects\framework\src\mx\core\UIComponent.as:10312]
at mx.core::UIComponent/set currentState()[E:\dev\hero_private\frameworks\projects\framework\src\mx\core\UIComponent.as:6415]
at eu.kiichigo.dd.editor.mvcs.views.mediators::AppMediator/onRegister()[/Users/Nirth/Documents/Projects/dragon-defence/dragon-defence-editor-commons/src/eu/kiichigo/dd/editor/mvcs/views/mediators/AppMediator.as:58]

Кто нибудь сталкивался?

давно ничего не писал. сейчас буду ругать таймеры.

давным давно, когда мы писали самое настоящее ММО с блэкджеком и перьями, нам приходилось синхронизировать действия на клиенте с действиями на сервере. для этого использовался не хитрый механизм синхронизации при входе в игру.
со временем мы начали получать репорты о том, что у некоторых пользователей после десяти минут в игре действия на экране начинают происходить со значительной задержкой. сперва мы думали, что во всём виноват пинг или лаги сервера, но потом репортов стало чуть больше чем много и мы забеспокоились.
начали тестировать и проблема долго не наблюдалась, пока однажды во время тестов мы не свалили на обед, оставив игру запущенной. вернувшись мы таки увидели задержку на реакцию в ~4 секунды. оставив на ночь мы получили задержку почти в минуту.
разбирая на кусочки всю игру мы поняли, что ошибка спряталась в методе getTimer. тот бесстыдно отставал от реальных часов. характер отставания был не понятен. после ряда наблюдений было установлено, что на разных компах время может как уходить вперёд, так и отставать с течением времени.
с тех пор прошло года три, но проблема всё ещё актуальна.

для решения этого косяка мы начали использовать ( new Date() ).getTime(), придумав свой блэкджек.

код решения есть тут: flasher.ru

Вообще, в плюсах ActionScript, является его скорость разработки, гибридный OOP/FP язык, местами лаконичный, местами зачем то нагородили ключевых слов. Но разрабатывать приложения быстро. Быстро в десятки человеко-часов раз нежели писать на Java под Android.
Но есть огромный минус, на этих платформах, прилжения принято не закрывать. А Adobe все никак не напишут человеческую работу с мусором. Хоть Object Pulling используй.

Предположим у меня есть класс А, есть какой нибудь способ узнать, из какого он SWC берется? Суть в том, что MobileSkin класс, пресутствует в трех: qnx, blackberry и spark библиотеках, и надо знать — откуда именно берется.

Смотрю на Flash Ripper люди писаются кипятком, если вакансия на Flash разработчкика — не Game Dev. Но если подумать серьезно — Приложения лучше писать на Qt, Java, HTML5. Flash и его фишки, все таки больше для казуальных one-timer игр, в которые поиграют пару дней и забьют*.

*Или в случае "наркоманов" будут играть каждый день, и забьют на жизнь, вроде FarmVille.

А есть какая либо причина, почему все пишут:
funciton someHandler( … ) {
var a:* = {};

Вместо того что бы написать
function someHandler( … ) {
const a:* = {}

Привычка, или есть практические плюсы в использовании переменной против константы?

Кажется, как-то Ваня Дембицкий (но могу ошибаться) писал, и я с этим согласен, насчет форматирования одинокой строчки кода в блоках типа if-else или в циклах. Типа принято не ставить скобочки если строчка в блоке единственная. Я с этим не согласен по двум причинам:

1. Код менее читаемый. Приходится специально принимать во внимание тот факт, что строчка одна. И форматировать в голове. С учетом того, что наличие или отсутствие {} никак не влияет ни на производительность, ни на размер, поставить {} — проявление уважения к читающему код.

2. Код — это не то, что вырублено раз и навсегда в граните. Его постоянно приходится менять. И что за мудачество приходится совершать если в блоке из нескольких строк надо удалить все, кроме одной? Или если надо добавить еще одну строчку. Приходится совершать глупые и неадекватные движения по простановке или убиранию скобочек. Я называю это мудачеством.

А вообще, формальное отношение к форматированию кода меня пугает. За всеми такими правилами либо лежит сермяжный смысл, либо не лежит. Скажем, перенос { на новую строку или написание на той же, где while, if или for. Полагаю, что в Java правило оставлять на той же связано с тем, чтобы уменьшить число строк чтобы на древних маленьких экранах их вместилось побольше. Резонно. Тогда в эту концепцию вписывается и убирание {} для однострочных выражений.

Но в ActionScript большинство придерживается Адобовских соглашений. Где { идет на новой строке. Ничего страшного. Но тогда довод про экономию строк в однострочных выражениях уже неубедителен.

В общем, строгое следование правилам форматирования в однострочных выражениях я считаю занудством. В чистом виде. Особенно с учетом отсутствия адекватных форматтеров в случаях использования в качестве корпоративного стандарта Flash Builder, в котором нет форматтера, а сторонний форматтер не поддерживает приведения к единому правилу по однострочным выражениям. Он лишь позволяет не менять текущего форматирования для них.

Легко писать, что кто-то формалист и зануда когда сам являешься таковым :) На будущее: меньше формализма в самом себе.

я разобрался почему мой жесон ( #1103610 ) был медленнее. слишком часто выделялась дополнительная память, так как на момент старта не известно сколько её понадобится.
что бы добиться максимальной производительности, необходимо выделить память один раз.
при вызове bytes.length = newLength, FP перевыделяет всю память целиком. поэтому чем чаще она выделяется, и чем больше куски становятся — тем медленнее работает алгоритм.

вчера весь день и ночь ковырялся с конкурирующим жесоном ( blog.brokenfunction.com ). его енкодер по непонятным мне причинам оказался быстрее. я вычислил, что у него очень упрощённая версия версия. но даже добавив в его код соответствующий функционал, мне не удалось его обогнать. начал разбираться со своим кодом.
итог: именно при кодировании жесона работа с памятью медленнее чем прямая запись в ByteArray. пока не понял почему =(

В AS сильно не нравится, что он в регулярных выражениях не считает юникодные алфавиты для матчинга метапоследовательностей типа \b :( Кто знает, написал ли кто универсальное решение, подходящее для всех языков? :)

*cpp_qt Компания на которую я сейчас работаю, закала себе Flex/ActionScript приложение: просмоторщик драгоценных [моделей] камней. Проблема в том, что кол-во мат расчетов оказалось достаточно большим, и приложение жутко тормозит в Flex, было решенно портировать его на C++ Qt.

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

Я давно хотел подучить Haskell, и нашелся повод, сижу учу стереометрию и haskell, забавно ^_^. Надеюсь у меня не возникнет потом проблем с Haskell Bindings for C++ Qt.