If you extend Game class, then just call setScreen(). It’ll call hide() on current screen, change reference, and call show() on new set screen. Your homework is make sure you do right thing on show(0 and hide().
On show() you’ll of course just need to prepare the content. On hide(), if each of your Screen child classes have individual disposable classes, dispose them.
When using tables you’ll never have to do pixel math for layout, so you’ll never even notice that things are y-up. Of course when rendering something inside an actor it is y-up.
On table I just adjust the align, expand, and number of rows 
can someone clear this up for me … if im going to be displaying a splash screen then the menu then the game/map (tmx file)
do i need to use the assets manager for everything?
https://code.google.com/p/libgdx/wiki/AssetManager
scene2d for the UI/HUD and maybe screen transitions,
https://code.google.com/p/libgdx/wiki/scene2d
and the tween engine for screen transitions (unless theres a better option)
https://code.google.com/p/java-universal-tween-engine/
is there a better way to display the splash screen cause right now all i did was slap my splash image in with the default code that comes with useing the setup-UI for libgdx
i bet theres a million different ways of displaying the splash screen but what would be the best way to go about it
i seen some videos on youtube where people put the splash image in with the sprites and game images in texture packer and they load it up like that but idk if mixing it with the game sprites would be a good idea :-\
btw has anyone out there actually finished a 2d game?
You definitely don’t have to use AssetManager, and I don’t see any problems with putting the splash screen image in the texture atlas, however you should probably stick to Textures while you’re developing your game to avoid the hassle of repacking your image all the time.
https://github.com/drabiter/magnet (REMEMBER, it’s old version not the published one. You should keep downloading my game! arggh!)
No AssetManager, the game logic is pretty buggy but the structure is so F simple to understand
@ Jimmt if i dont use assets manager i have to manually dispose of stuff right? so wouldn’t it be better to use it
@rebirth i couldn’t get your game to run i got two warnings :clue:
Description Resource Path Location Type
The serializable class does not declare a static final serialVersionUID field of type long LRUCache.java /Magnet/src/com/coffeefury/magnet/utils line 29 Java Problem
Build path specifies execution environment JavaSE-1.6. There are no JREs installed in the workspace that are strictly compatible with this environment. Magnet Build path JRE System Library Problem
@anyone who wants to reply
i managed to get a tiled map loaded on screen ;D
but how do i set the collisions for tiles and spawn a character
and how can i activate/call another java file/method sorry i dont know the right terminology
[quote]Build path specifies execution environment JavaSE-1.6. There are no JREs installed in the workspace that are strictly compatible with this environment.
[/quote]
Are you sure there is 1.6 installed?
i only have 1.7
C:\Users\cm>java -version
java version “1.7.0_17”
Java™ SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot™ 64-Bit Server VM (build 23.7-b01, mixed mode)
i tried installing Java SE Runtime Environment 6u43 cause theres no 1.6
only these
Java SE
Java SE 7
Java SE 6
Java SE 5
Java SE 1.4
Java SE 1.3
Java SE 1.2
Java SE 1.1
That’s odd. I compiled it with 1.7.
Mah, there’s download link if you want to play the game but what most important is for you to learn from the code structure. It shouldn’t have error on syntax/build, just runtime problem.
yea i was going through the code … its kinda the only thing i been doing lately since i started messing with libgdx since i’m still trying to understand how people make everything work and i think i kinda get it except for when everything is split up like the code is put into different files how do you make it run the file you want
like in magnet.java
setScreen(getMenuScreen());
this part would mean its going to use the menuscreen.java file right?
how do you go from one to another to another
You can see that my MenuScreen, (and all of my screens instance since they’re child class of AbstractScreen), holds reference to the main class (Magnet). This main class is the only one who can change screen. Inside MenuScreen, I just call game.setScreen(game.getXXXScreen()) to move on. With this structure, you will have solid structure that Game child class acts as the backbone, holding one screen reference who has different visual and logic.
why not just put all that stuff from AbstractScreen into the main?
Because that makes no sense to me. In my newer version I move every asset creation in AbstractScreen to new class, call it Factory. Basically main class should only do screen managements and holding reference to singleton-candidate classes like AssetManager, sound, music, etc.
i guess that does make sense is that how everyone else does it?
im not that far yet in my game to actually do that(well im not really sure how or when to try that) im barely learning how to place the buttons on screen
i have the splash screen fadeing in and out (with tween engine) and it should be triggering the menu screen next but i’m trying to figure out whether to use scene2d table layout and virtual viewport and skins but i’m starting to feel overwhelmed i dont know how to use any of this stuff yet :persecutioncomplex: im still digging through examples and wiki and what not
do you think i should use a class for this like you did with AbstractScreen or should i use it for the actual game when i load up controls sounds and stuff?
Mine is just example. Ofc all is up to you 
seems like everyone else is doing the abstractScreen thing i seen it on a few blogs now didn’t know what it was before 
for the menus i been doing some research into it and i think it goes something like this
(correct me if im wrong)
scene2d uses table layout (to set up the table you can use the tablelayout editor) and skin is for the UI buttons and widgets but to use skin you need to have the following stuff from here https://github.com/libgdx/libgdx/tree/master/tests/gdx-tests-android/assets/data
uiskin.json
uiskin.atlas
uiskin.png
could probably make the atlas with texture packer then change a few things in the uiskin.json file… thats if you need both or maybe you only need one of the two? ???
that part kind confused me … second paragraph under overview and the resource section from this link
https://code.google.com/p/libgdx/wiki/Skin
there used to be a skin packer but it has disappeared off the face of the earth :o (deprecated maybe?)
https://code.google.com/p/libgdx-users/wiki/SkinPacker
anyway closest thing i could find to a tutorial was steigert’s blog
)theres a few examples at the bottom of this link
https://code.google.com/p/libgdx/wiki/scene2dui#Widgets
so all this boils down to scene2d 
who would have guessed so many things go into makeing it work
so am i right or wrong? 8)
@hellrazer21: The problem with the TableLayout DSL (Domain Specific Language) is, that it has been deprecated
I hate Nate for doing that :cranky:
Would have been so nice with the DSL… :emo:
More info and general TableLayout tutorials here:
Documentation of the ‘old’ Version 1 TableLayout (with the DSL): https://code.google.com/p/table-layout/wiki/V1Documentation
Documentation of the new TableLayout: https://code.google.com/p/table-layout/
so all this time i spent looking around :persecutioncomplex: was a big waste of time >:(
wheres the rage face when u need it :cranky: … :point: lol
what about MTX it seems legit 8)
MTX looks like it would do the trick since scene2d only does buttons MTX seems like it can handle the resizeing the screen and aspect ratios and stuff
I hate the libgdx-users project. It is not maintained and way out of date. It makes people think all the libgdx documentation is out of date. We don’t control the libgdx-users and it is not official. It even says on its homepage that that libgdx-users is obsolete. I wish they would take it down.
You might try the official docs. This should be all you need:
https://code.google.com/p/libgdx/wiki/scene2d
https://code.google.com/p/libgdx/wiki/scene2dui
https://code.google.com/p/libgdx/wiki/Skin
http://code.google.com/p/table-layout/
http://code.google.com/p/libgdx/wiki/TexturePacker
Yeah, it’s too bad about the DSL. In practice with apps of any complexity, you end up needing code in the middle of your layout stuff. Then your options are 1) generate some DSL from code (nasty!), 2) do some layout in the DSL and the rest in code, 3) rewrite your whole layout in code. I found myself doing 3 far too often. Method chaining makes the Java API not too bad. It still has the problem of hiding the hierarchy. What I do to mitigate that is to create all the widgets before hand, then create and populate any nested tables, then assemble it all in the layout. Separating the layout code from the creation code makes it easy to see the layout.