Публикации Проекты Форум Работа
Мобильные платформыФорумОбщее

Android: NDK vs pure java, lets flame begin

Страницы: 1 2 Следующая »
#0
23:55, 7 дек 2010

>я как раз заканчиваю порт игры с айфона на андроид
>тетрис? :D
>И что? Думаешь это делает тебя особенным?

Ну особенным или не особенным, но тешу себя что в разработки игр под андроид уж что-то понимаю.

>Что с ним случится, о каких гарантиях речь идет?
>Гарантии насчет NDK, внимательней читать нужно.

>The NDK will not benefit most applications. As a developer, you need to balance its benefits against its drawbacks; >notably, using native code does not result in an automatic performance increase, but always increases application >complexity. In general, you should only use native code if it is essential to your application, not just because you prefer to >program in C/C++.

>А про JNI, вот именно.
>Это убогий стандарт который не менялся 10 лет,
>к тому же андроид реализация - кривая и нестабильная,
>может себя некорректно вести, и при этом даже не выдаст
>тебе в лог ничего. Практически с нулевой документацией.

>И программа на аднроиде это в первую очередь activity, и API доступный с далвика.
>Давай, покажи мне серьезное взаимодействие кода на С++, с activity через JNI,
>без оверхеда и лишнего копирования.

Ой ты господи.

Ну прочитал абзац - ухты, надаже я и не знал, что программа на двух языках более сложна чем на одном.

Про некоретное поведение, прошу примеры - в лог все выдается, даже номер строки где падение произошло в нативном коде узнать можно.
А то что оно "not benefit most applications", но мы не о most application говорим. Мы о играх говорим.

Серьезное взаимодейсвие звучит то конечно страшно.
Да и без оверхеда не получится конечно.
Но что впрочем игры делать не мешает.

Программа на андроиде на чистой яве это в первую очередь ограничение в 24 мега памяти (а то и 16).
Особенно забавно на планшетах, где одна полноэкраная текстура в памяти весит 3 мега.
Но нет, 24 мегабайта достаточно всем, и это при двух гигах на борту.

И еще я с удовольсвием посмотрю как ты на java с opengl графикой без мемори ликов будешь работать.

Или как на полноэкранную картинку попиксельный фильтр накладывть, для антиальязинга например (знаешь приятно получить прирост скорости на порядок)

Ну и много подобного.

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

Вообщем использование c++ при написании игр на андроиде к сожалению необходимость.
И хорошо что это понимает гугл, иначе зачем основные изменения в 2.3 коснулись как раз расширения api доступного из нативного кода.

И вот хочу у тебя спросить, как ты думаешь почему angry bird, при их доходах и возможностях, в андроид версии cpp кода (скомпилированного!) на два порядка больше чем java кода?

Или хочешь еще какие нибудь топовые новые игры разберем?

#1
16:52, 8 дек 2010

вообще работать с етим ндк просто ужасна неудобно, чего стоит візов какой нибудь функции из джавы
50 строчек кода что б вызвать функцию :)
Управление ресурсами - звуком (хотя его под ндк без джавы поднимали) видеокамерой (в теории поднимается но у меня неодин формат так и не поддержаляс из ндк) пришлось помучаться что бы вытянуть нужную инфу джавы, что бы портировать туда готовый движек. Еще написал шеллскрипт для генерирования мейкфайлов и все стало в шоколаде, правда компилится ужасно меделнно особено луабайнд и ОДЕ :)
Еще проблема не смог с помощью цмейка разрулить компиляцию.

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

#2
16:58, 8 дек 2010

Ну какие 50 строчек? Ну откуда?

    r = gJavaVM->AttachCurrentThread(&envCurrent, 0);
    if (r == 0)
    {
      cls = envCurrent->FindClass("com.bla.bla.SoundManager");
      js = envCurrent->NewStringUTF(GetFName());
      mid = envCurrent->GetStaticMethodID(cls, "playSound", "(Ljava/lang/String;)V");
      envCurrent->CallStaticVoidMethod(cls, mid, js);
    } else
    {
      LOGI("Error: AttachCurrentThread return %i, envCurrent %i\n", r, envCurrent);
    }

И это только потому что лениво нормальный макрос написать, или вообще шаблонный класс.

#3
17:02, 8 дек 2010

ну вот уже не верно :)
Атачится не всегда надо, необходимо проверять.
Также необходимо тут еще пару ифов что б все проверить и написать сообщение об ошибке внятное, ато ваще обічна когда в с++ чтото падает далеко не всегда понятно через джаву что и где.
Да и еще DetachCurrentThread пропустил в конце :) вот о чем я и говорил, написал кусок кода и там несколько ошибок сразу.

#4
10:48, 10 дек 2010

Можно и проверять, а можно и аттачится.
Кстати с удовольсвием посмотрю, на ваш кусок кода со всеми проверками.
Деаттач я просто не докопировал.

Посмотреть где убало в нативном коде, с точностью до строки можно через "arm-eabi-addr2line.exe -C -f -e " кстати - мало ли кому пригодится.

#5
12:08, 10 дек 2010 
static void javaCallbackTest(const char *s)
{
  int status;
  JNIEnv *env;
  bool isAttached = false;

  status = g_javaVM->GetEnv((void **)&env, JNI_VERSION_1_6);
  
  if ( status < 0 )
  {
    LOG( logs::e_logic, logs::el_message, "failed to GetEnv here", "" );
    status = g_javaVM->AttachCurrentThread(&env, NULL);
    if ( status < 0 )
    {
      LOG( logs::e_logic, logs::el_message, "failed to get AttachCurrentThread", "" );
      return;
    }
    isAttached  = true;
  }

  
  jstring js  = env->NewStringUTF(s);
  jclass interfaceClass = env->GetObjectClass(g_interfaceObject);
  if (!interfaceClass) 
  {
    LOG( logs::e_logic, logs::el_message, "failed to get GetObjectClass", "" );
    if (isAttached) g_javaVM->DetachCurrentThread();
    return;
  }
  jmethodID method = env->GetStaticMethodID( interfaceClass, "callBack", "(Ljava/lang/String;)V" );
  if (!method) 
  {
    LOG( logs::e_logic, logs::el_message, "failed to get getStaticMethodID", "" );
    if (isAttached) g_javaVM->DetachCurrentThread();
    return;
  }
  env->CallStaticVoidMethod(interfaceClass, method, js);
  if (isAttached) g_javaVM->DetachCurrentThread();
  
}

вот как бы так вышло пока

#6
18:53, 15 дек 2010

В последнем NDK (r5) можно все в нативе писать, какие мысли по этому поводу?

#7
19:19, 15 дек 2010

Еще не пробовал, но судя по описанию сугубо положительные. Как и введение нативной поддержки звука из-под NDK. Если бы последний проект бы делал сразу под r5 то много гемора бы избежал был.

#8
20:22, 15 дек 2010

Young
> Про некоретное поведение, прошу примеры - в лог все выдается, даже номер строки
> где падение произошло в нативном коде узнать можно.
Как ты этого добился? У меня при падении пишет крешдамп какой-то с регистрами, а про файл/номер строки ни слова :((

#9
20:36, 15 дек 2010

Значит так. Ну если по простому.
Находим в логе строчки вида
#00  pc 0000XXXX somelib.so
#01  pc 0000XXXX somelib.so
#02  pc 0000XXXX somelib.so
#03  pc 0000XXXX otherlib.so
Это наш стек.

Далее идем в ndk-sdk и запускаем
build\prebuilt\windows\arm-eabi-4.4.0\bin\arm-eabi-addr2line.exe -C -f -e somelib.so
Там вбиваем адрес который стоит после pc
Если либа будет дебажная (брать в obj\local\armeabi\ и впроекте, или в зависимости от настроек) - то получаем имя метода и строчку.

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

#10
20:38, 15 дек 2010

О, круто, спасибо :) А то printf'ом дебажить это ужос =\

#11
0:56, 16 дек 2010

Ну все таки нативная активити работает с андроидом 2.3+ то есть планы на будущее.
Есть ли вообще смысл движок писать полностью на нативе, или от явовсого лаунчера лучше не отказываться?

>Программа на андроиде на чистой яве это в первую очередь ограничение в 24 мега памяти (а то и 16).
>Особенно забавно на планшетах, где одна полноэкраная текстура в памяти весит 3 мега.
>Но нет, 24 мегабайта достаточно всем, и это при двух гигах на борту.

NDK разве позволяет обойти это ограничение?

#12
1:05, 16 дек 2010

Max_XT
> NDK разве позволяет обойти это ограничение?
да

> Есть ли вообще смысл движок писать полностью на нативе, или от явовсого лаунчера лучше не отказываться?
конкретно сейчас думаю смысла рыпаться нету в принципе, т.к. нет рынка девайсов с 2.3. Когда их действительно станет много, можно и переписать.. но зачем?) если уже будет движок с корректной поддержкой life-cycle через JNI.
если терзает сомнительный аргумент вроде "оптимизации", то нужно проектировать библиотеку таким образом, чтобы код достаточно было поменять в сильно локализованном участке кода. я, как фанат, могу порекомендовать OpenKODE спеку:)

#13
5:33, 16 дек 2010

Посмотрел презентацию Криса Пруетта (Chris Pruett) "Google I/O 2010 - Writing real-time games for Android redux", и там он говорит что нативный рендер не намного быстрее чем через Java. Сейчас изучаю Replica Island, поразительное быстродействие даже на эмуляторе, и никакого натива (правда там ничего кроме логики и рендера и нет).

Поэтому вопрос более продвинутым, что именно писать в native коде? Реализацию физики?

Gordon, ссылки про использование OpenKODE под Android не посоветуешь?

#14
10:45, 16 дек 2010

Если вы пишите opengl игру с нуля только под платформу android и она потребляет меньше 24 мегов памяти то большого смысла заморачиватся с нативным кодом нет - можно писать и на java.

Страницы: 1 2 Следующая »
Мобильные платформыФорумОбщее

Тема в архиве.

Участники Donate!
Контакт Сообщества Каталог сайтов Категории Архив новостей
GameDev.ru — Разработка игр
©2001—2025