Also... if you want changes to graphics or additional graphics or both.. please let me know. Maybe you would preffer them to be smaller... I guess feedback from people using them will make that determination.

Can you please give me ADB logcat output? Install aLogcat application from Market, crash UQM, launch aLogcat, press Menu->Send, you know my mail
No, it's okay like that, it's already pixelated if you select big keyboard size.
Maybe some auto-fire mode can be added - that will require additional images for buttons 1 and 2, though I can't think of any gesture to enable it (the buttons are so small), and I don't like autofire toggled by timeout (especially if you're playing with UQM Melee with Kohr-Ah or Chenjesu).

Found the error (oops, I should've clean my project before compiling)
Now it should work okay

Great! Ok works again. Let me point out some bugs that maybe not aware of yet.
1. Going into game menu setup and saving changed settings does not save settings. Have to change them. Everytime you load game.
2. After you've saved a game on the save game slots in the in game menu they can not be saved over again.
3. Missing a button for ESC key. I believe it was during battle with you main ship that it allows you to retreat from battle and try to escape them.
4. Can't get remix audio to load even though it was downloaded and then configured to be used in the in-game setup.
5. The virtual buttons seem to act sticky some times and cause double taps from a single press. Consistantly happens in menu.
6. Can't use virtual keyboard to input letters in the captain name and vessel name slots; instead have to use the dpad and for some reason can't change from caps to lower case and also seems to be less characters imputed.
7. Not really a bug but a suggestion to allow user to move the dpad and buttons to locations that they preffer at any time. Reasons for this... sometimes buttons occlude background when its neccessary to see background even though buttons are transparrent. Also maybe a fade out for road and buttons during videos and cutsceens?
8. Another suggestion: for auto-fire have the android in the middle bring down a menu at the top similar instyle of android OS menu go allow options and configurations to be changed... not just including auto-fire options. And you don't need new icons for auto fire unless you really want them. You could just changed their transparency level to not be so transparent. (Just an idea.)

For now that's my input. Excellent job on getting Urquan Masters working again so quickly.

1,2. - I'll look into that, probably some issue with directories.
3. ESC key triggered by Menu button, and Back button triggers F10 which exits game from any state (pressing Back from melee won't close the game until you're out of all your ships, so I've swapped the buttons).
Probably I should swap them back, or change dialog with Commander when he tells you he installed Escape Device to your ship triggered by Esc.
4. More directory issues. Well I should put some more time into debugging.
5. Yeah, noticed that, probably some inconsistency in SC2 input.
6. That's long standing bug that I'll fix someday.
7,8. I wanted to add keyboard designer in Friday's release, but end up fixing downloader bugs. I'll add it over time, and in-game config menu too.

pelya wrote:The new keyboard theme Ultimate Droid by Sean Stieber was added, well it looks not as good on device screen as on monitor.
Auto-fire was desperately disabled for that theme (still present in my Ugly Arrows), because there's no auto-fire button state images and I cannot think of any animation to toggle it.
The transparency setting will be added soon.
Also, what do you think about buttons layout?

Hi,

I was wondering if it's possible in OpenTyrian to get the touch-screen to act as the mouse-control do on the PC? I think this is the best way to control the game if you don't have a physical keyboard. A similar control method as Skyforce or the iphone-port of Tyrian is what I have in mind. It would be something like this:

Screen: Control ship like is done with a mouse
Trackball: Shoot
Volume up/down: change rear-weapon mode

Maybe this could be the control scheme chosen if you say you have a trackball on install? Would be absolutely perfect.

If that's not possible it would be nice if the rest of the screen didn't act as a button when you have the on-screen keyboard. I've got the trackball as the shoot-button and any accidental key-presses on the rest of the screen changes the mode of my rear-gun, which can be a bit annoying.

edit:

If this is the wrong place to ask, I apologize.

SBS: no it's the right place, and those are very good suggestions that I agree with for openTyrian as well.

I've also noticed on the Ur-Quan Masters that if you were to miss the right direction just slightly on the dpad... it's acting as a button press.. I think it was button 1. So I think the whole screen is still acting like a button 1 trigger. Might look into that one to see if you can remove it.

I just discovered this on Thursday and I have to say, it's exactly the thing I needed. With a little bit of work, I was able to get pygame running under android-SDL, which opens the door to porting many projects, including my Ren'Py engine.

Is there any work being done on integrating the android lifecycle with SDL, so that the application can be notified when android is about to destroy it? If not, I'd like to try to implement that, and give it back to this project.

renpytom wrote:I just discovered this on Thursday and I have to say, it's exactly the thing I needed. With a little bit of work, I was able to get pygame running under android-SDL, which opens the door to porting many projects, including my Ren'Py engine.

Are there many games written in Python-SDL? Most games I've found across internet use plain C.
If you've got working Python with SDL bindings I'll be happy to include it into my GIT.

renpytom wrote:Is there any work being done on integrating the android lifecycle with SDL, so that the application can be notified when android is about to destroy it? If not, I'd like to try to implement that, and give it back to this project.

I've planned to work on that bug next week, but I'll be happy if you'd fix it - I've still got enough bugs in UQM and OpenTyrian to fix.

The most important thing you have to worry about is that with Android 1.6 the application will lose OpenGL context when it is put to background (with Android 2.0+ it does not happen) - the SwapBuffers() Java call will return some error code when that happens. I was planning to make application sleep inside GlSwapBuffers() call, until it will get notification from Java that it created new OpenGL context, then re-create all GL textures with the pixel data from SDL surfaces/textures, so SDL application does not need to worry about GL stuff at all.
Also you'll have to remove PowerManager from MainActivity.java (it crashes anyway, and eats battery), and stop/restart both audio and video threads from OnSleep() / OnResume() (video thread is the one from which JNI main() is called).
SDL+GL applications will have to re-create all textures by themselves though, some notification mechanism should be added to make that possible.

DangerMouse wrote:I've also noticed on the Ur-Quan Masters that if you were to miss the right direction just slightly on the dpad... it's acting as a button press.. I think it was button 1. So I think the whole screen is still acting like a button 1 trigger. Might look into that one to see if you can remove it.

Okay, I'll remove that.

SBS wrote:I was wondering if it's possible in OpenTyrian to get the touch-screen to act as the mouse-control do on the PC? I think this is the best way to control the game if you don't have a physical keyboard.

Well, in PC version the ship was not following mouse, the mouse instead was acting as a dpad/joystick with the center of the screen as neutral position. I think making ship to follow your finger will be better.

pelya wrote:

SBS wrote:I was wondering if it's possible in OpenTyrian to get the touch-screen to act as the mouse-control do on the PC? I think this is the best way to control the game if you don't have a physical keyboard.

Well, in PC version the ship was not following mouse, the mouse instead was acting as a dpad/joystick with the center of the screen as neutral position. I think making ship to follow your finger will be better.

Ah ok, I was remembering wrong about the PC-version then. I meant to have the ship follow your finger. I like the implementation in Skyforce where it follow your finger, but still has a max speed. Thanks for great work on getting Tyrian to Android btw

pelya wrote:The most important thing you have to worry about is that with Android 1.6 the application will lose OpenGL context when it is put to background (with Android 2.0+ it does not happen) - the SwapBuffers() Java call will return some error code when that happens. I was planning to make application sleep inside GlSwapBuffers() call, until it will get notification from Java that it created new OpenGL context, then re-create all GL textures with the pixel data from SDL surfaces/textures, so SDL application does not need to worry about GL stuff at all.

This only a part of the problem, but this might then be of interest. The other part, texture reloading, is somewhat obnoxious from Android, because as soon as you do something fancy with your data/textures, it is very hard to reload them and modify them to the state where they left. As far as I know, sleep state on either Linux or Windows don't force you to do that.

At least on such active event, with iconification, the game knows when to put itself in pause state. Not many programs implement it (Wormux doesn't) and special care must be taken too to handle Android specific things, like turning the sound from the game down, or just shutting off audio.

Btw, what happens if someone phones us while playing? This happened to someone, and I know Wormux should have handled that as "shut down audio"...

I would rather prefer shutting down main and audio threads, so the audio just stops if someone calls you (and that wont' depend on bad application design, because it's handled inside SDL).
For application it will look like a very long SDL_SwapBuffers() call.
You may send SDL_ActiveEvent, but the problem is - you don't know in what order the application will draw things on screen and process events, it may first call SDL_SwapBuffers() - OpenGL context is lost here, then it will draw something without OpenGL context, in the best case it will spam logcat with error messages, in the worst - crash, and only then it will process SDL_ActiveEvent.

BTW I've added SDL on-screen keyboard interface exposed to the application - check out file SDL_screenkeyboard.h in SDL include dir. It has functions to hide or show overlay buttons, to redefine button coordinates to make it in sync with your app layout, and to bind different SDLKey to each button (except D-Pad).
So basically, you just have to rebind all buttons to what you like at the start of the game, override their coordinates, and hide them until you'll get to the game action screen (I hope 7 buttons will be enough for you).

pelya wrote:Are there many games written in Python-SDL? Most games I've found across internet use plain C.

Python + SDL is actually pretty popular, as that's what the pygame project makes easy. I'm guessing there are about a thousand projects that use it - but those projects vary wildly in quality, so I'm not sure how many would actually count as complete games. Ren'Py alone has over 200 projects made with it - but most are closer to interactive stories than games.

The most important thing you have to worry about is that with Android 1.6 the application will lose OpenGL context when it is put to background (with Android 2.0+ it does not happen) - the SwapBuffers() Java call will return some error code when that happens. I was planning to make application sleep inside GlSwapBuffers() call, until it will get notification from Java that it created new OpenGL context, then re-create all GL textures with the pixel data from SDL surfaces/textures, so SDL application does not need to worry about GL stuff at all.

I took the time this weekend to go ahead and do the Java side of this, just to see what it would take. I would up rewriting GLSurfaceView_SDL and Video into a new class, SDLSurfaceView. The reason for this was that the structure inherited from GLSurfaceView only checks for surface changes after a frame finishes rendering - and since the SDL main thread runs inside a frame render function, it never actually gets around to returning.

The new code checks for a surface change each time the buffers are swapped, and sets the context back up so it works. This is good enough for the unaccelerated 2d mode - and I think it might also work for the GL mode, if the error on swap propagates to a place where the user can see it.

The C side is pretty much unchanged, except for some of the natives moving between classes.

Also you'll have to remove PowerManager from MainActivity.java (it crashes anyway, and eats battery), and stop/restart both audio and video threads from OnSleep() / OnResume() (video thread is the one from which JNI main() is called).

I removed the powermanager one, without apparent ill effect.

For OnPause and OnResume, I did a more complicated thing. OnPause sets a flag, which the user code can query with SDL_ANDROID_CheckPause. It's required to check this flag frequently. When that goes to true, the user code should shut down any threads it's using, save it's state, and then call SDL_ANDROID_waitForResume. While in waitForResume, the app can be killed by the OS to reclaim memory.

Since Android is willing to kill an app while it's paused, I think the best thing to do is to provide an explicit pause handling API. Trying to do it automatically, without giving the app a chance to save its data, is asking for data loss.

I've uploaded what I have so far to:

http://code.google.com/p/android-jni-cp ... ndroid-sdl

It's probably best to think of this as a source of ideas, rather than something to be merged directly. It's diverged quite a bit over the course of a weekend - the Java code enforced a lot of policy, so I removed a large chunk of it to make things more flexible, while I was experimenting. (Including important bits, like the onscreen joypad.)

The most important bit is SDLSurfaceView, at:

http://code.google.com/p/android-jni-cp ... eView.java

That is, I think, pretty usable code.

The on-screen keyboard is not much of a problem, I'll try to merge as much as I can from your code.

pelya wrote:I would rather prefer shutting down main and audio threads, so the audio just stops if someone calls you (and that wont' depend on bad application design, because it's handled inside SDL).
For application it will look like a very long SDL_SwapBuffers() call.
You may send SDL_ActiveEvent, but the problem is - you don't know in what order the application will draw things on screen and process events, it may first call SDL_SwapBuffers() - OpenGL context is lost here, then it will draw something without OpenGL context, in the best case it will spam logcat with error messages, in the worst - crash, and only then it will process SDL_ActiveEvent.

Point taken, but still, sending that event would be cool: at least the game can behave as if paused.

pelya wrote:BTW I've added SDL on-screen keyboard interface exposed to the application - check out file SDL_screenkeyboard.h in SDL include dir. It has functions to hide or show overlay buttons, to redefine button coordinates to make it in sync with your app layout, and to bind different SDLKey to each button (except D-Pad).
So basically, you just have to rebind all buttons to what you like at the start of the game, override their coordinates, and hide them until you'll get to the game action screen (I hope 7 buttons will be enough for you).

I'm really not sure of what to do of this. On one hand, having a generic thing to handle this is fine. But with the next touchscreen-based platform, one has to rethink the controls as your work is not available there.

So, I ended adding the strict minimum buttons, and be the one to decide how and when they are displayed. So far, it's just the shoot button. Finer controls would benefit from your work, but it's just too much hassle for the user in the end.

renpytom wrote:Since Android is willing to kill an app while it's paused, I think the best thing to do is to provide an explicit pause handling API. Trying to do it automatically, without giving the app a chance to save its data, is asking for data loss.

+1
Even if it doesn't save its data, at least it can use the information