Pull to refresh

Comments 14

Есть ли у snow принципиальные отличия от OpenFL?
Насколько я понимаю, OpenFL это реализованное на haxe flash-api поверх низкоуровневого lime, который, точно так же, как и snow, где можно использует sdl.
То есть у lime и snow не должно быть сильных отличий…
Хотя, наверное, я не тот, кто может что-нибудь вразумительно ответить по этому поводу, потому что использовал только luxe, а snow напрямую не использовал, так же как и OpenFL и lime.
В одной из статей о том как появился snowkit Свен писал, что сперва работал над lime, а затем с нуля написал snow.

Принципиальное же отличие вы правильно указали — OpenFL — это кросс-платформенная реализация Flash-api. Свену же flash-api не нравится и он вряд ли будет добавлять его в snow или luxe.
Ну всё, ожидаем революцию в гейм-индустрии.
Вы все пропустили:) Например, прошлогодняя Papers, Please написана на Haxe (недавно кстати вышла версия для iPad). Ну и некоторые уже с флеша тоже перешли.
тссс, да что ты контору то палишь!
Спасибо, я рад, что сделанный мной перевод оказался вам полезен.
Присоединяйтесь к нашему чату (http://haxe.ru/slack-chat), мы всегда рады услышать новый опыт или помочь советом!
А как у него с производительностью? Насколько оптимальный код он генерирует в сравнении с написанием напрямую на JS(web) и cpp(ios, android)?
Как с тестированием и дебагом? Спасибо.
Совсем недавно были написаны следующие заметки jasonsturges.com/2014/12/02/openfl-haxe-performance/, jasonsturges.com/2014/12/11/openfl-haxe-performance-benchmarks/, в которых описывались результаты тестов некоторых операций при компиляции из Haxe в одну из целевых платформ.

Также стоит обратить внимание вот на эту заметку www.infognition.com/blog/2014/comparing_flash_haxe_dart_asmjs_and_cpp.html, в которой проводилось сравнение не только результатов компиляции из Haxe, но и решений написанных на «нативных» языках для платформы. В этой заметке описывается довольно специфичная задача (декодирование видео), но Haxe показал не плохие результаты.

Про тестирование — есть различные unit-testing библиотеки — munit, utest, buddy и другие. Также не сложно настроить travis-ci для тестирования ваших гитхаб репозиториев либо использовать другой CI инструмент.

В целом, если вас заинтересовала разработка на Haxe — могу посоветовать подписаться на haxe.io, на котором каждую неделю выпускается обзор самых заметных новостей сообщества.
Дизайнеру haxe.io надо руки переломать. Это же надо было постараться так испоганить сайт…
Я смотрел haxe и openfl около года назад и тогда у них производительность оставляла желать лучшего. Простые тесты на android проседали в разы по сравнению с sdl.

Судя по тому что я вижу, он неплохо развился за этот год. Посмотрю на него еще раз
Производительность я сам ещё не мерял, поэтому ручаться не буду. Но ведь код открыт и если какое-то место реально проседает, то наверняка можно оптимизировать.
Что Вы имеете ввиду под тестированием? Процесс разработки меня порадовал: пишешь код, нажимаешь Ctrl-B, через пару секунд тестируешь — почти скриптинг получается.
Визуального дебага точно есть в браузере, этого в принципе должно быть достаточно… Ещё можно попробовать консольный hxcpp-debugger или просто сделать проект из нагенерённого cpp кода в каких-нибудь Visual Studio или XCode, по идее это должно быть возможно. Просто я давно уже отвык от интерактивного дебага, будь то консольный или визуальный, и логгирования мне как-то хватает.
Насчёт оптимальности кода в сравнении с написанием напрямую:
Опять же, про JS ничего конкретного сказать не могу, сам на нём не писал, а вот cpp конечно получается медленнее, чем если всё заранее писать руками на cpp, зная наперёд предметную область и с этим знанием оптимизировать. Но haxe ведь позволяет использовать вставки на target-языке там где Вам нужно, поэтому опять же опасные места, требовательные к производительности можно и на плюсах наваять.
Стандартный пример не взлетел на моем планшете Prestigio Multi 4 Ultra Quad поэтому остаюсь на OpenFL
Sign up to leave a comment.

Articles