Discussion:
To use or not to use NDK ?
(too old to reply)
brainydexter
2010-12-23 04:56:59 UTC
Permalink
I am a game developer with a C++ background. I was considering to make
a game on android. I was going through the google IO videos and even
on the documentation it mentions to stay away from NDK unless
absolutely necessary.

I am trying to make a language choice here ?

What I am trying to find is an article or something which gives me a
little more specific details on what are the disadvantages of using
NDK ? Also, can someone please share some experiences on their use
especially with respect to making games ?

Thanks
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Tim Mensch
2010-12-23 16:42:36 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by brainydexter
What I am trying to find is an article or something which gives me a
little more specific details on what are the disadvantages of using
NDK ? Also, can someone please share some experiences on their use
especially with respect to making games ?
Android in general is based around a lot of unconventional design
decisions. These will likely sting you whether or not you use C++.

Specific things to worry about in the NDK:

* If you're not familiar with JNI, it can take some time to get things
right, but it's not that hard to learn. So read up on exactly how things
work!

* OpenGL operations can only happen from the OpenGL thread; you can't do
OpenGL calls from the main thread.

* Your shared object (.so, where the native code goes) can't go on to
the SD card, even in 2.2+, so if it gets big, your app will take up
precious internal RAM, and people will complain.

* If you want to use STL, you need to statically link to the C++
library. That makes your code bigger. Avoid std::string and streams if
at all possible, since they seem to bring in hundreds of k of overhead.

Personally, I wouldn't even consider using Java for a game, because I
want my game to also run on iPhone and other platforms. Garbage
collection on Java (pre-2.3) is also really annoying.

I've built up a cross-platform library that right now allows me to run
on Android and on Windows, so I don't need to suffer through a terribly
slow edit-build-run cycle as I develop my game. Adding an iPhone backend
shouldn't take long, and then my game can be posted what's still the
largest marketplace (for the time being).

The tools for Java development are far more robust, and much cleaner
(except for that disaster called Eclipse, which sucks no matter what you
do to it). You want to profile? In NDK code you're out of luck (PLEASE
someone correct me if I'm wrong!), but there's a Java profiler.

Similarly there's memory allocation tracking in Java -- which you'll
need to use if you want to write a game that has any real-time
components (like animation), or it will glitch all over the place.

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNE3v7AAoJENSbqLBCyKKstzYH/RqkW2nr+SIBUeL0it0XeXMM
P+JbypnIEOKmM/T7kZjdwmmvB6tGGBpqclfQQXG0aW2kC6epeptgR2iLPRCHPYFO
whSDy3LtZ24VddJhvM7mmji30veHRHWLXvzYwPtIA4wSwcbhOLLlJuup+Rr3RsaO
/P8CkjQ7TEhisZhLh3iKRgU/UxrGnn2J+wdLlTmLFjN8NKZOkpApnVR/Dc+ax00v
+wno3a3gDWytOjLmjZ2lSHch0lO+XJg8h1KYpsoCo71t+AvS1KvWAWBtdXtxXzKa
xgPVYwXTUCVxVXUQsPbrIdqHjFCw7isdA8vkn7UNZlKgMvlv2lNsIT7wv87bDMM=
=MIbu
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Dianne Hackborn
2010-12-23 18:13:25 UTC
Permalink
Post by Tim Mensch
* OpenGL operations can only happen from the OpenGL thread; you can't do
OpenGL calls from the main thread.
If you initialize your GL context on the main thread, that is where you
would do the operations. Generally for games, though, you probably want to
do them on a separate thread so you can do them as part of the dedicated
game engine. (The current native activity samples for 2.3 use client-side
glue code that puts the engine on a separate thread from the main one, but
you don't need to follow this.)
Post by Tim Mensch
* Your shared object (.so, where the native code goes) can't go on to
the SD card, even in 2.2+, so if it gets big, your app will take up
precious internal RAM, and people will complain.
Starting with 2.3 native shared libraries are also put in the SD card.
--
Dianne Hackborn
Android framework engineer
***@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Dianne Hackborn
2010-12-23 18:22:16 UTC
Permalink
Oh it's also worth mention Replica Island, whose full source is freely
available to look at and use. This is written in Java:

http://code.google.com/p/replicaisland/

I think the decision about whether to use native code or Java code also
depends a lot on the type of game. For example if you are doing a casual
game or one that isn't looking to do hard-core graphics (and not planning on
writing one engine to run across a variety of platforms), Java may be a
better choice due to the *much* easier development environment. You'll
spend less time writing it, allowing you to produce more games, and
hopefully make more money. :)

Another thing to consider is a hybrid approach -- writing in Java, but
dropping to native code for performance critical parts. Well at least until
2.3 (and for many platform features still after 2.3) you can't avoid having
some Java code. But you'll need to decide if the Java code is just a little
generic glue to interact with the platform, or more extensive containing
parts of the game flow and UI.

And Eclipse is not that bad. :) Whether or not you like it is mostly
personal preference; if it doesn't work for you, there are other Java IDEs
that people use.
Post by Dianne Hackborn
Post by Tim Mensch
* OpenGL operations can only happen from the OpenGL thread; you can't do
OpenGL calls from the main thread.
If you initialize your GL context on the main thread, that is where you
would do the operations. Generally for games, though, you probably want to
do them on a separate thread so you can do them as part of the dedicated
game engine. (The current native activity samples for 2.3 use client-side
glue code that puts the engine on a separate thread from the main one, but
you don't need to follow this.)
Post by Tim Mensch
* Your shared object (.so, where the native code goes) can't go on to
the SD card, even in 2.2+, so if it gets big, your app will take up
precious internal RAM, and people will complain.
Starting with 2.3 native shared libraries are also put in the SD card.
--
Dianne Hackborn
Android framework engineer
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
Dianne Hackborn
Android framework engineer
***@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Tim Mensch
2010-12-23 18:45:05 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Dianne Hackborn
And Eclipse is not that bad. :) Whether or not you like it is mostly
personal preference; if it doesn't work for you, there are other Java
IDEs that people use.
The Eclipse workspace, which contains important project settings, can't
be shared between computers, and is an opaque binary format.

Project files can only contain absolute paths, which prevent you from
sharing them between computers with different file systems -- between
Mac and Windows, for instance. So anything but a trivial project
configuration needs to be entered by hand on the other system.

Sometimes things get into a bad state and I have to exit and reload
Eclipse. Eclipse takes over a minute to load on my system, which is a
pain by itself.

Eclipse can end up with errors in the "problems" pane that prevent
builds from happening until you "delete" the error. When I say "build" I
mean build.

The logcat pane in Eclipse will sometimes stop working in one of 3-4
different creative and annoying ways. It breaks on Mac in at least one
way that it doesn't seem to break on Windows.

The project environment can change itself (we've observed this
happening) in such a way as to break the build. Sometimes it will work
until you exit and reload the project, for example. This happens because
I have a "library" project and a game project; getting everything to
build as one combined project to begin with was way harder than it
should have been, and the configuration I came up with is fragile.

Eclipse periodically forgets what the current project is, so that
Control-B doesn't work. Even when it knows the project, if you make the
mistake of using the "current project" variable in a script it will
sometimes error out with that variable not set. This is a known bug that
I found when I Googled for fixes.

The C++ integration have any obvious way to set paths to include files,
and so it shows every single C++ file as having tons of errors. I
searched for a bit on this one before giving up.

Maybe I'm doing everything wrong, but I've talked with others who have
seen all of the above problems, so it's not just me. If there are
workarounds for the above issues, they're also not obvious.

So even if there ARE better ways to deal with Eclipse, I stand by my
original statement, because it shouldn't be this hard.

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNE5ixAAoJENSbqLBCyKKsu3AIALAu/fJOxZyuNkEAWc2yx17j
f3dwEC6Qzc+XAD8Y0gtId5Z3l3LMJUPtt0KR3jPHVZYY/lBLViG3EJKZR3hSk485
z3hcIhPMddN4XGsqELgu4hHR3MD+743cifXqayUI/zgzi40QwMM+f3TJQ+7QETHo
lpWO4UDKrDPbPr8E9TdUGhjiVtzGKVRJaVl/PEFHSHReLAP0TYkwY0FBVnXw15kq
iqCGJhHiNIeCOj5ckwPGK+8+ovawmyGMAJ7MrznbkDHXIcB6DEp4i7Cci0YsFRog
kXdpBxc49qDkkqJCTVE/F/jHMZgMTSFbn6KcIimf1VWi3+o7m7+jLfJ8QPPK/aA=
=ucRt
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Mike Edenfield
2010-12-23 19:29:53 UTC
Permalink
Post by Tim Mensch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Dianne Hackborn
And Eclipse is not that bad. :) Whether or not you like it is mostly
personal preference; if it doesn't work for you, there are other Java
IDEs that people use.
The C++ integration have any obvious way to set paths to include files,
and so it shows every single C++ file as having tons of errors. I
searched for a bit on this one before giving up.
This one, at least, has an easy fix:

Project Settings -> C/C++ General -> Paths and Symbols -> Includes
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Tim Mensch
2010-12-23 19:54:58 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Mike Edenfield
Post by Tim Mensch
The C++ integration have any obvious way to set paths to include files,
and so it shows every single C++ file as having tons of errors. I
searched for a bit on this one before giving up.
Project Settings -> C/C++ General -> Paths and Symbols -> Includes
Ahh, wouldn't that be nice.

No such option for me. My project only has "Java" options. And I only
see project "Properties".

I did look in the obvious places. Under Window/Preferences I get a C/C++
tab, but no "General", and none of the options there have anything to do
with the tagging (or "indexing") search path.

The closest I can see are "Environment" and "Build Variables"; maybe if
I put CFLAGS in one or the other place, it will notice a -I option? Or
is there some magic to enable C/C++ in an existing Java project?

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNE6kSAAoJENSbqLBCyKKs7ZsIAMrbMtIjtQMcj7pBrbUxXUQi
gkIIieR+Gnqbu2esaTOg6oH6dDsCGoYydSON5UIFw5s+iJuPFkcQDQJTc+1kkbgy
NKfDeCsX0dUhVhalVyl+K/kGuHtnpuG8isTfgbWf7J0YRJY6ylHACpHPnCH/Eovj
h/9OkkpRIxToNqiBF6TD5TVJQ7ZoSFJcuJb7jSCXJ9YsDvhLz9cVIqOTDlCF8zkM
fXnnPVaoJ3MKn8ZdsGWtpBYQdIAxPlKgjMdnv0Uiy8mBSqSSME3fkkJAGn+2/RhV
pU1tgOk4C2vKkYLCwKeVirHUBHLJR14plg4wVsMZiO6XDuUt3HsEE4Vc+xrMICQ=
=m7/d
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Mike Edenfield
2010-12-24 19:59:27 UTC
Permalink
Post by Tim Mensch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Tim Mensch
The C++ integration have any obvious way to set paths to include files,
and so it shows every single C++ file as having tons of errors. I
searched for a bit on this one before giving up.
Project Settings -> C/C++ General -> Paths and Symbols -> Includes
Ahh, wouldn't that be nice.
No such option for me. My project only has "Java" options. And I only
see project "Properties".
Ah, that explains it. You're not using the correct Eclipse
plug-ins - you need to use the CDT plug-in if you expect
Eclipse to treat your C/C++ code as C/C++.

You can (in theory) make that happen manually by converting
your Java project to a C++ project. Eclipse will keep the
Java builders intact, you just need to set up your C++ build
process. Google will turn up a few guides on how to do
this, though many of them are for older NDK versions and
need tweaking.

A far easier option is to install the Sequoyah v1.1[1]
plug-in, which handles about 90% of the the NDK build
process, gdbserver debug setup, and CDT plug-in setup for
you. You mostly have to tell Eclipse to "Add Native
Support", then set up things specific to your environment[2].

The setup guide is also a bit dated -- the latest Sequoyah
does work with -r5, you'll just need to tweak the path
names. And you should debug on a device running v2.3,
regardles of what your target API level is. Pre-2.3, there
were bugs that prevented gdb from properly debugging
multiple threads.

[1] http://www.eclipse.org/sequoyah/downloads/
[2]
http://www.eclipse.org/sequoyah/documentation/native_debug.php
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Doug Schaefer
2010-12-25 16:18:16 UTC
Permalink
There is no doubting that we need better documentation on how to use
Eclipse for Android development. And some of this is just plain
Eclipse usage, which suffers the same problem everywhere.

But it is open source and community driven, which means it won't
happen unless someone volunteers to make it happen. Now, the term
"someone" includes employees of big corporations who have a vested
interest in growing their development communities :).

D.
Post by Tim Mensch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Tim Mensch
The C++ integration have any obvious way to set paths to include files,
and so it shows every single C++ file as having tons of errors. I
searched for a bit on this one before giving up.
Project Settings ->  C/C++ General ->  Paths and Symbols ->  Includes
Ahh, wouldn't that be nice.
No such option for me. My project only has "Java" options. And I only
see project "Properties".
Ah, that explains it.  You're not using the correct Eclipse plug-ins - you
need to use the CDT plug-in if you expect Eclipse to treat your C/C++ code
as C/C++.
You can (in theory) make that happen manually by converting your Java
project to a C++ project.  Eclipse will keep the Java builders intact, you
just need to set up your C++ build process.  Google will turn up a few
guides on how to do this, though many of them are for older NDK versions and
need tweaking.
A far easier option is to install the Sequoyah v1.1[1] plug-in, which
handles about 90% of the the NDK build process, gdbserver debug setup, and
CDT plug-in setup for you.  You mostly have to tell Eclipse to "Add Native
Support", then set up things specific to your environment[2].
The setup guide is also a bit dated -- the latest Sequoyah does work with
-r5, you'll just need to tweak the path names.  And you should debug on a
device running v2.3, regardles of what your target API level is.  Pre-2.3,
there were bugs that prevented gdb from properly debugging multiple threads.
[1] http://www.eclipse.org/sequoyah/downloads/
[2] http://www.eclipse.org/sequoyah/documentation/native_debug.php
--
You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Robert Green
2010-12-25 20:11:19 UTC
Permalink
I use Eclipse with CDT to do all my Android native development. It's
gotten pretty good as of version 7.
Post by Doug Schaefer
There is no doubting that we need better documentation on how to use
Eclipse for Android development. And some of this is just plain
Eclipse usage, which suffers the same problem everywhere.
But it is open source and community driven, which means it won't
happen unless someone volunteers to make it happen. Now, the term
"someone" includes employees of big corporations who have a vested
interest in growing their development communities :).
D.
Post by Tim Mensch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Tim Mensch
The C++ integration have any obvious way to set paths to include files,
and so it shows every single C++ file as having tons of errors. I
searched for a bit on this one before giving up.
Project Settings ->  C/C++ General ->  Paths and Symbols ->  Includes
Ahh, wouldn't that be nice.
No such option for me. My project only has "Java" options. And I only
see project "Properties".
Ah, that explains it.  You're not using the correct Eclipse plug-ins - you
need to use the CDT plug-in if you expect Eclipse to treat your C/C++ code
as C/C++.
You can (in theory) make that happen manually by converting your Java
project to a C++ project.  Eclipse will keep the Java builders intact, you
just need to set up your C++ build process.  Google will turn up a few
guides on how to do this, though many of them are for older NDK versions and
need tweaking.
A far easier option is to install the Sequoyah v1.1[1] plug-in, which
handles about 90% of the the NDK build process, gdbserver debug setup, and
CDT plug-in setup for you.  You mostly have to tell Eclipse to "Add Native
Support", then set up things specific to your environment[2].
The setup guide is also a bit dated -- the latest Sequoyah does work with
-r5, you'll just need to tweak the path names.  And you should debug on a
device running v2.3, regardles of what your target API level is.  Pre-2.3,
there were bugs that prevented gdb from properly debugging multiple threads.
[1]http://www.eclipse.org/sequoyah/downloads/
[2]http://www.eclipse.org/sequoyah/documentation/native_debug.php
--
You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Mario Zechner
2011-01-03 15:57:34 UTC
Permalink
I know this thread is old by i wanted to add my 0.2€.

I was initially considering going full native. However, the poor
debugging support in early NDK versions and the overall
"cumbersomeness" kept me from doing so. Instead i wrote a cross-
platform Java library that allows me to test/run/debug my apps on
Windows/Linux/Mac/Android and even deploy stuff as an applet if needed
(though i somewhat despise applets). For performance critical code i
wrote some JNI bridges to things like Box2D, libmpg123, tremor, cpu
skinning and so on. Not providing a direct link, search for libgdx.
I'd even go so far and postulate that with a nice hybrid approach
(90% Java, 10% native) you can write any game you like, not just
causal games. The biggest obstacle you'll hit is OpenGL ES or rather
the GPUs and their drivers. That's your enemy most of the time. Of
course you lose compatibility with other platforms like IOs. This is
not a problem for me as i'm not willing to shell out a couple of k€/y
just to be allowed to develop for a platform.

I'm of course a little biased. While i spent a lot of my coding career
in C/C++ and still love it, i eventually switched to Java a few years
ago (among other things) and didn't regret it so far. Productivity
increases a lot and at least on the desktop the performance doesn't
suffer when you know what you do. When compared to binaries produced
by gcc that is. Intel's compiler will beat anything under the Sun.

Also, Visual Studio is a stinking pile of dung. Just kidding :) (or am
i?)
I use Eclipse with CDT to do all my Android native development.  It's
gotten pretty good as of version 7.
Post by Doug Schaefer
There is no doubting that we need better documentation on how to use
Eclipse for Android development. And some of this is just plain
Eclipse usage, which suffers the same problem everywhere.
But it is open source and community driven, which means it won't
happen unless someone volunteers to make it happen. Now, the term
"someone" includes employees of big corporations who have a vested
interest in growing their development communities :).
D.
Post by Tim Mensch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Tim Mensch
The C++ integration have any obvious way to set paths to include files,
and so it shows every single C++ file as having tons of errors. I
searched for a bit on this one before giving up.
Project Settings ->  C/C++ General ->  Paths and Symbols ->  Includes
Ahh, wouldn't that be nice.
No such option for me. My project only has "Java" options. And I only
see project "Properties".
Ah, that explains it.  You're not using the correct Eclipse plug-ins - you
need to use the CDT plug-in if you expect Eclipse to treat your C/C++ code
as C/C++.
You can (in theory) make that happen manually by converting your Java
project to a C++ project.  Eclipse will keep the Java builders intact, you
just need to set up your C++ build process.  Google will turn up a few
guides on how to do this, though many of them are for older NDK versions and
need tweaking.
A far easier option is to install the Sequoyah v1.1[1] plug-in, which
handles about 90% of the the NDK build process, gdbserver debug setup, and
CDT plug-in setup for you.  You mostly have to tell Eclipse to "Add Native
Support", then set up things specific to your environment[2].
The setup guide is also a bit dated -- the latest Sequoyah does work with
-r5, you'll just need to tweak the path names.  And you should debug on a
device running v2.3, regardles of what your target API level is.  Pre-2.3,
there were bugs that prevented gdb from properly debugging multiple threads.
[1]http://www.eclipse.org/sequoyah/downloads/
[2]http://www.eclipse.org/sequoyah/documentation/native_debug.php
--
You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Doug Schaefer
2011-01-03 17:29:17 UTC
Permalink
Great points. The beauty of it all is that you decide how much Java
you want to do to meet your needs. You can go full Java or full native
and it's all good.

BTW, I'm going to start looking at the CDT debug integration. My day
job is knee deep into that stuff these days so I should be able to
leverage what I learn there and apply it to Android. We'll see where I
end up.

Cheers,
Doug.
Post by Mario Zechner
I know this thread is old by i wanted to add my 0.2€.
I was initially considering going full native. However, the poor
debugging support in early NDK versions and the overall
"cumbersomeness" kept me from doing so. Instead i wrote a cross-
platform Java library that allows me to test/run/debug my apps on
Windows/Linux/Mac/Android and even deploy stuff as an applet if needed
(though i somewhat despise applets). For performance critical code i
wrote some JNI bridges to things like Box2D, libmpg123, tremor, cpu
skinning and so on. Not providing a direct link, search for libgdx.
I'd even go so far and postulate that with a nice hybrid approach
(90% Java, 10% native) you can write any game you like, not just
causal games. The biggest obstacle you'll hit is OpenGL ES or rather
the GPUs and their drivers. That's your enemy most of the time. Of
course you lose compatibility with other platforms like IOs. This is
not a problem for me as i'm not willing to shell out a couple of k€/y
just to be allowed to develop for a platform.
I'm of course a little biased. While i spent a lot of my coding career
in C/C++ and still love it, i eventually switched to Java a few years
ago (among other things) and didn't regret it so far. Productivity
increases a lot and at least on the desktop the performance doesn't
suffer when you know what you do. When compared to binaries produced
by gcc that is. Intel's compiler will beat anything under the Sun.
Also, Visual Studio is a stinking pile of dung. Just kidding :) (or am
i?)
I use Eclipse with CDT to do all my Android native development.  It's
gotten pretty good as of version 7.
Post by Doug Schaefer
There is no doubting that we need better documentation on how to use
Eclipse for Android development. And some of this is just plain
Eclipse usage, which suffers the same problem everywhere.
But it is open source and community driven, which means it won't
happen unless someone volunteers to make it happen. Now, the term
"someone" includes employees of big corporations who have a vested
interest in growing their development communities :).
D.
Post by Tim Mensch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Tim Mensch
The C++ integration have any obvious way to set paths to include files,
and so it shows every single C++ file as having tons of errors. I
searched for a bit on this one before giving up.
Project Settings ->  C/C++ General ->  Paths and Symbols ->  Includes
Ahh, wouldn't that be nice.
No such option for me. My project only has "Java" options. And I only
see project "Properties".
Ah, that explains it.  You're not using the correct Eclipse plug-ins - you
need to use the CDT plug-in if you expect Eclipse to treat your C/C++ code
as C/C++.
You can (in theory) make that happen manually by converting your Java
project to a C++ project.  Eclipse will keep the Java builders intact, you
just need to set up your C++ build process.  Google will turn up a few
guides on how to do this, though many of them are for older NDK versions and
need tweaking.
A far easier option is to install the Sequoyah v1.1[1] plug-in, which
handles about 90% of the the NDK build process, gdbserver debug setup, and
CDT plug-in setup for you.  You mostly have to tell Eclipse to "Add Native
Support", then set up things specific to your environment[2].
The setup guide is also a bit dated -- the latest Sequoyah does work with
-r5, you'll just need to tweak the path names.  And you should debug on a
device running v2.3, regardles of what your target API level is.  Pre-2.3,
there were bugs that prevented gdb from properly debugging multiple threads.
[1]http://www.eclipse.org/sequoyah/downloads/
[2]http://www.eclipse.org/sequoyah/documentation/native_debug.php
--
You received this message because you are subscribed to the Google Groups
"android-ndk" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Robert Green
2010-12-23 19:57:21 UTC
Permalink
I developed 5 games for Android in Java. One with a lot of C to
improve animation and collisions performance.

I'm not doing that again. Everything I've done since has been
developed in cross platform C++.

Pros:
1) Development time is lower. I test in windows most runs.
2) It runs faster on every device. I don't care how people justify
Java's improvements with JIT, this is a matter of fact.
3) Some things are easier to do in C, such as operator overloading
for vector math and arrays on the stack
4) If you're careful about it you can have an app that builds for
Windows, OSX, Linux, Android and iOS all in one codebase.
5) You can implement your own memory manager so you can preallocate a
block amount and know for sure you won't run out on the device.

Cons:
1) Debugging is MF when something crashes on the release build but
not on the debug build
2) To be cross platform you need to provide all your own decoders and
platform abstraction
3) Things can be touchy in general.
4) Personally I'd avoid STL and supply a few lightweight data
structures of my own, but the con here is that you don't get nice
collections and such (I never used them for games anyway...)
5) You will need a cross platform UI library.
6) You will need a cross platform mixer for sound / etc
7) You will need a way to do font rasterizing

So yeah it looks like there's a lot going on here but I'm all native
and compatible back to Android 1.5. As for .so sizes:
Latest project SO is 674KB and includes:
All game code for a fully featured working game
Lua
Box2D
OGG/JPG/PNG/GIF/TTF decoders
UI Library
Sound Mixer

So that's on par with what a .dex would be for a good sized game
anyway.

If anyone is interested in what I've done, I've actually made all of
this into a middleware product that I will be making commercially
available next month. It'll be affordable and will save you months of
work :)
Post by Mike Edenfield
Post by Tim Mensch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
And Eclipse is not that bad. :)  Whether or not you like it is mostly
personal preference; if it doesn't work for you, there are other Java
IDEs that people use.
The C++ integration have any obvious way to set paths to include files,
and so it shows every single C++ file as having tons of errors. I
searched for a bit on this one before giving up.
Project Settings -> C/C++ General -> Paths and Symbols -> Includes
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Robert Mitchell
2010-12-23 21:45:16 UTC
Permalink
Eclipse for most of us is a reliable effective IDE.

For Android development with the NDK I recommend the Sequoyah plugin: http://download.eclipse.org/sequoyah/updates/1.1.

With the Sequoyah plugin only C and C++ files are processed by the Gnu compiler, the include paths are right, and there are no errors other than my mistakes.

I never even considered sharing projects from a central Eclipse; it is far too efficient to use a central repository - which is designed for sharing.  I have been using SVN, but the tide is moving to GIT.  And I go with the tide...  Both have good plugins for Eclipse.

Don't blame Eclipse for logcat - that is a direct line to your emulator, subject to all the problems communicating with that emulator.

- Robert Mitchell - ***@yahoo.com 

--- On Thu, 12/23/10, Tim Mensch <***@gmail.com> wrote:

From: Tim Mensch <***@gmail.com>
Subject: Re: To use or not to use NDK ?
To: android-***@googlegroups.com
Date: Thursday, December 23, 2010, 10:45 AM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
And Eclipse is not that bad. :)  Whether or not you like it is mostly
personal preference; if it doesn't work for you, there are other Java
IDEs that people use.
The Eclipse workspace, which contains important project settings, can't
be shared between computers, and is an opaque binary format.

Project files can only contain absolute paths, which prevent you from
sharing them between computers with different file systems -- between
Mac and Windows, for instance. So anything but a trivial project
configuration needs to be entered by hand on the other system.

Sometimes things get into a bad state and I have to exit and reload
Eclipse. Eclipse takes over a minute to load on my system, which is a
pain by itself.

Eclipse can end up with errors in the "problems" pane that prevent
builds from happening until you "delete" the error. When I say "build" I
mean build.

The logcat pane in Eclipse will sometimes stop working in one of 3-4
different creative and annoying ways. It breaks on Mac in at least one
way that it doesn't seem to break on Windows.

The project environment can change itself (we've observed this
happening) in such a way as to break the build. Sometimes it will work
until you exit and reload the project, for example. This happens because
I have a "library" project and a game project; getting everything to
build as one combined project to begin with was way harder than it
should have been, and the configuration I came up with is fragile.

Eclipse periodically forgets what the current project is, so that
Control-B doesn't work. Even when it knows the project, if you make the
mistake of using the "current project" variable in a script it will
sometimes error out with that variable not set. This is a known bug that
I found when I Googled for fixes.

The C++ integration have any obvious way to set paths to include files,
and so it shows every single C++ file as having tons of errors. I
searched for a bit on this one before giving up.

Maybe I'm doing everything wrong, but I've talked with others who have
seen all of the above problems, so it's not just me. If there are
workarounds for the above issues, they're also not obvious.

So even if there ARE better ways to deal with Eclipse, I stand by my
original statement, because it shouldn't be this hard.

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNE5ixAAoJENSbqLBCyKKsu3AIALAu/fJOxZyuNkEAWc2yx17j
f3dwEC6Qzc+XAD8Y0gtId5Z3l3LMJUPtt0KR3jPHVZYY/lBLViG3EJKZR3hSk485
z3hcIhPMddN4XGsqELgu4hHR3MD+743cifXqayUI/zgzi40QwMM+f3TJQ+7QETHo
lpWO4UDKrDPbPr8E9TdUGhjiVtzGKVRJaVl/PEFHSHReLAP0TYkwY0FBVnXw15kq
iqCGJhHiNIeCOj5ckwPGK+8+ovawmyGMAJ7MrznbkDHXIcB6DEp4i7Cci0YsFRog
kXdpBxc49qDkkqJCTVE/F/jHMZgMTSFbn6KcIimf1VWi3+o7m7+jLfJ8QPPK/aA=
=ucRt
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Tim Mensch
2010-12-23 22:02:03 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Robert Mitchell
Eclipse for most of us is a reliable effective IDE.
I guess none of the people I've talked to are part of "most of us." I've
even spoken with professional Java developers who hate Eclipse.
Post by Robert Mitchell
http://download.eclipse.org/sequoyah/updates/1.1.
I haven't tried Sequoyah yet, but I've burnt too much time on this;
maybe after I ship my game. I have a system that works (that involves
NOT using Eclipse as much as possible).
Post by Robert Mitchell
I never even considered sharing projects from a central Eclipse; it is
far too efficient to use a central repository - which is designed for
sharing. I have been using SVN, but the tide is moving to GIT. And I
go with the tide... Both have good plugins for Eclipse.
Not sure what you thought I meant. The PROBLEM comes when you share your
.project file using revision control -- I've used Git, Mercurial and
Bazaar.

The problem is when .project is copied to ("checked out on" in SVN
terminology) another computer with a different path structure.
Post by Robert Mitchell
Don't blame Eclipse for logcat - that is a direct line to your emulator,
subject to all the problems communicating with that emulator.
When I use adb logcat, it works; when it breaks in Eclipse that's how I
get to the log info. Another developer I talked with thought that the
Eclipse plug-in simply never worked, and he always used adb logcat
directly. Some of the problems are obvious display/data handling
problems -- too much logging causes the display to be screwed up, for
example, and the only way to fix it is to clear the logging, which sucks
if you have something in the output you need to search for.

At best the problems are in the Eclipse plug-in from Google, but from my
POV it's just another broken thing about Eclipse.

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNE8bbAAoJENSbqLBCyKKsK/EH/jlNgzc2F6vLycIba/dND3f0
72JPLY5CiUMBEBy5HEikfK1xG1fCpA9Kz443q3K+85ElHHaJKiO4K4jvN/LIFCqb
7zl4W87wYXHHflQn+uI6PSDnjyn4uScGsZLVWJ348j/dCE6th+ImFI0eIO5fag3L
pLsLfzQxc+chYCtTLGr3m+71rQKR2ippJEBChkN4du3dVZ/4YGfljpPJBnQkQ7FX
lArCId/3kCySgrUvT3AlrQOOsHr0TVefdujUoPK1n5Bunq6SdomAPk69FFHwPSdU
LNIqMfy/QAEPdYpa2j+2KHzio125SjjK9VkPfNMpbb8YueTSK58IkkmWAb5sKGs=
=EEwc
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Doug Schaefer
2010-12-23 22:53:37 UTC
Permalink
Post by Tim Mensch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Robert Mitchell
Eclipse for most of us is a reliable effective IDE.
I guess none of the people I've talked to are part of "most of us." I've
even spoken with professional Java developers who hate Eclipse.
Given there are 3 million Eclipse users, the bulk of them doing Java,
Eclipse lovers have many friends. Those that like it love it, those
that don't don't. Being a professional Eclipse developer spending
almost all my time in Java, and having been a former Visual Studio
user, I'm pretty happy with where things have got with Eclipse. Once
you start using QuickFix, you never go back.
Post by Tim Mensch
Post by Robert Mitchell
http://download.eclipse.org/sequoyah/updates/1.1.
I haven't tried Sequoyah yet, but I've burnt too much time on this;
maybe after I ship my game. I have a system that works (that involves
NOT using Eclipse as much as possible).
Your loss I suppose. I'm personally working on CDT support for Android
NDK. There's a lot more to do, but we'll get there. And I know I'll
use it for my Android development.
Post by Tim Mensch
Post by Robert Mitchell
I never even considered sharing projects from a central Eclipse; it is
far too efficient to use a central repository - which is designed for
sharing.  I have been using SVN, but the tide is moving to GIT.  And I
go with the tide...  Both have good plugins for Eclipse.
Not sure what you thought I meant. The PROBLEM comes when you share your
.project file using revision control -- I've used Git, Mercurial and
Bazaar.
The problem is when .project is copied to ("checked out on" in SVN
terminology) another computer with a different path structure.
I don't see any paths in an Android .project. If there was, it should
be fixed. Good news is that we know who the IDE developers are.

That said, of the 3 million Eclipse users I mentioned, the bulk of
them are also using source control without any problems.

<--- snip the rest --->

No reason to have flame wars over IDEs. Use what you need to use and
try not to spread FUD when you're not clear on all the facts. The good
news, if you have real issues, the Eclipse community is wide spread
and we'd be happy to help fix it.

Doug.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Tim Mensch
2010-12-23 23:17:07 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Doug Schaefer
I don't see any paths in an Android .project. If there was, it should
be fixed. Good news is that we know who the IDE developers are.
Try including a .jar file or any source from outside your project tree.
Like from a common library folder. It won't accept anything but an
absolute path, when the project tree would make a relative path work
just fine.

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNE9hzAAoJENSbqLBCyKKswP8H/31gt13MkTi8ocMJtJARaoh9
4hrTjPEaknMzgFt1NbJIbTKtND56RUn4EyNev6hBm9EWfaJkrN61DFAMLQmzARal
FGOn7a4WZVMTB7ezfsTvA5NVd6Odt671/TAlMuFNNRFqBog0fE7ySIeil8HQWHeE
L2XJTLlVfHETm4XcNxkjBl/dOCHcaxizUJ6gJxe3OqtAfiJTH7mOGEV8fF4IK1fT
ZCbeHf/n7iX/nZdAJd4Q8ocOZ8NJ0ildVtwoBmtvJd8p7enHEu2DLoVYSuGm+hct
awTngajnk36dxmm0/t66EFTjFJcY5H1W5axxpbg7UVJOYK9Wrfpxx6zEQ5mJzaY=
=wMmS
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
mingw android
2010-12-24 01:35:22 UTC
Permalink
I've used most of the big IDEs going and hacked a tiny bit on Eclipse. It's
got a lot got a lot going for it IMHO, but the decision to write it in Java
was a guarantee that it'd be slower than the competition.

I've recently been playing with Qt Creator and, from initial impressions,
I'm very impressed. Embedded and in particular, android support is lacking,
but it's open source and I'm going to see if it can be re-purposed to my
needs. It's also cross platform and I'd be very interested in collaborating
on an android focused fork with any interested coders. Give it a look, you
might be pleasently surprised.

Cheers,

mingw.android
Post by Tim Mensch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Doug Schaefer
I don't see any paths in an Android .project. If there was, it should
be fixed. Good news is that we know who the IDE developers are.
Try including a .jar file or any source from outside your project tree.
Like from a common library folder. It won't accept anything but an
absolute path, when the project tree would make a relative path work
just fine.
Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNE9hzAAoJENSbqLBCyKKswP8H/31gt13MkTi8ocMJtJARaoh9
4hrTjPEaknMzgFt1NbJIbTKtND56RUn4EyNev6hBm9EWfaJkrN61DFAMLQmzARal
FGOn7a4WZVMTB7ezfsTvA5NVd6Odt671/TAlMuFNNRFqBog0fE7ySIeil8HQWHeE
L2XJTLlVfHETm4XcNxkjBl/dOCHcaxizUJ6gJxe3OqtAfiJTH7mOGEV8fF4IK1fT
ZCbeHf/n7iX/nZdAJd4Q8ocOZ8NJ0ildVtwoBmtvJd8p7enHEu2DLoVYSuGm+hct
awTngajnk36dxmm0/t66EFTjFJcY5H1W5axxpbg7UVJOYK9Wrfpxx6zEQ5mJzaY=
=wMmS
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"android-ndk" group.
Post by Tim Mensch
To unsubscribe from this group, send email to
android-ndk+***@googlegroups.com<android-ndk%***@googlegroups.com>
.
Post by Tim Mensch
For more options, visit this group at
http://groups.google.com/group/android-ndk?hl=en.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Doug Schaefer
2010-12-24 16:56:48 UTC
Permalink
Post by Tim Mensch
Post by Doug Schaefer
I don't see any paths in an Android .project. If there was, it should
be fixed. Good news is that we know who the IDE developers are.
Try including a .jar file or any source from outside your project tree.
Like from a common library folder. It won't accept anything but an
absolute path, when the project tree would make a relative path work
just fine.
That's solved by using a classpath variable and user library settings
in your preferences. That's how the Android ADT source is set up to
point at things in the AOSP tree.

Doug.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
brainydexter
2010-12-23 19:09:35 UTC
Permalink
Thank you folks for your insight on this subject. I appreciate the
time you took to answer my query.

One of the objectives that I want to keep in mind while learning/
making these games on android is, I want to make an engine which would
let me publish content across other platforms. I think C++ is
definitely the choice for that route. I am sure, there will be some
sense of manual intervention that would be required to get them
running on each one of them separately, which I am okay with.
Post by Dianne Hackborn
Generally for games, though, you probably want to
do them on a separate thread so you can do them as part of the dedicated
game engine.  (The current native activity samples for 2.3 use client-side
glue code that puts the engine on a separate thread from the main one, but
you don't need to follow this.)
I agree with this approach and I could see the reason on Chris
Pruett's talk on google io. Dianne, maybe I am not reading this
properly, but when you mention that the samples are putting the engine
on a separate thread (from the main one); isn't your earlier statement
stating the same thing ("Generally for games, though, you probably
want to do them on a separate thread so you can do them as part of the
dedicated game engine") ? Can you please clarify this ?

Other than Replica Island, can you point me to an example/sample which
uses the approach you mentioned ?

IDE is a personal preference. Some works out better than others for
different people. Out of curiosity, Tim and Dianne, what IDE do you
guys use/prefer ?

Thanks
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Tim Mensch
2010-12-23 19:16:15 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by brainydexter
IDE is a personal preference. Some works out better than others for
different people. Out of curiosity, Tim and Dianne, what IDE do you
guys use/prefer ?
As far as I'm concerned, there are no "great" IDEs; that said, the best
one around, for targets it supports, is Visual Studio. Which is why I
made a Windows target for my cross-platform library; much cleaner to
debug and edit there.

As to personal preference, I actually use Visual Slickedit for most of
my C++ and Lua editing, and even much of my Java editing, entering
Eclipse mostly only to build; Visual Studio is finally getting better at
tagging, though (handling smart pointers and other templates in its
auto-complete, in particular), so the differences are not as compelling
as they used to be. Well, except that Slickedit supports Lua and Java
nicely. :)

There are still a few features in Slickedit that I am loathe to lose,
though, so that's where I'm likely to stay until a better option comes
along. AND...I'm not saying it's perfect. They all make me curse at
different times. :)

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNE5//AAoJENSbqLBCyKKsuz4H/Ay+jrcc0AgaOhCYWs7MueUq
ZoBQfbbT8TZJKDvTNGPxpDfu2gPURRgZE+FEifEDNJW+19c+ftoJqCFsr9pF62e+
/bHlbLqs0+iUDosXYKFtLjtJd2hfZ7EWSTaT2gLEFTdE84HH9eXYna6+yAakqvTj
nIy8cVNwhv8fhhefXfxiViZZk5QvGuaj/DOe5X+qmlBZj3iK25BjQHVIBbhrdbgE
9HQPOt1gFYrUsbVyK40JbKbXhsQwwyPxhNgrWlx6OET6e9VmAx2zyDKiHpncYo5B
lSGbw29ua0ip/Ocec7mIDcbC8OD400VVVN60hxm7E9EdMUBrWk+0gmEwAu+GYHc=
=SEhg
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Dianne Hackborn
2010-12-23 19:51:43 UTC
Permalink
Post by brainydexter
I agree with this approach and I could see the reason on Chris
Pruett's talk on google io. Dianne, maybe I am not reading this
properly, but when you mention that the samples are putting the engine
on a separate thread (from the main one); isn't your earlier statement
stating the same thing ("Generally for games, though, you probably
want to do them on a separate thread so you can do them as part of the
dedicated game engine") ? Can you please clarify this ?
Well I am just saying, there is nothing intrinsically forcing you to do your
GL stuff on a separate thread. Often people do dedicate a separate thread
for it, though, and the native activity sample for 2.3 uses glue code that
is designed to work this way, since that is what people typically want for
doing the type of apps (game etc) that was the main focus for those new
APIs. There is nothing in the platform forcing you to do this on a separate
thread, though.
--
Dianne Hackborn
Android framework engineer
***@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to android-***@googlegroups.com.
To unsubscribe from this group, send email to android-ndk+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Continue reading on narkive:
Loading...