Hello,

With the last version of git, and the SDL-1.3, the video resize option in AppAndroid.cfg seem not to work anymore.
- is this version stable ?
- how to put it back ? I looked at SDL_VIDEO_RENDER_RESIZE and the previous diff. But the merging, though it compiles, did not work ?

Any clues ?
Is this adviced to use the sdl-1.3 ? They are progressively moving to 2.0

Thanks,
sb

Hi,

I have simple SDL app using 32-bit bpp (both in AndroidAppSettings.cfg and SDL_SetVideoMode),
But it seems the result is incorrect compared to PC version. It seems mapped colors are lesser or
incorrect than 16-bit bpp.

How can I fix it ?

Here is my code:

confi wrote:the multitouch works fine when the touching points are moving, but is it possible to detect taps of the fingers on the screen? for instance if I just touch the screen with two fingers without moving them relatively to the plan of the screen (perpendicular touch on the screen if you prefer) only one of the touch is detected as a mouse event

Can you please try to download some multitouch test from Market, and confirm that it works better than SDL? It might as well be the issue with your device touchscreen or drivers. Also, you may wish to add some debug output to the function MultiTouchInput.process() inside project/java/Video.java:166, to see the touch events Android OS is sending to the SDL.

With the last version of git, and the SDL-1.3, the video resize option in AppAndroid.cfg seem not to work anymore.

I've merged with latest SDL 1.3 codebase from libsdl.org at December, and there were too many changes in it to stick my custom videoresize hack. So now it's very much like the official SDL 1.3, although a bit more stable and with an optional mouse events support. The latest commit with the old SDL 1.3 codebase and videoresize support is 2fe92bdcf . SDL 1.2 still has all the features, I've updated only SDL 1.3.
I cannot tell you anything about the stability, I've compiled the GemRB with SDL 1.3, and it ran without issues, however I did not test it extensively.

I have simple SDL app using 32-bit bpp (both in AndroidAppSettings.cfg and SDL_SetVideoMode),
But it seems the result is incorrect compared to PC version. It seems mapped colors are lesser or
incorrect than 16-bit bpp.

It was the bug in SDL, and I've fixed it, please update your repository. If you'll be using software video mode you'd better use 24bpp, it's faster, and you have no use for an alpha channel for the main video surface anyway.

Hello Pelya,

Thank for the answer.
Another question to clarify.
I want to use the touch-screen (only 1 finger).

Here's what I use :

SDL-1.3 + "motion + get finger" API -> Works fines (but no more video resize)
SDL-1.2 + "the AppUsesMouse=y" -> Works, but it seems "button down" is sent at the same time that "button up" appear.

SDL-1.2 + "the multitouch" -> Then, one needs to use the SDL_JOYSTICK. The drawback, is that one gets one event for each coordinate... Can we be sure that we get always X, then Y ?

is there any other way to receive a "one finger touchscreen interaction" ?

thanks,

/sb

The mosue in SDL 1.2 is emulated - the user may choose between different modes, like magnifying glass etc, and you won't get the raw touch coordinates in general (most ported apps don't need them anyway).
Joystick "multitouch" events with SDL 1.2 always come in burst of 4 - X coord, Y coord, touch force and touchpoint radius (although touch force is almost always constant for my device). The relevant code is in SDL_androidinput.c:440.

You are correct that this API is inconsistent, so I've added another API - SDL will send a touch position as an SDL_JOYBALLMOTION for a first joystick, which includes both X and Y coordinates and touch pointer index in a single event, and touch down/up events as a SDL_JOYBUTTONDOWN/SDL_JOYBUTTONUP for a first joystick, so there is no need to open up 16 joysticks to support 16-finger input (are there devices which support more pointers? I've heard about 10 touch points max).
IT will also send the touch force, using the SDL_JOYAXISMOTION event, with axis = touch pointer ID + 3, because the first 3 axes are used by accelerometer. It's not very consistent, but most of the time you don't need the touch pressure at all, so you can just ignore this event.
You may also receive SDL_JOYBALLMOTION without prior SDL_JOYBUTTONDOWN event, this usually means that the device has USB or Bluetooth mouse plugged.
You may wish to look into an updated example at project/jni/application/testmultitouch/example.cpp

Do you guys have any idea of the following behaviour with 32bit colors.

As a prerequisite, I'm using SDL 1.2 only for creating the surface for OpenGL, loading the textures from png-files and then uploading with glTexImage2D. Drawing is done with OpenGL draw-functions.

Two different cases:
Case 1. 32bit colors specified in both AndroidAppSettings.cfg and SDL_SetVideoMode-function call.
Case 2. 16bit colors specified in AndroidAppSettings.cfg and 32bit colors specified in SDL_SetVideoMode-function call.

On case 1 everything loads correctly. But when OpenGL draws the textures, colors are distorted (somehow brown tinted) also they seem to be zoomed(!?). When checking logcat it shows that the GL-config chooser chose a RGBA8888-surface.

On case 2 everything loads and works correctly. Logcat shows that the GL-config chooser chose a RGB565-surface. Nevertheless the textures are being uploaded (with glTexImage2D) as RGBA8888 and are clearly drawn as RGBA8888 too (you can see the difference between 16bit vs 32bit if there are textures with gradients).

So the big question is: Why is it possible to draw an 32bit (RGBA8888) texture correctly on a 16bit (RGB565) surface? Is this universal or is it my device only (ZTE Blade with and 2.2)?

You can upload textures in any format you want, as per OpenGL docs, they will be converted to the pixel format of your display by your GFX hardware on the fly (so it's fast).
Anyway, that should depend on your GFX hardware and drivers, however allocating 16-bit screen surface and drawing 32-bit textures witohut any loss of quality sounds like voodoo magic to me. That's not entirely impossible though - some devices may have the physical screen supporting only 65536 colors, and still support 32-bit color depth programmatically (they have to, because GLES spec requires that), so you won't notice any difference between 16 and 32 bits. Other devices might report that they've allocated 16-bit videosurface, but process everything in 32 bit, and you will newer know that happening, because with OpenGL you don't access the underlying screen buffer, you're just issuing commands to the GFX processor and it does all the work. So your device may give you some fake values, and do all processing in 32 bits underneath, and it's perfectly valid behavior.
Anyway, I think this behavior you are describing is device-specific. The only thing I might help you with is run your test app on my HTC Evo, if you'll post it somewhere.

Thanks for clearance.. sounds strange indeed.

I created a test based on opengl-hello. It's attached here. There are also two screenshots of the same texture loaded in rgb565 mode and rgba8888 mode. You can see the artefacts on rgb565 when you zoom a bit (or without zooming if you have good eyes . The texture is only 3 channels(rgb), so without alpha.

You can change the uploading mode between rgb565/rgba8888 from the .cpp. I guess you know how, but anyway there are some comments. I also tried between 16/32 of SDL_SetVideoMode, but it doesn't seem to affect anything. Only thing that seems to affect is how the texture is uploaded (by glTexImage2d).

The relevant data from logcat:

Code: Select all

V/SDL     (16723): GLSurfaceView_SDL::EGLConfigChooser::chooseConfig(): selected 0: R5G6B5A0 depth 0 stencil 0 type 7 (GLES GLES2 OPENVG) caveat none nr 0 pos 1
V/SDL     (16723): GLSurfaceView_SDL::EglHelper::createSurface(): creating GL context
I/libSDL  (16723): SDL_SetVideoMode(): application requested mode 800x480 OpenGL 2 HW 0 BPP 16


Hellom


A question, though it works on a few phones, the nexus Samsung does not receive the input key for
the "back" button.

I expect either :
(evt.type == SDL_KEYDOWN && evt.key.keysym.sym == SDLK_ESCAPE)
OR
(evt.type == SDL_QUIT)

Am I right ?

-> when the back button is pressed, it gives a "vibration", but the game does not react (it should only exit!)
this is not my phone and I cannot investigate it ...

Any idea ?


/sb

That seems to be the upward-compatibility issue, see this post. Seems like you can fix that by setting the compilation target to Gingerbread, which will enable compatibility mode - set the targetSdkVersion to 10 in the file project/AndroidManifest.xml, then run command
android update project -p project -t android-10
however you'll get some minor errors in Java files, you can fix them by commenting out code which uses MotionEvent.ACTION_HOVER_MOVE.
I'll add proper support for the on-screen buttons when I'll have some free time (that's probably will be another setting inside AndroidAppSettings.cfg, whether to show those buttons at all or not, also it seems like you can add your own custom buttons there).

Hello,

Maybe I did not explain correctly :
- on the Samsung Nexus-S (1 one year old) : the back button does not work (only it vibrates). It's not soft buttons, but real buttons I guess. (maybe I am wrong with the terminology).

- on the (new) Galaxy Nexus : it works, it is soft buttons.

Another problem:
- on the Samsung Nexus-S : the home button goes back to the desktop (correct), but when the application go back to the foreground it hangs on the "SDL logo" with "starting" message.

Any Idea.

Question :
- If I put the targetSdlVersion to 10, It is going to reduce the scope of device I can use to app on ?
(I use min sdk = 4, et target=12, and I run the project with -t android-12)

Thanks for your help,

/sb

If I put the targetSdlVersion to 10, It is going to reduce the scope of device I can use to app on

No, it will work on all newest devices, you just won't receive movement events from the USB/bluetooth mouse, if you'll plug it into your device, mouse clicks will still be received.

- on the Samsung Nexus-S : the home button goes back to the desktop (correct), but when the application go back to the foreground it hangs on the "SDL logo" with "starting" message.

Can you get a logcat output? It's unlikely that I'll get any Nexus S device into my hands anytime soon, so I won't be able to reproduce.
What graphics mode are you using (SDL with software buffer, SDH with HW acceleration, OpenGL inside SDL)? Could you please try to run some other SDL apps on that device, like Free Heroes 2, or GemRB? I've updated them rather recently.

I created a test based on opengl-hello. It's attached here.

I've run the test on my HTC Evo, and attached the resulting screenshots (I've made them using DDMS). when I'm setting BPP to 16, my device seems to draw to 16-bpp internal memory buffer, then output the video to 24-bpp screen surface with dithering. I've created a simple gradient image with vertical strip lines, and if you open the file device-2012-02-10-182023-16bpp.png with any image editor and use a color picker tool you'll see that the color values change across the vertical axis, and they do not change in the original image and in the 32-bpp screenshot.
So I conclude the behavior you've described is device-dependent.

Hello,

Thanks, I'll try.

I use:
SetVideoMode
With = 480, Height = 800, Bpp = 16, and Flag = SDL_SWSURFACE

I use no OpenGL in my code (but the SDL internal does?)

Thanks,

/sb

Hello,

It seems that setting targetSdkVersion to 10, both solve the "back button" issue and the foreground/background problem.
Thanks.

/sb

I am certainly doing something wrong, I still cannot compile the SDL library under eclipse IDE using WindowsXP. I get compile errors from SDL_render_gles.c and SDL_render_gles.h