<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>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.</p></blockquote><br>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. <span style="font-size: 15px; line-height: 1.4;">You don't need to download Android Studio at all, you only need basic Android SDK and NDK.</span><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<p>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?</p></blockquote><div><br></div><div>castlewindow_android.inc does<br></div><div><br></div>  {$I castlewindow_egl.inc}</div><div><br></div><div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<p>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.</p></blockquote><br>UNIX I/O works for reading files. On disk (device internal memory, sdcard etc.).</div><div><br></div><div>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.</div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<p>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.</p></blockquote><br>See the URLReadXML implementation:</div><div><div><br></div><div>procedure URLReadXML(out Doc: TXMLDocument; const URL: String);<br>var<br>  Stream: TStream;<br>begin<br>  Doc := nil; // clean "out" param at start, just like ReadXMLFile<br>  Stream := Download(URL, []);<br>  try<br>    ReadXMLFile(Doc, Stream);<br>  finally FreeAndNil(Stream) end;<br>end;<br><br></div><div>So it simply reads URL to a TStream, then uses overloaded ReadXMLFile version that reads XML from a stream:)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<p><span style="font-size: 15px; line-height: 1.4;">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.</span></p></blockquote><br></div></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Michalis</div>