Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Android NDK Development - Would like feedback

  • You cannot reply to this topic
11 replies to this topic

#1 Shanee   Members   -  Reputation: 207

Like
1Likes
Like

Posted 29 November 2013 - 01:57 PM

Hi everyone,

 

I am working on a series of Android NDK Development articles for my blog and would love your feedback. 

 

The first article can be found here: http://shaneenishry.com/android-ndk-programming-part-i/

 

If they are found useful I will consider re-creating them using the Articles tools.

 

Thanks smile.png

 



Sponsor:

#2 Grimshaw   Members   -  Reputation: 657

Like
1Likes
Like

Posted 30 November 2013 - 12:36 PM

Well, its a start! It looked good but just when it was about to get juicy, the part 1 ended ! I was just looking for more :P

 

If you keep this series going, I would love to read more on how you can achieve using native_activity on the c++ side along with a NativeActivity or NativeActivity inherited class in the Java side, and still use Android SDK stuff to integrate ad networks easily.

 

My approach is currently having the old glue code in regular Java activity and communicating with a c++ engine. I use a GLSurfaceView with it, and it all works fine, but I hear that native activities have lots of advantages over regular glue code. Can you elaborate on that? What's the pros and cons of each approach? In my case, I am interested in very little Java API's. I only use the basics and then its all made in c++. Only In-App billing, ad networks and very few other things will be useful to me.

 

Thanks!


Indie Game Developer - Daeva Theory Studios

 

Twitter - Facebook

 

Next

Terra - rise of mankind

 

Previous

SFML Game Development (Book)


#3 Shanee   Members   -  Reputation: 207

Like
1Likes
Like

Posted 30 November 2013 - 04:37 PM

Hi Grimshaw,

 

Thank you  for your feedback, it is really helpful. I am still somewhat torn between NativeActivity inherited and non NativeActivity and I am currently leaning toward the non NativeActivity.

 

I have worked all Saturday on this and finally it is here:

http://shaneenishry.com/android-ndk-programming-part-ii/

 

As for the advantages and disadvantages of the two, I am still working this out myself. The NativeActivity generally creates a thread and runs C++ from there, queueing events to the thread. I am not yet sure if there is performance gained from that although it is possible. The new article explains this, as well as why it is important to keep Java accessible (and therefore not use a fully NativeActivity implementation).

 

I am also wondering if it is worth having a new thread for complicating the use of Google APIs with the application. That is why I have decided to use the Java native calls route for now.

 

Hope you enjoy it and again, will love all feedback.

 

Thanks,

~ Shanee


Edited by Shanee, 30 November 2013 - 04:40 PM.


#4 Grimshaw   Members   -  Reputation: 657

Like
1Likes
Like

Posted 30 November 2013 - 06:19 PM

The part II still only touches the surface of  the problem, but its again pretty well written and clear. 

 

As far as my research goes, using native_activity will give you a little more control on things like opengl contexts and frame rendering frequency, but on the other side cuts access to many useful things. In terms of performance, it should be about the same, since those are two regular java activities both running native code underneath.. I don't think there is a significant difference.

 

I know you can still use Native Activity with java stuff by inheriting the java class, but if you do that, whats the point anyway of using it.. If you don't do java at all, I think you can access many things from c++ but the JNI code will look horrible.

 

I will just publish this game I am working on as-is, with normal java activity callbacks and see how it goes. I am sure many people did this too before and had no major problems :D 


Indie Game Developer - Daeva Theory Studios

 

Twitter - Facebook

 

Next

Terra - rise of mankind

 

Previous

SFML Game Development (Book)


#5 Shanee   Members   -  Reputation: 207

Like
1Likes
Like

Posted 30 November 2013 - 09:31 PM

Hi Grimsaw,

 

Thank you again for your feedback.

 

I know I still didn't get to the "meat" of things, I wanted to avoid making the article twice the size it is already.

 

I am with you on "what's the point of using it" if you already decided to inherit the Java class. As for the OpenGL Context, the next chapter I will show how you create it on C++ even without the NativeActivity by using EGL.

 

As for performance, as far as I know both approaches are limited by frame rate, therefore I suspect there shouldn't be any difference in performance using native callbacks over having a ful C++ thread. That will at least prevent having to sync the threads and unpleasant JNI code. That's my opinion anyway.


Edited by Shanee, 01 December 2013 - 12:44 AM.


#6 Grimshaw   Members   -  Reputation: 657

Like
1Likes
Like

Posted 01 December 2013 - 09:18 AM

Yeah, I think you convinced me into not changing to native activity. I don't see a single advantage to it, from my current work state. For a newcomer to android development, perhaps, but I am too far into this race already to feel the need to touch this part of the program anymore.

 

I wrote a "standard" Java activity using GLSurfaceView and then replaced some parts of the Java Code with preprocessor tokens, for customizability. Then, I run my own sort of preprocessor on this Java source and template APK, and generate on the fly a fully ready APK for the new project.. The Java part already gives me access to sensors, vibration, assets and all, then callbacks the c++ for events / rendering and updates, which is really all the c++ part needs to run well. 

 

With this approach, I was able to integrate ad networks like AirPush in no time before. That said, I don't need to touch java in ages, and when I need, the work needed to be done is really not hard because its just a standard use of the standard API, like integration of Facebook or Ads.

 

In this situation, I don't think I would benefit at all from a native_activity. Not for performance and not even for usability. One downside I find myself having was to be able to call opengl commands only from the rendering thread, which blew my plans to load textures in a parallel thread for the loading screen.. I thought native_activity and custom egl context initiialization could go around this issue, but as far as my research went, and from friend's opinions, it can't be done in android..

 

So yeah, I think I will indeed publish my games as they are now. 

 

Keep up the good work with the tutorials ^^


Indie Game Developer - Daeva Theory Studios

 

Twitter - Facebook

 

Next

Terra - rise of mankind

 

Previous

SFML Game Development (Book)


#7 Shanee   Members   -  Reputation: 207

Like
1Likes
Like

Posted 01 December 2013 - 09:21 AM

I just remembered there is an important subject I forgot to mention, the JNI_OnLoad. I will try to put it on the next article.
 

jint JNI_OnLoad( JavaVM* pJavaVM, void* pReserved )
{
    JNIEnv* pEnv;
    if ( pJavaVM->GetEnv(reinterpret_cast<void**>( &pEnv ), JNI_VERSION_1_6) != JNI_OK )
    {
        return -1;
    }
 
    // Get jclass with pJavaVM->FindClass.
    // Register methods with pJavaVM->RegisterNatives.
    ...
 
    return JNI_VERSION_1_6;
}


#8 Shanee   Members   -  Reputation: 207

Like
1Likes
Like

Posted 01 December 2013 - 09:27 AM

As for EGL and multi-threading for rendering. As far as I remember, and I will look into it again in the coming days/week: You can create the context on your C++ side and you can create multiple contexts for multi-threaded use.

 

The first half of the statement I know is 100% true. The second part I am pretty sure to be true except for Vertex Array Objects. I will try to get definitive answer by next week.

 

Thanks for the lovely feedback!



#9 Shanee   Members   -  Reputation: 207

Like
1Likes
Like

Posted 02 December 2013 - 10:35 PM

I released Part III last night. You can find it here:

http://shaneenishry.com/android-ndk-programming-part-iii/

 

I might go over and give it a small edit still but I think it will not be anything major ;)



#10 HScottH   Members   -  Reputation: 512

Like
1Likes
Like

Posted 03 December 2013 - 12:20 AM

This is a good start. Most of my feedback would relate to grammar and not technical issues.

 

I generally find the NDK to be a mostly useless addition to Android.  I love C++ and would rather use that language all the time, but in the hands of the most experienced developer, switching to C++ improves performance by less than 1/2 of a generation of devices. In other words, if you are writing something very peculiar and "cutting edge," and only want it to work on the latest devices, you may need C++.  Otherwise, if you are writing a commercial application and want wide device support, you will get far more payoff from learning how to write efficient Java than from switching to C++ (and inviting the compatibility issues that can arise as a consequence).



#11 Shanee   Members   -  Reputation: 207

Like
1Likes
Like

Posted 03 December 2013 - 06:13 AM

This is a good start. Most of my feedback would relate to grammar and not technical issues.

 

I generally find the NDK to be a mostly useless addition to Android.  I love C++ and would rather use that language all the time, but in the hands of the most experienced developer, switching to C++ improves performance by less than 1/2 of a generation of devices. In other words, if you are writing something very peculiar and "cutting edge," and only want it to work on the latest devices, you may need C++.  Otherwise, if you are writing a commercial application and want wide device support, you will get far more payoff from learning how to write efficient Java than from switching to C++ (and inviting the compatibility issues that can arise as a consequence).

 

Hi HScottH,

 

Thank you for the reply. The case is that I am not a native English speaker and still need to work on my writing so if you have any suggestions they will be warmly accepted.

 

As for using C++, the main reasons are performancecross-platform and convenience. I do agree performance for most applications will not be an issue and it will even be easier to create the whole program in Java with the tools given by Google, yet for more demanding applications - games for example, it is still highly beneficial to use C++.

 

In-fact many of the games out this day prove this is the case. An office I have been at had problems with things as simple as rendering smooth UI animations with the Java classes on devices such as the Galaxy S2, switching drawing and logic to C++ resolved the issue. It might be worth to note I am not familiar with the Java implementation which was at the time.

 

As for cross-platform: most games these days are out for iPhone before they are for Android and some are out on PC and then converted (FTL for example). This means there is an established code-base in C++ or Objective-C which could lead to a game being easily adapted for Android. In-fact, just the option to write games in C++ alone would influence people to choose it over Objective-C so their game can be played on both platforms.

 

As for convenience it is a simple matter, many programmers (myself included) are used to C++ and have some libraries they worked on. So added to the benefit of not having to write different code for different platforms (except for the application initialisation and some lifecycle events), the programmer will feel most comfortable using their "natural" language.

 

This is at least the case as I see it. I hope I made a good case for it ;)



#12 Shanee   Members   -  Reputation: 207

Like
1Likes
Like

Posted 28 December 2013 - 05:51 AM

Had a really busy month so I didn't finish the next page yet but I have started working on a slightly different take for this and was wondering if someone could give it a try and lend me some feedback.

 

I decided to try and simplify or better handle the NativeActivity state handling and events and compiled a small and simple library for use as a C++ source. It is still very much WIP but if anyone wants to give it a go I will appreciate it.

 

The library can be found here:

https://github.com/Lunarsong/NativeActivity/

 

And an example project to use it is here:

https://github.com/Lunarsong/NativeExample/

 

Currently it handles letting you know when the window is hidden (and you should stop drawing then), application is paused and key/touch data. You can also call the keyboard from Native.

 

Next I will be adding simple access to assets and then either leave it there or extend the BaseGameUtils for Google Play Services.

 

I want to keep it as slim as possible so it is just bare bones but also help exposing Android APIs to C++ with it.







PARTNERS