Graphics

I am still working on graphics for menu. Now I actually put some codes. But there are three dreadful problems. First one is that I cannot create ui file. I tried to create ui component inside the asset file, but instead of file, new scrip was created, so I deleted. The second problems is that I cannot input the .pack file. I am watching the Youtube video how to create menu icons.https://www.youtube.com/watch?v=WO52F0M_tio
It is definitely helpful, but because the codes we have and the codes he has are different. So it is hard to compare them and put translate his code to the compatible codes for our program.
The last problems are even though I read through instruction or information, I could not fully understood the difference between atlas and table.
So far I made little progress, but I start getting some concept. This is my code so far, it does not work yet.

Menu Progress

I've been working on adding functionality to the menu buttons. The most recent challenge I encountered was adding a slider for people to adjust the mass of a body. Like the buttons, a Slider is a widget included in scene2d ui. It's relatively simple to use once you get it set up. I found an example on the libgdx website and built mine off that model. Here's the code used to create a slider:

Slider slider = new Slider(min, max, step_size, false, skin);

Here, min and max are the minimum and maximum values of the slider and step_size is the step size in between. For example, if min = 0, max = 10, and step_size = 1, then the values you could get from the slider would be {0, 1, 2, 3, ... , 9, 10}. The fourth parameter (false here) corresponds to whether the slider should be displayed vertically. The skin is the reference to the .json file that determines graphics. The skin object is declared like this:

Skin skin = new Skin(Gdx.files.internal("data/uiskin.json"));

In this same example I found, I navigated to uiskin.json to figure out how this worked. It turns out that it's very similar to CSS. The .json file references the .atlas file that contains information for a .png texture atlas. Basically, the .png file is a big picture with a bunch of small pictures stitched together. The .atlas file tells the program where all of those pictures are using coordinates, dimensions, and angles. Then the .json file has entries that look like the below code snippet that tell the program what pictures should be used for what objects (such as slider elements or buttons).

{

"com.badlogic.gdx.scenes.scene2d.ui.Slider$SliderStyle": {
"default-horizontal": { "background": "default-slider", "knob": "default-slider-knob" },
"default-vertical": { "background": "default-slider", "knob": "default-round-large" }

}

I used this to create a slider that can be used to adjust the mass of a selected body. The slider actually adjusts the radius and then the mass is adjusted accordingly using volume and density. The min and max values of the slider are the respective radii of the MIN_MASS and MAX_MASS constants defined in the main file. The step size is 0.01 so that users can adjust to a fine precision. The skin is currently using the same .png file from the example I found as a temporary placeholder until we make our own graphics to replace it.

Here's a screenshot of the slider. Like before, disregard the yellow and blue lines. Those are temporary and just used for debugging.

The example referred to in this post can be seen here:
https://github.com/libgdx/libgdx/blob/master/tests/gdx-tests/src/com/badlogic/gdx/tests/UITest.java
https://github.com/libgdx/libgdx/tree/master/tests/gdx-tests-android/assets/data
(the second link points to the folder containing uiskin.json, uiskin.png, and uiskin.atlas)

Methods

Today I learned about methods. A method is used to set a behavior for a class. For example with the class person you can create a method to make an object say their name. When writing a method you type (void method_name();{}), with the method_name in lower case. Between the curly brackets you can write code for your method.

After you make your method you can call it in your main class. Since the method has access to the class, you can use the instance variables declared in the class. We can call a method by typing ( name_object.method_name();). Calling a method will run the code in your method.

Below is an example of a method used to calculate the derivative of a function at the point (2,2). First I imported the Math class so I could use it later in my code. Then I made a class called Function with a method productRule. After I created an object called variable, and add data to it. Last I called the method.

import java.lang.Math;

class Function {

     

      int x;

      int y;

      int n;

      int r;

      double derivative;

     

      void productRule(){

            int newn = n-1;

            int newr=r-1;

            derivative = n*Math.pow(x, newn)*Math.pow(y, r)+Math.pow(x,n)*r*Math.pow(y, newr);

            System.out.println("The derivative is: " + derivative);

      }

}

public class Application {

     

      public static void main(String[] args){

            Function variable = new Function();

             variable.x = 2;

             variable.y = 2;

             variable.n = 3;

             variable.r = 3;

             

             variable.productRule();

             

           

           

      }

     

}

     

Putting graphics on the menu bar

Today, I started working on menu graphics. First, I needed to download texture packer tool, and pack all icons or images I am going to use. Unlike putting graphics on the planets, I have to convert the images to .pack files. I have not tried yet, but this is what I understood so far. 

After I convert all the icons or images, I import that file into the program where the button functions are. And I create Skin class and under each button, I define a skin variable by putting the name of the icon. Then the icon will be called from the .pack file.

I am going to try them tomorrow and update how this actually works

Week 4 Progress

Progress

This week we made a lot of progress toward the user interface of the app. One of the first major things we did was implement graphics for the first time. This can be seen in some of the screenshots below as well as some of the earlier posts from this week. We also began working on incorporating an on-screen menu. We’ve created a hierarchical structure with different sub-menus attached to the main menu. Here’s an outline of what that looks like:

• Main Menu
• Add Body Sub-menu
• Add Single Body
• Add Multiple Bodies (matrix)
• Edit Body Sub-menu
• Scale Body
• Change Body’s Velocity
• Change Body’s Orbit
• Make Body Stuck in Place
• Body Info
• Delete Body
• View Options Sub-menu
• Zoom Camera
• Pan Camera
• Reset Camera
• Center Camera on Body
• Settings Sub-menu
• Delete All Bodies
• More Options (Change G, etc…)
• Help
• App Info

      

We just finished putting the menu together on the screen. It works so that when a user taps or clicks the menu button in the bottom right corner, the main menu slides out. Then if they tap the buttons in the main menu corresponding to the different sub-menus, their respective sub-menus slide out above the main menu. This was all done using scene2d.ui tables and button widgets. Information about that can be found in the FAQ on this blog or at these links:

https://github.com/libgdx/libgdx/wiki/Scene2d

https://github.com/libgdx/libgdx/wiki/Scene2d.ui

The second link contains specific information about working with the UI section of scene2d but it is recommended that you review the basics in the first link before visiting the second.

If you’d like to see how we implemented it specifically, our most up-to-date code can be found here:

https://github.com/njwidmann/OrbitGame/tree/master/core/src/com/game/nick/orbit

This is the menu closed. A user can tap menu to have it slide out. The blue lines through the center of the screen are for debugging purposes and won't be present in the final version.

This is the menu opened up. None of the sub-menus are open. Again, disregard the blue lines.

Here's a picture of the menu with one of the sub-menus open. The second row of buttons is the "Edit" sub-menu for editing bodies' properties.

Other Changes

I also found out a much easier way to map the pictures to the bodies. In a post I made a few days ago, I talked about how I needed to create methods to scale from world coordinates to screen coordinates. It turns out though that libgdx sprite batches come with a handy setting called a projection matrix where you can specify a viewport or camera for scale. All I had to do was add the line in bold below to the render loop where the sprites are updated.

public void render(float delta) {

…

… other code not shown ...

...

       batch.begin();

       batch.setProjectionMatrix(camera.combined);

       for(DynamicSprite sprite : sprites) {

           sprite.update();

           sprite.draw(batch);

       }

       batch.end();

…

… other code not shown...

...

}

Then I could make the update() method much simpler in DynamicSprite:

public void update() {

       Vector2 position = getBody().getWorldCenter();

       float radius = getShape().getRadius();

       setSize(radius * 2, radius * 2);

       setPositionCenter(position.x, position.y);

       setOrigin(getWidth() / 2, getHeight() / 2);

       setRotation((float)Math.toDegrees(physicsBody.getAngle()));

}

One more change I made was adding a pause function. This pauses the simulation when people press the P button. In the future, this will also be called whenever the main menu is opened. This was actually really easy and the only thing I had to do was change the time step to 0 inside the render loop:

world.step(TIMESTEP, 6, 2);

You can see all this code in context at the github link above.

Future Plans

The next thing we plan to do is attach functions to all of the buttons in the menu as well as add more graphics. We need to attach graphics to the menu items and also create GUI sliders and arrows and orbit paths for adjusting body properties.

Team Roles

Team roles have continued to be pretty similar. Nick is still doing most of the programming while Ebed and Jiho are focusing on the other main tasks and learning Java. Next week, Jiho and Ebed are going to start doing some more of the programming, starting with adding graphics.

Classes and Objects

Today I learned how to make classes and objects. You must first define your class. Like I explained in earlier post, a class is a blueprint and an object is an instant of that class. In our game an example of a class would be body, and an object of that class would be the sun. When defining a new class you must type class then the name of your class. After that you must define certain aspects of your class. These aspects may include things like mass, density, and velocity. These are called instance variables.

When declaring objects you define those specific values for those instance variables. First you must make a new object by typing (class_name object_name = new class_name()). Just like when you’re making an array you must use the key word new when making an object. After you have created your object you can then define values to your instance variables. Extending the example above, you can make the mass = 34 and the velocity = 9. Below is another example where I made a class called Person with instance variables of age and name. Then I defined those variables for two objects.

class Person{

     

      // Instance variables (data or "state")

      String name;

      int age;

      // Classes can contain

      // 1. Data

      // 2. subroutines (methods)

}

public class Objectsclass {

      public static void main(String[] args) {

            Person person1 = new Person();

            person1.name = "Joe";

            person1.age = 33;

            Person person2 = new Person();

            person2.name = "Sarah";

            person2.age = 67;

            System.out.println(person1.age);

      }

}

Friday meeting

In today's meeting, we talked about getting right limit for the limited speed. Unfortunately, the speed is limited to 120 m/s. We used the potential energy equation and the kinetic energy equation to figure this out. We have rough equation now but we are not sure it will work or not. Nick put graphics on the app and went over the changes in code. He told us about differences between public and private. and differences global and local. Also he told us how the "this" is used in program.

We are going to work on more graphics and finding the limit on the mass. 

The First Real Graphics!

Today, I added the first graphics to the game. To do this, I made a class called DynamicSprite. Basically this "extends" the basic Sprite class that comes with libGDX. I added additional functionality so that we can attach the Body objects to the DynamicSprite objects. Then everytime the main render loop is called, we loop through all the DynamicSprite objects and call each one's update() method. This uses the attached Body object and adopts its properties (position, rotation, and scale) so that the sprite appears correctly on the screen.

Here's the code called in the main render loop inside the GameScreen class:

batch.begin();
for(DynamicSprite sprite : sprites) {
    sprite.update(this);
    sprite.draw(batch);
}
batch.end();

And here's the update() method inside DynamicSprite:

public void update(GameScreen screen) {
    Vector2 position = screen.getScreenPosition(getBody().getWorldCenter());
    float radius = screen.scaleDistanceToScreen(getShape().getRadius());
    setSize(radius * 2, radius * 2);
    setPositionCenter(position.x, position.y);
    setOrigin(getWidth() / 2, getHeight() / 2);
    setRotation((float)Math.toDegrees(physicsBody.getAngle()));

}

One thing you can see in the update() method is a lot of scaling (see lines 2&3). This is because box2D and libGDX uses two different scales. Box2D is in meters and the number of meters on the screen changes depending on the zoom of the camera. LibGDX uses the pixels on the screen. This means that the Body object's position is given and set using the former scale and the Sprite object uses the latter. Because of this, it is necessary to convert the measurements and positions. Here is the method scaleDistanceToScreen() that I wrote in the GameScreen class:


public float scaleDistanceToScreen(float distance) {
    return distance * screenHeight / camera.viewportHeight*(1/getZoom());
}

In this method, "distance" is the values we want to convert from meters to pixels. "screenHeight" is the total height of screen in pixels and camera.viewportHeight*(1/getZoom()) gives us the total height of the screen in meters. The method uses these numbers in a proportion to calculate the "distance" in pixels.


This code can be seen in context here (no promises it will still be there though if you're looking at this far in the future):


https://github.com/njwidmann/OrbitGame/tree/master/core/src/com/game/nick/orbit

Right now there's only one graphic for the bodies. That will change soon.

Arrays

Today I studied arrays. Before explaining what an array is, I want to re-explain defining variables. For example if I want to make a variable that represents an integer, I must type (int variable_name = integer;). The (int) is used to tell the software to make a space big enough to hold an integer in memory.

When defining an array of integers you must type (int[] variable_ name;). Unlike an integer an array of integers doesn’t hold anything, it can only refer to a list of integers in memory. So a variable for an integer is similar to a bucket, but a variable for an array is similar to a label that refers to buckets. When allocating memory to a variable in an array you can use the key word new. This allows you to put a certain amount of place holders in that array. You can then allocate each index separately with an integer.

Another cool thing you can do with array is iterate through it. This can be done using a for loop. One key point to remember when making a for loop. Is that you must go from i=0 to i<array.length. This is necessary, because the index of arrays starts at 0 and ends at one minus the length of the array.

Week4 Lab

In today's lab, we mainly worked graphics. To make the app being able to use in both computer and android phone, several keys/options are needed. We are planning to make keys that can run the functions we implemented, by selecting them. First we brought out some ideas for the rough designs and Jiho started to gather some images to use for graphic, Nick was learning the code for putting images on the program and Ebed was learning Java.
This is the link we used to learn code for graphic.
https://github.com/libgdx/libgdx/wiki/Spritebatch%2C-Textureregions%2C-and-Sprites 

Week 3 Progress

Overview

This week, we made some more progress on the app. We’re still ahead of schedule and on track to finish early.

Progress

We made a lot of progress toward the functionality of the app and made everything much more intuitive. Now, every body can be selected by tapping or clicking on it. After it’s selected, a user can change its size and launch it by pinching and dragging back, respectively. They can also press the “o” button then click on a different body they want the selected body to orbit. They can also press the “f” key to make the camera follow the selected body so that it stays at the center of the screen. A user can click on any empty space (outside of a body) on the screen to deselect the body. Then, they can scroll or pinch to zoom and click and drag to pan. Finally, we added functionality for users to add more planets. They can either press the “n” key to add a new planet on each tap/click or the “m” key to add a (currently 5x5) matrix of planets centered at the tap/click. The latter is useful if someone wants to add a lot of bodies really quickly. Having a large clump of small bodies is useful if you want to model a collision that takes into account destruction of mass. The algorithms for all of these changes can be seen at the below link. This will take you to the main file in our program. The website is our github page that we are using to share the project between computers. The code is well-commented to aid with reader-understanding.

https://github.com/njwidmann/OrbitGame/blob/master/core/src/com/game/nick/orbit/GameScreen.java

Here are some screenshots showing the functionality of the app:

Here, all the smaller bodies have been set to orbit the larger body in the center. Some of the smaller bodies' orbits were thrown off due to the gravity acting between them. This can be seen in the cluster of several of these bodies in the middle of the screen.

All of those clusters were made using the "add body matrix" tool.

Below, you can see a cool application for having many small bodies. As the large bodies break apart they pull the mass of smaller bodies apart like fluid.

Future Plans

Moving forward, we will start adding graphics and user interface. We already have most of the functionality. We just need to start adding buttons for users to click/tap to use that functionality. This will follow a similar design to the concept image we included in last week’s post. Once, we add a user interface with buttons, we can start making sure everything works for the phone's touch screen. For the last couple weeks, we've been focusing on the computer version because we can use the keys to execute commands.

Team Roles

Team roles are still pretty similar to last week. Nick has been doing the majority of the programming. Ebed and Jiho are still learning Java but have started contributing to the programming now that they’re a little more up to speed. They are also still working on graphics and planning. We have all been working together to write in the blog.