• FConsole — инструмент для отладки PIxi.js (Canvas/WebGL) приложений
    0

    Если коротко, то адаптер графического движка (в нашем случае PixiAdapter), предоставляет метод для поиска объектов, потом идёт по дереву и проверяет детей объектов, попадают ли они под мышку. Думаю, вам будет нагляднее, если вы посмотрите в исходники либ, которе отвечают за это (в частности PixiAdapter: https://github.com/flashist/fgraphics/blob/master/src/adapter/pixi/PixiAdapter.ts )

  • FConsole — инструмент для отладки PIxi.js (Canvas/WebGL) приложений
    0
    Показ width/height происходит только при включённой опции «additional info» (была добавлена буквально 2-3 дня назад). Поэтому по-умолчанию проблем не будет (разработчики смогут дебажить это по-необходимости).
  • FConsole — инструмент для отладки PIxi.js (Canvas/WebGL) приложений
    0
    Уточните, пожалуйста, что вы имеете ввиду под «хуком»? В сам код Pixi.js консолька (и зависимости) никак не лезут, исопльзуют то, что доступно от Pixi.js извне (в частности из interaction используется InputManager с его mouse.global)

    Кстати, буквально недавно заметил, что консолька неработает на мобильной эмуляции (и подозреваю, что на мобильниках тоже), из-за того, что mouse.global не обновляется в случае с тач-событиями (что логично).
  • FConsole — инструмент для отладки PIxi.js (Canvas/WebGL) приложений
    0
    Поправил заголовок (если коротко, то консоль можно подружить с любой JS графической библиотекой, которая работает с Canvas/WebGL, поэтому лукавства не было, неправильно подобрал заголовок). Вам, как и DrReiz спасибо за то, что подсказали, как исправить заголовок.
  • FConsole — инструмент для отладки PIxi.js (Canvas/WebGL) приложений
    +2
    Сделано! На самом деле консоль разрабатывалась как независимая от графических движков библиотека: с возможностью использовать разные движки: но на данный момент реализован только Pixi.js адаптер.

    Жёлтых заголовков и тем более обманов кого-то делать не планировалось: просто не совсем правильно подобрал заголовок (но спасибо, что подсказали, как его улучшить)
  • FConsole — инструмент для отладки PIxi.js (Canvas/WebGL) приложений
    0
    Хороший вопрос) Я не пробовал, но если Phaser работает с «чистым» Pixi.js, и через него можно получить доступ к инстансу PIXI.SystemRenderer и главному контейнеру (если там есть такое понятние), то должно работать.
  • FConsole — инструмент для отладки PIxi.js (Canvas/WebGL) приложений
    0
    Спасибо, что напомнили про этот инструмент, когда-то давно пользовался им, но потом полностью перешёл на Flash-Console (кстати последний раз, когда я использовал MonsterDebugger, там была отдельная кнопочка для Flash-Console).

    На ваш взгляд, какие из функций MonsterDebugger могут быть полезны для отладки Canvas-приложений?
  • PushButton Engine Lesson #2: добавление простой фигуры
    0
    Да что ж это такое, и тут тоже )
  • PushButton Engine Lesson #3: добавление управления к пользовательскому компоненту
    0
    Исправил, спасибо, что заметили )
  • Про бесполезность длительного проектирования
    0
    Для себя, я понимаю, что, наверно, тут комментарий излишен, но я бы тоже написал комментарий даже к такому простому методу. Мне кажется, что постоянство — это хорошо, и если для других методов комментарии пишутся, то чем этот хуже =)
  • Про бесполезность длительного проектирования
    0
    «Как жаль, что я не могу показать вам наши исходники. Там нечего комментировать. Комментарии были бы смешны»

    Это цитата автора поста. Вот ссылка на комментарий: habrahabr.ru/blogs/pm/107655/#comment_3398536

    Кстати, не знаю, как в других языках программирования, но в AS3 есть такая клёвая штука, как ASDoc — это такие комментарии, на основе которых можно генерировать документацию. Иногда, комментирование == документирование.
  • Про бесполезность длительного проектирования
    0
    Если честно, я не очень понимаю суть нашего спора.

    Если вы мне всё ещё пытаетесь доказать, что создание более-менее серьёзной программы в Flash через написание кода в кадрах — это нормальная практика, то, на мой взгляд, вы не правы. Если вы действительно так считаете, то это, скорее всего, из-за недостаточного количества знаний в области Flash-разработок.

    Так уж случилось, что использование ООП и отказ от написания кода в кадрах — это 2 взаимосвязанных понятия (так как не желая писать код в кадрах будет необходимость писать его во внешних классах, с которыми без ООП работать нельзя). Из-за этого, если оценивать профессионализм с точки зрения удобства повторного использования исходников, можно сказать, что люди, которые пишут более-менее серьёзные программы в кадрах — непрофессиональны, так как использовать их исходники и модифицировать их достаточно трудоёмко и напряжно.

    Ещё раз повторюсь, что всё это не относится к баннерам и анимации, но относится к более серьёзным программам.
  • Про бесполезность длительного проектирования
    0
    На данный момент Flash, как технология, — это нечто гораздо более мощное, чем просто инструмент для создания баннеров и анимации.
  • Про бесполезность длительного проектирования
    0
    Профессионализм в данном случае — это знание того, что ты можешь сделать с инструментом (в данном случае Flash) и способность выбрать удобный способ реализации задуманного. В случае с дизайнерами — они, в большинстве своём, просто не знают как работать с классами и, поэтому, пишут код в кадрах.

    Ещё, профессионализм тут можно оценивать с точки зрения «повторного использования» исходников, как со всем этим будет удобно работать другим разработчикам и т.п. В случае создания более-менее серьёзной программы через написание кода в кадрах — об удобстве повторного использования и внесении модификаций можно забыть.
  • Про бесполезность длительного проектирования
    0
    То, что вы описали — это чуть-ли не единственное, для чего может понадобиться продолжать писать код в кадрах и для AS3. К слову, за последний год мне приходилось прибегать к этому раз 5-10, думаю, не больше.

    Кстати, есть и другие способы отследить окончание анимации, если программист хочет полностью избежать написание кода в кадрах.
  • Про бесполезность длительного проектирования
    0
    Никто не спорит, что человек будет пытаться разрабатывать продукт так, как он умеет это делать. Но это никак не повлияет на то, что писать код в классах более правильно и профессионально.

    И я ещё раз не могу понять, почему тема ушла в сторону Flash, если изначально разговор был о том, что автор поста против комментирования и проектирования, а моя точка зрения не совпадает с его точкой зрения.
  • Про бесполезность длительного проектирования
    0
    В AS2 многие вещи считались «нормальными» и разработчики с небольшим опытом часто ими пользовались. В частности, многими считалось, что писать код, разбросанный во-многих кадрах — это нормально, но с опытом все более-менее серьёзные разработчики приходили к тому, что код лучше писать в 1 кадре или, что более правильно, использовать ООП и работать с внешними классами, это было доступно уже в AS2.

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

    Если я правильно вас понял, то вы писали код исключительно в кадрах («событийная модель кейфреймов»), поэтому, скорее всего, у вас либо был очень простой проект, либо вы не обладали достаточными знаниями в Flash-разработках, чтобы использовать ООП.

    «Если ваш проект заканчивается на Flash'е, то это одно, а если флеш выступает в роли интерфейсного решения некого программного комплекса, то это уже другое.»

    Как это влияет на использование ООП в Flash-проектах?
  • Про бесполезность длительного проектирования
    0
    Я работаю Flash разработчиком, и AS3 является ООП языком, поэтому действительно, изъясняюсь в терминах ООП. Не знаю, как в вашей работе, но в Flash не применяя классы и ООП можно написать только маленькую и/или очень запутанное приложение.

    Кстати, я не могу понять, как это относится к тому, что вы против комментариев к коду, а я за них.
  • Про бесполезность длительного проектирования
    0
    Скажите, а что означает «ООП головного мозга»?
  • Про бесполезность длительного проектирования
    +1
    Не могу говорить за других, но могу сказать за себя, что мне приходилось и приходится работать с чужим кодом без каких-либо комментариев. И, вне зависимости, от понятности именования методов и переменных, а так же чистоты кода, мне ещё не встречался проект, в котором комментарии были бы лишними и мешали бы работе с проектом.

    Плюс, уже несколько раз в комментариях упоминали Макконнела и его «Совершенный код», в этой книге есть глава, в которой рассказывается о «споре» между несколькими типами разработчиков. На мой взгляд, там доходчиво рассказано о том, почему комментировать нужно, но так же, нужно знать меру в этом.
  • Про бесполезность длительного проектирования
    +1
    Вы правы, не поверю.

    Разве что в ваших проектах < 10 классов каждый из которых состоит из < 10 методов.
  • Про бесполезность длительного проектирования
    +1
    Попробуйте показать эти исходники 2-3 знакомым разработчикам и попросить их с ходу назвать назначение каждой функции и каждого класса.
  • Про бесполезность длительного проектирования
    +1
    Думаю, что в вашем случае проектирование — «зло», только потому, что вы не имели достаточного опыта/знаний, чтобы грамотно спроектировать систему до начала разработки.
  • Про бесполезность длительного проектирования
    +1
    Например, когда вы разрабатываете нечто, что будет повторно использоваться в других проектах (допустим фреймворк или библиотека для чего-то). Перед началом разработки необходимо решить, что вообще должен уметь фреймворк, как он это будет делать, как сделать так, чтобы ваша разработка была удобна в повторном использовании и как её можно будет гибко расширить при необходимости. Подозреваю, что если «с ходу» приступить к написанию кода, большинство проблем, которые были бы очевидны после нескольких часов проектирования на бумаге будут очевидны только через несколько дней/недель, и чем позже эти проблемы будут выяснены, тем дороже они могут обойтись, так как некоторые не заложенные возможности могут создать необходимость переработки почти всей архитектуры фреймоврка, а если вы уже потратили неделю на его создание у вас может возникнуть желание оставить всё как есть или придумать хак, так как выбрасывать уже написанный код жалко.
  • Про бесполезность длительного проектирования
    +3
    По поводу документирования — почитайте Макконнелла. Думаю, что если вы пишите, действительно очевидный и понятный код, наличие хотя бы небольшого количества комментарий сделает ваши исходники только лучше.

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

    Ещё вы пишите о том, что через полгода, продукт будет дорабатывать тот же человек, который его писал изначально, но вы не рассматриваете ситуацию, когда заказчик решит сменить разработчика и у новой компании будет куча поводов вспомнить добрым словцом первого разработчика и «поблагодарить» его за отсутствие какой-либо документации.
  • Секреты успеха Стива Джобса (интервью с Джоном Скалли)
    0
    Мне одному режет глаз фраза «…со Джоном…»? «…с Джоном…» как-то правильнее, наверно, будет.
  • Так всё-таки, полезно или вредно слушать музыку на рабочем месте?
    0
    «…к тому же отсутствие музыки само по себе не является раздражителем. »
    Прошу, прощения, не правильно вначале понял ваш комментарий.
  • Так всё-таки, полезно или вредно слушать музыку на рабочем месте?
    0
    «…к тому же отсутствие музыки само по себе не является раздражителем.»
    Не соглашусь с вами =) Мне кажется, что музыка может являться ещё каким раздражителем.

    «Мне кажется, нельзя сравнивать «Х любит музыку, но сидит в тишине» и «Х не любит музыку, но сидит с музыкой» нельзя.»
    На мой взгляд, в этом эксперименте сравнивались те, кто работает в тишине и те, кто работает с включенной музыкой. Т.е. и в той и в другой комнате были люди, которые попадали в «зону дискомфорта». А результаты брались, для каждой комнаты отдельно, а не по группам, которые попадали в «зоны комфорта/дискомфорта».
  • Так всё-таки, полезно или вредно слушать музыку на рабочем месте?
    0
    Делили, наверно, для того, чтобы посмотреть, как тишина и наличие музыки влияют на разные типы людей. Т.е. чтобы доказать, что музыка действительно мешает или действительно помогает, а не «каждому своё».
  • Так всё-таки, полезно или вредно слушать музыку на рабочем месте?
    +3
    «Затем половину участников каждой из подгрупп поместили в тихую аудиторию, а вторую половину — в аудиторию, оборудованную наушниками с возможностью выбирать музыку…»

    Если я правильно понял, то в каждой аудитории сидели и те, кому нравится слушать музыку и те, кому музыку слушать не нравится.
  • PushButton Engine Lesson #1: настройка FlashDevelop
    0
    Давно уже думал об этом, нужно, конечно, будет прикрутить RSS, только я не очень в этом разбираюсь, нужно будет покопаться в настройках.
  • PushButton Engine Lesson #3: добавление управления к пользовательскому компоненту
    0
    Спасибо за поддержку =)
  • PushButton Engine Lesson #1: настройка FlashDevelop
    0
    Тоже заметил, что в примерах игр, которые используют as3isolib наблюдается большая нагрузка на процессор.
  • PushButton Engine Lesson #1: настройка FlashDevelop
    0
    Вот обзор 11 изометрических движков: www.emanueleferonato.com/2010/02/23/11-flash-isometric-engines-you-can-use-in-your-games/

    Я для себя из них всех выбрал только 2-3 движка, остальные, как-то, слабенько совсем выглядят.
  • PushButton Engine Lesson #1: настройка FlashDevelop
    0
    Попробуйте скомпилировать и запустить исходники, которые представлены в конце урока, если они будут нормально работать, возможно, то проблема в вашем проекте.
  • PushButton Engine Lesson #1: настройка FlashDevelop
    0
    Сделано =) Спасибо за совет
  • PushButton Engine Lesson #2: добавление простой фигуры
    +1
    Пытались ли вы разобраться с PBE?

    У меня нет причин говорить, что в документации по PBE есть что-то непонятное. Краткие и лаконичные уроки, которые описывают работу с фреймворком с нуля.
  • PushButton Engine Lesson #2: добавление простой фигуры
    0
    Пожалуйста =)

    На данный момент мною переведены только 5 официальных уроков, но в ближайшее время я хотел бы заняться переводом официальных статей, которые предполагают более глубокое изучение PBE.
  • PushButton Engine Lesson #2: добавление простой фигуры
    0
    Всё, что вы сказали выше про экономию времени, может так же относиться к фреймворкам, библиотекам и т.п. Никто не говорит, что написание своего — это зло. Это не зло, это хороший опыт, но вы можете никогда не узнать, какие тенденции сейчас есть в разработках, что используется и что нового придумано, если не будете изучать чужие проекты, библиотеки, фреймворки, движки и т.д. и т.п.

    В общем использование чужих фреймворков/движков/библиотек, на мой взгляд, не является злом. Если если есть инструмент, который упростит вам разработку, то почему бы его не использовать?

    Если есть готовый молоток, зачем брать рубанок и полено, и строгать ручку для молотка, а потом искать железную руду, выплавлять из неё металл и заливать его в нужную форму?
  • PushButton Engine Lesson #1: настройка FlashDevelop
    0
    К сожалению, подборки с плюсами и минусами игровых фреймоврков не встречал. Натыкался на обзоры изометрических движков, если нужно, то могу поискать ссылку.