> I see you made a builder tool I’ll have to check out. From the Android
tutorials I’ve seen building Android packages seems be pretty forward. You can
run/install apps from the terminal also I think based on your documents.
That’d be nice to not be in Android Studio if I don’t have to be.
Yes, you can do whole compile + install + run process using castle-engine
tool. It's a rather simple wrapper around some Google tools, ant etc. You
don't need to download Android Studio at all, you only need basic Android SDK
and NDK.
> It looks like the majority of the startup code is in castlewindow_android
but I was expected to see an OpenGL context (surface view I think in Android).
How do you render OpenGL then?
castlewindow_android.inc does
{$I castlewindow_egl.inc}
and the code that initializes OpenGLES context is inside castlewindow_egl.inc.
It's using EGL library, https://www.khronos.org/registry/egl/ , specification
blessed by Khronos, available on Android, able to initialize OpenGL ES
context.
It can also be used to initialize OpenGL ES context on the desktops (which is
useful to test OpenGL ES renderer on Linux, Windows etc.). That's why the code
is not inside castlewindow_android.inc --- it's more generally useful.
> So UNIX I/O “works” but you can’t read anything without the asset manager?
That doesn’t really make sense but either way using the Asset manager in a
stream like you did is just fine. I only need to read the contents of images
and XML files anyways.
UNIX I/O works for reading files. On disk (device internal memory, sdcard
etc.).
It doesn't work to read stuff from the apk. Because the files you put inside
apk ("assets" in Android terminology) are not available to you as normal files
inside the Android application. You don't know where (and if, at all) they are
unpackaged on the Android filesystem. You can only access them (read-only)
using AssetManager.
> I was using ReadXMLFile to read the XML file but I assume this is just a
helper function that wraps something lower level I could use in conjunction
with the asset manager. Is that correct? Can’t find your code for this.
See the URLReadXML implementation:
procedure URLReadXML(out Doc: TXMLDocument; const URL: String);
var
Stream: TStream;
begin
Doc := nil; // clean "out" param at start, just like ReadXMLFile
Stream := Download(URL, []);
try
ReadXMLFile(Doc, Stream);
finally FreeAndNil(Stream) end;
end;
So it simply reads URL to a TStream, then uses overloaded ReadXMLFile version
that reads XML from a stream:)
> So internally Android just uses the same C libraries we were using in
Pascal? I guess that makes sense but I was thinking EVERYTHING on the system
was now Java but that’s not the case I guess. The lesson here is that Android
is built on Linux so we’re sharing more than I think.
There are *some* C libraries on Android, indeed. There is a version of libc,
there is OpenGLES (and friends like EGL). But not much else, so don't get your
hopes up:) http://developer.android.com/ndk/guides/stable_apis.html has the
list of available native libraries.
You can make a working game with them --- you have access to display (through
EGL and OpenGL ES) and sound (through OpenMAX). And you have access to input
by communicating through JNI with NativeActivity.
But a lot of other stuff is only available in Java libraries, and you need to
write custom Java code to access it. For example, everything that is part of
https://en.wikipedia.org/wiki/Google_Play_Services --- integration with Google
Maps, Google Analytics, Google Games, etc. Also in-app purchases. Also
integration with other apps e.g. to get/make photos. Or take location from
GPS. Or even open a WWW browser.
Fortunately, using these Java APIs through a JNI layer is not really hard in
my experience. And Castle Game Engine gives you some helpers:) ---
CastleMessaging and component system, to make it even easier.
Regards,
Michalis
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
