
Преимущество флеша над другими плагинами в Firefox
В будущей версии браузера Firefox flash-плагин будет работать как раньше, а всем остальным плагинам (Unity, Java и др.) придется спрашивать разрешение на запуск у пользователя на каждом отдельно взятом сайте.
Скриншоты, сделанные в будущей версии браузера


Причем на скриншоте видно, что по-умолчанию стоит пункт «Заблокировать» — непродвинутые пользователи будут просто нажимать «ОК» или «Отмена» и не смогут запустить игру.
Источник
blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-in-firefox/
Скриншоты, сделанные в будущей версии браузера


Причем на скриншоте видно, что по-умолчанию стоит пункт «Заблокировать» — непродвинутые пользователи будут просто нажимать «ОК» или «Отмена» и не смогут запустить игру.
Источник
blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-in-firefox/
- +4
- AndreSokolov
Комментарии (139)
Интересно, сколько проплатили :)
разработчики делают игры тем, чем привыкли-удобнее, и чтобы продавалось; издатели желают аудиторию поширше и пожирнее — т.е. мультиплеер, мультиплатформенность, регион где хватает денег и покупки производятся в один клик.
то есть — если юнити как инструмент дорастет по удобству до флеша, то издатели станут вкладывать деньги в юнити игрушки, которые будут более быстрыми, менее тормозючими, более красивыми и т.п.
так что юнити плагин как таковой имхо не решает.
Ну а флеш это совсем другое. Дешевая, легковесная реклама; аудио/видео плееры на сайт, в которых уже почти нет багов; потоковые вещания; всякие веб-онлайн инструменты; и еще куча всяких мелких модулей, не считая игр. И вполне очевидно почему FireFox не выключает Flash. Смысл, если буквально первый же сайт предложит скачать флеш-плеер из-за какого-то элемента на этом сайте.
На таком мощном инструменте, где даже слепой сделает игру.
Unity3D IDE — легко делается во Flash IDE. За что я его и люблю ;)
А студия которая делает игры на флеш, скорее всего купит юнити и уже будет делать игры на всё кроме веба:)
Когда мы упираемся в потолок — мы проходим еще раз по коду и фиксим кучу ошибок. Все становится нормально. Когда на мобиле захлебывается GPU — мы проходим по текстурам и вспоминаем, что чем меньше атласов — тем больше производительность и меньше нужды рендереру проходить с накатами графики по разных объеткам из разных атласов.
Сейчас я тестирую одну игрушку нашего камрада и и хрен кто в жизни скажет, что это Adobe Air. Все дело в ровности рук и немного магии. Когда люди var myVar: * = new BitmapData и потом говорят, что флеш медленный — остается вшить такому человеку public function dispose():void в голову :)
Air такой же замечательный как и Unity3D. Как порот бабу — решать тому, кто ее порит :) И если у кого-то 5см — это не значит, что баба плохая :)
Все, что мне нравится в unity — это встроенная поддержка физики. Точка.
Если о IDE говорить:
После моих экспериментов в Flash IDE я увидел, что все важные и невозможные вещи можно делать прямо в самом Flash IDE. Его можно так сильно навернуть, что многим и не снилось. Его пользователи 99 из 100 человек для «рисовать и кодить» используют. И только 1 разрабатывает компоненты :)
Я когда чувакам из адоба показал видео над чем работаю — они не поверили своими глазам. Они думали, что я хакнул Flash CC. Хотя все тупо и просто — это работает и работало очень давно. Просто никто не задавался целью и вопросом. Все тыкали руками и гемороились.
Соотв. что это даст — расстановку элементов в realtime как это у юнити без надобности загружать текстуры в Library. Выбрал файл с диска и вперед. Для level дизайнеров это может быть просто фантастика. Лично я это уже использую на работе интерфейс приложения накидал в разы быстрее. Перетягиваю компонент и выбирая ему текстуру из атласа — сразу вижу изменение.
Мультиплатформа? :) Ну пусть… хоть на калькулятор паблиш делают. Я сильно сомневаюсь, что у наших камрадов есть такие игры, которые и на виндафон и на ps3 разойдутся. Кувать надо то, что куется. А делить шкуру неубитого медведя — не мое. Много наших юнитистов сделало игры для Wii и PS3? А хоть кто-то под WinPhone сделал то, что он сделал одновременно под iOS и Android? Ну может быть 1 из 100 :) И то… как бы не из 1000.
Лучше иметь реальную игру на iOS/Android и хоть что-то с нее заработать, чем не иметь вообще игр на всех платформах и быть владельцем unity pro :)
Всему своя нища.
Всем учить химию! Там сила! )
Не нужно покрытия под все платформы. Иногда просто достаточно одной, которой на флеше нормально нет. Обычный унылый дестоп, например. Однако на юнити он есть.
Нужно выбирать инструмент наиболее подходящий под задачу. Для игростроя ориентированного не на портальные винегреты игр (или флеш-порталы), юнити пока что уделывет флеш.
Ну и с прицелом на «авось» — юнити опять выигрывает. Т.е. если игра пошла, под кучу платформ получаем ее на той-же кодовой базе.
И по флеш-ИДЕ:
Оно же глючное и унылое, — я не дам за него денег. Для не шутки «унылое» заменяем на тормозное. По поводу его расширения — док нет. А так да, расширяемое, возможность есть. Да и пишется на жабаскрипте, который сам по себе порождает новые баги и улучшает тормознутость. Для историч правильности — искал доки по программированию флеш-ИДЕ несколько лет назад, может они подсуетились за последние годы.
Да и АПИ там убогое. Лично мне многих/некоторых вещей не хватило.
Чем плох десктоп на эире?
Я разрабатываю 2D игру под мобилки, почему мне лучше Unity 3D использовать, какие у меня преимущества перед флешем будут?
«Isaac was designed in Flash using ActionScript 2; that's what Florian could program in»
Вообще тот факт что этот Флориан на AS2 писал код — уже как то плохо его квалифицирует как разработчика — просто AS3 нормпальный OOП язык — любой разработчик с радостью на него переключится тем более узнав, что AS2 — это прошлый век — нет Флориант понимаешь тока на AS2 мог писать…
а это зачем? зачем они все ассерты заимбеддили во FLA вместо того чтобы подгружать их когда нужно с файлов? они же не флеш игру делали а для десктопа
Фотошоп вон просто все — кушает честных 50% ресурсов. В моем случае это 8 гиг. Это просто его открыл и он резервирует под себя. У флеша налогично все
Обычно от незнания такие проблемы и возникают. Буквально в обед паренек в скайп задал вопрос почему его игра тормозит дико на втором айпаде :) Я ее глянул и чуть не упал от ржача со стула :) Мало того, что у него в EnterFrame висит генерация партиклов и их убийство (не знает слово пул объектов) — у него еще текстуры примерно 800х600 используются в объектах, которые 80х60 по факту на экране :)
Я ему задал вопрос «что это» — он добавил дров в топку… «Ну как… на компе играли — было нормально. Сделали для растягивания в браузере. Как растянули — качество хуже не становилось» :D
Откуда инфа что на AS2, а не AS3?
Air на десткопе очень широко на ряду с Java используется. Все наши апликухи внутриофисные и на поставку клиентам — на Air. Скорость разработки просто бешенная.
На экране у нас много камер (объект video). Нажав на каждую — вызывается метод во внешней dll. DLL уже дальше связывается с железом и открывает дверь. Эту DLL дает клиент.
Долго ты будешь на плюсах делать это приложение под тач экран? На Air это делается очень быстро.
Понятия не имею как сделать на Air или C++. «Енкодер» у меня на плюсах получился бы быстрее.
Но если делается игра, чуть основательнее и богаче портальной флэшечки, то есть смысл ее на нормальном языке делать, из которого получается бинарник для проца, а не байткод для ВМ.
Энкодинг ресурсов, всякие там тачи и прочее — обычно у каждого разраба есть свои библиотечки и фрэймворки, чтобы все это очень быстро заводить. Ну и в гугле такие простые вещи аж махом ищутся, рутиной не приходится особо заниматься при разработке на плюсах.
Кстати, тот же UDK (UE) стал таким удобным и кроссплатформеным потому, что все в нем с самого с началу жутко грамотно побито на классы и отдельные модули, что и позволило в будущем достаточно быстро пересобрать все это на нативный сишник под все. И он сделан на плюсах, не на экшнскрипте и не на бэйсике :)
Давай рассмотрим простейший пример. Раньше если у тебя каждая картинка была в отдельном в отдельном файле, в разных классах — то да, это несколько затруднит разработку. А если ты когда-либо делал под DirectX приложения — должен знать, что надо в атласы делать и ресурсы хранить во внешнем конф. файле (или ссылки на них). И тогда любая web > standalone будет песней по переводу :)
Ведь у многих проблемы какого рода… берут флешку, которой 100 лет в обед и давай портировать ее. Конечно оно будет туго и мертво происходить. Но если ты хотя бы в этом году начал что-то делать — очень глупо делать игру так, чтоб ее заведомо без магии и кристаллизированных веществ невозможно было портануть.
К примеру, можно делать такую архитектуру кода, что классы и методы будут без допилов портироваться через Starling. А лишь минимально добавляться, а не переделываться :) В этом вся разница.
Лучше сейчас потратить 16 часов на обдумывание и ресерч, чем потом 116 часов на copy-paste
Ну вот например я когда делал воду, то с этим столкнулся. Максимум, что удалось выжать это ~120 частиц воды (с фильтрами, эффектом и привязкой к физ объектам) + на сцене около 40 тел (земля разбитая iso на квадраты, камни, сенсоры и статика). Был конечно и другой алгоритм, заточенный на партиклах, но там во-первых терялась реалистичность физики (подходило для стоячей воды, либо большого напора), во-вторых дабы это всё преобразить нужно было юзать минимум пару шейдеров (всякие diplace/bump/specular), что очень негативно сказывалось на производительности.
А приходилось конечно же подстраиваться под старенькие компы.
Ну а взять ту же игру Sprinkle, где физика натив box2d. Получилось большое кол-во частиц + различные шейдеры + эффекты пены и тд. И это на мобилке. Если делать под десктоп, то вообще можно этой водой всё залить.
Это я к тому, что на флеше мало игр с сильной физикой потому, что приходиться это всё обрезать. Т.к. работает всё очень медленно. Ты придумываешь крутую идею, а через пару дней тестов она превращается в обычный физ пазл:D
Никто не запрещает использовать FlasCC (старая алхимия) для математики. Кодирование в Mp3 с микрофона прямо из флеша в браузере делалось в 6 раз быстрее, чем используя as3 версию кодировщика. Это говорит о том, что смысл в использовании есть.
Где-то видел Box2D на алхимии обновленной в FlasCC в сети. Она работает быстрее, чем Nape.
Просто общество делится на тех, кто жалуется на низкий fps и паблишит все еще под 10.3 плеер и тех, кто использует вменяемые версии с инлайном и допиливает opensource до своей кондиции. Плюс использует все возможные плюшки для повышения fps.
В Nape тоже много огрехов. Я пытался их убрать но без результата. Я не могу запустить собранную swc из-за того, что она компилируется с ошибками. И мне с этим так никто и не помог. Хотя все рассказывали «да что там собирать»… Собрать и запустить собранное — две разные вещи ;)
Когда начинал Nape > As3 переводить (есть мысль, что asc2.0 ускорит его) — столкнулся с тем, что некоторые методы Haxe просто не в состоянии перевести в as3. А это значит, что и во время выполнения будут ошибки и утечки памяти возможно. Что сейчас и получается.
С одной стороны можно взять сразу либу, где все ок и перейти на другую технологию и там найти ограничения и косяки и сказать себе «и тут не торт».
И другое дело ты своими руками можешь переделать и допилить до нужной кондиции решение, которое будет выполнятся быстрее, чем его «не твоя» версия.
Возьми тот же старлинг. В нем много проблем и они устранимы. Просто это никому не надо. 50-90 drawcalls на игру не просаживают fps. А этого в большей массе просто достаточно для игры из серии ХИТ.
P.S. Adobe решили же продолжить совершенствовать vm :) Со счетов рано списывать.
Или потому, что люди ничего кроме как подключить готовый модуль и пробовать не хотят ) Ведь свой модуль писать — это не в носу ковырять )
Кстати физика у меня на Nape.
Я о том, что техническая сторона флеша иногда в корне ломает всю идею которую мы видим на порталах.
У меня были планы сделать 6 видов жидкости, огромный скролинг экрана, куча разных механизмов для взаимодействия с водой, метаболлы, пена, брызги, а тут такой облом:) В итоге потратив целый месяц на изучение воды в играх получилось «Доведи воду до трубы» с оптимизацией «экономия на спичках».
Теперь это очевидно, но тогда, когда я не умел вообще программировать и изучал as3, казалось что «всё будет как захочу».
Кстати, в Sprinkle бокс используется только для твердых тел, которых по минимуму(динамических), сама вода на самописных частицах 600 частиц + 240 баллистических частиц (упрощенная физ.модель), рендер шейдерами — 60 фпс на первом айпаде.
FlasCC это компилятор Crossbridge :) Но он не работает на мобиле так хорошо, как на десктопе. Потому, что для мобил есть NativeExtension.
Поищи в нете — есть где-то бокс нормальный на фласце
Тут же девелоперы сидят, а не менеджеры с клиентами.
Или плеер уже научился исполнять нативный код?
Ты пишешь код на С\С++ и он работает. Как это еще называется?
На выходе получается обычная swc, только пропущенная через оптимизирующий компилятор.
Исполняется байткод на обычной VM с обычным набором инструкций.
Как раз неделю назад допилил небольшой sph движок. Пока пробовал небольшой стрестест: около 6000 частиц, 3 типа жидкости с разными массами, ветер, рисование/стирание стенок.
Как говориться раньше опыта не было.
(Если кому нужно на немецком есть пару книг и вот неплохая remindgames.com/doc/SPH_mobile.pdf [3Мб] поверхностно для мобилок)
Проц i7 2700k, 50-60фпс (на старой машине пока не тестил, жесткий нужен).
Графики нету, отсюда и фпс высокий. Вернее есть, но просто дебаг шарики. Стены по marching squares, но думаю заменю на обычный draw.
Графическую часть нужно будет отдельно писать с нуля. Не хочется обычные фильтры юзать. Хочется normal+displacement+specular map.
Кстати threshold не советую вообще юзать. Когда еще ту игру делал опытным путем вывел, что он медленее чем 3-4 фильтра наложенных на воду. А к threshold'у еще и блюр будет нужен. Поэтому в первой игре его вообще нету, только дефолтные фильтры.
Короче еще пилить и пилить.
Тогда неудивительно, что такие показатели.
Трешолд можно оптимизировать, как и другие постэффекты впрочем, разбив картинку на области (сетку), и обрабатывать только те, в которых находятся частицы. Правда, тоже его не использую, потому он топорно выглядит, без антиалиасинга, хотя и самый простой в реализации на флеше (для метасфер).
1. Плохая интеграция с осью, у шарпа, который в юнити, с этим получше.
2. Производительность. На десктопе свои критерии, игра на флеше в большинстве случаев будет проигрывать. Если же писать под стейж3д, то там другое АПИ — наработки на флеше (если они есть) придется переписывать (флеш не располагает изначально писать под МВЦ, т.к. визуал там сокрыт изначально). Либо писать все заново под стеэйж3д фреймвоки.
Зависит от кучи критериев. Для меня «2д игра под мобилки» не определяющий критерий. И я не пытаюсь ничего навязывать. Возможно будет достаточно и Аир или даже он будет лучше в силу прочих обстоятельств. Ключевое: «Нужно выбирать инструмент наиболее подходящий под задачу».
Лично я (если интересует) склоняюсь к нативным средствам. Если нужна преемственность кода, то: хсамарин, хэкс, манки.
И как зы: я согласен с Рэбиттом в том, что крики про мультиплатформенность слишком преувиличены — и именно для инди, т.к. у них как-раз игры не того порядка, чтобы о ней заботиться, если быть честными.
никто не говорит, что давайте на все все все платформы портировать — это конечно для инди слишком — но на парочку самых перспективных — вполне нужно — например, если это мобильное приложение, то iOS и Android — вполне достаточно для инди — я тоже согласен, что портировать на консоли — это кто-то фантазирует, реально мороки и требований, чтобы выйти на консоли столько, что редкий инди до туда доберется
Ну вообще то же самое 1 в 1 можно сказать про air
В чем именно?
Повторяю в 100500 раз. Когда во флеш иде нашелся баг или есть четкие шаги для вызывания краша — писать надо мне, а не молча жить с этим. Уже пофиксили дохера багов благодаря сознательным разработчиком, которые не равнодушны.
Тормоза в чем? В запираченной CS5.5? См. строку выше. Все касается конкретно Flash CC и всех обновлений, которые вышли и будут выходить. Есть проблема — пишешь мне, мы смотрим с индусами как ее можно исправить. Все очень просто.
p.s. Кстати, юнити у меня крашится регулярно при импорте 3д моделей.
Flash CC тормозит при публикации и при работе с большими fla, особенно на операциях объединения нескольких fla в одну. Ну и сам по себе глюкавый, типа подвинул объект, пропала заливка.
Кстати, свежий повторяемый бажок. Если при тестировании флешки из Flash IDE крашится флеш плагин где-нибудь в браузере, машина зависает намертво.
Во флеше для больших файлов есть формат XLF, а не FLA. Объясняю. FLA это архив, который распаковывается в память. Внутри XLF. Изначально, когда XLF появился, он задумывался как спасение от крашей, т.к. данные считываются не из бинарного потока zip файла + распаковка, а сразу же попадают в IDE. Что снижает лишнюю нагрузку и засорение памяти. Попробуй поработать не с Fla, а с XLF во вкладке Save As. Возможно решит твою проблему и отпишись. Интересно.
В том же юнити проекты и сцены создают папку и туеву хучу файлов. Как раз по той причине, что если был бы один файл — постоянно крашилось бы.
Известный баг. Его причина в том, что холст таймлайна во флеше написан на AS3. Краш плагина влияет на это, к сожалению. Над устранением работают.
Баг с тормозами brush в режиме pressure не пофиксили. Проявляется на некотором железе (в офисе с intuos5 баг есть, дома с intuos3 бага нет).
С увеличением размера проекта и нарисованных объектов появились общие подтормаживания IDE в моменты перехода между клипами, иногда просто на пустом месте, такое ощущение, что IDE весь свой интерфейс перерисовывает.
Когда пытаешь рисовать внутри вложенных на пару-тройку итераций клипов кривая у карандаша получается неровной, зигзагообразной. Приходится заходить в объект из библиотеки, править, снова открывать корневой мувклип.
Причем зигзагообразность не всегда появляется, то есть, то нет.
Вот такие вот плавающие баги реально раздражают. В моей старой копии CS3 зигзагов и торможений при рисовании не было. А заливка пропадала и раньше, это во флэше какое-то наследственное.
Ещё не очень понятно почему fl.getAppMemoryInfo выдаёт отрицательные числа. Память отслеживать приходится через диспетчер задач.
Но так то мы конечно всё что можно было вынесли из jsfl в as3 расширение.
Ещё вспомнил баг по jsfl.
setPersistentData во-первых работает почему-то только если проект тестируется в ide, а собранная swf-ка «забывает» забитые в placeTag метаданные. Ну и setPersistentData поддерживает по факту лишь string формат данных, остальные будто не видит вовсе.
Упомяну еще про тот факт, что на старых CS3 почему-то летает, а с CS4 начинаются тормоза шо ппц. Улучшили, — молодцы, чо. На новых это не заметно «на глаз».
Да хотя-бы лучшая поддержка дескопов и больше платформ.
Про 3д-игро-ориентированное ИДЕ с кучей готовых (заметь — готовых, а не с возможностью в перспективе написать) интегрированных примочек (но это за деньги) и ассетов, думаю, тоже следут заметить. А теперь и с 2д «из коробки» (т.е. это теперь бесплатно и с меньшими затратами в кодинг чем раньше).
Где твой флэшовый бог теперь?
Мой флеш в полном порядке. Не вижу смысла в публикации «везде и сразу». Крупные игроки это слишком редко делают, что я сомневаюсь в рациональности данного мероприятия. Реклама нужна под все платформы, что дороже. Дороже разработка и в любом случае будет адаптации…
Но однозначно молодец, раз замахнулся на всё и сразу. Что за проект? Где посмотреть превьюшки?
Проекты до релиза обычно не афишируем ) В январе-феврале выйдет.
срачобсуждение «эир или не эир» :) многие разработчики как я вижу практически не мыслят игры без физики, да года 2-3 назад очень популярная тема была — сейчас уже не настолько по моему — все же далеко не все игры требуют физику, а от физ-пазлов уже тошнить скоро будетПросто стоит разделять игры, где «перекати круг из точки А в точку Б и получи 3 звезды» и игры где должно всё ломаться, взрываться и отскакивать. Ну а физпазлы надоедают, только от однообразия и рескинов, которыми всё завалено.
Конечно, качество != реализм. Но возьми любую 2д игру и добавь хотя бы нормальных теней — уже получается совсем другая атмосфера и картинка.
Игра фантастика! Покажи ее Air-хейтеру и он тебе скажет «да это же 100% юнити».
Вот, например, две схожих по концепции игры:
www.kongregate.com/games/MaTX222/one-and-one-story
www.kongregate.com/games/flazm/jim-loves-mary
— последняя с физикой, но судя по оценкам, это не дало ей, каких-то преимуществ над первой, хотя в остальном она такого же высокого уровня.
З.Ы. Да, и нужно было видеть, какая простыня физ.багов была найдена благодаря самоотверженным действиям puzzlesea на тестировании второй части Jim loves Mary, там точно по объему на небольшую брошюру наберется :D
Но если взять 2 одинаковых игры (чисто теоретически), то с хорошей физикой она пойдет лучше. Непредсказуемость мира как раз и выводит игру на другой уровень (если конечно ящик вдруг не станет летать, а персонаж проваливаться под землю).
Блин, тут много НО.
Во-первых годы выпуска, во-вторых там совсем другая атмосфера и настроение, в-третьих не о такой физике я говорил, там можно было и без неё обойтись.
Я о таких играх как зомботрон. Именно там физика дает много фишек: толкнуть ящик на голову зомби или пострелять в конструкцию, что бы она разрушилась и убила врагов, всякие осколки от взрыва которые задевают соседних зомби, поездить на машинке и реалистично давить зомби, сломать лифт и он упадет на головы врагов. Вот о чем я писал.
Ну а физпазлы простенькие, там физика не для реалистичности и фана, а просто потому, что так легче, чем рассчитывать попиксельно столкновения с землей.
Или просто потому, что народ в конец обленился и отупел… :)
Ну, так об этом же и идет речь в этой ветке, если необходимо потуже затянуть ремень, то можно и без физики обойтись, а геймплей и историю подать другими средствами, просто немного сместив фокус.
З.Ы. Ну, а фишке «толкнуть ящик на голову» уже лет эдак так тридцать, со времен Boulder Dash’а аж, а может и того раньше :D
Я об этом и писал. Использовать надо когда это нужно. Пихать физику в тетрис не нужно.
Когда у тебя в голове идея игры в которой «Всё взрывается, рушится, разлетается и отскакивает», то как туже ремень не затягивай, но без физики тут не обойтись.
Проще говоря: есть боевики, а есть мелодрамы.