hellrazer21
|
 |
«
Reply #30 - Posted
2013-04-24 06:58:20 » |
|
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
|
|
|
|
ReBirth
|
 |
«
Reply #31 - Posted
2013-04-24 10:48:02 » |
|
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.
|
|
|
|
hellrazer21
|
 |
«
Reply #32 - Posted
2013-04-25 21:20:39 » |
|
why not just put all that stuff from AbstractScreen into the main?
|
|
|
|
Games published by our own members! Check 'em out!
|
|
ReBirth
|
 |
«
Reply #33 - Posted
2013-04-25 23:38:33 » |
|
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.
|
|
|
|
hellrazer21
|
 |
«
Reply #34 - Posted
2013-04-26 06:37:24 » |
|
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  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?
|
|
|
|
ReBirth
|
 |
«
Reply #35 - Posted
2013-04-27 02:20:01 » |
|
Mine is just example. Ofc all is up to you 
|
|
|
|
hellrazer21
|
 |
«
Reply #36 - Posted
2013-04-27 20:12:38 » |
|
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/datauiskin.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/Skinthere used to be a skin packer but it has disappeared off the face of the earth  (deprecated maybe?) https://code.google.com/p/libgdx-users/wiki/SkinPackeranyway closest thing i could find to a tutorial was steigert's blog http://steigert.blogspot.com/2012/03/4-libgdx-tutorial-tablelayout.htmlan important part that he mentions is when useing the tablelayout editor to save the code in a txt file (i was looking for a save button  like a dumbass for a few minutes till i read his blog ... theres no save button in tablelayout-editor  ) "Now we should save this layout descriptor inside our resources folder. I saved it under: tyrian-android/assets/layout-descriptors/menu-screen.txt " theres a few examples at the bottom of this link https://code.google.com/p/libgdx/wiki/scene2dui#Widgetsso all this boils down to scene2d  who would have guessed so many things go into makeing it work so am i right or wrong? 
|
|
|
|
|
hellrazer21
|
 |
«
Reply #38 - Posted
2013-04-27 21:19:21 » |
|
so all this time i spent looking around  was a big waste of time  wheres the rage face when u need it  ...  lol what about MTX it seems legit http://moribitotechx.blogspot.co.uk/p/what-is-mtx.htmlMTX 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
|
|
|
|
Nate
|
 |
«
Reply #39 - Posted
2013-04-27 21:45:28 » |
|
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/scene2dhttps://code.google.com/p/libgdx/wiki/scene2duihttps://code.google.com/p/libgdx/wiki/Skinhttp://code.google.com/p/table-layout/http://code.google.com/p/libgdx/wiki/TexturePackerYeah, 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.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
|
Nate
|
 |
«
Reply #41 - Posted
2013-04-27 22:14:25 » |
|
Hmm, that is from the old build server, Mario still probably has access there.
|
|
|
|
hellrazer21
|
 |
«
Reply #42 - Posted
2013-04-28 01:38:41 » |
|
so the tablelayout-editor is the only thing i shouldn't use everything else is ok ?
|
|
|
|
matheus23
|
 |
«
Reply #43 - Posted
2013-04-28 09:13:13 » |
|
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.
The Idea of the DSL for me was not to write the DSL inside my .java files, but actually have them lying outside in layout files. I'd call them .tbl or .lay then. Or simply .txt, but the point is: My goal was to write a little nashorn javascript magic inside the DSL, pre-parse the DSL to separate the Javascript stuff from the DSL stuff and then make it be the 'Model' and 'Component' part of the MVC pattern, the 'View' part being in java code. The goal was not to create 10 classes for all of my layouts. The real goal was to have something, where I don't have to write any code anymore for writing a game. But that is only fiction 
|
|
|
|
hellrazer21
|
 |
«
Reply #44 - Posted
2013-04-28 18:26:55 » |
|
MTX uses a ton of classes just for a fancy menu but you gotta admit its really nice
|
|
|
|
matheus23
|
 |
«
Reply #45 - Posted
2013-04-28 20:45:16 » |
|
MTX uses a ton of classes just for a fancy menu but you gotta admit its really nice
Whats MTX? Googleing doesn't help that much there... <edit> To add a little bit to what I said: In my opinion, code should not represent Data, but data should represent Data, and code should be the abstract Structure of the Data. In other words: Classes are Button types, the table layout, the Label, the ScrollPane, etc., but not my "MenuScreen" or "SplashScreen". Since those classes would (almost) only contain data. </edit>
|
|
|
|
hellrazer21
|
 |
«
Reply #46 - Posted
2013-04-28 22:40:17 » |
|
MTX is something for making menus, haven't looked into too much but it looks interesting http://moribitotechx.blogspot.co.uk/p/what-is-mtx.html someone told me about it in another forum when i was asking "how do you make your menus" i think the guy that told me about it, is the same guy that made MTX
|
|
|
|
Nate
|
 |
«
Reply #47 - Posted
2013-04-29 15:23:21 » |
|
The Idea of the DSL for me was not to write the DSL inside my .java files, but actually have them lying outside in layout files. I'd call them .tbl or .lay then. Or simply .txt, but the point is: My goal was to write a little nashorn javascript magic inside the DSL, pre-parse the DSL to separate the Javascript stuff from the DSL stuff and then make it be the 'Model' and 'Component' part of the MVC pattern, the 'View' part being in java code.
The DSL works fine to describe your layout, until you need some code to generate layout. JavaScript could help there, but I would rather all my code be in Java for debugging, type safety, refactoring, etc. Ultimately it is better to do layout in Java, just need a nice API and to separate widget creation from layout.  MTX is built on top of scene2d, AFAIK. I haven't look at it much so can't comment.
|
|
|
|
matheus23
|
 |
«
Reply #48 - Posted
2013-04-29 15:29:07 » |
|
The Idea of the DSL for me was not to write the DSL inside my .java files, but actually have them lying outside in layout files. I'd call them .tbl or .lay then. Or simply .txt, but the point is: My goal was to write a little nashorn javascript magic inside the DSL, pre-parse the DSL to separate the Javascript stuff from the DSL stuff and then make it be the 'Model' and 'Component' part of the MVC pattern, the 'View' part being in java code.
The DSL works fine to describe your layout, until you need some code to generate layout. JavaScript could help there, but I would rather all my code be in Java for debugging, type safety, refactoring, etc. Ultimately it is better to do layout in Java, just need a nice API and to separate widget creation from layout.  MTX is built on top of scene2d, AFAIK. I haven't look at it much so can't comment. Nice to live in the same Time Zone now  Javascript was more or less only an example. Also it's always a personal preference. Why deprecate the DSL, if you could make your library a little bit more awesome?  Yes. I read the Article about the deprecation. But maybe the DSL just needed to be tweaked a little? maybe... The Idea I had was to actually use Scala for scripting. It's incredibly easy and I know how it works. And It's typed. Also, Javascript might be un-typed, but (I quote) "then it's less 'typing'"  It's a scripting language, so it should be suited for such kind of thing.
|
|
|
|
Nate
|
 |
«
Reply #49 - Posted
2013-04-29 15:41:23 » |
|
Aye, I'm in Croatia.  I'm not too interested in Scala, but dragging around the runtime would be inconvenient. The DSL was cool but increased the complexity of the lib. The biggest reason to dump it is that its goal was to make complex layouts easier and to expose their hierarchy. What actually happened was the DSL could only be used for simple layouts. Anything complex had to be written in code anyway. This means it was the wrong tool for the job. I don't see how it could have been saved. Turns out the Java API is quite easy to use.
|
|
|
|
|
heisenbergman
|
 |
«
Reply #51 - Posted
2013-04-30 09:50:21 » |
|
I'm keeping tabs on this thread since I'll be jumping into libgdx as well  Looking forward to the exchange of information. Reading the whole thread as been enlightening so far.
|
|
|
|
ReBirth
|
 |
«
Reply #52 - Posted
2013-04-30 10:59:23 » |
|
FYI mostly Test classes on libgdx official repo is kinda outdated. For example test classes that use ShapeRenderer, there're some unknown enum members. Refer to Nate's link, it has very complete guides. http://code.google.com/p/table-layout/And it'll be better to post the error.
|
|
|
|
isteinvids
|
 |
«
Reply #53 - Posted
2013-04-30 11:26:52 » |
|
Start by creating a class ;DDD
|
|
|
|
|
|
matheus23
|
 |
«
Reply #56 - Posted
2013-05-01 19:59:29 » |
|
What error? These are simple warnings (even less than warnings).
|
|
|
|
Jimmt
|
 |
«
Reply #57 - Posted
2013-05-01 21:45:29 » |
|
You might want to learn simple java first if you think those are errors... 
|
|
|
|
ReBirth
|
 |
«
Reply #58 - Posted
2013-05-02 01:40:32 » |
|
Nothing wrong on code, although you forget the @Override on listeners' methods.
|
|
|
|
hellrazer21
|
 |
«
Reply #59 - Posted
2013-05-02 01:56:28 » |
|
lol my bad its cause every time i see something under the problems tab i always just think to my self its an error i'll be more specific next time  so what am i missing cause when i do the quick fix it just tell me to get rid of those lines an with or without them i still dont get anything on screen im just running that class by itself heres what shows up on the console tab http://pastebin.java-gaming.org/22e40386354Nothing wrong on code, although you forget the @Override on listeners' methods.
where exactly do i put it ?
|
|
|
|
|