Move logic to native, build Android JNI glue layer

[haahmad]

Core API logic should be platform agnostic C++

Then we can provide an API to JNI bindings that Android Java code can call (Android glue).

This way we can build a glue layer for each platform we want to support in the future.

Discuss.

[Quillion]

I have no problem rewriting the whole logic in C++ (should take a day or two at most), but how would we glue things together? The issue that I have is that these are not individual tasks (like making a database management system, or fetch info from Internet system), all tasks should work together seamlessly, and the way I see it, passing objects into C++ and back again might cost as much as just keeping them as is. I do agree however that if we manage to do this, then everything will be that much faster, and I have done it in the other Android apps before. But I can't wrap my head around how we can do it in this case? A simple scenario. Let's say we have two object that are moving towards each other, then we will have to pass them to C++ which will check for collision and spit back the objects with new coordinates. We will have to take these objects back and attach them back to beginning. This is the only issue that I see

We have two objects. We pass them to the glue. Glue passes to C++ (costly) C++ does collision things and the whole shabang (extremely fast) C++ passes things back to glue (costly) Glue reassigns the properties back to the objects (slightly costly)

If this is the logic then we will have no gains and will simply have two sets of same objects both in Java and C++. If however there is more to this and I am simply blind then we are looking at a goldmine.

[haahmad]

It's going to be more than a straight port of the Java logic, would have to design it as a layer underneath the developers API. Mostly static functions. Definitely a large refactoring. The real issue is whether cross platform is a major priority.

[Jovani]

I'm going to speak out against this.

1. I want to make games, not spend the next X months making a C-based core, then wrapping it in Y levels of layers, only to be sick of it all and never wanna see it again.
2. The OUYA looks really cool and I personally want to focus on this for now.
3. If later down the line we wish to think about cross platform and opening this up; we'll have a finished codebase which can then be converted to C++. It may be harder to convert at that point, but I still think it will be for the better as more of the engine will be scoped out and completed. We'll have a better viewpoint on the project, and will better be able to switch to C++.
4. By having some games (or game-like things that aren't quite games) already functioning, they will act as tests for the core switch. As we'd move functionality over to C++, we'd be able to both test to make sure that what we just did works, and we'll be able to directly see how much of a performance gain or hit the switch is having.

My four cents.

[Jovani]

If you look at the process of major game designers, they make the product first, then spend time optimizing. Otherwise, you have no idea how far to optimize and how much gain X days/weeks/months of work will have.

[Quillion]

I do absolutely agree with Ivan that we should produce something and then focus on optimization (even though it will be more difficult by that point), and because Ouya release date is coming (June 25th), and by the time their ODK becomes stable (hopefully by mid July) I would like to be able to roll out a game quickly. However we have so many of us working on this. So if you would like, try optimization Hasan, I will try joining in and taking a peek at it too myself since I am very curious how it will work out. But I do agree, my main focus is to have the groundwork setup and ready.

[haahmad]

This isn't really about performance optimizing or testing. I am posing this question now so that a decision about cross-platform is made early on.

The change I am talking about here is not a simple port, it is a re-write. If this project wants to be cross platform then I suggest the re-write happens now. Otherwise I agree with the above points.

[Quillion]

My vision works somewhat like this. The platforms that can be considered is anything android, pc, Kindle (also runs on java and would be awesome for sim game that Ivan wants, I started this to get amazon to approve, they don't give their sdk without proof), and even blackberry. All those use Java. Xbox, ps3 and Nintendo are dead, and even if not, then competing against big companies that release games for them is close to impossible. Due to that I still would love to do that rewrite and improve efficiency and such, but seeing the somewhat small window we have to get into the field (ouya gets released on 25th, and by August, when odk becomes more stable I want to launch something), I don't see it being done that quickly. This is by far my favorite issue, and I intend to fully get it working, but only after we release something. However this is simply my agenda and I am racing to have things ready for set up, feel free to modify this as you see fit, I didn't start this project and invite you guys so I would be the only one saying things or making decisions.