New answers tagged

0

It's probably better to use one surface view. Each GLSurfaceView appears to get its own OpenGL context unless you jump through a bunch of hoops to manually create the context and customize the way each surface creates its context. The practical upshot is that you cannot easily share resources between each view, so you will need to reload textures and ...


0

https://developer.android.com/guide/topics/manifest/supports-screens-element.html we have to add the Screen support in Manifest file..


11

If you're not using Google Play's tools as in Josh's answer (although, I recommend you do use those tools). You'd have to manage this information yourself. You would want to avoid storing something locally on the user's device. Users don't want to have to pay to remove ads per device or per install. You need to maintain a database with users who have ...


28

If you use Google Play's in-app purchase APIs to implement your 'disable ads' purchase, this is basically handled for you. You'll want to create a non-consumable product that users can purchase. Non-consumable products represent, essentially, a permanent benefit or unlock. Such purchases can be restored to wiped/clean/new phones by the user, so they'll never ...


0

If your class implements InputProcessor: @Override public boolean touchDown(int screenX, int screenY, int pointer, int button) { MoveToAction mta = new MoveToAction(); mta.setPosition(screenX, Math.abs(stage.getHeight()-screenY)); mta.setDuration(5f); //moves to new location by this time interval stage.addAction(mta); return false; ...


0

According to this section in the AssetManager page. When Android pauses, then the managed libgdx elements, like Textures, get cleaned up an have to be reloaded when the app resumes. To do this, you call Texture.setAssetManager(manager); and then call update on the asset manager like you did when you first loaded. Secondly, Android apps have no guarantee ...


0

To expand on @user3068350's answer, something like this should work; public class MyGame extends Game { private Stage stage; private Texture myTexture; private TextureRegion myTextureRegion; private TextureRegionDrawable myTexRegionDrawable; private ImageButton button; @Override public void create() { myTexture = new ...


0

A drawable has information about its size and how to draw itself. It's used to determine size and position by ui components. Since you are using a texture, you can use a TextureRegionDrawable. Drawable drawable = new TextureRegionDrawable(new TextureRegion(playTexture); ImageButton playButton = new ImageButton(drawable);


0

Some of the answers here are reasonable for early uses of OpenGL ES on Android. The first GLES devices only supported a single context, so GLSurfaceView was designed to aggressively discard state. Convincing GLSurfaceView to do otherwise isn't easy. For more recent versions of Android (probably anything using GLES 2.x), the best answer is to use a plain ...


1

If you require specific behavior, your best option is to use a plain SurfaceView rather than a GLSurfaceView. GLSurfaceView is just a SurfaceView subclass that handles threading and EGL context management. You can find multiple examples of GLES use with plain SurfaceViews in Grafika, including some handy classes for working with EGL. When OpenGL ES was ...


0

There are a few ways to do this. This is the solution described by poirot: I ultimately achieved what I wanted using the stencil buffer combined with my own shader... The texture drawn to the stencil buffer was an elongated rectangle with rounded corners. The texture drawn to the image buffer was just a stretched red rectangle, which as you can ...


0

It is because your "Ball b" and your ball's collider "Rectangle ball" know nothing about each other. When you update the ball's position with b.update() the rectangle ball stays put. I would make the Rectangle be a member variable of the Ball class and update its position every time the ball's position updates. i.e. if(goal.contains(b.getCollider())


0

Published a sample doing 30FPS using choreographer API. https://github.com/googlesamples/android-ndk/tree/master/choreographer-30fps Does that work for you?


0

My guess is that you have a stray ! in your code. Remove the ! in: if (!Gdx.input.isTouched()) { This is making it so shootToward() is being called when the player is not touching the screen.


0

I use this and it seems to work on different devices. The motion of putting the phone down gives me a value for the delta x of -0.5041921 on a samsung galaxy and a -0.5021868 on a Nexus 5. using UnityEngine; using UnityEngine.UI; public class GyroController : MonoBehaviour { // public Text x, y, z; public Dice dice; public GameManager ...


1

I think you have created many jar files. Combine the two or more jar files into one and give them the same package name. If you get the jar file from Eclipse, create more classes in the same package, and call this package name into your plugin. This will be a better choice.


1

If you want to use sqlite with libGdx you can use opensource project gdx-sqlite . gdx-sqlite is a cross-platform Libgdx extension for SQLite database handling. The extension abstracts database handling to provide a unified method to handle database transacitons across multiple platforms while also adding SQLite support for desktop version of Libgdx ...


2

Look at some free android Java tutorials on youtube or read some from places like code+tuts or mybringback. Nobody is going to hand you code. Guru Raj is right, use lists because they are less of a pain to use and also fetch your words from an external csv file or so. That way you can pull your word library from wikipedia. Then you can pull random words ...


2

You can store the values in a database,It is simple if you use database like sqlite but that wont work with libgdx -android. Instead you can use gdx-sqlite gdx-sqlite is a cross-platform Libgdx extension for SQLite database handling. The extension abstracts databse handling to provide a unified method to handle database transacitons across multiple ...


0

Unity is probably set to build for Android 4.0.3 (or something higher than 2.3.3). You can change this in the Player Settings.


3

Unity remote sends a compressed stream from the editor to your phone and then sends back the inputs from the phone to the editor. there is nothing you can do about it being bad quality. How ever this does not represent the final quality of the build. Try making a real build for android and check how it looks then.



Top 50 recent answers are included