in my game id like to have some interface at the bottom of the screen,
like XP bar, health status etc.
should i create a custom XML view to hold game SurfaceView (to draw the game) and
SurfaceView to draw interface and then share data between two classes
(one huge frame layout for game drawing, and smaller frame layout for interface)
or draw the interface directly on the game canvas?
I would split the interface up in several smaller custom views (probably inheriting from imageview, or progress-bar for the xp-bar) and then put it all in a relative layout. And have the relative and the gameview in a frameview.
Related
I have a dynamic loaded fragment inside the activity. The fragment contains one SurfaceView in the bottom and it contains some text image. I used ExploreByTouchHelper for Talkback. It can read the context but can't draw the green square on SurfaceView. But if the activity contains some components(like buttons) below this SurfaceView then the green square can be drawn.
So it seems that the Application doesn't know that the space on screen for SurfaceView belongs to this Application. If some components added below, only then it knows that itself owns that space.
So anything I can do to get this green square back?
Many thanks.
It seems that SurfaceView by default will not enable drawing on it's surface so the talkback can't draw on it's surface. To enable this you have to call setWillNotDraw(false).
I would like to display the score when user click on a button (make +1 fly to top of the screen) and I wonder if it is better to use a surfaceview or view?
See here for more information on the differences between SurfaceView and View.
For your case, View would probably be simpler and appropriate.
If your application does not require a significant amount of processing or frame-rate speed (perhaps for a chess game, a snake game, or another slowly-animated application), then you should consider creating a custom View component and drawing with a Canvas in View.onDraw(). The most convenient aspect of doing so is that the Android framework will provide you with a pre-defined Canvas to which you will place your drawing calls.
A SurfaceView, on the other hand, is not drawn on the main thread and instead takes place on a secondary thread:
The SurfaceView is a special subclass of View that offers a dedicated drawing surface within the View hierarchy. The aim is to offer this drawing surface to an application's secondary thread, so that the application isn't required to wait until the system's View hierarchy is ready to draw. Instead, a secondary thread that has reference to a SurfaceView can draw to its own Canvas at its own pace.
I think view fits this scenario better. You could translate a view to the top of the screen.
So far, I've only used SurfaceView for rendering background graphics. Of course you could do it using SurfaceView, but that would bring more complexity in terms of coding. You need to draw this "+1" and calculate its position from frame to frame.
Using a View, you could just apply an animation, set the duration, and that should do the trick.
I have a simple app with graphics moving about on a canvas, implemented in a surfaceview, i.e. not using an xml layout.
Is there an easy way to use the camera preview as the background?
You could use a FrameLayout and put first your surfaceView as a child and then some other view with no/transparent background.
A FrameLayout draws its children in the order of adding.
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.
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.