Hello all,

Currently I've got my game "engine" working on Desktop with OpenGL on top Win32/X11 and I want to port it to Android (and after that potentially to iOS).
The question is what is the easiest way in my situation with least resistance (potentially with least amount of non C/C++ code)?
I know that I need to make my OpenGL comply with OpenGL ES 2/3, but other that that I do not know  how is the modern way to implement an C++ app for Android?

As an additional info I'm currently using CMake.

One option of course is to make use of an existing cross-platform library such as Godot, Cocos2d-x, etc. Obviously though this could require significant changes to your current code.

Here's some info though if you want to do it from scratch, more or less.

You can implement applications entirely in C++ on Android. However, in my experience this introduces some challenges and obstacles that can be avoided if you mix languages. As such, it may be that the easiest way to do it is a thin Java wrapper, with most of your code in C++. (For convenience I'm speaking in terms of Java here, but it can be done with Kotlin as well.)

The Java class GLSurfaceView provides a basic framework for OpenGL ES rendering. Using JNI, you can then hook into your native code. There are of course a lot of details (which I'm trying to deal with myself, as it happens), but based on my exploration so far, it's the most straightforward approach. Also, for what it's worth, some other mainstream libraries that I've looked at do it this way as well.

With iOS, you'll have to contend with the fact that OpenGL and OpenGL ES have been deprecated on Apple platforms. As far as I know they're still supported and I suspect they will be for some time, but technically they're deprecated. If you want to plan ahead for that, it might be advisable to keep your rendering code reasonably modularized to make it easier to swap out for e.g. Metal if needed.

As far as IDEs go, I've only used Android Studio, but it's the official IDE for the platform and seems effective, so that's what I'd recommend.

Those are my initial thoughts based on my own experience. Maybe others will offer different advice.

Thanks for the replay!

All that feels like tedious work, I don't want to spend Christmas debugging Android crap, so I'll postphone it again

Porting from dx to ogl is a pain, however there is another pain like handling system calls/events with different oses ao my best bet would be to port input handling, graphics initialization to sdl2.

Another thing is permissions to access directories and resources, youd vetter for the start use fixed directory path where you put your files, another thing that youll have to face loading textures by your own or use sdl where x and y axis are negated.

Not to mention youll have to find the correct path (best way to do is to execute ahstem call ls /storage/ and parse data you have received to find sdcard path or use /storage/emulated/0/ but depending on android platform you might be forced to install application to access specific data/packagename/files write/read permissions

Networking differs too, handling time too

Quote

You can implement applications entirely in C++ on Android. 

From my xp i can say no you cant, you think you can but you cant unless you rooted the device and used make.

And i highly dont recommend using java at all if you want to use c++, you only start app in java then call c++ code and thats all, no input handling or drawing once you started c++ code execution you contibhe with while loop till you want to exit application and habdle everythong from that, this will make you feel more like youre developing on windows without to care of threads spawning everywhere

Quote

Another thing is permissions to access directories and resources, youd vetter for the start use fixed directory path where you put your files

Quote

Not to mention youll have to find the correct path (best way to do is to execute ahstem call ls /storage/ and parse data you have received to find sdcard path or use /storage/emulated/0/ but depending on android platform you might be forced to install application to access specific data/packagename/files write/read permissions

Although all this may be true (I'm not sure - I can't quite follow it all), for the sake of the OP I'll mention that basic asset loading on Android and iOS shouldn't necessarily require jumping through a lot of hoops (I don't think). For both Android and iOS, assets are generally included in the app package in various ways, and accessing them is fairly straightforward (although I've heard of assets sometimes being distributed separately on Android due to size).

Perhaps _WeirdCat_ is talking about something else here (like writing saved game files), but I thought it might be worth clarifying that loading game assets shouldn't necessarily be difficult.

Quote

another thing that youll have to face loading textures by your own or use sdl where x and y axis are negated.

I don't think the x axis is negated in SDL (correct me if I'm wrong). As for the y axis being negated, that depends on what you're comparing it to. Maybe I'm not interpreting you correctly though.

Quote

From my xp i can say no you cant, you think you can but you cant unless you rooted the device and used make.

Not saying you're wrong, but I haven't heard of or encountered what you describe. Pure C++ apps have bytecode running behind them (as I understand it), but as a developer you can write apps entirely in C++ with no Java. If you think this is wrong though, maybe you could clarify, as I'd certainly like to learn if I'm wrong about this. (Maybe we're using different definitions of 'entirely in C++'.)

Quote

And i highly dont recommend using java at all if you want to use c++, you only start app in java then call c++ code and thats all

Not sure if you're saying to use Java or not use Java here, but as I mentioned earlier, I think there may be some things that are more difficult to do in native code than in Java. If that's the case, there may be advantages to a mixed-language approach. But, ultimately it may just be a matter of personal preference.

Anyway, even though the OP isn't planning on pursuing this currently, I thought I'd offer some comments for the purpose of clarity. (And apologies _WeirdCat_ if I'm misinterpreting parts of your post.)

Well I already have Direct3D 11 and OpenGL 3.x abstracted away so these aren't a problem.
The main thing that I want to reuse in that case is my CMake scripts, as I detest configuring libraries...

About that pure C++ thing, can you point me any examples?

Quote

The main thing that I want to reuse in that case is my CMake scripts, as I detest configuring libraries...

If you're using a lot of third-party C/C++ libraries (especially complex ones), there may be some challenges there. I can't really comment directly on that, as the C/C++ libraries I've used on Android haven't been difficult to configure and build.

Quote

"About that pure C++ thing, can you point me any examples?"

My experience is that resources and documentation on this are a little scarce, presumably because there's not much call for fully native Android apps. As I think I mentioned earlier, even the major cross-platform libraries I've looked at use a Java wrapper rather than taking the fully native approach.

That said, there's a book called "Android NDK Beginner's Guide" that walks you through creating a fully native Android application using OpenGL ES. Personally I had some issues with the book, but it does include a complete working example. Maybe others can recommend other resources though.

I pursued fully native for a while, but encountered enough things that seemed excessively difficult or like they'd require a lot of research that ultimately I decided a mixed-language approach was more practical. That's just my experience though.

I did a few posts on my android version which might be useful:

https://www.gamedev.net/blogs/entry/2264243-android-build-and-performance/

https://www.gamedev.net/blogs/entry/2262630-android-build/

For OpenGL ES I had to use an emulator (ARM Mali I think?) on windows, it is handled natively on linux. I went with the thin java wrapper around my c++ code, it was recommended at the time because not everything was available to fully native c++ apps, this may have improved since. SDL or similar may be worth investigating.

I also seem to remember I had to be careful about threading and input compared to desktop, but this may have just been my setup.