Thanks Pelya

In the meantime, i'm trying to play with another sdl project. I do have a problem, i can't get any joystick to work, no joystick overlay is shown on the screen.

Here is my cfg file :

Code: Select all

SdlVideoResize=y
SdlVideoResizeKeepAspect=y
NeedDepthBuffer=n
SwVideoMode=y
AppUsesMouse=n
AppNeedsTwoButtonMouse=n
AppNeedsArrowKeys=n
AppNeedsTextInput=y
AppUsesJoystick=y
AppHandlesJoystickSensitivity=y
AppUsesMultitouch=n
NonBlockingSwapBuffers=n
RedefinedKeys="SPACE RETURN LCTRL LALT SPACE"
AppTouchscreenKeyboardKeysAmount=0
AppTouchscreenKeyboardKeysAmountAutoFire=0
RedefinedKeysScreenKb="SPACE RETURN LCTRL LALT"


And sdl_joystick output :

Code: Select all

I/libSDL  (13818): > display_sdl.c/display_init(): number of joysticks available : 1
I/libSDL  (13818): - joystick  : Android accelerometer/orientation sensor
I/libSDL  (13818): - axes      : 3
I/libSDL  (13818): - buttons   : 0
I/libSDL  (13818): - trackballs: 0
I/libSDL  (13818): - hats      : 0


Thanks for any help

Edit : i did finally get it by enabling on screen keyboard/joystick when launching the application, but is there a way to enable this settings without having the user to manually enable it ?

Edit2 : i just find that we need to uninstall the application from the device to get the new "AndroidAppSettings.cfg" variables to be active. Else, is there a way to define all the variables found in the settings menu manually ? And maybe prevent the user from accessing them ? For example i would need to set the mouse as relative maunally.


Thanks !

That's not intended, I think I'll fix that by sending fake touch event to EditText control.

But did you observe it? I'm using a port of the HTC vkbd to my phone (which isn't an HTC).

Also, what place in a code you have on your mind?

Maybe having a section in the readme could help, but i was more thinking of modifying of modifying the script directly. btw, if you want the echo command to interpret '\n' you should call it with -e (ie echo -ne in your case).

Those keys are defined in ChangeAppSettings.sh, then in SDL_androidinput.h, then used in both SDL_androidinput.c and SDL_touchscreenkeyboard.c. And also you may re-map them through SDL config menu (ChangeAppSettings.sh gives you only 4 most common keys, so if user has unusual key like Camera for example he can make it return some SDL keycode).

Last 4 keycodes are generated when you do multitouch gesture - zoom in/out or rotate left/right, I've decided that it's better to pass them to app as keypress events rather than some obscure joystick or mouse wheel events.

8 is del, 9 is search and 10 is call. Those are mappable buttons afaik, so mapping them to multitouch gesture seems strange to me. Do you mean such key events are generated when a multitouch even occurs? Not that I care in my case, but i would probably prefer to map del/search/call to some actions, and then the multitouch events to something additional.

The double-buffering is not supported in SDL itself, and I think I won't add it because most apps arent' using it anyway. And if by some chance an app properly uses double-buffered SW mode it's much easier to make it HW-accelerated by adding SDL_HWSURFACE flag everywhere, which will give an instant speed gain.

The h/w mode seems now more feasible for me, but I'm wondering... Firstly, I'm currently using sdl_gfx for drawing some shapes (rectangle, antialiased lines, box, polygon, ...) and rotozooming sprites. All of those are interfering with hw surface, and rotozoom can't be emulated using sdl 1.2 (only zooming, no rotation in 1.3) - all of this needs direct use of opengl. Secondly, I'm editing rather often the textures (i divide a map to display into 64x64 tiles which are the ones updated): do you think that might kill performance or is still practical (use of Lock / edit pixels / Unlock) ?

Following your work on this new API: text entry might not yet have text set, so calling SDL_ANDROID_GetScreenKeyboardTextInput will start with garbage. Once edited, the proper text seems to have been inserted, but there is in fact invisible garbage in front of it. And indeed 2nd call for SDL_ANDROID_GetScreenKeyboardTextInput starts with garbage (previous text not yet saved). pressing ok then no longer yields the text actually typed, but another kind of garbage.

I really think a function to initialize its content is needed.

Another note: on my phone, the physical camera button being pressed causes the camera keycode to be generated,g but releasing it generates focus keycode! To avoid disruption, i therefore set it to SDL_KEY(UNKNOWN)

kurosu wrote:Following your work on this new API: text entry might not yet have text set, so calling SDL_ANDROID_GetScreenKeyboardTextInput will start with garbage. Once edited, the proper text seems to have been inserted, but there is in fact invisible garbage in front of it. And indeed 2nd call for SDL_ANDROID_GetScreenKeyboardTextInput starts with garbage (previous text not yet saved). pressing ok then no longer yields the text actually typed, but another kind of garbage.

Did you initialize the output buffer before calling SDL_ANDROID_GetScreenKeyboardTextInput()? (sorry for a stupid question). It uses output buffer also as input for initial EditText control contents, because I didn't like an idea of creating temporary buffer inside SDL just for that - in contrast to that SDL_ANDROID_ToggleScreenKeyboardTextInput() will use only first 255 bytes of initial text, because it has to use a temporary buffer.

kurosu wrote:Another note: on my phone, the physical camera button being pressed causes the camera keycode to be generated,g but releasing it generates focus keycode! To avoid disruption, i therefore set it to SDL_KEY(UNKNOWN)

That's rather a device manufacturer' failure, however I've added a workaround - both keycodes are now attached to the same SDL key. BTW how is it generated? Camera down+up events on keypress, and Focus Down+Up events on release? Or Camera Down, then Focus Up?

Maybe having a section in the readme could help, but i was more thinking of modifying of modifying the script directly. btw, if you want the echo command to interpret '\n' you should call it with -e (ie echo -ne in your case).

8 is del, 9 is search and 10 is call. Those are mappable buttons afaik, so mapping them to multitouch gesture seems strange to me. Do you mean such key events are generated when a multitouch even occurs? Not that I care in my case, but i would probably prefer to map del/search/call to some actions, and then the multitouch events to something additional.

You can bind different keycodes to hardware keys and to on-screen keys (including multitouch gestures) from ChangeAppSettings.sh . The multitouch gestures will return same keycodes as Del, Search and Call only when you not redefine them, or give less than 10 keycodes to ChangeAppSettings.sh.

That's kinda non-obvious, but I'm always accepting patches

The h/w mode seems now more feasible for me, but I'm wondering... Firstly, I'm currently using sdl_gfx for drawing some shapes (rectangle, antialiased lines, box, polygon, ...) and rotozooming sprites. All of those are interfering with hw surface, and rotozoom can't be emulated using sdl 1.2 (only zooming, no rotation in 1.3) - all of this needs direct use of opengl. Secondly, I'm editing rather often the textures (i divide a map to display into 64x64 tiles which are the ones updated): do you think that might kill performance or is still practical (use of Lock / edit pixels / Unlock) ?

If you're updating several small 64x64 tiles per frame it will be faster indeed then updating one big 640x480 texture (that's what SDL does in SW mode), however rotating and zooming is CPU-intensive.
I don't want to give you any false advice, because the effort of making all things HW-accelerated might not be worth the performance gain (and by the time you'll do it everyone will get new fast device that run it comfortably even without acceleration, that's what usually happens ).
Also I'm planning to include support for libjnigraphics, that might give another 10% acceleration for SW-only mode.

cpasjuste wrote:In the meantime, i'm trying to play with another sdl project. I do have a problem, i can't get any joystick to work, no joystick overlay is shown on the screen.

You need both AppNeedsArrowKeys=y and AppUsesJoystick=y for on-screen joystick to be shown by default (also the on-screen joystick will not generate arrow keypresses, only joystick events with AppUsesJoystick=y).

is there a way to define all the variables found in the settings menu manually ? And maybe prevent the user from accessing them ? For example i would need to set the mouse as relative maunally.

Currently no, I'm planning to add some config var to hide selected menu entries from user in the future. But you may always edit Globals.java or Settings.java - all that stuff is inside showConfigMainMenu() method.

pelya wrote:Did you initialize the output buffer before calling SDL_ANDROID_GetScreenKeyboardTextInput()? (sorry for a stupid question).

D'oh! As you could infer from my question and my lack of questioning, I had completely misread the function comment.

Now that i have tested it, it seems like the added text is appended/strcated to the buffer rather than replacing it.
Here's a code snippet to illustrate how i use the feature:

I do get the text i get from GetText(), but when I use "buffer", it contains in fact garbage then the string i want.
One first clue is that SDL_ANDROID_TextInputInit() needs to do "textInputBufferPos = 0;"
However, there's still garbage on the start of the returned string, consisting only of character 0x08.

That's rather a device manufacturer' failure

Once again :/

BTW how is it generated? Camera down+up events on keypress, and Focus Down+Up events on release? Or Camera Down, then Focus Up?

I thought it was separate keycode1 up then keycode2 down, but in fact the 2 are generated at a time: focus (80) then camera (27).

You can bind different keycodes to hardware keys and to on-screen keys (including multitouch gestures) from ChangeAppSettings.sh . The multitouch gestures will return same keycodes as Del, Search and Call only when you not redefine them, or give less than 10 keycodes to ChangeAppSettings.sh.

I was thinking of the multitouch gestures generating by default synthetic keycodes (>110) to really distinguish them from real keypresses, but then indeed, you must find a corresponding empty sdl key to map them. Better let the user do it indeed.

That's kinda non-obvious, but I'm always accepting patches

I'm not yet using multitouch features, but rather distinguish long/short presses. My phone, until recently with user-developped touchscreen driver, wasn't physically able to use multitouch.

If you're updating several small 64x64 tiles per frame it will be faster indeed then updating one big 640x480 texture (that's what SDL does in SW mode)

The ground is even bigger than this, rather around 2000x1500. Doing partial updates would be critical if using hw acceleration, but in our case, with software, it's just a memcpy.

however rotating and zooming is CPU-intensive.

We're not zooming the ground, just sprites (for animation), that are often rather small. Profiling on a Nokia N900 showed zoom+rotation of those sprites (which can be cached) was around 5% of the run time.

I don't want to give you any false advice, because the effort of making all things HW-accelerated might not be worth the performance gain (and by the time you'll do it everyone will get new fast device that run it comfortably even without acceleration, that's what usually happens ).

In fact, I had the dream of having our graphical code ported to opengles as it would allow zooming on the ground. But indeed, the game is already fast on fast recent devices. Galaxy S/Tab (and N900) are nearing max refresh, but supposedly fast devices are very slow (some htc phones, nexus 1). I was suspecting a lot the gfx<-cpu transfert (and thus why i wanted it to be done separately from game code)

Also I'm planning to include support for libjnigraphics, that might give another 10% acceleration for SW-only mode.

I don't really know what to expect of this, and alas, I don't have any 2.2 phone to test it on (and they would probably be powerful enough).

kurosu wrote:However, there's still garbage on the start of the returned string, consisting only of character 0x08.

D'oh, that's our friend the ASCII backspace! If we filter the non-printable ascii characters in UnicodeToUtf8 by doing:
it now works.

See my changes here

Thanks for the report pleya. Else i'm thinking that it would be usefull to be able to activate/deactivate the on screen pad/buttons on the fly, maybe a special key (F13 ?). I'm actually playing with some emulator and some require sometime a mouse and sometime a pad. Setting the "Menu" key to "F13" for example would allow to show/dissmis the pad and be able to use both without problems.

Hehe, looking at the code it seems my open pandora sdl 1.3 port was usefull to someone at least :p

Edit : I also wonder how your guys are handling controls. I noticed that if we use the on screen dpad (direction) + one button at the same time, the last "direction" touched on the dpad is still active until we release the on screen button. Do i need to set "useMultiTouch" and handle the buttons differently ?

hi guys,

I want to add a admob , but it seems that when the admob view is added in the framelayout, the touch event only been transfered to GLsurfaceView rather than the admob view. can't make a click event for the admob view.

Is anyone have success for this? thanks in advance .here is the code

Code: Select all

      _videoLayout = new FrameLayout(this);
      
      mGLView = new DemoGLSurfaceView(this);
      _videoLayout.addView(mGLView, new LayoutParams(LayoutParams.FILL_PARENT,
LayoutParams.FILL_PARENT));
      _videoLayout.addView(adView, new LayoutParams(LayoutParams.WRAP_CONTENT
, LayoutParams.WRAP_CONTENT));
      mGLView.setFocusableInTouchMode(true);
      mGLView.setFocusable(true);
                adView.requestFreshAd();
      setContentView(_videoLayout,
            new LayoutParams(LayoutParams.FILL_PARENT, LayoutParams.FILL_PARENT));
      mGLView.requestFocus();



You should also change Mainactivity.dispatchTouchEvent() - check that touch event coordinates are inside AdMob rect and dispatch them to AdMob layout instead of mGLView.
Someone already requested support for advertising in SDL, would be nice if you'll submit your code if it will work for you.

I have now tested the moving to background. It works, but that's somewhat luck, as it's not happening as intended. In particular I'm not receiving any SDL_ACTIVEEVENT event.

Here's the logcat during a lock screen/unlock screen cycle related to this:
D/PhoneWindow( 7345): couldn't save which view has focus because the focused view org.warmux.DemoGLSurfaceView@4403e178 has no id.
V/SDL ( 7345): GLSurfaceView_SDL::onPause()
I/libSDL ( 7345): OpenGL context recreated, sending SDL_ACTIVEEVENT

It's not well paired; as far as i see, I should have received SDL_ACTIVEEVENT loss, but we never went through nativeGlContextRecreated: i don't have a line in logcat saying ""OpenGL context lost, waiting for new OpenGL context".

But GLSurfaceView_SDL::onPause() is properly called. It sets mPaused to true. Contrary to all functions around it, it doesn't have a notify() call, don't know if that matters but I thought it might be worth noting. I guess onSurfaceDestroyed() is never called, but I have no idea why.

pelya, could you shed some light on this?

kurosu wrote:SDL_ANDROID_TextInputInit() needs to do "textInputBufferPos = 0;"

pelya, I think you missed that part with the fix commited 1 day ago.

Fixed that, thanks.
I'll check the SDL_ACTIVEEVENT, I wrote some support code but never tested it.
Also libjnigraphics is reported to work on some 2.1 devices, so I'll let user to enable/disable it.

pelya wrote:Also libjnigraphics is reported to work on some 2.1 devices, so I'll let user to enable/disable it.

Could be worthwhile, as it seems 2.1 devices are suffering unduly. Since I upgraded my spica to a custom rom mixing froyo and eclair, i improved my framerate by ~30%; there are further speed improvements i did in my own code, but nexus one under gingerbread is now twice faster, so it's most likely the android innards that improved a lot.

I have tested latest version (commit 5a91ed9723e1eb49a6d7). I do receive the SDL_ACTIVEEVENT event with gain=0 and state=7 (ie SDL_APPMOUSEFOCUS|SDL_APPINPUTFOCUS|SDL_APPACTIVE), which is good: I do enter my pause handling loop. Here's the log of what occurs on the lock:

Code: Select all

V/SDL     ( 5210): GLSurfaceView_SDL::onPause()
[some random logcat]
I/libSDL  ( 5210): OpenGL context lost, waiting for new OpenGL context
V/SDL     ( 5210): GLSurfaceView_SDL::EglHelper::finish(): destroying GL context
I/        ( 5210): libGLESv1_CM_fimg.so was unloaded and GLES 1.1 API was succes
sfully unmapped
I/warmux  ( 5210): Pause: entering, state=7
I/warmux  ( 5210): Dropping event 24
D/dalvikvm( 1949): GC freed 5386 objects / 319824 bytes in 149ms
D/LockScreen( 1949): onResume emer button : MotionEvent=MotionEvent{443da2a8 action=2 x=-60.0 y=-100.0 pressure=1.0 size=1.0}

The SDL_USEREVENT is our doing, but deactivating its creation doesn't help.

Unfortunately, on power button resume, I receive:

Code: Select all

D/LockScreen( 1949): onResume emer button : MotionEvent=MotionEvent{44154458 action=2 x=-60.0 y=-100.0 pressure=1.0 size=1.0}
V/SDL     ( 5210): GLSurfaceView_SDL::onResume()
[some key events as I'm unlocking screen]
I/warmux  ( 5210): Dropping event 4
I/warmux  ( 5210): Dropping event 5
I/warmux  ( 5210): Dropping event 4

I'm not getting any SDL_ACTIVEEVENT event at all (even less with gain=1 which would unstuck me). I'm consequently stuck into my pause handling loop, where I drop any event not of type SDL_ACTIVEEVENT. The display remains black until I see:
W/SurfaceFlinger( 1949): timeout expired mFreezeDisplay=0, mFreezeCount=1
I then get my game display, but of course it still considers itself stuck in the inactive state.

Here are the (afaik) relevant part of Globals.java:


I have therefore 2 requests:
- of course, could you fix that? I don't understand why I'm getting an image after a while with no opengl context supposedly recreated
- when is the active event sent? on power button resume or screen unlock? the second would be better