Wormux code is indeed doing a lot of pixel access. I've compiled SDL 1.3 under Windows, and observed a drastically bad performance. No wonder about the performance under Android.

I'll therefore continue with SDL 1.2, and try to adapt your code (audio/controller/video).

Finally I've got Android developer account and published the Alien Blaster! ePenis++;
If you've got an application in usable state and don't want to spend $25 for dev account I can publish it for you. However I'll demand really _usable_ state, even on phones without keyboard.

I understand your demand has to do with how many complaints you'd have to transmit, but I'm still far from having something playable (for instance, some of your key assignments don't work out when playing wormux), and having a perfect playability with such restrictions is pretty down my "to do" list.

If your app cannot work without keyboard I'll set android:reqHardKeyboard in AndroidManifest.xml, but your application will be invisible to the touchscreen-only devices on Android Market (I think it's like half of all Android devices around).
On the other hand, I won't get complaints

If you don't like my keybindings just edit file jni/sdl/src/video/android/SDL_androidinput.c and re-bind the keys to something your game understands.

In the future I'll implement some (rather simple and crude) onscreen keyboard, for now I'm trying to port only the games that require no more than 3 keys besides cursor keys (that is, Menu, Volume Up and Volume Down, accelerometer emulates cursor keys).
Back key is also usable, but should not be binded to any game action IMO because user should be able to close game anytime without any nasty popup dialogs like "Are you really want to exit (y/n)?". Well, just my thoughts about usability.
Also touching screen may be 4th user input for games that do not support mouse.
Another possibility is to use orientation-meter instead of accelerometer, that will be like 3-axis joystick and you may emulate 6 buttons instead of 4, however playing such game will require some juggling skills from user.

I guess you should change the downloader code, 70% of the times i download the data files from net, the app will crash... maybe if you download first the whole zip file and unzip after...

oNaiPs wrote:I guess you should change the downloader code, 70% of the times i download the data files from net, the app will crash... maybe if you download first the whole zip file and unzip after...

How can we include the files in teh apk.

No idea i managed to include a file in an apk putting it on res/raw and using some code (for instance with file named androidvncserver):

InputStream ins = getResources().openRawResource(R.raw.androidvncserver);
int size = ins.available();

// Read the entire resource into a local byte buffer.
byte[] buffer = new byte[size];
ins.read(buffer);
ins.close();

FileOutputStream fos = new FileOutputStream("/data/data/org.onaips.vnc/androidvncserver");
fos.write(buffer);
fos.close();


I do not recommend to do it with large/many files...

Any one else getting a "Undefined Reference" error when trying to use TTF_OpenFont() :\

pelya wrote:If your app cannot work without keyboard I'll set android:reqHardKeyboard in AndroidManifest.xml, but your application will be invisible to the touchscreen-only devices on Android Market (I think it's like half of all Android devices around).
On the other hand, I won't get complaints

That's probably what I'll need to do. Currently, Wormux needs:
- shoot key (usually space, but I'll map it also to camera)
- left/right (to move the character, ok with accelerometer but I'll provide a way to deactivate it)
- up/down (to aim, ok with accelerometer)
- esc (to move out of menus, to change game options while playing)
- s (to start chatting, probably deactivated for Android)
- jump (mapped to enter, or ok button on dpads)
- mouse (we have kinetic motion now)

Except troublesome to handle mouse gestures (double clicks or the like), I hardly see how we can cram than many events with only touchscreen.

If you don't like my keybindings just edit file jni/sdl/src/video/android/SDL_androidinput.c and re-bind the keys to something your game understands.

Already under way, but good to know for people starting out.

In the future I'll implement some (rather simple and crude) onscreen keyboard, for now I'm trying to port only the games that require no more than 3 keys besides cursor keys (that is, Menu, Volume Up and Volume Down, accelerometer emulates cursor keys).

What about popping a text entry of some kind (disclaimer: I know zilch about jni and the android platform), and import the resulting string into a native buffer?

Back key is also usable, but should not be binded to any game action IMO because user should be able to close game anytime without any nasty popup dialogs like "Are you really want to exit (y/n)?". Well, just my thoughts about usability.

I've seen other people recommend this (for instance, our Maemo maintainer prefers the game to exit instantly, but as I said, we allow checking help, modify options etc during gameplay).

Also touching screen may be 4th user input for games that do not support mouse.
Another possibility is to use orientation-meter instead of accelerometer, that will be like 3-axis joystick and you may emulate 6 buttons instead of 4, however playing such game will require some juggling skills from user.

On the other hand, this could be an interesting gameplay, but the game would have to be thought around this principle to really be that enjoyable.

Jug6ernaut wrote:Any one else getting a "Undefined Reference" error when trying to use TTF_OpenFont() :\

Wormux use SDL_ttf, and we don't have such problem. Are you sure the font you request is actually available? The freetype lib is separated from the whole android environment, so I expect you have to provide your own fonts.

About the physical keyboard vs accelerometer, instead of the application doing that work, could the java part do the detection, for instance keyboard != Configuration.KEYBOARD_NOKEYS, and set like a static variable to activate/deactivate the accelerometer?

kurosu wrote:

Jug6ernaut wrote:Any one else getting a "Undefined Reference" error when trying to use TTF_OpenFont() :\

Wormux use SDL_ttf, and we don't have such problem. Are you sure the font you request is actually available? The freetype lib is separated from the whole android environment, so I expect you have to provide your own fonts.

wouldn't that cause a run time error not a compile error?

also how would I go about disabling the gsensor as soar? or have direct access to the gsensor?

I'm getting some REALLY bad performance compared to the (generally) same code running on wm. not sure y... sdl code on windows flys so idk what it is.

oNaiPs wrote:No idea i managed to include a file in an apk putting it on res/raw and using some code (for instance with file named androidvncserver):

Android market has some restrictions on raw resource data, 1 or 2 megabytes, I don't remember. The officially supported way is to download data from the net yourself on the first run.

oNaiPs wrote:I guess you should change the downloader code, 70% of the times i download the data files from net, the app will crash... maybe if you download first the whole zip file and unzip after...

Yeah, I've noticed that - if the phone goes to sleep 'till data is downloading the app wil crash, I'll fix that.

kurosu wrote:bout the physical keyboard vs accelerometer, instead of the application doing that work, could the java part do the detection, for instance keyboard != Configuration.KEYBOARD_NOKEYS, and set like a static variable

Thanks for the reference. I thought of writing "Select your phone type" dialog which pops up on app first run where you can choose to use accelerometer or dpad or trackball etc.

Jug6ernaut wrote:

kurosu wrote:

Jug6ernaut wrote:Any one else getting a "Undefined Reference" error when trying to use TTF_OpenFont() :\

Wormux use SDL_ttf, and we don't have such problem. Are you sure the font you request is actually available? The freetype lib is separated from the whole android environment, so I expect you have to provide your own fonts.

wouldn't that cause a run time error not a compile error?
also how would I go about disabling the gsensor as soar? or have direct access to the gsensor?
I'm getting some REALLY bad performance compared to the (generally) same code running on wm. not sure y... sdl code on windows flys so idk what it is.

Dunno about SDL_ttf, I didn't test it, just included in the project and made sure it compiles. Please check that SDL_ttf properly links to freetype lib - check that LOCAL_STATIC_LIBRARIES var in SDL_ttf/Android.mk includes "freetype", and the libfreetype.a itself exports symbol TTF_OpenFont. I'll check it in Monday when I'll get to the office.
About performance: the only configuration where you're getting HW-acceleration is when you're using SDL 1.3, with revision tagged "android-market-release-01" or later. SDL 1.2 has only SW rendering available, I intend to add HW accelerated surfaces to it but it will require two weeks, if not more. Also you may use SDL 1.3 in OpenGL mode (it uses OpenGL internally anyway to be accelerated). Don't know about SDL 1.2, I did not test it with OpenGL.
Also HW acceleration depends on your app greatly - if you're drawing to 24 or 32 bpp 640x480 px SW surface you'll get awful performance, even though if it runs okay on your PC. Using 16 bpp surfaces will increase performance greatly, even if you're not using HW acceleration.

kurosu wrote:That's probably what I'll need to do. Currently, Wormux needs:
- shoot key (usually space, but I'll map it also to camera)
- left/right (to move the character, ok with accelerometer but I'll provide a way to deactivate it)
- up/down (to aim, ok with accelerometer)
- esc (to move out of menus, to change game options while playing)
- s (to start chatting, probably deactivated for Android)
- jump (mapped to enter, or ok button on dpads)
- mouse (we have kinetic motion now)

Except troublesome to handle mouse gestures (double clicks or the like), I hardly see how we can cram than many events with only touchscreen.

So, you need accelerometer for up/down/left/right, touchscreen for mouse input and 2 keys - to fire and to jump.
You can bind Fire to Menu key and Jump to Volume Up, and you even have one unused Volume Down key (I believe that keys are available on any device, correct me if I'm wrong).
Raw Android touchscreen events include your finger pressing force and radius of spot your finger touches, I think I can use that somehow to emulate double-click or right mouse click.

kurosu wrote:What about popping a text entry of some kind (disclaimer: I know zilch about jni and the android platform), and import the resulting string into a native buffer?

That would be cool, if I'll manage to get virtual keyboard to be half-transparent and don't totally hide your app screen, however I think Android won't allow me to do that.

kurosu wrote:

Back key is also usable, but should not be binded to any game action IMO because user should be able to close game anytime without any nasty popup dialogs like "Are you really want to exit (y/n)?". Well, just my thoughts about usability.

I've seen other people recommend this (for instance, our Maemo maintainer prefers the game to exit instantly, but as I said, we allow checking help, modify options etc during gameplay).

I meant that you should be able to exit by pressing Back key 5 times in a row for example, like in built-in web-browser. Exiting to game main menu is okay, just no confirmation dialogs plz.

Hello pelya, I downloaded your source from here http://github.com/pelya/commandergenius ... dl_android and tried to build it using instructions from the README, but the build stops on this error.

Code: Select all

make: *** No rule to make target `/home/peeps/android/pelya-commandergenius-784b430/alienblaster/project/obj/local/armeabi/libsdl.so', needed by `/home/peeps/android/pelya-commandergenius-784b430/alienblaster/project/obj/local/armeabi/libapplication.so'.  Stop.


Any ideas what I've got wrong?

I've never tried doing a port like this before, and I haven't developed on this game, but I would really like to see enigma running on android. Maybe it is a task beyond my skills, but I figured I would give at least give it a shot.

Oops, forgot to commit one file.
Run ChangeAppSettings.sh and change SDL version from 1.2 to 1.3 - I'm adding HW acceleration to 1.2, so it's not working currently.
Also I've made some symlinks inside repository, make sure you have compilation environment that supports symlinks (Linux or MacOs preferred, Windows + Cygwin should support symlinks, but I'm not sure about it. If you're using Windows you'd better to install andLinux or Ubuntu+Wubi - I was told andLinux compiles code faster than Cygwin).
If current HEAD fails you may try to use some stable revision, for example tagged "android-market-release-01" or "last-working-1.6". If you don't want to port your game to SDL 1.3 you certainly want to use revision tagged "last-working-1.6" - it's SDL 1.2 without HW acceleration. Then you can recompile it with HW accelerated 1.2 when I'll finish it.