Helping Yourself

Please go through this short checklist to be sure you haven’t missed an easy to find solution.

  • Are you using the latest nightly build? Please try that first, as issues are being fixed every single day.
  • Have you read the documentation on the ? It can also be very helpful to look at the Javadocs and (don’t be shy!). Search the tests for a specific class to find example code.
  • Have you for your problem?
  • Have you searched the issue tracker for your problem? Be sure to search “All issues”, not just “Open issues”.

If you still have a problem, the way to get help is the . There are a lot of active users, any one of which could answer your question right now.

Otherwise, if you wish to post a new issue on the , keep reading.

Help Us Help You

If you believe your issue, error, or suspected bug is related to a specific backend, please present the following information with your issue. If you are on the Discord/IRC have the following information on hand.

For Android backend issues

  • Note: Android issues can sometimes be more difficult due to device manufactures breaking things or buggy drivers.

  • Note 2: libGDX only works completely on the Android Runtime (ART) on devices running the Android L developer preview and higher. Some functions will not work on the ART builds in 4.4.x due to an issue in ART that was fixed and included in the L developer preview.

  • Please have the device name and Android version in the bug report. Providing things won’t be broken, we will make an attempt to fix the issue or implement a workaround for the device.

For Desktop backend issues (LWJGL 2 & 3)

  • Please list the operating system and version, architecture, and if necessary OpenGL version.
  • Also mark specifically which of those backends have this issue.
  • Please list the iOS version, and device the issue occurs on

For GWT (WebGL) backend issues

  • Please list the operating system and version, and architecture.

Title

Write a clear and short title. Titles that do not describe the issue (such as “please help”) or contain all caps, exclamation marks, etc. make it much less likely that your issue will be read.

Describe what you are trying to achieve. If it might help your question get answered, also explain the reasons why. If specific solutions are unacceptable, list them and why.

Try to keep the information relevant. If you aren’t sure, include the extra information but if your text gets very long, provide an executive summary separate from the rest.

Problem Statement

Concisely describe the problem. Describe each approach you have tried and, for each of those, explain what you expected and what actually happened.

If you fail to do this, likely you will be ignored. No one wants to guess what your problem is and often they don’t have the time or patience to ask for the information you should have included from the start.

Exceptions

If an exception occurred, include the full exception message and stack-trace.

Often the first line number just after the deepest (nearest to the bottom) exception message is most relevant. If this line is in your code, along with the full exception message and stack-trace you should include your code for this line and 1-2 surrounding lines.

Code Snippets

Code snippets are most often not very useful. Unless you are blatantly misusing the API, most problems cannot be solved just by looking at a code snippet. Code snippets mostly lead to vague guesses at what might be wrong instead of a real answer to your question. Instead, include executable example code.

Creating executable example code does take some time. You need to take apart your application and reconstruct the relevant parts in a new, barebones application that shows the problem. Quite often just by doing this you will figure out the problem. If not, you will get help very quickly and the people helping you will have more time to help more people.

Example code should be contained entirely in a single class (use static member classes if needed) and executable, meaning it has a main method and can simply be copied, pasted, and run. Do not use a GdxTest, as that cannot be copy, pasted, and run.

For more about how to make executable example code, please see and MCVE.

Often executable examples need some resources, such as an image or sound file. It is extra work for those trying to help if they must download your specific resources. Instead, it is ideal to use resources from the . This enables your example code to be simply pasted into the project and run.

The easiest way to write an executable example is to paste one of the barebones applications below into the gdx-tests-lwjgl project and then modify it to show your problem, using only the test resources. Note the test resources are pulled in by from the gdx-tests-android project.

Below is a simple, barebones, executable application. This can be used as a base for creating your own executable example code.

This barebones application uses SpriteBatch to draw an image from the project.

This barebones application has a Stage and uses scene2d.ui to draw a label and a button. It uses the from the gdx-tests-lwjgl project.

Actually Executable

If your executable example cannot be pasted into the project and run, then it is not actually an executable example. Others should not have to fix up your code to run it, not even to add a main method.

Attitude

Formatting

If you spend a little bit of your time to format your post nicely, it is more likely others will spend their time responding to your post. This means capital letters where appropriate, paragraphs to separate ideas, use actual words (rather than “u”, “bcoz”, etc), put code in code blocks, etc. If English is not your first language, we understand. No need to apologize, just do your best to make an effort.