[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Ok, for those interested in the port, some notes.
Some things should be kept in mind due to the nature of the android platform.
The latest SDK should always be used if at all possible. The latest platform
version should be targeted (with minSDK targeting something like 1.6 or 2.2?).
OpenGL ES support should likewise be treated as supporting the abolute latest
in the default config of allegro. Meaning, a generic setup of an allegro
android project should be able to be compiled to work on versions from 1.6
(2.2?) through 4.0. ****
I intend to build a table of the various supported android device profiles,
including cpu type, instruction set version, and instruction set extensions,
to help lay out a proper set of compile time switches.
**** that's given that the platform works the way I assume it does, I don't
know for sure exactly how the store treats different cpu variants yet. if you
can't make a large monolithic multi arch apk, then well it may not make much
sense at all to allow the use of say, GLES2, on a compile that can work on 1.6
devices, and most of them likely won't support GLES2. This needs some thought.
To trentg, that WANT_ANDROID_4 option is very mis-named. Someone more familiar
with Android development will immediately assume Android ICS (aka 4.0) when
reading that. And we /really/ shouldn't be making that /just/ a compile time
option. I have nothing against having compile time options that cut out a lot
of compatability code paths, but by default I think the config should be to
leave most of them in, so as few apk's need to be built as possible for a
given app (last I heard the android store can be silly about multiple apk
package versions).
Note: I'm quite tired, so I may have misunderstood some of the changes
you/trentg made, or completely mis-brained everything I wrote above. But
that's just some of the stuff I've been thinking about, and it should be kept
in mind.
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx