I'm using OpenGL ES on android 2.3.3 at the minute to render a simple 3D game. I'd like to extend it using the built in gestures library, but I can't find a way to recognise the gestures from a GLSurfaceView as opposed to an android view(I don't have an XML layout is what I'm saying)
Is there any way to either implement an XML layout on top of what I have already, or preferably to implement the gestures library on top of the GLSurfaceview instead.
Thanks.
You can attach a normal onTouchListener to GLSurfaceView, so long as you have an instance of GLSurfaceView (which it sounds like is what you have). This is only really useful if you just want to know the raw x,y coordinates on screen where the user has pressed (e.g to rotate around the y if the user moves their finger left/right across the screen)
For gesture library, which I haven't used myself, you should be able to just place your GLSurfaceView inside a frame layout and then place another view (e.g. linear layout set to match_parent) in the same frame layout so that it completely covers the GLSurfaceView and is on top of it. Attach the gesture library to this view (and obviously make sure it is transparent so people can still see the GLSurfaceView below).
The gesture library has a way of 'stealing' events from the view. See here for details.
Here, here, and here are some examples that should make it clearer.
Related
My idea is to have two surfaceViews. One surfaceView which will hold an image (say ImageSurgaceView) and second surface that lie on top of the first one which holds the annotations (say AnnotationSurfaceView) like circle, rectangle etc. Now I have to map these surface views such that the height, width are same and moreover, both the surface view should move on drag i.e share the touch events. To be precise, when I move the image up the annotations should also move up.
Now, I am not sure if this is possible in android. Can any one tell or share some info on this. I don't have any implementation idea to this and hence I don't have any specific code. Moreover, I couldn't find anything similar.
Thanks for helping.
Yes, this is possible. You can add both SurfaceViews as children of a FrameLayout. You will also want to call setZOrderMediaOverlay on one or both of your SufaceViews in order to specify how they are layered.
Furthermore, this could be a graphic intensive algorithm you are describing. Consider adding the AndroidManifest.xml application attribute android:hardwareAccelerated="true".
Finally, just set up a custom OnTouchListener to handle drag events. Use MotionEvent.getRawX() and MotionEvent.getRawY() to get the touch point, and use this to manipulate the canvases.
I am developing an Auto-cad App in OpenGLES2.0 in Android.
I want to add the panning functionality.
That's how I achieve this pan function:
[Pan Functionality -- just drag the GLSurfaceview to top, bottom,left and right side using touch event].
I need to add a Scrollable View in GLSurfaceview in android.
When I try to add a scroll view in GLSurfaceView, it will not work.
Then, also I tried to add GLSurfaceview in to the ScrollView.
This method also does not work.
Please suggest me some sample code.
I have some game pawns on a screen inside of a RelativeLayout. When the user clicks the pawn I would like then to be able to drag it under there finger. I have the MotionEvent captured but can't seem to find how to adjust the orion of the pawn.
I've seen posts saying to adjust the margin but that seems questionable. I still want to do hit tests for the pawns after they've been moved and don't understand how to work with the margins in that case.
thanks!
I would recommend not using a Relative Layout at all.
A Canvas is a much better option
Or if you really want to use a layout, possibly an AbsoluteLayout is a better option
Using a layout for a game may prove unsatisfactory as you proceed. I can recommend using the free and open source game engine AndeEngine for making 2D games. The problems you have with collision detection and x,y positioning are trivially easy to implement with it. I've made 2 games and a visualization view within an app with is so far.
Check it out here:http://www.andengine.org/
You can download the demo app to your android device and see its out-of-the-box capabilities. (They include Sprites, sound, animation and more.)
This one game I made with it.
https://market.android.com/details?id=com.plonzogame&hl=en
I am working on a project that involves painting on images.
To delete the unwanted lines or curves i have to draw a border and X button to delete it.
I have a relative layout where i have the freehand drawing canvas. on edit mode i should make them as u see in the pic, where i have to create button on a varying x,y positions.
i am confused how to achieve this.
Thanks in advance.
Jana.
I suggest doing this manually rather than using the Button widget. Override the onTouchEvent on the view holding your painting and use MotionEvent.getX and MotionEvent.getY in combination with MotionEvent.getAction to determine behaviour when the user touches the 'button'. Skipping widget creation will improve performance and open up doors to other types of functionality.
You could use the deprecated AbsoluteLayout container for this or keep the RelativeLayout and use layoutMargins to set the location of the buttons. The former is the route you should take despite the container being deprecated as the later breaks the layout paradigm by misusing margins...
You should keep in mind that there are a variety of devices with different screen sizes and setting explicit, pixel based locations is going to be awkward.
I have a FrameLayout containing first a SurfaceView, and second a RelativeLayout which in turn contians various Buttons and TextViews.
Upon the canvas of the SurfaceView I am drawing numerous Bitmaps, and, via Touch and Motion Events am allowing the user to drag them around.
These Bitmaps, when dragged around pass underneath the Buttons etc that are inside the RelativeLayout.
Now, it's my (possibly mistaken) understanding that the "Z-level" of the SurfaceView, or whatever it has that passes for it, is entirely unrelated to the actual Z-level of the rest of the Layout. Is this the case? If so, how may I get around it, so that dragged Bitmaps are drawn ontop of other Views? Or what other way can I implement a full-screen canvas and yet not have my buttons etc act like the controls of an overlay.
I guess what I actually need is an underlay, where touch events can still be picked up by the Buttons etc underneath. But I don't know how to achieve this, as, when redrawing my Canvas, I have to also redraw the background.
Can I swap the order of the RelativeLayout and the SurfaceView inside the FrameLayout, and then make the background of the Canvas transparent? If so how? Will touch events still "fall through" to the buttons underneath?
Thanks for bearing with me, I know I'm a bit of a waffler.
SurfaceView doesn't work that way.
SurfaceView has two parts, the "view" part and the "surface" part. The "view" part is a transparent hole that is laid out with the other view elements, and composited onto the view layer. The "surface" part is a completely separate layer that will be positioned and scaled to match the "view" part, and composited by the system compositor rather than the app.
You can control the Z-order of the "surface" layer when the SurfaceView is first created, but it's going to be above or below all View elements. It can't go above some Views and below others because they're completely independent layers. The "surface" layer does not catch input events, so having it on top (via SurfaceView#setZOrderOnTop()) doesn't affect input focus.
For API 14+, you can use a TextureView, which behaves in a more View-friendly way.
Edit: for full details, see the much longer explanation.
Can you clarify a little bit more? In your SurfaceView do you have a background assigned? If not, you could probably also use AbsoluteView if your intention is to simply drag pieces around. If there is no background, you should be able to place the entire view above the RelativeView that you have and only have the various Buttons and such drawn on the view on top, which would be draggable and remain above everything else.