Develop Reference

Rotating Coordinates (Java and Geometry)

I am working on a 2D java game engine using AWT canvas as a basis. Part of this game engine is that it needs to have hitboxes with collision. Not just the built in rectangles (tried that system already) but I need my own Hitbox class because I need more functionality. So I made one, supports circular and 4-sided polygon shaped hitboxes. The way the hitbox class is setup is that it uses four coordinate points to serve as the 4 corner vertices that connect to form a rectangle. Lines are draw connecting the points and these are the lines that are used to detect intersections with other hitboxes. But I now have a problem: rotation.
There are two possibilities for a box hitbox, it can just be four coordinate points, or it can be 4 coordinate points attached to a gameobject. The difference is that the former is just 4 coordinates based on 0,0 as the ordin while the attached to gameobject stores offsets in the coordinates rather than raw location data, so (-100,-100) for example represents the location of the host gameobject but 100 pixels to the left, and 100 pixels up.
Online I found a formula for rotating points about the origin. Since Gameobject based hitboxes were centered around a particular point, I figured that would be the best option to try it on. This code runs each tick to update a player character's hitbox
//creates a rectangle hitbox around this gameobject
int width = getWidth();
int height = getHeight();
Coordinate[] verts = new Coordinate[4]; //corners of hitbox. topLeft, topRight, bottomLeft, bottomRight
verts[0] = new Coordinate(-width / 2, -height / 2);
verts[1] = new Coordinate(width / 2, -height / 2);
verts[2] = new Coordinate(-width / 2, height / 2);
verts[3] = new Coordinate(width / 2, height / 2);
//now go through each coordinate and adjust it for rotation
for(Coordinate c : verts){
if(!name.startsWith("Player"))return; //this is here so only the player character is tested
double theta = Math.toRadians(rotation);
c.x = (int)(c.x*Math.cos(theta)-c.y*Math.sin(theta));
c.y = (int)(c.x*Math.sin(theta)+c.y*Math.cos(theta));
}
getHitbox().vertices = verts;
I appologize for poor video quality but this is what the results of the above are: https://www.youtube.com/watch?v=dF5k-Yb4hvE
All related classes are found here: https://github.com/joey101937/2DTemplate/tree/master/src/Framework
edit: The desired effect is for the box outline to follow the character in a circle while maintaining aspect ratio as seen here: https://www.youtube.com/watch?v=HlvXQrfazhA . The current system uses the code above, the effect of which can be seen above in the previous video link. How should I modify the four 2D coordinates to maintain relative aspect ratio throughout a rotation about a point?
current rotation system is the following:
x = x*Cos(theta) - y *Sin(theta)
y = x*Sin(theta) + y *Cos(theta)
where theta is degree of rotation in raidians

You made classic mistake:
c.x = (int)(c.x*Math.cos(theta)-c.y*Math.sin(theta));
c.y = (int)(c.x*Math.sin(theta)+c.y*Math.cos(theta));
In the second line you use modified value of c.x. Just remember tempx = c.x
before calculations and use it.
tempx = c.x;
c.x = (int)(tempx*Math.cos(theta)-c.y*Math.sin(theta));
c.y = (int)(tempx*Math.sin(theta)+c.y*Math.cos(theta));
Another issue: rounding coordinates after each rotation causes distortions and shrinking after some rotations. It would be wise to store coordinates in floats and round them only for output, or remember starting values and apply rotation by accumulated angle to them.

Libgdx's World Units

I've been trying to learn libgdx a little but now i'm kinda confused about world units there that i don't even know what exact question i should be asking.
Anyway, i've been reading this example game code here
and from what i understand, when there's no camera, SpriteBatch renders everything in relation to device resolution, so pixels, but when we make a camera, set it's "size", position and then use batch.setProjectionMatrix(camera.combined), batch translates pixels to units and then it knows where to render , but in this game there's collision detection between Rectangle objects, and when you're setting position of this Rectangle with rect.set(x, y, 1, 1); where x and y are world units and not pixels, how does rectangle know if it should use those x and y as units and not as pixels if there's nothing used like setProjectionMatrix to let it know that now we're working in units and not in pixels, and then there's this 1, 1); at the end, is it in units too? if so, then how does Rectangle know how big those units shoud be (Scale in game is 1 / 16 for example) renderer = new OrthogonalTiledMapRenderer(map, 1 / 16f);.
I don't even know if this question really makes sense, but that's where i'm at and i'm really lost here
EDIT: Ok, i understand how units work now, but collision still confuses me a bit, here's example, i created this
// onCreate
mapSprite = new Sprite(new Texture(Gdx.files.internal("space.png")));
planetTexture = new Texture(Gdx.files.internal("planet.png"));
shapeRenderer = new ShapeRenderer();
//Planet(X,Y,Radius)
planet = new Planet(20, 30, 7);
planet2 = new Planet(70, 50, 8);
circle = new Circle(planet.getPosition().x + planet.radius, planet.getPosition().y + planet.radius, planet.radius);
circle2 = new Circle(planet2.getPosition().x + planet2.radius, planet2.getPosition().y + planet2.radius, planet2.radius);
mapSprite.setPosition(0,0);
mapSprite.setSize(133, 100);
stateTime = 0;
camera = new OrthographicCamera();
camera.setToOrtho(false, 133, 100);
camera.position.set(133 /2, 100 /2, 0);
camera.update();
batch = new SpriteBatch();
...
// Render Method
batch.setProjectionMatrix(camera.combined);
batch.begin();
mapSprite.draw(batch);
batch.draw(planetTexture, planet.getPosition().x, planet.getPosition().y, planet.radius * 2, planet.radius * 2);
batch.draw(planetTexture, planet2.getPosition().x, planet2.getPosition().y, planet2.radius * 2, planet2.radius * 2);
batch.end();
shapeRenderer.setProjectionMatrix(camera.combined);
shapeRenderer.setColor(Color.RED);
shapeRenderer.begin(ShapeRenderer.ShapeType.Filled);
shapeRenderer.circle(circle.x, circle.y, circle.radius + 1);
shapeRenderer.end();
And everything renders fine, the ShapeRenderer circle is where it's supposed to be after setting ShapeRenderer's projection matrix shapeRenderer.setProjectionMatrix(camera.combined) :
But, i still don't understand how to check collision on this circle, when i do this in render method and press on the circle nothing is happening, like i don't get that log and i assume that's because the circle doesn't know the world scale (no nothing like setprojectionmatrix ) and render coordinates and where the actual circle "thinks" it is don't match. How do i check collision on that circle?
if(Gdx.input.justTouched()) {
if(circle.contains(Gdx.input.getX(), Gdx.input.getY())) {
Gdx.app.log("SCREEN", "TOUCHED AND CONTAINS");
}
}
EDIT2: I get it now, everything works, i just wasn't using camera.unproject on touch coordinates

Imagine you have a device 1200 x 800 pixel big.
Now you say you will have a box2d rectangle on position: 100, 100 and size: 100,100
When you now use your SpriteBatch (Box2dDebugRenderer) to render this you will see a world 1200 x 800 units big. You must try to forget to think in pixels. Important is that the SpriteBatch always draw 1200 x 800 pixels but not always 1200 x 800 units, later more.
So this is what you see:
When we now use a Camera we say we will only our world of 600 x 400 units.
We create a Camera with size: 600 x 400 units!
camera = new OrthographicCamera(600, 400);
The batch still draw 1200 x 800 units and 1200 x 800 pixels
Now with batch.setProjectionMatrix(camera.combined); you give the batch a Matrix to calculate the size of a unit. With this Matrix he can calculate how big it musst draw 1 unit.
And after that the SpriteBatch draw 600 x 400 units but still 1200 x 800 pixels.
And then you see:
For this reason you can forget to think in pixels the Matrix of camera makes the calculation for you from pixel to units and you can focus on thinking in units.
The next thing why you must think in units is that box2D calculates in meters. So the rectangle is 100 x 100 meters big and 100 meter above the bottom. So by gravity of g = 9,81m/s the rectangle falls not so fast as you might expect.
The SpriteBatch always draw 1200 x 800 pixels otherwise you only see the game on the half of your screen. But with the Matrix of camera the batch know how many pixel he must draw 1 unit and so you see a World of 600 x 400 units on a Screen of 1200 x 800 pixels.
Attention: 1 unit is not always equal 1 meter. For example in a spaceship game there are for example 5 kilometre between two ships. So please don't create a World of 10000 x 10000 units because Box2d won't calculate that.
Then you can say 1 unit = 100 meter, so you have a World of 100 x 100 units.
Now you must remember when a ship should be 200 m/s fast you must set body.setLinearVelocity(2,0) because 1 unit = 100 meter.
So always think in units!
Edit:
Sometimes we do not come around pixel for example Gdx.input
Gdx.input return the position in pixel.
Now our camera have two methods to convert from pos in pixel to pos of our units and vice versa.
float x = Gdx.input.getX();
float y = Gdx.input.getY();
camera.unproject(new Vector3(x, y, 0));//this converts a Vector3 position of pixels to a Vector3 position of units
camera.project(new Vector3(10,10,0));//this converts a Vector3 position of units to a Vector3 position of pixels
I hope I could help you

When rendering things using a camera, you should be setting the projection matrix of the sprite batch to the combined view of the camera.
The world is completely separate from the camera. The world has coordinates both positive and negative. The camera is your view of the world, and like a literal camera, it can move around in space. When you move the game camera, you are merely changing what part of the world you can see.
All physics is done on pixel level (in your case) relative to the world origin. It is not changed in any way by the camera.

How to set Abitrary Units properly?

I'm currently working on a game where you have to avoid asteroids. I started to use arbitrary units.
public final static int WIDTH = 100, HEIGHT = 100;
Additionally, I'm using an OrthographicCamera:
float aspectratio = 16/10;
cam = new OrthographicCamera(100, 100 * aspectratio);
cam.position.set(cam.viewportWidth / 2f, cam.viewportHeight / 2f, 0);
cam.update();
In the game screen, the asteroids look deformed:

That's a problem of your Viewport. Have a look at this page. For example, you can use a FitViewport that scales your game as much as possible to fit the screen, but there may be black bars.

Your aspect is off. Notice your planets aren't round either. Your viewport is 500x400, which is a 5:4 aspect, you want 16:10 aspect.
Try changing
cam = new OrthographicCamera(500, 250 * aspectratio);
to
cam = new OrthographicCamera(500 * aspectratio, 500);
that will give you a viewport of 800x500, or 16:10 aspect

Why doesn't simply scaling things up in LibGDX and Box2D work correctly?

I'm trying to get rid of having to scale all the coordinates on my sprites when using Box2D and LibGDX.
Here are the settings for my viewport and physics world:
// Used to create an Extend Viewport
public static final int MIN_WIDTH = 480;
public static final int MIN_HEIGHT = 800;
// Used to scale all sprite's coordinates
public static final float PIXELS_TO_METERS = 100f;
// Used with physics world.
public static final float GRAVITY = -9.8f;
public static final float IMPULSE = 0.15f;
world.setGravity(new Vector2(0f, GRAVITY));
When I apply a linear impulse to my character (when the user taps the screen) everything works fine:
body.setLinearVelocity(0f, 0f);
body.applyLinearImpulse(0, IMPULSE, body.getPosition().x, body.getPosition().y, true);
The body has a density of 0f, but changing this to 1f or even 100f doesn't seem to have any real effect.
This means that I have to scale all the sprite's locations in the draw method by PIXELS_TO_METERS. I figured (perhaps incorrectly) that I could simply scale GRAVITY and IMPULSE by PIXELS_TO_METERS and have it work exactly the same. This doesn't seem to be the case. Gravity seems really small, and applying the impulse barely has any effect at all.
// Used to scale all sprite's coordinates
public static final float PIXELS_TO_METERS = 1f;
// Used with physics world.
public static final float GRAVITY = -9.8f * 100;
public static final float IMPULSE = 0.15f * 100;
So:
1) why doesn't simply scaling up all the values make it work the same?
2) Is there a better way to do this?

It looks like you're over complicating your design by using some imaginary pixel units (i doubt it are actual pixels you're referring to). I'd advice you to use meaningful units instead, for example meters, and stick to it. Thus, use meters for all coordinates (including your virtual viewport). So, practically modify you code to look like this:
// Used to create an Extend Viewport
public static final float MIN_WIDTH = 4.8f; // at least 4.8 meters in width is visible
public static final float MIN_HEIGHT = 8.0f; // at least 8 meter in height is visible
This completely removes the need to scale meter to your imaginary pixel units. The actual scaling from your units (virtual viewport size) to the screen (values between -1 and +1) is done by the camera. You should not have to think about scaling units in your design.
Make sure to remove your PIXELS_TO_METERS constant (don't set it to 1f, it is only complicating your code at no gain) and make sure you're not using imaginary pixels at all in your code. The latter includes all sprites that you create without explicitly specifying its size in meters.
It is still possible to "scale" your units (in your game logic) compared to SI units, because of valid reasons. For example, when creating a space game, you might find yourself using very large numbers when using meters. Typically you'd want to keep the values around 1f to avoid floating point errors. In such case it can be useful to use e.g. dekameters (x10), hectometers (x100) or kilometers (x1000) instead. If you do this, make sure to be consistent. It might help to add the units in comments so you don't forget to scale properly (e.g. GRAVITY = -0.0098f; // kilometer per second per second).

I have implemented as this:
// in declaration
float PIXELS_TO_METERS = 32; // in my case: 1m = 32 pixels
Matrix4 projection = new Matrix4();
// in creation
viewport = new FitViewport(
Application.width
, Application.height
, Application.camera);
viewport.apply();
// set vieport dimensions
camera.setToOrtho(false, gameWidth, gameHeight);
// in render
projection.set(batch.getProjectionMatrix());
projection.scl(PIXELS_TO_METERS);
box2dDebugRenderer.render(world, projection);
// in player body creation
BodyDef bodyDef = new BodyDef();
bodyDef.type = BodyDef.BodyType.DynamicBody;
bodyDef.position.x = getPosition().x / PIXELS_TO_METERS;
bodyDef.position.y = getPosition().y / PIXELS_TO_METERS;
CircleShape shape = new CircleShape();
shape.setRadius((getBounds().width * 0.5f) / PIXELS_TO_METERS);
// in player update
setPosition(
body.getPosition().x * PIXELS_TO_METERS - playerWidth,
body.getPosition().y * PIXELS_TO_METERS - playerHeight);
So to set pixels to meters in box2d methods you have to divide pixel-positions by PIXELS_TO_METERS and to set meters to pixels in player position you have to multiply box2d values by PIXELS_TO_METERS.
Set your PIXELS_TO_METERS correctly to how much pixels in your screens match to 1 meter.
Good luck.

Libgdx Box2D pixel to meter conversion?

When trying to program a game using Box2D, I ran into a problem with Box2D. I filled in pixel numbers for the lengths of the the textures and sprites to create a box around it. Everything was at the right place, but for some reason everything went very slowly. By looking on the internet I found out that if you didn't convert pixels to meters box2d might handle shapes as very large objects. this seemed to be a logical cause of everything moving slowly.
I found similar questions on this site, but the answers didn't really seem to help out. in most of the cases the solution was to make methods to convert the pixel numbers to meters using a scaling factor. I tried this out, but everything got misplaced and had wrong sizes. this seemed logical to me since the numbers where changed but had the same meaning.
I was wondering if there is a way to make the pixels mean less meters, so everything whould be at the same place with the same (pixel) size, but mean less meters.
If you have a different way which you think might help, I whould also like to hear it..
Here is the code i use to create the camera
width = Gdx.graphics.getWidth() / 5;
height = Gdx.graphics.getHeight() / 5;
camera = new OrthographicCamera(width, height);
camera.setToOrtho(false, 1628, 440);
camera.update();
This is the method I use to create an object:
public void Create(float X, float Y, float Width, float Height, float density, float friction, float restitution, World world){
//Method to create an item
width = Width;
height = Height;
polygonDef = new BodyDef();
polygonDef.type = BodyType.DynamicBody;
polygonDef.position.set(X + (Width / 2f), Y + (Height / 2f));
polygonBody = world.createBody(polygonDef);
polygonShape = new PolygonShape();
polygonShape.setAsBox(Width / 2f, Height / 2f);
polygonFixture = new FixtureDef();
polygonFixture.shape = polygonShape;
polygonFixture.density = density;
polygonFixture.friction = friction;
polygonFixture.restitution = restitution;
polygonBody.createFixture(polygonFixture);
}
To create an item, in this case a table, I use the following:
Table = new Item();
Table.Create(372f, 60f, 152f, 96f, 1.0f, 0.2f, 0.2f, world);
The Sprites are drawn on the item by using the following method:
public void drawSprite(Sprite sprite){
polygonBody.setUserData(sprite);
Utils.batch.begin();
if(polygonBody.getUserData() instanceof Sprite){
Sprite Sprite = (Sprite) polygonBody.getUserData();
Sprite.setPosition(polygonBody.getPosition().x - Sprite.getWidth() / 2, polygonBody.getPosition().y - Sprite.getHeight() / 2);
Sprite.setRotation(polygonBody.getAngle() * MathUtils.radiansToDegrees);
Sprite.draw(Utils.batch);
}
Utils.batch.end();
}
The sprites also have pixel sizes.
Using this methods it displays the images at the right places, but everything moves slowly.
I was wondering how or if I whould have to change this to make the objects move correctly, and / or mean less. Thanks in advance.

Box2D is an entirely independent of the graphics library that you use. It doesn't have any notion of sprites and textures. What you read online is correct, you'll have to convert pixels to metres, as Box2D works with metres(the standard unit for distance).
For example, if you drew a sprite of size 100x100 pixels, that's the size of the sprite that you want the user to see on the screen. In real world the size of the object should be in metres and not in pixels - so if you say 1px = 1m, then that'll map the sprite to a gigantic 100x100 meter object. In Box2D, large world objects will slow down calculations. So what you need to do is map the 100 pixels to a smaller number of meters, say, 1 meter - thus 100x100px sprite will be represented in Box2D world by a 1x1 meter object.
Box2D doesn't work well with very small numbers and very large numbers. So keep it in between, say between 0.5 and 100, to have good performance.
EDIT:
Ok. Now I get your question.
Don't code to pixels. Its as simple as that. I know it'll take some time to understand this(it took for me). But once you get the hang of it, its straight forward.
Instead of pixels, use a unit, say, you call it meter.
So we decide our viewport should be say 6mx5m.
So initialization is
Constants.VIEWPORT_WIDTH = 6;
Constants.VIEWPORT_HEIGHT = 5;
...
void init() {
camera = new OrthographicCamera(Constants.VIEWPORT_WIDTH, Constants.VIEWPORT_HEIGHT);
camera.position.set(Constants.VIEWPORT_WIDTH/2, Constants.VIEWPORT_HEIGHT/2, 0);
camera.update();
}
Once you know the actual width and height, you call the following function in order to maintain aspect ratio:
public void resize(int width, int height) {
camera.viewportHeight = (Constants.VIEWPORT_WIDTH / width) * height;
camera.update();
}
resize() can be called anytime you change your screen size(eg: when you screen orientation changes). resize() takes the actual width and height (320x480 etc), which is the pixel value.
Now you specify you sprite sizes, their positions etc. in this new world of size 6x5. You can forget pixels. The minimum size of the sprite that'll fill the screen will be 6x5.
You can now use the same unit with Box2D. Since the new dimensions will be smaller, it won't be a problem for Box2D. If I remember correctly Box2D doesn't have any unit. We just call it meter for convenience sake.
Now you might ask where you specify the dimensions of the window. It depends on the platform. Following code shows a 320x480 windowed desktop game:
public class Main {
public static void main(String[] args) {
LwjglApplicationConfiguration cfg = new LwjglApplicationConfiguration();
cfg.title = "my-game";
cfg.useGL20 = false;
cfg.width = 480;
cfg.height = 320;
new LwjglApplication(new MyGame(), cfg);
}
}
Our camera will intelligently map the 6x5 viewport to 480x320.