I have a screen in my LibGDX game that will be essentially two columns, the first being 75% of the real estate and containing labels/buttons, and the next being 25% that will contain text and images. It is pretty complicated to include all of the code directly in the screen itself for this.
What I would like to do is to have one object contain the logic for the left side of the screen, and one for the right. This would be similar to ASP.NET, where I have a page, with one user control for the left content, and one for the right.
How can this be setup in a LibGDX screen?
I recommend you use scene2D and create new class for each element.
For example, you can create one class that extends Group for each side. Then you can add a ClickListener to group or to each Actor of the group with your logic.
Actually there are alot of ways you could do this. You can handle the events yourself by checking the if something is touched and if so, you do handle it yourself by the position.
On the other side you can use the scene2D system by creating Actors inside of a Stage and set the inputprocessor to the stage. In that case every event is given to the actors and if its inside of his bounds he does handle it depending on the implemented way (Take a look at this: ActionListenes).
So in your case you could create 2 Actors which are invisible
and everyone of it has its side.
You could also use the Button
from libgdx and use this without a background/foreground or such. Simply set the right sizes and make it invisible by the alpha or no background.
or you do check in every cycle of the gameloop if something is touched and if so you do handle the event as you whish. Take a look at this: input polling and creating an input processor
Related
I would like to achieve the following behavior:
Draw a scrollable world map of x*y tiles. Draw a given part of this map inside a dialog window (using the class Dialog). Pretty much the way Transport Tycoon enabled you to see a little part of the world inside a dialog window: https://wiki.openttd.org/images/7/76/Speed-limits.png.
You can be anywhere on the map, but still see the train, plane or any object inside the dialog window.
I am currently clueless about a smart way to achieve this. My current thought can be broken down to using two stages: one for the world and for the UI. I can then draw the Map onto the world stage. But according to this: Is it possible in LibGDX's `scene2d` API to have the same Actor instance in multiple Stages? I cannot simply add the Map or any Actor to another stage because it will be removed from the previous stage.
So I am wondering: What is the most intelligent way to solve this? Is there one? Do I miss something essential here? Thank you for any answer!
I am trying to get something like this:
I want a UI windows and in the center of window I want to display my world.
I want to use scene2D and scene2D.ui with an Orthographic camera.
Any advice?
Edit: I know that I must use two stages in order get a ui and world windows but I don't know how I can tell to the world window stage that render its content in that section instead all screen.
There are two ways you can go about.
Use a CustomViewPort for the stage responsible for rendering world. It is fairly easy to use and example is given in the wiki.
Let it be rendered on entire screen. This way you could keep UI backgroundless and space between components would be filled by world itself. It might be considered more immersive by many. You would also be allowed to use semi-transparent UI this way.
Anyways, it's a matter of taste.
Hope it helps.
I have an application that is a Maths Game for kids. Since I'm in college, I've usually only had a god object for all my past projects but for this applciation I've split my code into multiple classes:
MathsGame.java: main class which initialises components and constructs and controls the UI.
DiffScreen.java: contains methods for use on the difficulty selection screen.
GameScreen.java: contains methods for use on the game screen.
EndGameScreen.java: contains methods for use on the end game screen.
MigJPanel.java: extends JPanel and sets layout to MigLayout and adds a matte border.
Each screen that the 3 XScreen classes control is simply an instance of MigJPanel and screens are switched to using a CardPanel container JPanel.
I'm wondering how I can divide my code to each class so that they are properly abstracted but I'm not entirely sure how to approach this.
Should my 3 screen classes be extending from my MigJPanel so these then can be instantiated?
So instead of having my DiffScreen, GameScreen, and EndGameScreen classes solely containing methods related to each screen which are then called from MathsGame, each screen will control itself within its own class.
If yes to the previous question, should the UI components for each screen be made inside that screen's class?
At the moment, all components for each of the three screens are created in my MathsGame constructor. This makes the connection between a screen and the class which 'controls' (I use this word very lightly at the moment) it even further apart. So each screen is just an instance of MigJPanel whose components are constructed in MathsGame. The only relation the EndGameScreen class—for example—has to the End Game screen is that when the MathsGame causes the End Game Screen to be displayed, anything done there makes a method in EndGameScreen be called from MathsGame.
I hope I explained myself well. If not, leave a comment and I'll clarify. Any help would be greatly appreciated!
Yes
Yes.
Focus on self containment and maintain areas of responsibility. It is the responsibility of each UI screen to manage it's content, no one else, in fact, you should guard against allowing unrestricted modification to these components and provide access only through managed methods indirectly (setters and getters), which allow the modification of the properties you want to be changed, and not simply providing the component via a getter, this prevents problems with people removing components you don't want removed, for example.
You could also use interfaces to maintain common functionality if required, so if the MathsGame really only wants to deal with a certain amount of the information/functionality, you can use an interface that all the other screens use which will simplify the process, as the MathsGame only needs to know about the class that implement the interface and not EVERY thing else that might be going on...as a suggestion..
Also, where should I put the code for switching between screens?
From my perspective, it's the responsibility of the MathsGame game to determine when and to which screen should be shown. What I would normally do, is provide some kind of notification process that the current screen can ask the MathsGame to switch screens, maybe via a listener or other agreeded interface. This would mean that each screen would need reference to MathsGame.
Instead of passing it (MathsGame) directly, I'd create an interface that MathsGame would implement (say NavigationController), which defined the calls/contract that each sub screen could use (nextScreen/previousScreen) for example.
Take a look at Model-View-Controller for more ideas
I am attempting to create a a java GUI for use on Zedboard with the 7" touchscreen display. The GUI I am creating is supposed to mimic exactly (though scaled down) a physical console with many interactive buttons.
My question is what would be the best method in making the buttons interactive, my first thought was to cut out the buttons of the console and have each one a separate image that can be set as interactive, but I feel there may be another simpler method.
Thanks
LDY
For the console mimicking, you could take an image of the entire console and then listen to touch event at specific points in the image which corresponds to a button. Based on where the touch event occurs, you could do different actions.
For this you need to get the coordinates of the touch event and check if it corresponds to any of the buttons on the console.
I'm creating a standalone SWT desktop application that has around 10 different screens (few wizards, help, forms, etc). Some elements on screen don't change at all (like header, background, etc) and there is a working area that changes depending on what is clicked, etc.
What is the best way to manage application screens? Do I need to create all screen at startup and then show/hide them depending on what is clicked? Or do I need to create those screens dynamically?
Also, I couldn't find any way to show/hide a Composite, do I need to dispose it and then create again?
What is the best practice? I'm new to SWT developing outside of Eclipse so any help would be beneficial.
Deciding whether to create screens up front or creating them the first time they need to be displayed is a decision that needs to be made on a per application basis. If there is a good chance that all the screens are going to need to be used on a particular application run and the number of screens is low (10 screens is relatively low) then you may want to create them at application startup so the UI is snappier once the application loads.
If you use bindings then you may need to come up with a dispose strategy (even if you only dispose the bindings) so you don't have too many events flying around.
Control has a setVisible(boolean) method (and Composite inherits from Control) which you can use to show and hide a component. Note this will only prevent the composite from being shown on the screen, the layout manager will still allocate a blank space for it. Many SWT layouts have a way to exclude a control from the layout which will get rid of the blank space. For example if you are using GridLayout then you would set the exclude variable on you GridData object to true when you hide that control.
Another option is to use StackLayout. This lets you stack a bunch of Composites on top of each other and then choose which on is on top. This might be a good fit for you if you have static areas plus a working area like you described. I would put the header, footer, and an empty composite with a StackLayout in a class file. I would then put each screen that will be displayed in the working area in their own classes. You can either have these screen classes extend Composite and then set up themselves in the constructor or you can use a factory method to setup the screen. Either one is a common and acceptable practice and comes down to a matter of taste.