• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Seabolt

How feasible is using the NDK?

15 posts in this topic

Hey, sorry to piggy back on this thread, but I'm also just doing an introductory look into android, but I'm looking to use the NDK. How feasible is using the NDK? How easy is it to integrate an already made C++ engine to work with Android? I know there is some unavoidable Java code that I'll have to write to query platform features and such, but how intrusive is that code?

I'm an experienced C++ programmer and would really like to target the platform if it doesn't require a whole rewrite of my engine.

0

Share this post


Link to post
Share on other sites
Spitting this off to its own thread. Please start a new thread for a new question.
0

Share this post


Link to post
Share on other sites
Exactly how easy or difficult it would be depends entirely on the code base.

There is no way to know with the information you provided.

If you have a small code base or an extremely simple code base it could be a relatively simple matter.

If you have a large code base or an extremely complex code base it could be a relatively complex matter.
2

Share this post


Link to post
Share on other sites

Hah fair enough, sorry to intrude on the other thread.

I have an engine that is primarily just rendering tech with some additional functionality like cameras, file IO, the like. It's a completely cross platform engine though, and I render using OpenGL, DirectX 9, and DirectX 11. I should be able to fold OpenGL ES into my engine well enough, but I'm worried about rendering not being a clean break from Java. Like how much Java code would I have to write to just get my engine spinning under the hood?

I'm sorry, I know it's a very vague question.

0

Share this post


Link to post
Share on other sites
I don't understand what you are trying to get at with the question.

We cannot give an answer that makes sense. "It takes 3 units of work". Or maybe more. Or less. We don't know your engine.


Is it possible? Yes, it is possible.
0

Share this post


Link to post
Share on other sites

I guess my question is, how intrusive is the Java code necessary to properly initialize an engine and run with it?

0

Share this post


Link to post
Share on other sites

You can use native-activity, then you don't need to mess with Java. And example is in samples folder.

1

Share this post


Link to post
Share on other sites

Awesome, thank you. I haven't dug into the samples yet, I'm just probing around a bit.

0

Share this post


Link to post
Share on other sites

I wish you luck but sharing a bit of my experience its not pretty but I do hope it keeps getting better.

 

Pros

1. Ease of conversion only real issue was pthread_cancel in my case

2. Excellent performance must faster than java in some heavy cpu encryption cases

 

Cons

1. With much research I still cannot get a gl context without java

2. Targeting multiple devices is a pain I must be doing something wrong but that leads to 3. Out of the 4 devices in my home apparently there are 3 different types of arm cores which makes sense being some are old and 1 is a media player but I still havent been able to get all of them to work.

3. Horrible docs alot of things are not documented

4. pthread_cancel is non existent and probably more but thats just something my project was using that it cant anymore.

 

I hope this is just me and not the ndk itself this has just been my experience and I have never compiled for arm devices before maybe someone knowing more can put tell if the cons are just me or not I would be interested to know.

 

One note about my findings so far I have not done audio so thats a bit scary as the library we were using is not capable and were looking for low level audio im not sure how well it will come out.

2

Share this post


Link to post
Share on other sites

Awesome, that's great to hear, thanks Buster! I'll take a look at some of those resources. Though I'm a foolish person, and am going to roll my own tech.

0

Share this post


Link to post
Share on other sites

Using NDK is a must for me, as it allows to share 99,9% of code with IOS, and i can develop my game with Visual Studio 99,9 % of the time :)

Using native activity is only available on updated devices, so i avoid it and use java for those things:

 

* Loading files (c file functions work, but can't access the comprerssed package contents so easy)

* Sound (OpenAL is available but relatively new to Android)

* Threading (never tried pthreads, but they would be available on IOS too!)

* Creationg OGL context 

* reading sensors

* (Network, server communiction... if you need)

 

Expect a little bit of pain getting all this basic things to work, but then it shouldn't be a problem

to run any OGL engine with a few #ifdefs, no matter how complex it is

NDK itself is just C++ as you know it - Nvidia has some nice Installers that setup all you need (Cygwin...)

2

Share this post


Link to post
Share on other sites

JoeJ, that sounds amazing. I'm a console developer at work, and I'd really like to be able to still work in Visual Studios without too much hassle. And I have experience with pthread, so I should be able to cross that one off the list.

I hope I can create my OGL context in my code, but if I can't, it's not the end of the world.

I'll have to check out the Nvidia resources and see what they can do for me.

0

Share this post


Link to post
Share on other sites

I'm currently using the NDK with SDL2 (ex. 1.3) and it's been a piece of cake. Sure, the debuging options are limited, but so long as you setup some defines for logging (so you can use the logcat) and learn how to use gdb it's not too bad. It helps if you can help your project for a different platform (e.g. Linux or Windows) and debug on there, but this may not be possible depending on what you are doing.

 

I'm sharing code between Windows, OSX, Linux and Android (all non-NEON devices, as SDL doesn't build correctly for them) at the moment, using CMake to build all of the projects except the Android one - where I use the NDK tools on Linux, but I've tested Cygwin and that works too. Eventually I'll add iOS in the mix, but I thought I'd leave that for a while (this is probably a massive mistake) as I wanted to get on and actually start developing.

 

At some point I'll clear out all the project specific code and upload a blank project template to bitbucket or github, since it's taken a little bit of work to get it all working, but now it is all setup it's a doddle.

1

Share this post


Link to post
Share on other sites

That's great to hear. I've never played around with make files so this should be quite the learning experience, but I'm glad to hear such positive feedback. Another question. I've got a working OpenGL 2.0-3.3 graphics engine, how hard is it to port to Android/iOS. (I know you don't know the code, but just in general)

0

Share this post


Link to post
Share on other sites

I don't know exactly, cause i work with OGL 1.x, which is similar to ES 1.0.

But i'm pretty sure that 2.0-3.3 is very similar to ES 2.0.

The deprecated stuff (glBegin, glRotate...) is missing from ES 2.0, and ES supports only triangles, no quads.

Which means that most probably you don't need to change anything from the runtime stuff.

 

Performance is another question - i target 60 fps and for me fillrate is the only thing that seriously affects performance.

OGL calls do not return immideatly, so it's good to have another thread doing the next timestep

while the render thread waits on gpu even on single cores.

 

I think the real mess with mobiles is understanding the thing called activity lifecycle on android:

What happens on incoming calls... When do you need to reload textures, because android killed OGL context...

What does my app in background... Which things are restored automatically when it comes back...

Problem is that i'm never sure if what i do is right for all devices.

 

 

@MODERATORS: I CAN'T LOGIN FROM FIREFOX (19.0) - IE IS OK

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0