I am making a game in LibGDX. I have a GameScreen(screen) class where the main gameplay happens. I want use use multithreading so that user can do his/her own thing in the screen and computer does its own thing in the screen (changing the output of the screen at the same time). I have good knowledge of multithreading in java. But with graphics i'm confused. Any help will be appereciated.Thanks in advance.
You can use threading as per usual. Only thing you have to think of is that just as when working with swing only the graphics thread can do graphics operations so if your worker thread needs anything from graphics use the libgdx PostRunnable command.
Rather late but let me clarify something if I can.
Generally on LibGDX you have to be careful with threading.
Having said that, and if you decide you are not interested in html, you could start a thread normally and when you need to change something in the UI you should use Gdx.app.postRunnable() method
For code example and limitations, have a look here https://github.com/libgdx/libgdx/wiki/Threading
As per the page https://github.com/libgdx/libgdx/wiki/Threading , if you're hoping to create an HTML5 version of your game, then you won't be able to use traditional threads:-
JavaScript is inherently single-threaded. As such, threading is
impossible.
Related
this question is more for looking advices
I've developed an almost full user interface in pure c++ and opengl es 2, currently I'm developing that the click/touch events be propagate as in HTML, I can't remember why I decided do a UI in opengl, but now I realize that I'm reinventing the wheel.
so currently I have many "elements", buttons, containers, scrolls, pictures, animated pictures, borders, text, drag-drop's, I can set easily where I want each element, set sounds, and I really don't know how fast and effective it is right now, but I've maked all the fast and memory effective that I can, and I planning to use multi-threading in the future. And my goal is to approach a system like html.
And now that I'm looking for how to implement my UI in native Android (java), I realized that I was in the correct way, all the properties and methods all the structure I'm implementing in c++ and opengl is almost the same as in android, even I think my implementation is easier to use the images and sounds because I've automatized all and I can put it in the assets folder, and in the code only put the name of the file and the program returns it, with and effective memory managment.
the current elements are elements that I need for a game interface, so if I need other kind of element I'd have to write it, but right now, I have all elements that I need, I think so.
maybe my code in c++ is faster than java.
but even with all this, I know I have a lot to do to have a full UI, so can you give some advices or experience, advantages, disadvantages, it worth to continue with the UI, or better learn (beacuse I just know a llitle bit of UI Android) UI Android, modify all my game for use the new arquitecture/system, What do you think?
i am pretty good in android but have not developed any games yet, and have no idea where to kick off.
I have idea of Game in my mind, but i have no idea how to convert that idea into game.
The most big problem i am finding is building UI for that, as i can build backend for the game with my logic but how to interact with games-UI that i new to me and have not done before.
Is there any tool or some kind of help by which i can easily build UI comonents for a game and use them easily in my game creation.
i had read about libgdx for android but i am not sure as using that i have to write code to display even a single point/entity.
Is there any nice, easy and fast way to develop game UI
I have done starter RnD on google but still not much clear with GameUI creation.
Any kind of guidance is appreciated.
Thanks
Aj
What kind of game is it? 2d / 3d graphics? Or just text input (like a chance game or a quiz game?)
UI could mean many things. To some people it's just the menu overlays and other interfaces, like health bars and the like. To others UI is the entire rendering field. Please clarify your terminology in this regard.
If you want to avoid as much code as possible there are libraries that can help. Is there a way you can describe your game by analogy without giving away your secrets? Then we can better assist you.
The right place to ask would be in the gamedevs section of stackexchange, other than that it is a possible duplicate of / related to https://gamedev.stackexchange.com/questions/3401/how-do-i-get-started-making-android-games
I have a Gallery. This Gallery has a lot going on in it and it is slowing down the scrolling effect substantially. Does anyone have any idea as to how to optimize something like this?
The essence of my question is this: How can I make layouts that zip substantially faster than their standard android implementations. Renderscript? NDK? Flash layouts?
Keep in mind I am already caching my views. I know this is a very general question so any and all input is appreciated.
Thanks.
Quite often a sluggish UI is the result of doing a lot of work on the UI thread. I suppose you could double check whether this is the case and consider abstracting non-UI related logic into one or more different theads. E.g. you probably want to avoid fetching large amounts of resources from the SD card or a database on the UI thread. Doing such actions in seperate thread might improve responsiveness, although results will obviously depend on the particulars of your app.
Okay here is what I found from watching just the first several minutes of this video:
http://www.youtube.com/watch?v=v9S5EO7CLjo
I am building my app on 3.1. In the application tag of the Manifest, add the following as an attribute: android:hardwareAccelerated="true". The difference in UI performance is amazing. Thumbs up to Google for this addition to the Android SDK.
What considerations should one be mindful of when constructing a GLSurfaceView-centric UI?
This is for a game and the bulk of the UI will be an intro screen (start, options, about, exit) and a level selector screen. I've put a lot of time into the rendering/animation for the game using OpenGL, and I'm no graphic artist, so taking the OGL UI route seems to make sense to me. But I'm an Android novice and need some outside input. Thanks for reading.
There is nothing wrong with that, especially for a game. The only problem is that you will have to do everything yourself. Most games seem to be doing this.
Due to the ease from which one activity can start another, I would say it is worthwhile to abstract your options and level selection from the game itself. If you're unfamiliar with starting activities and/or passing information between activities, there are plently of good tutorials and examples to help. You could try the ubiquitous Notepad tutorial if you haven't already ( http://developer.android.com/resources/tutorials/notepad/index.html ).
The advantages of this method would be to leave your OpenGL/game Activity less cluttered, and that you would be able to use tried-and-true Android UI elements instead of building your own from scratch.
After a relatively easy coast to simple app coding, I would like to understand better the intricate relationships between various conceptual components in Android.
More specifically, I would like to understand what is Runnable, Looper and Handler.
As you may noticed, the above 3 terms are links to formal documentation in http://developer.android.com so my question may seem strange, so let me explain: That documentation may be perfect for someone who already understands how things work in Android, but I need something that sequentially walks through fundamentals, building on top of previous concepts.
To summarize, I need some sort of tutorial on core inner building blocks of Android. Can you recommend one?
The detailed article Painless Threading is probably your best resource for threading on Android.
The moral of the story is that AsyncTask makes multithreading easier for you.
Runnable is a core Java interface - it represents a code part that can be run (usually by a specific thread).
Handler is an Android class that is responsible for posting a Runnable\Message so that a particular thread will run or process them (in a specific order).
Looper is the structure that holds the Runnable\Message queue that a HandlerThread will read from.