Adobe AIR + Nape Physics. Разработка под iOS.

iPhone и iPad
Итак, недавно я купил Mac mini, т.к. давно мечтал заняться портированием одной из своих игрушек под iOS. Вопрос стал в выборе платформы, и я какое-то время склонялся к Adobe Air, пока не копнул глубже…



На днях у нас была локальная «конференция» из пяти человек в одном из питерских баров KillFish. И там мы обсудили мельком и Air, и Unity, и Cocos2d, и прочее… Я голосовал за AIR, т.к. думал, что раз уж «Angry Birds: Star Wars» сделана на Starling + Air, и она летает с приличным количеством физики и эффектов — значит, это мой выбор! Тем более, многие видели демки на Starling, где в iOS мы наблюдаем сотни анимированных объектов со стабильными 60 fps. Но на деле… всё упирается в физику.

З.Ы. ДАННЫЕ В СТАТЬЕ ОБНОВЛЕНЫ!!!


Зерно сомнения в моём мозгу посеял Павел (он же apostol). Придя домой, я скачал с торрентов .apk файл энгри бёрдов, переименовал в .zip, и обнаружил всё то, чего быть в AIR-версии просто не может: уровни в .lua, ассеты в .pvr и .zip, и прочие непотребства. Оказалось, на AIR делали всего лишь версию для Facebook. В довершении я скачал все фреймворки из заголовка, открыл IntelliJ IDEA, подключил сертификаты от Apple, и сделал простую демку для теста производительности физики. Результаты огорчили…

Чтобы получились честные 60 fps:

UPDATE #1
iPhone 4 — тянет всего 40-50 динамических тел.
iPad 1 — 50-60.
iPad mini — до 100.

Многие, конечно, делают и во флешках 24-30 fps. Но это не наш метод. Конечно, если выставить 30 fps, на том же iPhone 4 можно будет использовать до 100 физ.тел.
Что мы получаем в итоге:

1. AIR подходит для игр без физики, GPU вполне тянет большое количество графики.
2. AIR + Nape подходит для игр с физикой, при условии небольшого количества тел (50 тел — 60 фпс).
3. AIR + Nape подходит для нединамичных игр с физикой, при условии занижения фпс (100 тел — 30 фпс).

UPDATE #2
Стоит отметить, что код в Air, всё же, выполняется медленно. Т.к. в тесте особо не было нагрузки по части графики, можно смело предположить, что в реальных условиях мы получим на 20-30% меньше динамических тел на сцене — т.е. минимальный вариант для iPhone4 — 35-40 тел при 60 fps. Не густо, но может хватить для многих физ.пазлов.



Какие выводы можно сделать? Утверждать, что AIR не подходит для iOS игр — нельзя. Можно делать фермы, тауэр дефенсы, матч3 и прочие пазлы, платформеры и ещё кучу всего. Можно делать даже игры с физикой, при условии небольшого количества тел и заниженного фпс. Но вот когда вам нужно сделать динамичную игру на 60 фпс с нормальным количеством физ.объектов — AIR сдаёт позиции.

Посмотрев на свои игры, я понял, что AIR подходит далеко не для всех. Laser Cannon, который я планировал портировать, теперь будет лежать в ящике до выхода Unity 2D (что обещают уже совсем скоро):



Инфа о Unity 2D — http://blogs.unity3d.com/2013/08/28/unity-native-2d-tools/

Видюшка вдохновила. Как и инфа, что Unity для iOS девелоперов теперь абсолютно бесплатная (не Pro версия, само собой). Так что, расстраиваться, в принципе, нечему. C# я люблю не меньше ActionScript 3.0.

Смотрим, читаем, экспериментируем… делаем выводы:)

UPDATE #3
После долгого срача... При помощи черной магии от камрадов TheRabbit и ArtPL мне удалось перекомпилировать приложение с правильным параметром (ipa-app-store), в результате чего производительность возросла в два раза (все цифры в статье я обновил). Выводы можно немного пересмотреть. Ощутимый потолок производительности все же есть, но при хорошей оптимизации игры с физикой на Air делать можно (но не сильно навороченные).

Общими усилиями комьюнити мы добились правильных результатов! Всем спасибо! Ура!
  • +16

Комментарии (277)

+1
Наконец-то ёптыть ))
  • fedos
  • fedos
  • ↓
0
Ты к какому конкретно факту это высказал?:)
0
По Юнити :)
0
Я думаю, месяц-два, и мы сможем пощупать этот самый 2d-native-extension:)
0
пора мылить лыжи
0
Данные в статье обновлены, результаты стали выше и приятнее:)
+2
еще тебе подкину пищу. Pvr можно загружать на оис напрямую минуя atf :) достаточно делать это через байтаррей. Если сам ейр не знает напрямую что это, то девайс без проблем это отображает
0
А смысл, Сань)? Он же на флеш больше не компилирует.
0
А причем тут флеш? Я думаю, Саня планировал его юзать для iOS/Android.
0
Не знаю могу ли я лично от лица Саши говорить).
В общем я не просто так это сказал))
0
1. Не суди о производительностости платформы по фреймворкам. Starling не лучший пример производительности. Он просто популярный, но не лучший!
2. Какая верся Air использовалась для тестов?
3. Где гарантии, что ты использовал последний Nape?

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

Мы не знаем как ты обустраивал код, как ты его оптимизировал. По-этому извини, но немного не авторитетно звучит о низкой производительности Air.

Несомненно он не пример большого FPS. Но от рук разработчика зависит примерно 50-70 процентов производительности.

Пришли мне исходники своих тестов и я сделаю технический анализ. Тогда я хоть как-то соглашусь с твоими утверждениями. Ведь я тоже на Unity3d пробовал работать и не нашел там ничего сверхестественного.

Так же ты можешь запилить Nape через нативное расширение и сделаешь прирост производительности.
+3
Ну ты за кого меня держишь, уважаемый?.. Последний Air, последний Nape. И уж в неумелой работе тебе меня упрекать не стоит.
0
Запруфь исходниками? Если все честно у тебя хорошо — скажу, что Air пока не тянет :)
Я вот не столько unity2d жду, сколько поддержку физики в айр встроенную и мультипоточность
0
я тебе больше скажу. Мы делали фреймворк под проект на прошлой работе. Он честно обогнал старлинг. при том, что наш не самый оптимизорованный был
0
Наслаждайся:
dl.dropboxusercontent.com/u/7202976/NapeTest.zip

Можешь проводить «технический анализ» трёх с половиной классов:)
Starling тут особо не причём, потому что тестировалась физика.

З.Ы. Что-то я не слышал, чтобы Adobe планировали запилить в AIR нативную физику.
0
З.Ы. Что-то я не слышал, чтобы Adobe планировали запилить в AIR нативную физику.
у нас много кого мало что слышали )
+2
Может я конечно груб, но ты выдвигаешь сентенции в стиле «может ты нуб и лузер, почему мы должны верить твоим данным»? При этом ничего в опровержение сказать не можешь, кроме своего недоверия. А это бесит. Я не первый год варюсь в геймдеве, и уж в состоянии сделать элементарный тест на производительность и правильно его скомпилировать.
0
дружище, дело не в том, сколько ты в геймдеве, а в том, сколько ты в айре ))) доубираю на кухне и займусь файлами
0
дружище, дело не в том, сколько ты в геймдеве, а в том, сколько ты в айре )))

Достаточно, чтобы уметь грамотно скомпилить тест.
+1
Ага, интересно услышать подтверждение или опровержение результатов тестов топикстартера.
+3
доубираю на кухне и займусь файлами
не знаю почему, но я засмеялся.
0
Сдаётся мне, срач большой на кухне у кролика:)
0
ну потому, что у тебя есть домработники, а у бедного кролика нет
0
Ну же… удиви меня!:)
0
Я слышал. Только что-то мне подсказывает, что это не будет прорывом. Просто повысится производительность физики, ну, максимум на 30-40%. Видимо это пожизненные проблемы с производительностью в AIR, т.к. он всегда будет являться промежуточным транспортом между кодом и системой.
0
Учитывая общую скорость физики, можно заключить, что скорость выполнения AS3-кода вообще не блещет. Т.е. более менее тяжёлые алгоритмы один фиг будут убивать фпс, будь то физика, или что-то другое. И как ты не оптимизируй, у платформы есть хорошо ощущаемый потолок.
0
за кого тебя держу? за человека с мнением. Как известно — «сколько людей — столько мнений».

ps мне в аське неделю назад человек доказывал, что у него последняя айр версии 3.6
0
Ты не поверишь! А я перед разработкой скачал последние версии Air, Starling и Nape с оф.сайтов. Всегда так делаю:)
+7
+1
Ага… Иначе не авторитетно. Вот когда уважаемый TheRabbit сделает свой технический анализ, сразу станет авторитетно…
0
Давай не будем многословно разговаривать ни о чем. Простестируй на iPhone4 своем adobe.ly/1dELirw
Запускай из браузер на девайсе и вываливай отчет. Это может сделать каждый. Пока я не услышу результаты — ничего не буду рассказывать.
0
Safari не может открыть указанный адрес,
бла-бла-бла, так как OS X не узнает адреса, начинающиеся с «itms-services:»

Что сделать-то надо?
0
что у тебя за прошивка такая?
скачай файл по прямой ссылке colorsite.ru/iOSNape/nape.ipa и заинсталь себе как тебе удобнее
0
В общем, ссылка у тебя битая, но я установил.
0
Не битая. Надо открыть Safari на iPhone4 и там запустить было ссылку adobe.ly/1dELirw
0
Ну всё, ты мой бог! Ты сделал вместо 20 физ. тел 45 без падения фпс. И в чём же твой секрет?
0
Мой секрет умрет со мной. Пошел пить яд.
0
Да нет уж, сказал А, говори и Б. Давай не будешь лоаматься, как восьмиклассница.
0
В конце концов:

Пока я не услышу результаты — ничего не буду рассказывать.
+1
Он знает кунг фу
0
А представь, что если Nape переделать на Native Extensions — Nape просто порвет твое представление о Adobe Air :)
0
Ну пожалуйста… Ну что он порвал? Прирост не более, чем в 2 раза. Ты же не станешь весь код игры в Native Extensions пилить. Даже при такой повышенной производительности ему далеко до идеала.

Но да, я ошибся, с такими костылями AIR может больше, чем я написал.
0
Причём, давай представим, что помимо физики будет ещё много чего… Тут и на 45 тел уже не останется. Дай бог 30-35. Но ты правда молодец! Тайное знание — дело хорошее:)
0
Или ты всех обманул, и уменьшил в два раза количесвто итераций физики?:)
0
Понятно, ты отказываешься от своих слов, и будешь молчать, как партизан:)
0
Не не :) У меня сегодня за месяц единственный день был, когда я смог наконец-то провести качесвтвенную чистку мусора на кухне :) Баночки, бутылочки, крупы и прочее говно покрылось пылью и пауками :)
+5
Дружище, мы экспериментально прикручивали рассчет Transform Matrix через Native Extensions и у нас мертвая Alternativa3D буквально восставала из ада на девайсах.
Производительностью в больше части зависит не только от медленного AS3, о чем я не спорю. Но еще и от не правильных подходов к сборке.

1) Твоя сборка ipa по дефолту стоит как device testing. Быстрая компиляция, но низкая производительностью. Deployement type надо ставить Market/AppStore Market. Ты все показатели получает от 1.5 до 2х лучше
2) Зачем для старлинг запрашивать antialiasing? Это не 3Д графика. Достаточно юзать небольшой хак. Отступаешь по 1 пикселю с каждой стороны грифики. Предварительно делаешь её smooth в том же фотошопе. И у тебя уже нет надобности рассчитывать сглаживание, которое для 2Д нафиг не надо. Но я могу и ошибаться «надо или нет». Дело вкуса
3) Ты когда заливаешь текстуры для 2Д — тебе нафиг не нужны mipmaps, которые кушют лишнюю память. Отключай их.
4) Самый важный параметр, который я не знаю зачем для mobile — enableErrorChecking. Ставь его false и ты поднимаешь у старлинг малость fps. Не помню где там был еще запрет на отлов потери контекста. Он нафиг не нужен. Его раньше false ставил.

Несомненно, Air пока «не тянет» так, как мы все бы того хотели. Но и проводить ошибочные бенчмарки не совсем правильно. Люди могут быть гениальными программистами. Но у них могут быть небольшие пробелы в деликатных вопросах по сборкам :)

Всем мир!
0
Не-не-не… Как так?.. Я выбирал не «fast-packaging», а полную компиляцию… Проверю.

Всё-таки вот ты мог бы тоже по человечески. Я провёл кое-какую работу, и выложил результаты. Если бы ты не хамил, а просто помог советом, разобрали бы всё это, и выложили исправленные результаты.

Рад, что на твоей кухне стало меньше говна:)
0
Вот сейчас перекомпилю, перетестю, обновлю результаты. Ну разве не хорошо будет?.. Для чего, по твоему, комьюнити существует?.. Явно ведь не для срача:)
0
P.S. Не нашел в IntelliJ IDEA параметр Deployement type...:( Есть у меня галочка fast packaging, ее я не ставил. Остального нету. В xml для app тоже нету… Подскажешь, где хранится этот важнейший параметр?
0
Увы, я как последний лох кодю в Flash CC :)
Там вот так этот вопрос решается.


Как конкретно решить в IntelliJ IDEA я не знаю. Я могу помочь найти ошибку, но не всегда знаю как её устранить в ПО, которого у меня даже нет :)
0
Увы, в Идее этот параметр отсутствует, как факт… Одна надежда, что его можно прописать в Application Descriptor (пока не нашел, как это сделать).

Во Flash IDE меня не заставить кодить и под дулом пистолета:)
0
параметр типа сборки устанавливается в компилятор строкой. Если Intelli компилирует через коммандную строку — попробуй погуглить на эту тему. Все эти параметры отправляются в adt во время сборки. help.adobe.com/en_US/air/build/WS901d38e593cd1bac1e63e3d128cdca935b-8000.html
Твоя задача пропихнуть как-то -target ipa-app-store :)
Относительно недавно человек жаловался вообще на 15 fps в приложении. Когда он поставил ipa-app-store — он просто был в шоке, какая разница может быть. Не, ну ясно не +100500 процентов. Но все же прилично выше.
+1
Build -> Package AIR Application…
0
Во! Спасибо тебе, милчеловек!
0
Бро, извини, если тебя обидел. Мой мозг насиловали целый месяц на работе. Я не помню когдf спал. А еще клавиатур плохо работет, т.к. встречалась со стеной по два раза в день. Без сна я становлюсь эмоциональным. А с бордаком на кухне я становлюсь злой :)

Уже не впервый раз я вижу, что сборки в IntelliJ IDEA приводят к фатальным ошибкам в сборках без ведома людей. Господа жалуются на низкий FPS. Я люблю Flash Pro IDE за то, что там настройка самой сборки осуществляется элементарно через Drop Down и никогд не глючит :) Не ставит что-то «от себя», когд ты другое что-то ставишь.

Я вот хотел найти Nape исходники — что-то не вижу их нигде. Хотел оценить сколько часов надо для переноса н Native Extensions. Правда не знаю в надобности. Ведь Билл Ховард обещал Air со встроенной физикой на основе Nape.

А если бы пилить nape на нативном расширении — фактический прирост будет конечно, но не 500%. Скажем с 40 боксов получим 90 стабильно думаю. Хотя для большинства игр и 30 уже достаточно будет.
0
Уже не впервый раз я вижу, что сборки в IntelliJ IDEA приводят к фатальным ошибкам в сборках без ведома людей. Господа жалуются на низкий FPS.
Проблема в том что люди не достаточно компетентны в тех или инных вопросах, а идея ничего без их ведома не делает.
IntelliJ IDEA лучшая IDE для разработки ;)

Я вот хотел найти Nape исходники — что-то не вижу их нигде.
И не найдешь. Никто ж не говорил что он Open Source
0
Ага, только у меня они есть откуда-то. Но старые
0
Open Source. Исходники на гитхабе github.com/deltaluca
0
Что-то не понятно там всё… Там не AS3 исходники, а haxe что-ли. Я с ним не работал.
+7
Вообще исходники на caxe, который генерирует haxe-классы, которые компилируются в swc, которые используются в as3, который бранится с коровницей строгою, которая доит корову безрогую, лягнувшую старого пса без хвоста, который за шиворот треплет кота, который пугает и ловит синицу, которая часто ворует пшеницу, которая в темном чулане хранится в доме, который построил Джек. ;D
0
Ага, вот и я вот думаю как Адоб хочет это портировать под себя?
0
Ключевое слово «портировать». На это еще в начале лета отвечал Бил. Не портировать, а брать за основу идею и структуру. Это малость разные вещи :) В любом случае время покажет, а история спишет :) Всем флеш!
0
Так а когда это случится? Ты вроде человек осведомленный, хотя бы год/осень/зима/весна/лето. В общем когда?:)
0
Бил обещал к концу этого года. Но потом они решили, что надо сначала сделать workers для мобил. Потом разошлись в отпуска все. Потом приутихло все и они зачем-то начали фиксить баги, которые мешают жить Enterprise приложениям. Это в основном работа с видео и ничего общего нет с игровой индустрией.

Из последних данных — что-то обещали на октябрь. Что именно — точно не ясно.
0
вот только не понятно за что ты извиняешься. Всё таки тест не правдивый был.
+4
Я был груб :) Не зависимо от результатов теста.
0
Я тоже извиняюсь! Главное, что все помирились, и всё поправили:)
0
Вообще не трогал итерации
0
А есть какая-нибудь физическая ane? Теоретически должно сильно ускорить физику и тогда вообще не возникнет проблем с производительностью.
0
Где-то в инете валялся древний box2d. Правда не уверен, что под мобайл.
Есть буллет физикс на алхимии первой. У приятеля машин в 3д на нем ездит.
Если бы Adobe не грозились Air и физику — кто знает, может быть уже запилил бы кто
+1
Услышал в видео что они туда еще и бокс2д встроили, шикарно.
Учитывая что C# тож самое что AS3, выглядит очень соблазнительно :)
0
Но AIR с нативным нейпом всё равно был бы круче.
+3
В том то и дело, что нет нативного нейпа. Практически весь буст его производительности достигается за счет микро-оптимизаций под архитектуру флеш плеера / виртуальной машины. Даже Лука где-то писал, что нейп транслированный хаксом в c++ сливает нативному боксу практически в два раза.
+1
То есть нет особого смысла портировать нейп. Порт практически никак не будет выделятся среди аналогов, к тому же имеет слабую распространенность.
0
Интересно, а что мешает встроить в AIR нативный бокс как подключаемый компонент?
0
Почему-то мне кажется, что это не так просто… Но я в таких тонкостях не соображаю.
0
это просто
0
Сделай, выложи сёрсы. Мы скажем спасибо, и будем пользоваться:)
+6
Сейчас. Гостиную пропылесосит, прихожую подметет, мусор вынесет — и выложит :D

Please be patient!
+2
Да-да-да… Я всё жду возвращения из кухни:)
0
Если серьезно, то вроде даже попадались нативные расширения с боксом, правда, не в курсе на какой они стадии завершенности сейчас. Если говорить в общем, то основная сложность, наверное, прикрутить к имеющейся архитектуре и системе управления памятью (GC) и заставить это все идентично работать на всевозможных таргетах. Ну, и вроде же Адоби в своих несмелых мечтах, в своих робких фантазиях, хотят нативную физику прикрутить в будущем. Только вот пока одни планируют, другие (Unity 2D) уже делают :D
0
Это да. Недавно на форуме был трейд по этому поводу. Если с физикой и дальше будет всё так плохо, то Unity2D самый лучший вариант для перехода. Конечно можно делать отличные игры и без физики, но это скорее не выход из ситуации, а ограничение своих возможностей.
+3
Родина там, где хорошо. Если Unity2D окажется и удобный и быстрым — я раздумывать не стану.
+1
Трезвая мысль. Я уж было подумал, что ты ярый евангилист Adobe Air:)
0
Вот! Это уже прогресс, я считаю.
0
The rendering performance of all these engines is pretty impressive, about on par here with native rendering on mobile devices, with some language overhead only when you get into the thousands of objects. Problem is the game also makes use of a physics engine, and it this is where the limitations of the platform really start to become a problem. Using the as3 version of the Nape engine (a really nice engine – way faster that Box2DAS3 and with a much better API), I was only able to simulate around 50 dynamic bodies on an iPad2 (hardly a low end device) with decent frame rates (above 40 FPS).

Инфа отсюда
0
Используй haxe )
0
Claymore
Даже Лука где-то писал, что нейп транслированный хаксом в c++ сливает нативному боксу практически в два раза.
0
А вообще, достали умники:) Сделай на хаксе, выложи свои результаты. А то кроме вбросов ничего не слышно…
0
А сколько сливает Air?
Мое дело предложить, не знал что реакция будет такая бурная.

Отличия между as3 и haxe минимальные, поправить 3 класса и проверить недолго, намного быстрее чем ждать выхода Юнити2Д.

У меня нет девайса, так бы проверил.
0
У меня есть девайсы, но я не представляю, как компилить в haxe через IntelliJ IDEA.
0
А ещё у меня сомнения в наличии Starling на haxe.
0
Под IntelliJ есть плагин, если не ошибаюсь этот plugins.jetbrains.com/plugin/?pluginId=6873

+ FlashDevelop хорошо поддерживает haxe, вот инструкции если интересно:
haxe3.blogspot.com/2013/07/getting-started-with-haxe-3-and.html
haxe3.blogspot.com/2013/07/setting-up-flashdevelop-for-haxe-3-and.html
github.com/openfl/openfl/wiki/Get-Started
0
А с рендером как быть? Starling вроде как только на AS3?
0
Для всех таргетов, кроме флеша используется DrawTiles (он же упоминается в статье)
github.com/matthewswallace/openfl-tilelayer
0
Т.е. итого, прирост будет в 1.5-2 раза. Но это уже не ActionScript, а гибрид бульдога с носорогом… Таким же макаром, лучше какой-нить Cocos2D-x использовать, там прирост будет в 10 раз.
0
ЗЫ В приведенной же ссылке и приводится для сравнения haxe, это если кто читает через строку и не заметил.
0
90 физ.тел при 40 фпс. Против 50 тел. на 40 фпс… А 60 фпс, один хрен, речи не идёт. Хоть прирост и ощутимый, но этого явно не достаточно.
0
вопрос может не в тему… Юнити компилит swf-ы, а можно их потом выставлять на Конге или Ньюгрунтах? Почему спрашиваю, с ними какая то чертовщина, они проигрываются только из НТМЛ страницы скомпилированной тем же Юнити, если просто запускать swf то не запускается.
  • DedoK
  • DedoK
  • ↓
0
Насколько я слышал (может ошибаюсь), компиляция из юнити в свф — дело прошлых лет, и больше не развивается и не поддерживается… Так что, эту штуку можно забыть.
0
Они использует Stage3D, поэтому должен быть прописан правильный wmode.
Но они и правда уже забили на флеш.
0
Читаем апдейт, пересматриваем цифры.
0
Дружище, обнови пожалуйста и хабр. Не пугай людей. Мне уже писем 20 пришло от разных людей…
0
Сильно спать хотелось:) Обновил…
+1
Не очень понятно, зачем делать игры со 100 динамическими не «спящими» объектами на экране? Симулятор разрушающегося города?
Статика и Кинематика в Нейпе очень быстрая. Динамики даже в не оптимизированном платформере не больше 20-50 объектов. И то из них не спит 5-10 всего. Это даже на 3gs будет летать.
Я недавно портировал наш Georganism на Старлинг+Нейп для мобилок. Уровни совершенно не оптимизировал, каждый блок — это отдельное тело. На 3гс наблюдаются лёгкие тормоза, но играть можно. На девайсах мощнее проблем нету совсем.
0
100 — много… Но я же написал, что для 60 фпс получится в лучшем случае 30-40. А 30 фпс, я, к примеру, не рассматриваю. На мой взгляд, это убивает в хлам динамику.
0
*30-40 тел
0
Даже 30-40 неспящих динамических тел — это очень специфичная игра.
0
Это хороший уровень в энгрибёрдах. Но я ж не спорю, для ощутимой части физ.пазлов 40 тел хватит с головой.
0
Фактически кроме ангрибёрдсов и прочих кастл крашерсов больше и не припоминается жанров с необходимостью в таком большом количестве динамических не спящих тел.
+3
Если используются сложные тела, то поидее легко наберется: веревки, мягкие тела, регдолы, разрушаемые объекты, симуляция жидкости, etc. Например, пять регдолов по 12 тел, плюс с десяток объектов — вот уже 70 объектов в Ragdoll cannon.

Или, к примеру, здесь на вид тел 100-150:

http://www.physicsgames.net/game/Jelly_Cannon.html
0
Тут важны ещё маски коллиженов. Потому что не всё сталкивается со всем. И если всё правильно оптимизировать, то будет летать где угодно.
И я не спорю, что в принципе можно нагрузить физику. При желании можно и графику нагрузить. Очевидно надо делать скидку на мобильность платформы.
В том плане, что на юнити можно так же легко сделать игру, которая даст 2 фпс на ипад4.
0
которая даст 2 фпс на ипад4.
Хоть один человек это понимает! Я талдычу уже всем, что когда начал юнити крутить — ушатал его на лопатки. Потому, что я не шарю в нем и делал так, как думал «правильно».
0
А так вообще — Blosix, Cover Orange, и т.д. В любой игре можно сделать верёвку/мост на 20-30 тел, что мешает?:)
+2
Тела это хорошо, а вот добавить немного джоинтов и картина станет еще менее радужной.
0
Ага… В боевых условиях все может стать еще сложнее.
+1
Мои мысли такие. Потолок имеет любой движок. Зачем тебе в него упираться специально, если в боевых условиях ты не дойдешь до него скорее всего? А когда дойдешь — тогда и решай надо ли вообще под мобилы писать?
0
Ну у меня есть ещё сомнения… С одной стороны, я хотел бы попробовать переписать Laser Cannon под AIR, но у меня нет уверенности, что я не упрусь в этот потолок. По моим ощущениям, нагрузка от игры должна быть как раз около пределов производительности AIR на iPhone4. Может даже её хватит… Но надо пробовать. А это время…
0
Ну что тебе сказать. Как уже в инете писалось — Unity не панацея. Ты можешь уменьшить всё на 10% и сделать быстрее н Air или же можешь сделать как есть, но на unity3d. И не факт, что будет особо отличаться :)
0
Надо пробовать. Я ж в выводах написал, что AIR слабее, чем хотелось, но при желании можно сделать жизнеспособно. Главное выяснить, на что уйдёт меньше усилий — на оптимизацию в AIR, или на полное портирование в Unity.

Так-то, если в AIR действительно впилят нативную физику, будет почти совсем хорошо:)
0
Ну так можешь не ждать и впилить её сам :)
0
Ждём нативного 2Д тулкита для Юнити и там видно будет. Думаю лыжи так или иначе потихоньку все затачивают.
0
Ну на Юнити есть большие надежды, это да:)
0
Пока вы спорили, кто-то уже все сделал за автора :))
play.google.com/store/apps/details?id=zjgame.laser.cannon.funnygame
0
А про это я писал очень давно. Пока ребят меряются писюнами — другие работают с тем, что есть… Увы
0
Сдаётся мне, это не «сделал»… Это тупо флешка, стопудово жутко тормозящая. А может и вообще не работает:)
0
Не то, что не работает… Ещё и пытается лезть в инфу телефона и устанавливать всякое говно. Вот беда, что Гугл ПЛей не модерируется.
0
Короче говоря это фейл
0
Это фейк:) А то, что творят китайцы… Это полная жопа. Портят заранее рейтинг и имя играм, которые ещё не дошли до платформы.
0
Настрочил жалобу в Гугл Плей на подлого Зяо Миня…
0
Там еще и улитка боб 4 (под номером 3 почему-то), флакбой и 3 панды из известного play.google.com/store/apps/developer?id=zhaojia+studio
0
Мда, китайцы не дремлют…
0
Кстати, новая беда. АнтиАлиасинг в старлинге на девайсах вообще не работает. Кто знает, в чем может быть проблема? На ретине этого и заметно толком не будет, а вот на айпад-мини — весьма ощутимо не хватает.
0
На форумах пишут, что он на iOS тупо не работает.
0


Разница ощутимая, всё-таки…
0
Сейчас попробую заюзать хак с прозрачностью в PNG.
0


Работает!:) PNG с обводкой из почти прозрачных пикселов хорошо заменяет anti-aliasing, практически неотличимо.
0
Вот про это я и говорю :) Иногд не понимаю как в играх могут быть крутые эффекты, которые явно не должны тянуть девайсы. Когда копать начинаешь — получается, что все юзают всякие ухищрения.
+1
а самое главное, что это вовсе и не хак — и решение напрашивается само собой — например проблемма эта существует только для прямоугольных спрайтов — например спрайты песонажей всегда имели прозразную обводку — и проблем с их антиалиазингом и не было никогда — но боксы оказались «особенными» — а всего лишь потому что забыли им эту прозрачную обводку добавить, а им тоже нужно — тоже хочется :)
0
зачем тебе антиалиазинг — Rabbit же уже писал как нужно делать 2д антиалиазинг правильно — кстати даже Джонни-К в кавер оранже наткнылся на эту беду с антиалиазингом — а решается она довольно просто — рисуешь спрайты с антиалиазингом в редакторе и делаешь прозрачную рамку по контуру спрайта — все — антиализинг можно отключить — все будет рисоваться как нужно
0
Так и сделал постом выше:)
0
А почему всегда 60 фпс, 30 фпс так плохо выглядит на мобильном что-ли?
0
Дело вкуса… На мой взгляд, очень нединамично получается с 30 fps. Но это очень зависит от игры.
0
Ну да, это нужные какие то большие скорости, что бы заметить рывки на 30, а на маленьком экране это будет еще более не заметно. Просто на флеше всегда делал с 30 фпс и вроде всегда было нормально. Но может я просто привык к 30)
0
по моим наблюдениям для определенных типов игр и 30 фпс абсолютно нормально — но игры где много динамики — особенно скролинг экрана выглядят гораздо приятнее при 60 фпс — например в тентакл ворс у меня 30 фпс во время геймплея — а вот в меню 60 фпс — потому что там скролинг окон и левел паков — 30 фпс был очень заметен
0
У меня в Laser Cannon на 30 фпс всё смотрится так себе. Слишком много быстро летающих объектов. Говорю же, зависит всё от игры.
0
Можно ли где эту игру с 30 фпс посмотреть на флеше?
0
Неа… Я специально напрягаелся, чтобы сделать 3-ю часть с 60 фпсами:)
0
У меня просто такое чувство, что игроки этого даже не заметят и подумают что так и должно быть)
Интересно часто ли в комментариях игроки указывают недостаток в 30 фпс и влияет ли он на продажу.
0
Зачем спорить? Я считаю, что это влияет на восприятие игры. Тут уж кому как нравится:)
0
У меня вопрос: именно 60фпс физики влияют на восприятие? Или фпс игры?
Дело в том, что прием, когда игра показывает сколько хочешь фпс, а логика/физика вообще 10фпс не фокус.
30 фпс физика должно быть достаточно, если туннельные эффекты избегать.
0
Ну, опять же, смотря какая игра. У меня было много быстро двигающихся физ.объектов, и на 60 фпс. физики это смотрелось гораздо лучше. Если б они летали медленнее, хватило бы и 30 фпс.
0
Вот я и спрашиваю, почему смотрелось лучше? Предметы протыкали друг друга? Пролетали? Ведь плавность все равно идеальная, если графически у тебя все равно 60 фпс с интерполяцией между физ. кадрами.
0
Я этим вопросом не запаривался, потому что во Flash для Web я не использовал GPU, и у меня графика жрала 80% ресурсов, и только 20% уходило на код. Поэтому делать 30 fps для физики не было смысла даже.
+1
Ты о чем то не о том. 60фпс флешка. Физика считается раз в два кадра. Получается информация по положению и ориентации объекта есть только через кадр. В промежуточном кадре просто интерполируем его положение между двумя кадрами физики которые нам известны.
0
У тебя такое было в топдэфенсе? Ты лучше пример сделай, посмотрим как работает)
0
А в топ дефенсе была физика?
0
там было разделение логики и рендера вроде.
0
физики не было, было просто логика 10фпс
выше ответил подробнее
0
В топ дефенсе не физика, но логика работала 10фпс. Флешка 30.
Зачем пример делать, народ, это старо как мир. Вы думаете если в стратегиях реального времени фпс 100 то и логика с пасфайндингом и пастрекингом путей каждого юнита, АИ итд все это 100 раз в секунду считается? И еще если кадры в секунду пляшут в завиcимости от железа, то и логика плавает?
10 раз в секунду логика. А графика — сколько потянет железо.

Можно почитать, плясать отсюда:
www.gamedev.ru/code/forum/?id=156562
gafferongames.com/game-physics/fix-your-timestep/
www.koonsolo.com/news/dewitters-gameloop/
0
Ну, просто мы тут смотрим сколько максимум можно сделать физических объектов на аир, а то сейчас до оптимизируем как раз до 100)
0
Меня уже почти убедили пробовать делать порт игры на AIR/Nape/Starling:) Если использовать хак с просчётом физики через кадр — и фпс будет хороший, и нагрузка небольшая. Гениально же!:)
+2
Вот меня смутило откуда известен второй кадр физики?
Или будет запаздывание на два кадра?
0
тебе известно положение тела в физ. мире. Запомнил его как «предыдущее». Просчитал физический кадр. Запомнил положение тела как «новое». Дальше несколько промежуточных кадров просто отрисовываешь положение тела в промежуточных между этими положеними точках.
Если у тебя плавает граф. фпс — то положение тела интерполируешь пропорционально прошедшему времени. Во флешке можно проще: если установил фпс 60 а физика 30, то ты точно знаешь что в промежуточном кадре надо положение вполовину брать.
0
Таки хитрый приём! Задумаюсь над апробацией сего:)
0
В конце концов, в случае с AIR для iOS, можно для слабых девайсов (iPhone4, iPad1) делать просчёт физики через кадр (30 fps). Тогда уж точно будет куда меньше проблем с производительностью:) Спасибо за клёвый хак!
0
делать просчёт физики через кадр
Только нужно делать не в буквальном смысле через кадр, а каждый кадр, но по половине от общего объема физических вычислений. Чтобы получалось, что один физический шаг равномерно размазан на два графических по нагрузке, ведь во флеше фиксированный фпс. Или в отдельном потоке физику считать, но в мобильном AIR они пока не поддерживаются.
0
И как же посчитать половину физики? Плохо себе представляю…
0
Особенно учитывая отсутствие серсов Nape на AS3. Так-то можно было часть итерраций считать…
0
Сорцы есть, но не as3. Написал Луке. Глянем, что ответит. Я не понимю как компилировать то, что есть :) Если пойму — есть шанс своими силами некоторые функции перекинуть в Native Extensions. Даст по идее громадный прирост.
0
Claymore выше описал алгоритм )
gamedevblogs.ru/blog/iphone/1312.html#comment36886
0
мне это нифига не дает ) я написал Луке письмо с просьбой помочь мне тупому куда нажимать и что качать )
0
Мне нужны именно сёрсы в AS3. На haxe у меня нет особого желания писать. Я ведь правильно понимаю, что нельзя одновременно и на том, и на этом?
0
Я не знаю. Когд открыл haxe — через 20 минут я его удалил. Не люблю я эти все хэксы, кексы. Вот минус open source — сколько разрабов, столько и версий. И нигде нет четких step by step tutorials что скачать и куда нажать, чтоб из папки выплюнолось swc файл
0
Я вот не пойму… Если haxe-версия Nape в open-source, почему нельзя и AS3 выложить?
0
Так он на caxe или haxe его писал :) Просто комилирует в AS3. Я не нашел как из caxe в as3 переделать исходники. Пробовал swc декомпилировать. У него там инструкции висят в коде, которые в виртуальной машине просто не существуют. По-этому не выполняются. Подумал косячит декомпилятор. Начал дизассемблить. Та же хня :)

В общем пока делаю основную работу и жду ответа Луки. У меня руки чешутся хотя бы 10 строк закинуть в native extensions :) Он же тогд порвет все ожидания и еще больше обрадует
0
А ты ему написал, для каких целей тебе оно нужно? Может его тоже вдохновит идя:) Напиши о перспективах развития Nape на мобильных платформах:)
0
Да, я написал, что хочу эксперимент провести :) Я вчера математический тест делал. 3000 итераций на iPad4 во флеше 4мс посчитало. А в Native Extensions 0мс ) Т.е. есть все предпосылки, что Nape будет минимум в 2 раза быстрее
0
Реквестирую отдельный пост о результатах экспериментов:)
0
будет обязательно
0
Интересно, а как ты хочешь native extension собирать? Портировать нейп на objective-c? Про транслирование хаксом в с++ тут ниже писал уже, не буду повторятся.
0
Я не буду портировать его весь. В Nape есть тяжелые функции, которые можно отправить в obj-c и нагора просто получить результат рассчета. У меня это будет эксперимент, а не полноценное решение :) Вместо зпуска метод встроенного в Nape — будет запускаться мой и передаваться туда будут парметры. Obj-c вернет результат расчета.
0
Может скинуться всем денежкой, и пусть Лука сам напишет пару нативных экстеншенов?:)
0
Нифига он не напишет :) Его и так всё устраивает :)
0
У него там инструкции висят в коде, которые в виртуальной машине просто не существуют.
Все там существует. Просто Хэкс использует недокументированные опкоды флешевой ВМ.
0
Все там существует.
И где же они взяли эти недокументированные опкоды? Которые даже сам флеш плеер просто перепрыгивает
0
Давай чтоб не говорить о сферических конях в вакууме ты напишешшь эти опкоды, а я скажу есть они или нет.
И перевод из Хэкса на АС3 невозможен по этой-же причине.
А взяли их из анализа Алхимии, в блоге Николаса (который Хэкс изначально разработал) все есть.
+1
Давай чтоб не говорить о сферических конях в вакууме ты напишешшь эти опкоды
Кролик и без сферических коней, за кого ты его держишь? :D Ну и ты же должен осознавать всю тяжесть последствий, которые повлечет публикация опкодов. Мы же не хотим чтобы роскомнадзор похерил блоги? :D Раз в пустых функциях есть невидимые инструкции — это неспроста, значит что-то страшное хотели скрыть, спрятать подальше от посторонних взоров, настолько ужасное, что если человек с неподготовленной психикой увидит хотя бы малую часть, может запросто потерять рассудок, и уж точно не останется прежним. Ходят слухи, что все, кто написал свой физ.движок, продали душу — по-другому нереально. Только подготовленные и просветленные адепты могут видеть невидимое:
developers must be only like Japan Master 'Sun Say'
— TheRabbit said :D
0
Вроде как уже давно все документировано: learn.adobe.com/wiki/display/AVM2/5.+AVM2+instructions (слева там надо тыкнуть на менюшку).
0
ну не вижу там abs_jump, timestamp, coerce_o, с памятью нашел, больше не смотрел. Ну и м.б. они официально по другому называются, а не «по народному» — сложно найти т.к. кодов нет доступных для поиска; попробовал через гугль — не находит недокументированные, которые искал.
0
Да, похоже там не все выложили.
Власти Adobe скрывают!
0
Особенно учитывая отсутствие серсов Nape на AS3
Да, без доступа к исходникам сложно будет распилить поровну, но можно, например, попробовать уменьшить количество итераций солвера на шаг, и его длину вдвое, получится как бы два подшага, они, конечно, будут больше чем половина вычислений каждый, но нагрузку на каждый кадр снизят. Снижение итераций, само собой, снизит точность моделирования, но это должно компенсироваться уменьшением шага (dt).
0
Тут все не так однозначно. Да, флеш изо всех сил пытается выровнять равномерность под заданный фпс. В целом, если у тебя 1/60 секунды не хватает на просчет физики, но не так чтобы уж очень сильно не хватает, то считая физику через кадр у тебя будет небольшая неравномерность, но она будет малозаметна, потому что 60фпс это не точнюсенько равные по времени кадры. Будут довольно гладкие 60 фпс графики.
А вот если хочется раза в два под предел физику нагрузить — тогда надо просить нейпу вместо одного метода step иметь методы startUpdate(deltatime), resolveCollisions(), iterateVelocityResolving() iterateVelocityResolving() — последние два можно дергать в цикле сколько надо раз. Можно еще попросить коллижн детекшн побить на фазы.
0
Тут все не так однозначно. Да, флеш изо всех сил пытается выровнять равномерность под заданный фпс.
Если флеш, рассчитает все вычисления отведенные на текущий кадр, он же просто будет простаивать до следующей фазы рендера и следующего энтерфрейма. Допустим, есть лимит 16 мс/кадр (60 фпс), графика считается — 10 мс, физика — 10 мс, если считать физику через кадр, то в одном кадре нагрузка будет 10 мс, и оставшиеся 6 мс он просто будет простаивать, а в следующем кадре будет 20 мс и будет просадка до 50 фпс, и рассинхрон с аппаратным обновлением экрана (lumarama ниже писал про это немного), если же физику распилить пополам, то будет по 15 мс на кадр – т.е. 60 фпс с небольшим запасом.
0
Значит со следующего гонорара выделю сумму для пожертвования, и буду писать письмо «турецкому султану»… чтобы для страждующих апдейтик выкатил:)
0
Ну, это все решается просто запуском физики в отделном потоке, вроде Адоби обещает воркеры для мобильных в ближайшее время, для флеш плеера уже давно все есть.
0
Я о чем писал — когда я экспериментировал не с физикой, а просто с логикой — помню флеш хитро работал и простои он учитывал чтобы вывести на 60фпс все равно. Что-то типа: 10мс + 6мс простой, 20мс, 10мс + 2мс простой, 20мс + 2мс простой итд
То-есть флеш просто так не простаивает, он пытается нагнать 60фпс. Да неравномерность будет, вместо 16,16,16,16,16,16 будет 12,20,12,20. Но это все равно сильно лучше тормозящго 60фпс при полной физике, и плюс никогда не бывает 16 16 16 16 — оно все равно плавает.
0
То-есть флеш просто так не простаивает, он пытается нагнать 60фпс.
Возможно. Но все равно как-то смутно представляю, как это реализовано в рамках одного потока. Думаю это просто связано с менеджментом ресурсов операционной системой, которая в зависимости от интенсивности вычислений, разное количество процессорного времени выделяет процессу, отсюда и колебания фпс, так как перераспределение ресурсов не моментальное.
0
Надо будет просто попробовать разные варианты, и не париться:) Будет время, напишу тестик.
0
Значит надо будет пожертвовать парню на развитие $300-400, и попросить разбить метод step() на несколько, чтобы можно было вручную разбивать расчёт физики на части.
0
В step() можно вроде количество итераций солвера задавать. (если пробовать метод который я выше предлогал)
0
Можно, нужно экспериментить, насколько хорошо получится. Типа если ты хочешь считать step(1/30, 10), то будет ли эквивалентом два раза по step(1/60, 5). Колллижн детекшн фаза все же будет два раза работать, она жрет достаточно.
0
Можно, нужно экспериментить, насколько хорошо получится.
Получается, с чего начиналось, к тому же и пришли. Сначала слепили два физических шага в одни подлиннее, потом обратно разбили. В общем, поинт подхода в том, что на слабых девайсах нужно подобрать оптимальное количество итераций солвера, чтобы не тормозило :)

З.Ы. Ну, или отдельным потоком физику пускать или архитектурно шаг на две итерации делить.
0
Замутил тест внизу топа.
0
Т.е. все-таки будет небольшое запаздывание, хотя никто не заметит?
Интересная фишка.
0
Т.е. все-таки будет небольшое запаздывание, хотя никто не заметит?
Можно воспользоваться подходом, который используют в сетевом взаимодействии для компенсации задержки: предсказание --> моделирование --> корректировка
0
Вопрос в том будет расчет предсказания и компенсации грузить меньше чем расчет физики )
0
Ну, в контексте моделирования, предсказание — это про продолжить двигать тело со скоростью с предыдущего шага плюс накинуть гравитацию (и дампинг, если есть), а корректировка — это выставить тело в середину между предсказанной позицией и смоделированной. С таким маленьким dt все будет работать достаточно хорошо, получается что-то вроде leapfrog integration. При таком подходе и фпс задержка вообще не будет ощущаться, в любом случае будет лучше, чем просто отставание картинки на два кадра.
0
* в контексте моделирования физики
0
Интерполяция положения тел — это совсем простая операция.
0
Для физпазла оно не нужно вообще. Как ни странно для RTS игр тоже хватает без предсказаний. Не стоит и заморачиваться.
0
Если физику апдейтить 30фпс, то движение будет апдейтиться также. Это только анимация будет обновляться 60фпс, или как интерполировать?
0
ну там объекты могу немного провалится друг в друга, максимум на пол секунды, а иногда наверное и сквозь стены пролетать, все от скорости зависит.
0
Плавность то есть, но стоит ли она по сути двойного уменьшения производительности?
0
По мне, так стоит:)
0
На самом деле много видел приложений, где ставят честно 45 fps и это вроде не 30, но уже почти 60 :)
0
Сам во флешках раньше ставил 45. Во многих этого хватало.
+2
но даже когда девайс справляется с 60 фпс — при 30 фпс игра будет более экономно сажать аккумулятор мобильного устройства, конечно мало кто обратит на это внимание — но мне просто приятно думать, что моя простая 2д игра не выжимает все соки из CPU, который по сути может тянуть игры типа Infinity Blade, а использует его ресурсы «экономно» — как полагается простой 2д игре :)
0
Вообщем тут получается «плавность» vs «количество объектов», хотя на мобилках экран маленький, так что возможно что количество объектов проигрывает.
0
Можно усреднить, использовать 45 fps:)
0
а вот мне че-то показалось, что на iOS устройствах нужно или 30 или 60 — иначе движения получаются с рывками так как родная частота обновления экрана iOS 60 fps — если частота перерисовки экрана игры не кратна 60 — то получается что кадры будут неравномерно попадать в очередной решреш экрана
0
буквально недавно боролся с этими «рывками» при 30 и 60 — рывки пропадают
0
Именно AIR на iOS?
0
да, а если еще точнее старлинг — правда именно 45 фпс я не пробовал — пробовал 50
0
то есть при 50 фпс были рывки, которые пропали при 60 фпс
0
Например, в tower defence на 30 fps монстры при движении немного размываются, при 60 всё нормально.
Тоже самое с полётом снаряда.
0
В тауэр-дефенсе и физика обычна не нужна:)
0
Чтоб не размывлись — делай так Monster.x = Math.ceil( value );
таким обрзом у тебя будет пиксельня привязка и ничего не будет стоять на двух пикселях
0
Я думаю, имелось ввиду не размыливание, а дёрганность перемещения, ибо в 60 фпс плавнее будет двигаться монстр, чем при 30 фпс.
0
Это как просмотр фильма 24 и 60 кадрах, что за мода на них пошла а?)
0
В играх всегда стремились к 60 кадрам…
0
Чем больше частота кадров, тем плавнее и чётче картинка.
0
А через round не будет точнее?
0
А через round не будет точнее?
Честно говоря это без разницы. Кто как хочет :)

Конечно, чем выше FPS — тем выше плавность движения. Тут даже спорить смысла нет. Но бывают такие ситуации, когда важнее получить четкое движение (пиксельное). И оно важнее, чем просто быстрое :)
+1
Если только речь о нативной растровой графике.
Для Stage3D неактуально.
+2
Самый болтливый топик месяца, блин:)
0
Ибо самая больная тема))
0
а тем временем не имея ровных рук собрть Nape из сорцов caxe/haxe — я инжектю опокды почуток в nape swc
0
Если у тебя всё получится, добавлю тебя в титры к своей игре:))))
0
Так, настает самый интересный ход работы :) Врезал свой код и сейчас пытаюсь проанализировать кто сколько ms кушает — тем и займусь в первую очередь

+1
Тебе надо стрим на twitch.tv запилить — смотреть чтобы риал тайм :)
+1
роскомнадзор похерит весь твич.тв, когд увидят чем я занимаюсь и где лажу )
0
Согласен, туториал по флеш кунг-фу был бы интересен )
+2
Так вроде и так все ясно: print screen --> crop --> red arrow x2. ;D
+1
Тут немного инфы по будущим воркерам в AIR 3.9
А тут Луку спрашивали по планам развития нейпа
0
Давай начнем просто с установки 3.9 labs.adobe.com/downloads/air.html
+1
Собственно, заделал тест.
Каждый кадр step(1/60, 3, 3);
Через кадр step(1/30, 6, 6) + интерполяция.

При наличии большого количества тел, когда «каждый кадр» начинает тормозить, интерполяция может дать прирост 20-30% производительности (пример, было 20 фпс, стало 30). Но при этом картинка становится очень дёрганной, ибо реально каждый второй кадр в два раза тяжелее. Получается, что смысла так поступать нет. Единственный метод — разбить расчёт физики на 2 кадра, но без исходников такого не замутить.

+1
Исходники теста:
dl.dropboxusercontent.com/u/7202976/NapeTest.zip
0
Короче темный лес там :) прошерстил всю функцию step. Там нет такого, чтоб что-то одно жрало все FPS. Там 3мс отъело, тут 2мс отъело. Там 4, там 2… и набигает под 25-30мс когда дофига коробок.
0
Охринеть можно… В step методе лежит вызов другого метода:


При 100 объектах он жрет тупо 10-11мс + раз в Х секунд по непонятным причинам от 50 до 100мс как щелчок и снова оке… 10-11мс. Иду в эту функию и офигеваю. Она пустая! Стоп, думаю. Может дизассемблер опкод не знает. Лезу в хакс исходники и вижу реально — она пустая! В релизе лежит пустая функция, которая при 100 боксах отъедает 10-11мс! Epic fail!



утром попытаюсь понять нафига она там
+2
Броадфаза? Пустая? Да я тебя!!! ©
+1
Бродфаза будет экземпляром DynAABBPhase или SweepPhase
(в коде с префиксом ZPP_)

github.com/deltaluca/nape/tree/master/cx-src/zpp_nape/space
0
Все, я разобрался со своим Epic Fail.

bphase.broadphase(this, true); действительно пустой. Но вызывется не тот класс — там стоит переназначение.

Я в сорцах увидел это и подумал это косяк. Оказалось нет. Засунул сюда флаг — мы сюда не заходим
public function broadphase(space:PR(Space), discrete:Bool) { assert(false,«not implemented»); }
0
Короче, ребята. Nape может быть быстрее. Даже без Native Extensions. То, что можно скачать с сайта Luca для AS3 — тихий ужас. Haxe ломает все труды этого математического гения.
Haxe добавляет глупые инструкции в код.

К примеру:

if ( something ){
return null;
}

haxe пишет в abc файлы

if (something ){
false;
}
if ( false ) {
return null;
}

и такого очень много! Представьте, что если этот весь мусор был бы убран — движок и без всяких Native Extensions был бы поживее.
0
Дизасм показывай, чото я очень сильно сомневаюсь.
Хоть haxe и ацтой, но не до такой степени.
0
TheRabbit, а ты не задумывался, что декомпилятор может просто криво декомпилировать, так как заточен под другие компиляторы?
0
Я не декомпилятором смотрю :) Скоро вернусь. Либо пруф сделаю либо выставлю себя лохом.
0
Если программа из бинарника восстанавливает код на ЯВУ — то это декомпилятор, как бы ты его не называл.

Скоро вернусь.
Опять на кухне проблемы начались что ли? :D
0
да не, Enterprise работа. Надо делать то, за что платят. Так, что вернусь сюда только вечером.
0
Как успехи?
0
Короче бред какой-то. Haxe ну прям анал генерирует. Я не понимаю как оно вообще работает. Сначала декомпилятором прошелся. Потом непроработанные участки руками:


Скриншот иллюстрирует лишь пример процесса этой работы. Так вот — вроде и версия ABC подходящая. И опкоды по hex совпадают с теми, что существуют. Но какая-то муть выходит.

На это потребуется куда больше времени, чем я думал. Походу проще дождаться ответа Луки, как он делает сборки и в них проводить уже изменения.
0
1 Подчистить swc
2 Профит!
0
Кто-нибудь объяснит мне, что делает этот пример по воркерам из АИР 3.9?
0
github.com/jcward/AS3-Worker-Compat/blob/master/demos/WorkerCompat/WorkerCompatTest.as
0
Вроде флешка запускает свою копию фоновым потоком, в главном треде выводится анимация «часов», в фоновом просто пустые циклы гоняет, чтобы нагрузка была, и передаются значения между потоками. А вообще где-то встречались демки Starling+Nape+Workers.
0
P.S. esdot.ca/site/2012/intro-to-as3-workers-part-3-nape-physics-starling
0
Вот это уже интереснее:)
0
Правда, как-то криво она работает, в многопоточной версии ящики через пол проваливаются, раньше вроде все норм было. Наверное сборка устарела уже, что-то поменялось.
0
Странно… У меня не проваливаются. Можешь скриншот запилить?
0
Хм, сейчас тоже вроде не проваливаются, может там какие-то проблемы с синхронизацией на разных фпс'ах. Даже не знаю как там это заскринить показательно, в общем, проваливались как-будто пола нет, т.е. пирамида в своем начальном положении сползала вниз за экран.
0
А вот и ane появилось: Native Extension for the Bullet Physics github.com/mziwisky/bullet-ane
И видео Bullet ANE vs AwayPhysics: www.youtube.com/watch?v=IH4mrUagA74
Сам не смотрел, не знаю что там
0
Ощутимая разница… Думаю, NE для Nape реально порвало бы все шаблоны:)
0
Да, и судя по всему на видео дебажные сборки
0
Не уверен. Судя по всему, 3D-физика на AS3 просто жрёт туеву хучу ресурсов:)
0
На 35-ой секунде видно название иконки «Bulle...debug» youtu.be/IH4mrUagA74
Так что это точно не релизная сборка :) А разница между ними огромна.
0
То, что там написно — ерунда. Он мог и Hello World написать.
Но суть та же, что и я хочу. Некоторые методы выведены в Native
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.