I am creating a game which uses accelerometer to move ball (football model game).
function acc(e)
physics.setGravity(e.xInstant*(screenW/4), -1*e.yInstant*(screenH/4))
end
But this code not giving a smooth flow of game. Can u guys help me for right option
You either need to "calibrate" or to change the algorithm. I would try calibrate first: replace your acc() with
function acc(e)
local calibX = 1
local calibY = 1
-- physics.setGravity(calibX * e.xInstant*(screenW/4), -calibY * e.yInstant*(screenH/4))
print(e.xInstant, e.yInstant, e.zInstant)
end
and do the tilting that you feel is "not smooth", looking at the values printed when you do that. This will tell you what calibX and Y should be, set them then uncomment the physics line, comment out the print line, try again, until you get it right. For example, if the x and y instant are around 10, you could try calibX = 0.1 or less.
If you can't find values for calibration coefficients that give you desired motion, you need to change your algorithm. For example, if you are trying to simulate the tilt of your device as though it was a table on which a marble rolls, and tilting the table should make marble move, then changing gravity is not the way to do it. You want to apply a horizontal force which is equal to g*sin(theta) where g is gravity and theta is the tilt angle of the device side-to-side. The formula is slightly more complex if you allow tilt along the other direction.
Related
I'm trying to code a Pong game on Lua using the framework Love2D with some extra features. Among others, I want curves to occur. In order to do so, I'm trying to implement the trajectory of horizontally launched projectiles. I have a ball table with a position attribute for x (ball.x) and another for y (ball.y). I, also, have a an attribute for the x velocity (ball.dx) and another for the y velocity (ball.dy). Finally, I have an acceleration variable (gravity)
In my game, if the paddle moves and the ball hits it, the ball should follow and horizontal curve. In order to create my curves, I want to change the y-axis velocity on each frame in order to make my ball move in an arc across the screen. The main issue that I have is that I don't know how to change this velocity in each frame in order to create the expected arc. The most recent attempt that I made was to create a while loop like the following code. However, it creates an infinite loop. Can someone enlighten me please?
Clarification:
-Player.x and player.y are the player coordinate
-Player2.x and Player2.y are the opponent coordinate
-This piece of code is inside another if statement detecting a collision. It is inside the love.update(dt) function.
Thank you so much!
if love.keyboard.isDown("up") and distanceBetween(ball.x,ball.y,player.x,player.y)>30 then
ball.dy=0
while CollisionDetector(ball.x,player2.x,ball.y,player2.y, player2.width,player2.height,ball.size)==false or ball.x>0 or ball.y-20>0 or ball.y+20<love.graphics.getHeight() do
ball.dy=ball.dy+gravity*dt
ball.y=ball.y+ball.dy
end
end
I believe the snippet you've provided is a part of love.update function. (At least it should be.) That function is supposed to perform a single step of the game at a time and return. It is not supposed to handle the whole flight in a single call.
In your particular case, while loop expects the ball to move, but that is not something that will happen until the loop and encompassing function end.
In general, to simulate ongoing processes you'll have to store the information about such process. For example, if you want gravity be dependent on the paddle movement direction, then you'll have to modify the corresponding variable and store it between the call.
In your code, there are multiple other design flaws that make it do not what you think it should do. With some functions and code parts left to be implemented by yourself, the code outline would look as follows:
function collides(ball,player)
return (ball.x,player.x,ball.y,player.y, player.width,player.height,ball.size)
end
function love.update(dt)
handle_paddle_movements()
--handle the ball-paddle interaction
if collides(ball,player1) or collides(ball,player2) then
ball.dx=-ball.dx
if love.keyboard.isDown("up") then
--store the info you need to know about the interaction
ball.d2y = -gravity
else if love.keyboard.isDown("down")
ball.d2y = gravity
else
ball.d2y = 0
end
end
handle_the_wall_collision()
--ball movement code should be separate from collision handling
--concrete equations can be whatever you want
ball.x = ball.x+ball.dx*dt
ball.dy = ball.dy + ball.d2y * dt
ball.y = ball.y + ball.dy * dt
end
My code for physics in my game is this:
-- dt = time after each update
self.x = math.floor(self.x + math.sin(self.angle)*self.speed*dt)
self.y = math.floor(self.y - math.cos(self.angle)*self.speed*dt)
-- addVector(speed,angle,speed2,angle2)
self.speed,self.angle = addVector(self.speed,self.angle,g,math.pi)`
when it hits the ground, the code for it to bounce is :
self.angle = math.pi - self.angle
self.y = other.y - self.r`
the function addVector is defined here:
x = math.sin(angle)*speed + math.sin(angle2)*speed2
y = math.cos(angle)*speed + math.cos(angle2)*speed2
v = math.sqrt(x^2 + y^2)
a = math.pi/2 - math.atan(y,x)
return v,a
but when I place a single ball in the simulation without any drag or elasticity, the height of the ball after each bounce keeps getting higher. Any idea what may be causing the problem?
Edit: self.r is the radius, self.x and self.y are the position of the centre of the ball.
Your Y axis is increasing downward and decreasing upward.
Making self.y = math.floor(..) moves your ball a bit upward every frame.
The solution is to store your coordinates with maximal precision.
You could make new variable y_for_drawing = math.floor(y) to draw the ball at pixel with integer coordinates, but your main y value must have fractional part.
I’ve managed to get your code to run and reproduce the behavior you are seeing. I also find it difficult to figure out the issue. Here’s why: movement physics involves position, which is affected by a velocity vector, which in turn is affected by an acceleration vector. In your code these are all there, but are in no way clearly separated. There are trig functions and floor functions all interacting in a way that makes it difficult to see what role they are playing in the final position calculation.
By far the best and easiest-to-understand tutorial to help you implement basic physics lime this is The Nature of Code (free to read online, with interactive examples). As an exercise I ported most of the early exercises into Lua. I would suggest you see how he clearly separates the position, velocity and acceleration calculations.
As an experiemnt, increase g to a much higher number. When I did that, I noticed the ball would eventually settle to the ground, but of course the bouces were too fast and it didnt bounce in a way that seems natural.
Also, define other.y - it doesnt seem to affect the bouncing issue, but just to be clear on what that is.
I am trying to make a new tool for the tabletop simulator community based on my "pack up bag". The Packup Bag is a tool that remembers world position and rotation of objects you place inside it, so you can then place them back in the same positions and rotations they came from when "unpacking the bag".
I have been trying to modify this so it spits things out in a relative position and rotation to the bag, instead of using hardcoded world coordinates. The idea here is that players can sit at any location at the table, pick the faction bag they wish to play.. drop it on a known spot marked for them and press the place and it will populate contents of the bag relative to its location.
Now I have gotten some of this worked out... I am able to get the bag to place relative in some ways .. but I am finding it beyond my maths skills to work out the modifications of the transforms.
Basically I have this part working..
The mod understands relative position to the bag
The mod understands relative rotation to the bag
BUT.. the mod dose not understand relative position AND rotation at the same time.... I need someway to modify the position data relative to the rotational data... but can not work out how.
See this video....
https://screencast-o-matic.com/watch/cFiOeYFsyi
As you can see as I move the bag around the object is placed relative to it.... but if I rotate the bag, the object has the correct rotation but I need math to work out the correct position IF it is rotated. You can see it is just getting placed in the same position it was as if there was no rotation... as I haven't worked out how to code it to do this.
Now I have heard of something called "matrix math" but I couldn't understand it. I'm a self taught programmer of only a few months after I started modding TTS.
You can kinda understand what I mean I hope.. In the video example, when I rotate the bag, the object should be placed with the correct rotation but the world position needs to be changed.
See this Example to see relative rotation ....
https://screencast-o-matic.com/watch/cFiOeZFsyq
My code dose this by remembering the self.getPostion() of the bag and the obj.Position() of the object getting packed up.. it then dose a self - obj and stores that value for the X and Y position. It also remembers if it is negative or position and then when placing it uses the self.postion() and adds or subtracts the adjustment value. Same for rotation.
Still I do not know what ot go from here.. I have been kinda hurting my head on this and thought maybe some of you math guys might have a better idea on how to do this.
: TL;DR :
So I have
bag.getPosition() and obj.getRotation()
bag.getRotation(0 and obj.getRotation()
These return (x,y,z}
What math can I use to find the relative position and rotation of the objects to the bag so if I rotate the bag. The objects come out of it in a relative way...
Preferably in LUA.. thank you!
I'd hope you've found the answer by now, but for anyone else finding this page:
The problem is much simpler than what you're suggesting - it's basic right triangle trigonometry.
Refer to this diagram. You have a right triangle with points A, B, and C, where C is the right angle. (For brevity, I'll use abbreviations opp, adj, and hyp.) The bag is at point A, you want the object at point B. You have the angle and distance (angle A and the length of the hyp, respectively), but you need the x,y coordinates of point B relative to point A.
The x coord is the length of adj, and y coord is the length of opp. As shown, the formulas to calculate these are:
cos(angle A) = adj/hyp
sin(angle A) = opp/hyp
solving for the unknowns:
adj = hyp * cos(angle A)
opp = hyp * sin(angle A)
For your specific use, and taking into account the shift in coordinate system x,y,z => x,z,y:
obj_x_offset = distance * math.cos(bag.getRotation().y)
obj_z_offset = distance * math.sin(bag.getRotation().y)
obj_x_position = bag.getPosition().x + obj_x_offset
obj_z_position = bag.getPosition().z + obj_z_offset
Diagram source:
https://www.khanacademy.org/math/geometry/hs-geo-trig/hs-geo-modeling-with-right-triangles/a/right-triangle-trigonometry-review
I want to add force to the grenade according to the touch positions of the user.
--this is the code
physics.addBody(grenade1,"dynamic",{density=1,friction=.9,bounce=0})
grenade1:applyForce(event.x,event.y,grenade1.x,grenade1.y)
Here more the x and y positions are the lower the force is. But the force here is too high that the grenade is up in the sky.
You must calibrate the force applied. Remember that F=ma so if x=250 then F=250, if the mass of the display object (set when added body, based on material density * object area) is 1 then acceleration a = 250, which is very large. So try:
local coef = 0.001
grenade1:applyForce(coef*event.x, coef*event.y, grenade1.x, grenade1.y)
and see what you get. If too small, increase coef until the response is what you are looking for. You may find that linear (i.e., constant coef) doesn't give you the effect you want, for example coef=0.01 might be fine for small y but for large y you might find that coef=0.001 works better. In this case you would have to make coef a function of event.y, for example
local coef = event.y < 100 and 0.001 or 0.01
You could also increase the mass of the display object, instead of using coeff.
Recall also that top-level corner is 0,0: force in top level corner will be 0,0. So if you want force to increase as you go up on the screen, you need to use display.contentHeight - event.x.
How to make a 2d world with fixed size, which would repeat itself when reached any side of the map?
When you reach a side of a map you see the opposite side of the map which merged togeather with this one. The idea is that if you didn't have a minimap you would not even notice the transition of map repeating itself.
I have a few ideas how to make it:
1) Keeping total of 3x3 world like these all the time which are exactly the same and updated the same way, just the players exists in only one of them.
2) Another way would be to seperate the map into smaller peaces and add them to required place when asked.
Either way it can be complicated to complete it. I remember that more thatn 10 years ago i played some game like that with soldiers following each other in a repeating wold shooting other AI soldiers.
Mostly waned to hear your thoughts about the idea and how it could be achieved. I'm coding in XNA(C#).
Another alternative is to generate noise using libnoise libraries. The beauty of this is that you can generate noise over a theoretical infinite amount of space.
Take a look at the following:
http://libnoise.sourceforge.net/tutorials/tutorial3.html#tile
There is also an XNA port of the above at: http://bigblackblock.com/tools/libnoisexna
If you end up using the XNA port, you can do something like this:
Perlin perlin = new Perlin();
perlin.Frequency = 0.5f; //height
perlin.Lacunarity = 2f; //frequency increase between octaves
perlin.OctaveCount = 5; //Number of passes
perlin.Persistence = 0.45f; //
perlin.Quality = QualityMode.High;
perlin.Seed = 8;
//Create our 2d map
Noise2D _map = new Noise2D(CHUNKSIZE_WIDTH, CHUNKSIZE_HEIGHT, perlin);
//Get a section
_map.GeneratePlanar(left, right, top, down);
GeneratePlanar is the function to call to get the sections in each direction that will connect seamlessly with the rest of your world.
If the game is tile based I think what you should do is:
Keep only one array for the game area.
Determine the visible area using modulo arithmetics over the size of the game area mod w and h where these are the width and height of the table.
E.g. if the table is 80x100 (0,0) top left coordinates with a width of 80 and height of 100 and the rect of the viewport is at (70,90) with a width of 40 and height of 20 you index with [70-79][0-29] for the x coordinate and [90-99][0-9] for the y. This can be achieved by calculating the index with the following formula:
idx = (n+i)%80 (or%100) where n is the top coordinate(x or y) for the rect and i is in the range for the width/height of the viewport.
This assumes that one step of movement moves the camera with non fractional coordinates.
So this is your second alternative in a little bit more detailed way. If you only want to repeat the terrain, you should separate the contents of the tile. In this case the contents will most likely be generated on the fly since you don't store them.
Hope this helped.