Преимущество флеша над другими плагинами в Firefox

www.kongregate.com/unity-games?sort=gameplays

И? От силы 5 игр нормальных?
На таком мощном инструменте, где даже слепой сделает игру.

Пол вконтакта забито играми типа кантерстрайка. Тупые топорные рескины и репаки. Я не считаю это играми. Такого говна и на Flash куры не клюют. Если уже делать что-то серьзное — брать надо как минимум UDK. А поделки из серии «на втором курсе лабу делал» лично меня не привлекают :) Лучше уж вообще не делать, чем делать что попало.

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

Ну лично меня, после того какие компоненты разрабатывают для Flash CC www.youtube.com/watch?v=BihmaSKAgIw на юнити заставят перейти только насильно :D
Unity3D IDE — легко делается во Flash IDE. За что я его и люблю ;)

угарные каменты на ютубе оставляешь.

Я как раз писал о отключении плагина Юнити. Т.к. флеш это далеко не только игры.
А студия которая делает игры на флеш, скорее всего купит юнити и уже будет делать игры на всё кроме веба:)

live вещание, онлайн телевидение :) Протокол RTMP — без этого никуда :) Значит без флеша тоже.

а вот, что касается выхода на PC/мобильные (то есть не веб) — то мое мнение здесь адоб прошляпил момент немного — поздно они сделали поддержку GPU ускорения в Adobe AIR — то есть вот буквально два-три года назад, когда вся эта тема с кросплатформенными средами разработки для мобильных платформ поперла — и все заговорили что флеш умирает — нужно идти в мобильные игры — флеш девелоперы начали искать как идти на мобилы — конечно все хотели использовать Adobe AIR — но он на тот момент времени был очень плох, очень тормознут — и вся эта волна двинулась в другом направление — кто куда — юнити, мармелады, короны всякие — и теперь оттуда уходить не хотят, тем более, что Adobe AIR все же не стал лучше, чем указанные SDK — он стал лишь «почти не хуже»

Не согласен. Air стал лучше и он позволяет делает сумасшедшие вещи. Я еще не видел практически ни одного реального примера, где Air «не лучше». Обычно это все слова из серии «сосед сказал».

Когда мы упираемся в потолок — мы проходим еще раз по коду и фиксим кучу ошибок. Все становится нормально. Когда на мобиле захлебывается GPU — мы проходим по текстурам и вспоминаем, что чем меньше атласов — тем больше производительность и меньше нужды рендереру проходить с накатами графики по разных объеткам из разных атласов.

Сейчас я тестирую одну игрушку нашего камрада и и хрен кто в жизни скажет, что это Adobe Air. Все дело в ровности рук и немного магии. Когда люди var myVar: * = new BitmapData и потом говорят, что флеш медленный — остается вшить такому человеку public function dispose():void в голову :)

Air такой же замечательный как и Unity3D. Как порот бабу — решать тому, кто ее порит :) И если у кого-то 5см — это не значит, что баба плохая :)

ну это даже еще лучше :) но что я хотел сказать — что популярность многих кросплатформенных движков по моему началась именно потому что в свое время адоб эир был очень плох — а людям хотелось в мобилы идти — сейчас же эир не хуже — но конечно возвращаться к эиру те кто он него отказался 2-3 года назад не хотят — во первых — «не доверяют», во вторых — «а зачем, если мы уже научились по другому»

то есть прошляпил адоб момент — не сильно но упустил «поклонников»

Бро, ты не так ставишь вопрос… Air был и раньше не плох. Просто на первой ступени своего развития он специализировался только под desktop. А это две разные вещи, чем быть «тогда плохим». Нельзя ребенка ругать за то, что его на завод не взяли работать токарем :)

Все, что мне нравится в 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 :)

Раньше говорил, что не нужно их сравнивать, ведь никто не сравнивает Unity с UDK — разные весовые категории. А теперь «такой же замечательный». Скоро AIR станет таким же замечательным как и Unreal Engine.
Всему своя нища.

Я не сравниваю :) Я лишь пытаюсь донести до хейтеров банальную капитанску мысль, что лучше лишь там, где нас нет :)

Так делают же, тот же Binding of Isaac криво написанный на as2, что не помешало ему быть отличной игрой.

Ага, и аффтор потом не раз проклял, что делал его на флэше… :)

та ну лааадно… писали на as2 — то есть наверняка никаких тебе Starling-ов ни Satage3d в другом виде не использовалось — и плачутся теперь что флеш плох — типичный случай

«Isaac was designed in Flash using ActionScript 2; that's what Florian could program in»

Вообще тот факт что этот Флориан на AS2 писал код — уже как то плохо его квалифицирует как разработчика — просто AS3 нормпальный OOП язык — любой разработчик с радостью на него переключится тем более узнав, что AS2 — это прошлый век — нет Флориант понимаешь тока на AS2 мог писать…

нужно было написать так «поскольку Флориан был не очень опытным разработчиком — у нас было много проблем в коде» :)

Once the .FLA file rose above 300MB

а это зачем? зачем они все ассерты заимбеддили во FLA вместо того чтобы подгружать их когда нужно с файлов? они же не флеш игру делали а для десктопа

а это зачем?

От обычного незнания :) Я вообще не понимаю чем думают люди, которые FLA загружают в 300 мегабайт. Еще и небось оперативы под 4 гб у них… Неужели не ясно, что FLA при распаковывании в память 300 мегабайт — распаковывает ресурсы, которые превращаются раза 4 больше по размеру… Конечно иде крашится будет… не говоря о том, что самому иде нужны и ресурсы отдельно… А назад сохранить — мало того, что это пересчет… это же еще и в ZIP много мелких файлов засунуть, чтоб этот FLA сделать. Что мешает XLF для файлов больще 50 мб юзать не понимаю. А потом жалуются, что крашится все когда 100500 мегабайт грузят в иде

Фотошоп вон просто все — кушает честных 50% ресурсов. В моем случае это 8 гиг. Это просто его открыл и он резервирует под себя. У флеша налогично все

Распакованные проекты так же тормозят.

Что значит тормозит? Давай по порядку. Желательно видео с файлами… Если ты в IDE работаешь — тебе хочется видеть меньше багов. Если хочешь меньше багов — посодействуй.

но Эдмунту простительно делать такие неверные выводы (он человек искусства а не программист) — или просто своего товарища Флориана обижать не хотел в интервью :)

та ну лааадно… писали на as2 — то есть наверняка никаких тебе Starling-ов ни Satage3d в другом виде не использовалось — и плачутся теперь что флеш плох — типичный случай

Обычно от незнания такие проблемы и возникают. Буквально в обед паренек в скайп задал вопрос почему его игра тормозит дико на втором айпаде :) Я ее глянул и чуть не упал от ржача со стула :) Мало того, что у него в EnterFrame висит генерация партиклов и их убийство (не знает слово пул объектов) — у него еще текстуры примерно 800х600 используются в объектах, которые 80х60 по факту на экране :)

Я ему задал вопрос «что это» — он добавил дров в топку… «Ну как… на компе играли — было нормально. Сделали для растягивания в браузере. Как растянули — качество хуже не становилось» :D

ну не скажи — просто игра у них «Ultra HD Ready»

Ага :) при условии, что если stage.scaleMode = «noScale» :D

Откуда инфа про AS3?

Тьфу, ты.
Откуда инфа что на AS2, а не AS3?

вот :)

О, круто, сильнейше благодарю.

это не в счёт. У него был раскрученный автор.

Как это влияет на то, что игра получилась отличной?

Ты по себе не суди. Вот я на плюсах пишу очень мало. А теперь расскажи мне сколько времени и какие знания тебе будут нужны для написания массового аплоадера файлов на сервер. Мне на Air хватило примерно 45 минут. Сможешь ли ты сейчас на плюсах написать енкодер изобрайжений в свой формат? Сколько времени потребуется? уверен, что в больше в несколько раз.

Air на десткопе очень широко на ряду с Java используется. Все наши апликухи внутриофисные и на поставку клиентам — на Air. Скорость разработки просто бешенная.

Ты по себе не суди. Вот я на плюсах пишу очень мало. А теперь расскажи мне сколько времени и какие знания тебе будут нужны для написания массового аплоадера файлов на сервер. Мне на Air хватило примерно 45 минут. Сможешь ли ты сейчас на плюсах написать енкодер изобрайжений в свой формат? Сколько времени потребуется? уверен, что в больше в несколько раз.

Сила C++ в огромной кодобазе (на пару-тройку порядков больше чем у as3). Про аплоадер не скажу, но енкодер изображений из любых форматов на плюсах — это очень просто.

Просто != быстро в реализации. Не так ли?
На экране у нас много камер (объект video). Нажав на каждую — вызывается метод во внешней dll. DLL уже дальше связывается с железом и открывает дверь. Эту DLL дает клиент.

Долго ты будешь на плюсах делать это приложение под тач экран? На Air это делается очень быстро.

Просто != быстро в реализации. Не так ли?

Нет.

Долго ты будешь на плюсах делать это приложение под тач экран? На Air это делается очень быстро.

Понятия не имею как сделать на Air или C++. «Енкодер» у меня на плюсах получился бы быстрее.

Ну вот. А я не пишу на С++ ничего больше 40 строк. По-этому для меня плюсы совсем не вариант.

Клиентские и потре6лядские поделки, где не требуется из ЭВМ вычислительную мощность вытягивать, конечно удобнее на яве и на этом, как его, твоем эйре :) По крайне мере между операционками кроссплатформенность.
Но если делается игра, чуть основательнее и богаче портальной флэшечки, то есть смысл ее на нормальном языке делать, из которого получается бинарник для проца, а не байткод для ВМ.
Энкодинг ресурсов, всякие там тачи и прочее — обычно у каждого разраба есть свои библиотечки и фрэймворки, чтобы все это очень быстро заводить. Ну и в гугле такие простые вещи аж махом ищутся, рутиной не приходится особо заниматься при разработке на плюсах.

Если мне надо будет делать игру под десктоп — я возьму в руки UDK. А если под веб, десктоп и мобайл — я проведу ресечь. Если Air удовлетворит планируемые потребности в производительности — я не буду тратиться на изучение новых технологий.

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

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

возможно скажу очевидное — ну суть десктопа на эйре все же есть — потому что кроме десктопа можно минимальными усилиями и на iOS и на Android — да и флещ-версию игры можно выпустить — для раскрутки тех де дексктопов, iOS/Android, а вот ну сдул ты пыть с плюсов написал под десктоп — и все — только на десктопе и останется — конечно есть вариант что игра только для десктопа планируется — для тач-скрина 100% не годится например.

Не соглашусь – сделанную на ЭИР на мобилы игру легко портировать на десктоп (веб), но не наоборот.

Вставлю свою пару крышек от люка. Если речь идет играх, которым дофига времени и тут тебя осенило «А не собрать бы ее под мобайл» — то да. Хлебнуть придется. Но не факт, что много. Зависит от игры и от того, на сколько ты грамотно подходил к работе ранее.

Давай рассмотрим простейший пример. Раньше если у тебя каждая картинка была в отдельном в отдельном файле, в разных классах — то да, это несколько затруднит разработку. А если ты когда-либо делал под DirectX приложения — должен знать, что надо в атласы делать и ресурсы хранить во внешнем конф. файле (или ссылки на них). И тогда любая web > standalone будет песней по переводу :)

Ведь у многих проблемы какого рода… берут флешку, которой 100 лет в обед и давай портировать ее. Конечно оно будет туго и мертво происходить. Но если ты хотя бы в этом году начал что-то делать — очень глупо делать игру так, чтоб ее заведомо без магии и кристаллизированных веществ невозможно было портануть.

К примеру, можно делать такую архитектуру кода, что классы и методы будут без допилов портироваться через Starling. А лишь минимально добавляться, а не переделываться :) В этом вся разница.

Лучше сейчас потратить 16 часов на обдумывание и ресерч, чем потом 116 часов на copy-paste

Я подразумевал, что без стэйдж3д практически 100% будет непросто портировать. Да у доброй половины всех флеш-игр, думаю, графон хранится в фла-файле. Даже сейчас буквально единица делают на десктоп на Старлинге.

Уверяю тебя… если иметь желание — все очень просто делается. А когда много ошибок в архитектуре — ну извините :) Плохой подход к разработке даже на С++ не даст хороших результатов. FLA файл не проблема. Есть встроенные экспорты в BitmapData, есть генератор спрайтов прямо во Flash IDE. В нем есть все, что надо для этой самой доброй половины. Ничего не мешает это использовать :) Может быть мне повезло, но когда делаем акционные проекты под веб — они делаются так, что подключив другой класс-менеджер мы получаем загрузку файлов с диска устройства, а не из Embed :)

Ровные не ровные — если плюсы дают, очень тупо, в 100 (сто) раз больше вычислительной мощности, позволяя кинуть на экран не только 100500 партиклов с блюром, но и заставить пол сотни высокополигональных роботов сношаться на физике, ты со своим эйром хоть заоптимизируйся :)

Покажи мне игру с 100500 партиклами, чтоб она выстрелила благодаря партиклам или наличию 250 падающих кубиков на нативной физике?

Вы конечно оба правы. И в том что производительность не помешает и в том, что это нужно под конкретную задачу.

Ну вот например я когда делал воду, то с этим столкнулся. Максимум, что удалось выжать это ~120 частиц воды (с фильтрами, эффектом и привязкой к физ объектам) + на сцене около 40 тел (земля разбитая iso на квадраты, камни, сенсоры и статика). Был конечно и другой алгоритм, заточенный на партиклах, но там во-первых терялась реалистичность физики (подходило для стоячей воды, либо большого напора), во-вторых дабы это всё преобразить нужно было юзать минимум пару шейдеров (всякие diplace/bump/specular), что очень негативно сказывалось на производительности.
А приходилось конечно же подстраиваться под старенькие компы.

Ну а взять ту же игру Sprinkle, где физика натив box2d. Получилось большое кол-во частиц + различные шейдеры + эффекты пены и тд. И это на мобилке. Если делать под десктоп, то вообще можно этой водой всё залить.

Это я к тому, что на флеше мало игр с сильной физикой потому, что приходиться это всё обрезать. Т.к. работает всё очень медленно. Ты придумываешь крутую идею, а через пару дней тестов она превращается в обычный физ пазл:D

Ну смысл в твоих слова есть :) Только не читываешь одну вещь. Самая быстрая физика из популярный на флеше это Nape. Он очень мощнее того же Box2D, который является кривым портом хорошего нативного решения.

Никто не запрещает использовать 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, казалось что «всё будет как захочу».

Максимум, что удалось выжать это ~120 частиц воды

Попробуй SPH или MPM, тянет где-то 2000-4000 частиц на относительно слабых машинах, жидкости получаются естественней чем при симуляции твердотельными движками. Единственное слабое место — это коллижен с твердыми телами, обычно для статики заранее просчитываются карты нормалей и попиксельно детектируется, но в игре со свободной деформацией террейна, как в твоей — да, придется помудрить, или ограничиться приближением через marching squares, типа как в Where's my water. Но это, конечно, не отменяет того факта, что на мобильниках через AIR это все будет тормозить, хотя SPH-водичку можно считать и на GPU, но на AIR'е не пробовал.

Ну а взять ту же игру Sprinkle, где физика натив box2d

Кстати, в Sprinkle бокс используется только для твердых тел, которых по минимуму(динамических), сама вода на самописных частицах 600 частиц + 240 баллистических частиц (упрощенная физ.модель), рендер шейдерами — 60 фпс на первом айпаде.

Можно просто взять Box2D собранный с помощью FlasCC (не путать с Flash CC) — он в браузере работает фантатически. И получить нативную скоростью в браузере.

а можно подробнее?

Все очень просто. Adobe разработала возможность выполнять С++ код в своих приложениях и получить существенное ускорение. Раньше это называлось Alchemy (быстрые байта, алхимия, как угодно). Проект закрыли и сделали из него платную фичу для доступа к быстрым байтам. Потом они поняли, что это плохое решение и сделали поддержку XC возможностей — бесплатно :)

FlasCC это компилятор Crossbridge :) Но он не работает на мобиле так хорошо, как на десктопе. Потому, что для мобил есть NativeExtension.

Поищи в нете — есть где-то бокс нормальный на фласце

И получить нативную скоростью в браузере.

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

flash-ripper.com/crossbridge-opensource-flash-cpp-compiler

Ты пишешь код на С\С++ и он работает. Как это еще называется?

Я давно делал проект, который являлся онлайн mp3 енкодером. Файлы кодировались в разы быстрее, чем это делалось бы на as3. При том, что енкодер был написан на С++ и прикручен к флешке. Если это не нативное выполнение кода — что это тогда? Ясен пень ты format c: не сделаешь, т.к. ограничен набором инструкций. Но все работает и проблем нет

Там С++ работает ниже чем as3, но всё равно через VM. Поэтому быстрее, но далеко не нативно.

Ну хорошо. Не нативно. В моем случае разницы во времени кодирования mp3 что в goldwave, что в flascc я не видел ) хотя в чистом as3 это был ад с залипанием компа и крашем плагина ) помню тестировал 30 минутные mp3

Это называется, что код на с/с++ конвертируется в байткод avm2 через LLVM.
На выходе получается обычная swc, только пропущенная через оптимизирующий компилятор.
Исполняется байткод на обычной VM с обычным набором инструкций.

Ок, убедил. Кролик публично сообщает, что он заблуждался на этот счет. Но в любом случае истина есть — с скроссбридж код шустрее. Очень сильно шустрее.

С этим полностью согласен, скорость действительно выше.

Подверждаю, работает раза в три быстрее как минимум.

Попробуй SPH или MPM

Как уже писал, во время разработки той игры я только начинал изучать программирование, и поковырявшись в SPH не смог адекватно прикрутить коллизии с землей.
Как раз неделю назад допилил небольшой sph движок. Пока пробовал небольшой стрестест: около 6000 частиц, 3 типа жидкости с разными массами, ветер, рисование/стирание стенок.
Как говориться раньше опыта не было.

около 6000 частиц

Норм результат. Интересно, у тебя классический SPH, double density relaxation + viscosity + viscoelasticity? И пара вопросов чтобы прикинуть производительность: фпс, проц, рендер (threshold, gradient map, marching squares) — если несложно.

Лагранжа, наверное он классический:) Остальные методы не изучал. Может почитаю, если есть смысл.
(Если кому нужно на немецком есть пару книг и вот неплохая remindgames.com/doc/SPH_mobile.pdf [3Мб] поверхностно для мобилок)
Проц i7 2700k, 50-60фпс (на старой машине пока не тестил, жесткий нужен).
Графики нету, отсюда и фпс высокий. Вернее есть, но просто дебаг шарики. Стены по marching squares, но думаю заменю на обычный draw.
Графическую часть нужно будет отдельно писать с нуля. Не хочется обычные фильтры юзать. Хочется normal+displacement+specular map.

Кстати threshold не советую вообще юзать. Когда еще ту игру делал опытным путем вывел, что он медленее чем 3-4 фильтра наложенных на воду. А к threshold'у еще и блюр будет нужен. Поэтому в первой игре его вообще нету, только дефолтные фильтры.
Короче еще пилить и пилить.

Лагранжа

Само собой :D Это как бы по дефолту подразумевается раз SPH. Просто необязательно, что реализуются все свойства жидкостей, например, по приведенной тобой ссылке: double density relaxation + viscosity, поэтому и уточнял, чтобы прикинут вычислительную сложность.

Проц i7 2700k

Тогда неудивительно, что такие показатели.

Кстати threshold не советую вообще юзать. Когда еще ту игру делал опытным путем вывел, что он медленее

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

*потому что он топорно выглядит

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

никто не говорит, что давайте на все все все платформы портировать — это конечно для инди слишком — но на парочку самых перспективных — вполне нужно — например, если это мобильное приложение, то iOS и Android — вполне достаточно для инди — я тоже согласен, что портировать на консоли — это кто-то фантазирует, реально мороки и требований, чтобы выйти на консоли столько, что редкий инди до туда доберется

Вот скажем Джонни-К уже довольно долго пилит апельсины под андроид — игра то хитовая получилась — а все потому что нативно были написаны для iOS

А вот еще версия: "…но не достаточно хитовая — а все потому что написана не на AIR".

Aaa! Я не сразу понял о чем ты :) пока не родят на блогах редактирование — сами маркером закалякайте мой комментарий, пожалуйста!

зато плюсанули 2 раза уже — а ты хотел отредактировать :)

да вот и сам думаю :)

Почему у меня ничего не крашится? Я в нем только и работаю :)

Повторяю в 100500 раз. Когда во флеш иде нашелся баг или есть четкие шаги для вызывания краша — писать надо мне, а не молча жить с этим. Уже пофиксили дохера багов благодаря сознательным разработчиком, которые не равнодушны.

Тормоза в чем? В запираченной CS5.5? См. строку выше. Все касается конкретно Flash CC и всех обновлений, которые вышли и будут выходить. Есть проблема — пишешь мне, мы смотрим с индусами как ее можно исправить. Все очень просто.

p.s. Кстати, юнити у меня крашится регулярно при импорте 3д моделей.

Почему у меня ничего не крашится? Я в нем только и работаю :)

Да много объяснений почему, удача, например, или банальная ложь.

Тормоза в чем? В запираченной CS5.5? См. строку выше. Все касается конкретно Flash CC и всех обновлений, которые вышли и будут выходить.

Flash CC тормозит при публикации и при работе с большими fla, особенно на операциях объединения нескольких fla в одну. Ну и сам по себе глюкавый, типа подвинул объект, пропала заливка.

Кстати, свежий повторяемый бажок. Если при тестировании флешки из Flash IDE крашится флеш плагин где-нибудь в браузере, машина зависает намертво.

или банальная ложь.

Во время работы в Flash IDE я пишу экран на видео постоянно. Делаю для отлова багов в IDE. В последней публично версии 13.0.1.808 их прилично меньше, чем было в момент релиза. А в бете новой их еще меньше.

Flash CC тормозит при публикации и при работе с большими fla, особенно на операциях объединения нескольких fla в одну. Ну и сам по себе глюкавый, типа подвинул объект, пропала заливка.

Во флеше для больших файлов есть формат XLF, а не FLA. Объясняю. FLA это архив, который распаковывается в память. Внутри XLF. Изначально, когда XLF появился, он задумывался как спасение от крашей, т.к. данные считываются не из бинарного потока zip файла + распаковка, а сразу же попадают в IDE. Что снижает лишнюю нагрузку и засорение памяти. Попробуй поработать не с Fla, а с XLF во вкладке Save As. Возможно решит твою проблему и отпишись. Интересно.

В том же юнити проекты и сцены создают папку и туеву хучу файлов. Как раз по той причине, что если был бы один файл — постоянно крашилось бы.

Кстати, свежий повторяемый бажок. Если при тестировании флешки из Flash IDE крашится флеш плагин где-нибудь в браузере, машина зависает намертво

Известный баг. Его причина в том, что холст таймлайна во флеше написан на AS3. Краш плагина влияет на это, к сожалению. Над устранением работают.

Известный баг. Его причина в том, что холст таймлайна во флеше написан на AS3. Краш плагина влияет на это, к сожалению. Над устранением работают.

Если бы при краше плагина Flash IDE вылетала, можно было бы простить, но зависание машины наглухо — это рукожопость.

Сейчас как раз рисую во Flash CC, так вот, подтверждаю: заливка бывает пропадает в момент сдвига точки на кривой.
Баг с тормозами brush в режиме pressure не пофиксили. Проявляется на некотором железе (в офисе с intuos5 баг есть, дома с intuos3 бага нет).
С увеличением размера проекта и нарисованных объектов появились общие подтормаживания IDE в моменты перехода между клипами, иногда просто на пустом месте, такое ощущение, что IDE весь свой интерфейс перерисовывает.

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

Причем зигзагообразность не всегда появляется, то есть, то нет.

Вот такие вот плавающие баги реально раздражают. В моей старой копии CS3 зигзагов и торможений при рисовании не было. А заливка пропадала и раньше, это во флэше какое-то наследственное.

Все ждем обновления. Оно планируется до нового года в ближайшее время.

Вспомнил. Во Flash СС утечка памяти при выполнении jsfl скриптов. Такое ощущение, что память выделенная в скрипте вообще не высвобождается. Если скрипт тяжелый и выполняется часто, то приходится перезапускать среду.

Ещё не очень понятно почему fl.getAppMemoryInfo выдаёт отрицательные числа. Память отслеживать приходится через диспетчер задач.

О, вспомнил еще один глюк! JSFL — невероятно тормозной инструмент ;)

Эт тоже. Вообще не сильно понятно зачем нужно было брать javascript когда есть свой язык который быстрее и красивше.

Но так то мы конечно всё что можно было вынесли из jsfl в as3 расширение.

Ещё вспомнил баг по jsfl.
setPersistentData во-первых работает почему-то только если проект тестируется в ide, а собранная swf-ка «забывает» забитые в placeTag метаданные. Ну и setPersistentData поддерживает по факту лишь string формат данных, остальные будто не видит вовсе.

Запость пожалуйста потом постмортем :) Интересно почитать будет :)

Я не пишу статьи, т.к. незачем. Пришлю ссылку )

Незачем тебе или сообществу?

Мне конечно же. Лень )

Очень зря. Скупой обзор лучше никакого. Кому-то полезно, кому-то капитанство. Но в обоих случаях — это прокачка своего скила :) Я когда начал паблишить всякое — мне начали указывать на ошибки и недочеты. И это помогает работать над собой :)

Но обзоры же ты писать не стал? )

Статистика старлинга выдает флеш. :)

упс))

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

Вот, например, две схожих по концепции игры:

Блин, тут много НО.
Во-первых годы выпуска, во-вторых там совсем другая атмосфера и настроение, в-третьих не о такой физике я говорил, там можно было и без неё обойтись.
Я о таких играх как зомботрон. Именно там физика дает много фишек: толкнуть ящик на голову зомби или пострелять в конструкцию, что бы она разрушилась и убила врагов, всякие осколки от взрыва которые задевают соседних зомби, поездить на машинке и реалистично давить зомби, сломать лифт и он упадет на головы врагов. Вот о чем я писал.

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

… зомботрон. Именно там физика дает много фишек:… зомби… зомби… давить зомби, сломать лифт… Вот о чем я писал.

А еще там можно убивать зомбей из пистолету, можно убивать зомбей из дробовика, можно убивать зомбей из автомата, можно убивать зомбей из пулемета, можно убивать зомбей из базуки — да этож какое дикое разнообразие! :)

а просто потому, что так легче, чем рассчитывать попиксельно столкновения с землей

Или просто потому, что народ в конец обленился и отупел… :)

* последний абзац — это было про физпазлы, а не про зомботрон )

Да кто ж спорит, физика — это клево. Но, в большинстве жанров она сродни спецэффектам, как всяческие системы частиц, постэффекты, etc — все это делает задешево картинку сочной, дает фидбек игроку от взаимодействия с игровым миром, и прочие вкусности и прелести. Но, как и любой спецэффект, она должна очень гибко подстраиваться под аппаратные ограничения, должна закладываться ее деградация вплоть до полного выпиливания, не руша при этом сам геймплей.

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

Ну, так об этом же и идет речь в этой ветке, если необходимо потуже затянуть ремень, то можно и без физики обойтись, а геймплей и историю подать другими средствами, просто немного сместив фокус.
З.Ы. Ну, а фишке «толкнуть ящик на голову» уже лет эдак так тридцать, со времен Boulder Dash’а аж, а может и того раньше :D

должна закладываться ее деградация вплоть до полного выпиливания, не руша при этом сам геймплей.

Не должна. Тут всё просто. Ты делаешь игру, тестишь её на старой машине. Если у игрока на Pentium 1 не идёт твоя игра, то пусть хотя бы нетбук за 200$ купит. А закладывать полную деградацию — только себе хуже сделаешь. Давайте тогда еще закладывать деградацию в граф часть. В итоге докатимся обратно до 8бит.

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

Я об этом и писал. Использовать надо когда это нужно. Пихать физику в тетрис не нужно.
Когда у тебя в голове идея игры в которой «Всё взрывается, рушится, разлетается и отскакивает», то как туже ремень не затягивай, но без физики тут не обойтись.
Проще говоря: есть боевики, а есть мелодрамы.

Само собой, если основная механика построена на физике — тут уже никуда не денешься, но если физика — это спецэффекты, то должна быть возможность выпилить их без особых последствий для геймплея или дизайна уровней. К примеру, физика (регдоллы) используется для просчета падения трупов, должна быть возможность их выпилить частично или полностью, и поменять на скелетку с инверсной кинематикой, или сделать разлет джибсов, или просто классическую анимацию прикрутить, при этом не нужно все это сразу реализовывать, просто должна быть возможность выпилить регдоллы, не переделывая игровую логику или уровни. Речь о максимальном охвате платформ и железок. Если сразу целить в самую слабую железку, то игра будет выглядеть убого на современных устройствах, лучше наоборот метить в современные, и за счет адаптируемого пласта спецэффектов/физики иметь запас производительности.

Пихать физику в тетрис не нужно.

А, я бы запихнул, какое-нибудь желеобразное поведение на разворотах и стыковке через интегрирование Верле, а вместо исчезновения заполненных рядов «Всё взрывается, рушится, разлетается и отскакивает» — думаю, добавило бы к визуалке.

Про тетрис было и не раз. Из общей (каловой :)) массы эти поделки не смогли выделиться.