[Ohrrpgce] Android port
James Paige
Bob at HamsterRepublic.com
Fri Jun 7 07:44:09 PDT 2013
Hmmm... installing FB and SDL and the OHR is pretty tricky, but
installing the ADK+NDK is really quite easy.
If we could make the OHRRPGCE a library to extend, and we didn't need to
compile anything but Java, seems like expecting the user to install the
ADK+NDK might not be that difficult of a requirement.
Actually, the approach taken by the buildozer project is worth looking
at. It is a tool for packaging python projects for Android or iOS. It
can autmatically download the ADK+NDK, automatically download and
compile python 2.7 from source, automatically download and install an
assortment of dependency modules.
That approach is definitely a brute-force method of solving the problem,
but in spite of the tedious download times on the first run, it really
works nicely, and is pretty simple.
> * Server signs with the "OHRRPGCE.COM" key. (Something you guys maintain).
I was about to say that it would have to be HamsterRepublic.com because
ohrrpgce.com has been owned by web-sqatters for years, but when I went
to check which web squatter currently held it, I was surprised to
discover that they have *finally* let it lapse, so I just snapped it up.
ohrrpgce.com is now mine :)
On Fri, Jun 07, 2013 at 10:16:29AM -0400, Seth Hetu wrote:
> Having a build server would certainly be helpful; ADK+NDK+FB+ohr/sdl
> is not the easiest toolchain to install. You might want to consider
> three options for signing:
> * Server signs with the Debug ADK key. (Good for just "trying it out")
> * Server signs with the "OHRRPGCE.COM" key. (Something you guys maintain).
> * Server provides an unsigned APK, and you guys provide a small
> utility for developers to sign unsigned APKs (with their own keys).
>
> -->Seth
>
> On Fri, Jun 7, 2013 at 5:52 AM, Ralph Versteegen <teeemcee at gmail.com> wrote:
> > On 7 June 2013 04:18, Simon Bradley <neworiginal at gmail.com> wrote:
> >> On Thu, Jun 6, 2013 at 4:44 PM, James Paige <Bob at hamsterrepublic.com> wrote:
> >>>
> >>> On Thu, Jun 06, 2013 at 04:16:32PM +0100, Simon Bradley wrote:
> >>> > On Thu, Jun 6, 2013 at 3:22 PM, James Paige <Bob at hamsterrepublic.com>
> >>> > wrote:
> >>> >
> >>> > On Thu, Jun 06, 2013 at 01:28:10PM +1200, Ralph Versteegen wrote:
> >>> > > On 6 June 2013 02:19, James Paige <Bob at hamsterrepublic.com>
> >>> > wrote:
> >>> > >
> >>> > > > For people who don't have their own domain name, we can provide
> >>> > a
> >>> > > > namespace like com.hamsterrepublic.ohrrpgce.games.gamename but
> >>> > I
> >>> > would
> >>> > > > also like to allow people to specify their own namespaces, so
> >>> > for
> >>> > your
> >>> > > > own game, tmc, you might choose to use
> >>> > > > com.castleparadox.tmc.foresttemple or maybe Mogri would want to
> >>> > use
> >>> > > > com.slimesalad.phantomtactics or Harlock might use
> >>> > > > org.crithit.spellshard
> >>> > >
> >>> > > Is there any point to allowing customisation of namespace? I
> >>> > think it
> >>> > > just has to be unique, eg a com.hamsterrepublic.ohrrpgce.games.
> >>> > > prefix.
> >>> > > I see that the Android documentation says "To avoid conflicts
> >>> > with
> >>> > > other developers, you should use Internet domain ownership as the
> >>> > > basis for your package names (in reverse)."
> >>> >
> >>> > Well, from a making-things-work perspective, no, there is no point
> >>> > to
> >>> > allowing people to specify their own namespaces, but from the
> >>> > perspective of people signing their own games and uploading them to
> >>> > the
> >>> > google play store, I would like to give people that option,
> >>> > especially
> >>> > for people who are going to sell their games rather than post them
> >>> > as
> >>> > free apps.
> >>> >
> >>> > Someone can still sell their game with a name in the
> >>> > com.hamsterrepublic.ohrrpgce.games.* namespace, but by doing so the
> >>> > are
> >>> > trusting me as the owner of that domain to behave honorably about
> >>> > it :)
> >>> >
> >>> > The simplest way would presumably be to make the ohrrpgce a library
> >>> > project and wrap it with the new namespace, I think:
> >>> >
> >>> > package com.newnamespace.myrpg;
> >>> >
> >>> > public class MainActivity extends com.ohrrpgce.games.OHRActivity
> >>> >
> >>> > etc.
> >>> >
> >>> > I believe that would work. That seems to be how these examples I am
> >>> > looking at are set up.
> >>> >
> >>> > (I am actually working on an Android project right now for my day
> >>> > job, but
> >>> > it's been a while and I'm a bit rusty. And someone else has already
> >>> > written it; I'm just changing it.)
> >>> >
> >>> > Cheers,
> >>> > Simon
> >>>
> >>> Hmm... If that is the only way to change the namespace, then it sounds
> >>> like having the Android SDK installed and recompiling the project would
> >>> be required. Maybe it isn't worth it if it is that much trouble?
> >>>
> >>> Even though I want people to be able to customize the namespace of their
> >>> game, I guess that should be a low-priority goal :)
> >
> > Don't forget that while allowing the user to select the namespace is
> > low-priority, packaged .apks still need to have unique namespaces,
> > otherwise Android will consider them all as the same program.
> >
> >> Ah, yes. Maybe not ideal. It might be possible to change it with something
> >> like proguard instead, in the compiled version.
> >
> > There's an additional problem. It turns out that in addition to all
> > the Java code, lots of the C code in the SDL port requires the
> > namespace to be compiled in too. I have no idea how JNI works, but it
> > appears that Java code like...
> >
> > package com.hamsterrepublic.ohrrpgce.game;
> > class AudioThread
> > {
> > private native int nativeAudioInitJavaCallbacks();
> >
> > requires an implemention provided by a C function named
> > Java_com_hamsterrepublic_ohrrpgce_game_AudioThread_nativeAudioInitJavaCallbacks!
> >
> > However perhaps by using Simon's library suggestion we can use a
> > separate namespace for all of the code compiled into the .so files,
> > leaving just the xml metadata and compiled Java files to worry about.
> >
> > In order to edit the namespace in compiled Java code we would have to
> > modify .dex files (targetting .class files instead would mean still
> > having to convert them to .dex and requiring the NDK). Looking around
> > a bit I see there are a couple projects like smali/baksmali
> > (https://code.google.com/p/smali) for disassembling/reassembling a dex
> > file. It sounds a whole lot simpler to just set up a web server which
> > compiles the required java source files with desired on request :)
> >
> > Unless creating a single trivial java module which includes everything
> > else is enough; in that case smali/baksmali could be practical, or
> > even a small edit to the right offset in the file...
> > _______________________________________________
> > Ohrrpgce mailing list
> > ohrrpgce at lists.motherhamster.org
> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
More information about the Ohrrpgce
mailing list