I followed this tutorial to make a breakout game, but at some point, the ball keeps leaning on the top wall when the ball angle is too large ( too horizontal ). Is there any logic I can tune so that the ball can avoid this behavior?
Here is the screenshot :
The ball's related source code is:
local ballRadius = 10
ball = display.newCircle( display.contentWidth / 2, display.contentHeight / 2, ballRadius )
physics.addBody(ball, "dynamic", {friction=0, bounce = 1, radius=ballRadius})
It is some kind of weird. But I've done once like this...
Create 3 variables/flags:
local horizontalMotionFlag,yPos_1,yPos_2 = 0,0,0
Then:
wall.type = "LeftWall" -- to the LeftWall
-- and --
wall.type = "RightWall" -- to the RightWall
Add the following lines inside event.phase == "ended"
------------------------------------------------------------------------------------------
if(event.other.type == "LeftWall") then
yPos_1 = ball.y
if(horizontalMotionFlag==0)then
horizontalMotionFlag = 1
else
if(math.abs(yPos_1-yPos_2) < 50)then
print("CoHorizontal motion detected. Change angle...1")
horizontalMotionFlag = 0
ball:applyForce( 0, 1, ball.x, ball.y ) -- apply a small downward force
ball:applyForce( 0, 0, ball.x, ball.y ) -- resetting the force
-- You can also check the direction of ball and apply force to -1(upwards) also --
end
end
end
if(event.other.type == "RightWall") then
yPos_2 = ball.y
if(horizontalMotionFlag==0)then
horizontalMotionFlag = 1
else
if(math.abs(yPos_1-yPos_2) < 50)then
print("CoHorizontal motion detected. Change angle...")
horizontalMotionFlag = 0
ball:applyForce( 0, 1, ball.x, ball.y ) -- apply a small downward force
ball:applyForce( 0, 0, ball.x, ball.y ) -- resetting the force
-- You can also check the direction of ball and apply force to -1(upwards) also --
end
end
end
------------------------------------------------------------------------------------------
Then add the following line inside event.other.type == "destructible" and event.other.type == "bottomWall" :
horizontalMotionFlag = 0;
Keep Coding............. :)
Related
So I am trying to make a ball fall and when it is touched, I need it to bounce in the direction the ball is touched. Right now all I have it doing is going straight up, but if I were to tap on the edge of the ball, it needs to start heading in that direction but also up.
The game is a soccer keep ups game, you tap and the ball goes up, if it hits the ground, the score resets. Simple. But I cannot seem to find any examples on how to have the ball roll side to side as well as upwards.
local ball = display.newImageRect("soccerball.png", 112, 112)
ball.x = display.contentCenterX
ball.y = display.contentCenterY
physics.addBody(ball, "dynamic", {radius=50, bounce=0.3})
local function pushBall(event)
ball:applyLinearImpulse(0, -0.75, ball.x, ball.y)
tapCount = tapCount + 1
tapText.text = tapCount
end
ball:addEventListener("touch", pushBall)
Code above only allows the ball to go straight up. No roll.
Thank you for your help.
Try
function ball:touch( event )
local phase = event.phase
if ( phase == 'ended' ) then
local x, y = ball.x - event.x, ball.y - event.y
self:applyLinearImpulse( x / 30, -math.abs(y) / 30, self.x, self.y )
--tapCount = tapCount + 1
--tapText.text = tapCount
end
return true
end
ball:addEventListener("touch")
I am getting the message "This game indicates it was made for version '0.9.1' of LOVE.
It may not be compatible with the running version (0.10.2)." when I try and run my game. The game still works but the message is annoying me. How do I update it to the latest version? My code is here:
debug = true
Main.lua
-- Timers
-- We declare these here so we don't have to edit them multiple places
canShoot = true
canShootTimerMax = 0.2
canShootTimer = canShootTimerMax
createEnemyTimerMax = 0.4
createEnemyTimer = createEnemyTimerMax
-- Player Object
player = { x = 200, y = 710, speed = 150, img = nil }
isAlive = true
score = 0
-- Image Storage
bulletImg = nil
enemyImg = nil
-- Entity Storage
bullets = {} -- array of current bullets being drawn and updated
enemies = {} -- array of current enemies on screen
-- Collision detection taken function from http://love2d.org/wiki/BoundingBox.lua
-- Returns true if two boxes overlap, false if they don't
-- x1,y1 are the left-top coords of the first box, while w1,h1 are its width and height
-- x2,y2,w2 & h2 are the same, but for the second box
function CheckCollision(x1,y1,w1,h1, x2,y2,w2,h2)
return x1 < x2+w2 and
x2 < x1+w1 and
y1 < y2+h2 and
y2 < y1+h1
end
-- Loading
function love.load(arg)
player.img = love.graphics.newImage('assets/plane.png')
enemyImg = love.graphics.newImage('assets/enemy.png')
bulletImg = love.graphics.newImage('assets/bullet.png')
end
-- Updating
function love.update(dt)
-- I always start with an easy way to exit the game
if love.keyboard.isDown('escape') then
love.event.push('quit')
end
-- Time out how far apart our shots can be.
canShootTimer = canShootTimer - (1 * dt)
if canShootTimer < 0 then
canShoot = true
end
-- Time out enemy creation
createEnemyTimer = createEnemyTimer - (1 * dt)
if createEnemyTimer < 0 then
createEnemyTimer = createEnemyTimerMax
-- Create an enemy
randomNumber = math.random(10, love.graphics.getWidth() - 10)
newEnemy = { x = randomNumber, y = -10, img = enemyImg }
table.insert(enemies, newEnemy)
end
-- update the positions of bullets
for i, bullet in ipairs(bullets) do
bullet.y = bullet.y - (250 * dt)
if bullet.y < 0 then -- remove bullets when they pass off the screen
table.remove(bullets, i)
end
end
-- update the positions of enemies
for i, enemy in ipairs(enemies) do
enemy.y = enemy.y + (200 * dt)
if enemy.y > 850 then -- remove enemies when they pass off the screen
table.remove(enemies, i)
end
end
-- run our collision detection
-- Since there will be fewer enemies on screen than bullets we'll loop them first
-- Also, we need to see if the enemies hit our player
for i, enemy in ipairs(enemies) do
for j, bullet in ipairs(bullets) do
if CheckCollision(enemy.x, enemy.y, enemy.img:getWidth(), enemy.img:getHeight(), bullet.x, bullet.y, bullet.img:getWidth(), bullet.img:getHeight()) then
table.remove(bullets, j)
table.remove(enemies, i)
score = score + 1
end
end
if CheckCollision(enemy.x, enemy.y, enemy.img:getWidth(), enemy.img:getHeight(), player.x, player.y, player.img:getWidth(), player.img:getHeight())
and isAlive then
table.remove(enemies, i)
isAlive = false
end
end
if love.keyboard.isDown('left','a') then
if player.x > 0 then -- binds us to the map
player.x = player.x - (player.speed*dt)
end
elseif love.keyboard.isDown('right','d') then
if player.x < (love.graphics.getWidth() - player.img:getWidth()) then
player.x = player.x + (player.speed*dt)
end
end
if love.keyboard.isDown(' ', 'rctrl', 'lctrl', 'ctrl') and canShoot then
-- Create some bullets
newBullet = { x = player.x + (player.img:getWidth()/2), y = player.y, img = bulletImg }
table.insert(bullets, newBullet)
canShoot = false
canShootTimer = canShootTimerMax
end
if not isAlive and love.keyboard.isDown('r') then
-- remove all our bullets and enemies from screen
bullets = {}
enemies = {}
-- reset timers
canShootTimer = canShootTimerMax
createEnemyTimer = createEnemyTimerMax
-- move player back to default position
player.x = 50
player.y = 710
-- reset our game state
score = 0
isAlive = true
end
end
-- Drawing
function love.draw(dt)
for i, bullet in ipairs(bullets) do
love.graphics.draw(bullet.img, bullet.x, bullet.y)
end
for i, enemy in ipairs(enemies) do
love.graphics.draw(enemy.img, enemy.x, enemy.y)
end
love.graphics.setColor(255, 255, 255)
love.graphics.print("SCORE: " .. tostring(score), 400, 10)
if isAlive then
love.graphics.draw(player.img, player.x, player.y)
else
love.graphics.print("Press 'R' to restart", love.graphics:getWidth()/2-50, love.graphics:getHeight()/2-10)
end
if debug then
fps = tostring(love.timer.getFPS())
love.graphics.print("Current FPS: "..fps, 9, 10)
end
end
conf.lua
-- Configuration
function love.conf(t)
t.title = "Scrolling Shooter Tutorial" -- The title of the window the game is in (string)
t.version = "0.9.1" -- The LÖVE version this game was made for (string)
t.window.width = 480 -- we want our game to be long and thin.
t.window.height = 800
-- For Windows debugging
t.console = true
end
As noted in the comments, the problem in your case was that, in conf.lua, the version was specified as "0.9.1". In some cases, changing this value to "0.10.2" is sufficient, but a significant amount of changes occurred between 0.9.0 and 0.10.0.
Be especially aware that mouse input is definitely going to be broken because, in versions before 0.10.0, LOVE used strings to represent mouse buttons, whereas in 0.10.0 and beyond, numbers are used. To fix this, look for mouse-related functions (love.mouse.isDown, love.mousepressed, etc.) and change "l" to 1, "r" to 2, and so on. See the full list of old values and love.mousepressed for more. Additionally, mousewheel movement changed as well, with the addition of the love.wheelmoved callback and removing the strings passed to love.mousepressed.
Additionally, read through the changelog for any changes that may have affected your program.
Using the Love2D Lua framework, I am trying to program a very basic game much like Nintendo-era RPGs where the heroes' and NPCs' movement was restricted to a tiled grid. So far I've found my past any problems, until I hit this tricky error where the player movement isn't functioning correctly.
function love.load()
love.graphics.setDefaultFilter('nearest', 'nearest', 1)
love.keyboard.setKeyRepeat(true)
font = love.graphics.newFont(14) -- the number denotes the font size
win_size = 6
love.window.setMode(160 * win_size, 144 * win_size)
true_sfc = love.graphics.newCanvas(160,144)
view_sfc = love.graphics.newCanvas(160 * win_size, 144 * win_size)
player = {
grid_x = 3,
grid_y = 3,
act_x = 48,
act_y = 48,
transit = false,
direction = {0, 0}
}
end
function love.update(dt)
if player.transit == true then
-- The idea is that if the player selects a direction, the player will walk in that direction until it stops on the grid.
-- When I press left or right, the movements works as intended- the player square walks until it stops on the grid.
-- However, when I press up or down, the player only moves a single pixel, despite having the same instructions
player.act_x = player.act_x + player.direction[1]
player.act_y = player.act_y + player.direction[2]
if player.act_x == player.grid_x * 16 then
player.direction[1] = 0
player.transit = false
end
if player.act_y == player.grid_y * 16 then
player.direction[2] = 0
player.transit = false
end
-- Now in this if-statement, if I have the program compare the player's y-coordinates before comparing the x coordinates,
-- the program will move the player on the y-axis correctly, with it locking to the 16 pixel grid, while the x coordinates
-- will starts to have the single-pixel movement issue.
end
end
function love.draw()
love.graphics.setCanvas(true_sfc)
love.graphics.setColor( 0, 0, 0)
love.graphics.rectangle("fill", 0, 0, 256, 224)
love.graphics.setColor(255,255,255)
love.graphics.rectangle("fill", player.act_x, player.act_y, 16, 16)
love.graphics.print(player.direction[1], 100, 100)
love.graphics.print(player.direction[2], 100, 120)
love.graphics.setCanvas()
love.graphics.draw(true_sfc, 0, 0, 0, win_size, win_size)
end
function love.keypressed(key)
if player.transit == false then
if key == "up" then
player.grid_y = player.grid_y - 1
player.direction = {0, -1}
player.transit = true
elseif key == "down" then
player.grid_y = player.grid_y + 1
-- press down, the player's map position goes down one tile
player.direction = {0, 1}
player.transit = true
elseif key == "left" then
player.grid_x = player.grid_x - 1
player.direction = {-1, 0}
player.transit = true
elseif key == "right" then
player.grid_x = player.grid_x + 1
player.direction = {1, 0}
player.transit = true
end
end
end
Admittedly I'm pretty new to Lua so I don't understand how it uses variables very well. And I realize that my code isn't very effecient, but that's something I planned on improving over time anyway.
The problem here is that you check if the vertical movement lines up, see that it does, and then you set self.transit to false, preventing any future checks.
You want to also check that you are moving in that direction, before checking if you're lined up:
if player.direction[1] ~= 0 and player.act_x == player.grid_x * 16 then
player.direction[1] = 0
player.transit = false
end
if player.direction[2] ~= 0 and player.act_y == player.grid_y * 16 then
player.direction[2] = 0
player.transit = false
end
When I run this code (which is based on the "DragMe" sample app) I get very unexpected results in very particular circumstances.
My "snapToGrid" function sets x and y to the nearest round 100 value after a drag.
The "examine" function outputs the x and y values after an object is created, moved or rotated (by clicking on it).
If you place an object in row 5 (so y = 500) and rotate it you will see that the y value changes to 499.99996948242 but this does not happen in any other row.
How can this be explained? I notice this does not happen if the physics bodies are not added to the display object.
I know I could call snapToGrid after rotation or round the value before I use it for anything else but I think there is an important opportunity here for me to learn something useful about Corona.
local function snapToGrid(t)
modHalf = t.x % t.width
if modHalf > t.width/2 then
t.x = t.x + (t.width-modHalf)
end
if modHalf < t.width/2 then
t.x = t.x - modHalf
end
modHalfY = t.y % t.height
if modHalfY > t.height/2 then
t.y = t.y + (t.height-modHalfY)
end
if modHalfY < t.height/2 then
t.y = t.y - modHalfY
end
display.getCurrentStage():setFocus( nil )
t.isFocus = false
return true
end
function rotatePiece(target)
if target.rotation == 270 then
target.rotation = 0
else
target.rotation = target.rotation + 90
end
end
local function dragBody(event)
local target = event.target
local phase = event.phase
local halfWidth = target.width/2
local halfHeight = target.height/2
--get tileX and tileY relative to tile centre
local tileX = event.x-target.x
local tileY = event.y-target.y
local modHalf = ""
local snap = 15
if phase == "began" then
-- Make target the top-most object
display.getCurrentStage():setFocus( target )
-- Spurious events can be sent to the target, e.g. the user presses
-- elsewhere on the screen and then moves the finger over the target.
-- To prevent this, we add this flag. Only when it's true will "move"
-- events be sent to the target.
target.isFocus = true
-- Store initial position
target.x0 = event.x - target.x
target.y0 = event.y - target.y
elseif target.isFocus then
if phase == "moved" then
-- Make object move (we subtract target.x0,target.y0 so that moves are
-- relative to initial grab point, rather than object "snapping").
target.x = event.x - target.x0
target.y = event.y - target.y0
if target.x > display.contentWidth - (target.width/2) then target.x = display.contentWidth - (target.width/2) end
if target.y > display.contentHeight - (target.height/2) then target.y = display.contentHeight - (target.height/2) end
if target.x < 0 + (target.width/2) then target.x = 0 + (target.width/2) end
if target.y < 0 + (target.height/2) then target.y = 0 + (target.height/2) end
modHalf = target.x % target.width
if modHalf < snap then
target.x = target.x - modHalf
end
if modHalf > ((target.width) - snap) then
target.x = target.x + ((target.width)-modHalf)
end
modHalfY = target.y % target.height
if modHalfY < snap then
target.y = target.y - modHalfY
end
if modHalfY > ((target.height) - snap) then
target.y = target.y + ((target.height)-modHalfY)
end
hasMoved = true
return true
elseif phase == "ended" then
if hasMoved then
hasMoved = false
snapToGrid(target)
--tile has moved
examine(target)
return true
else
--rotate piece
rotatePiece(target)
display.getCurrentStage():setFocus( nil )
target.isFocus = false
--tile has rotated
examine(target)
return true
end
end
end
-- Important to return true. This tells the system that the event
-- should not be propagated to listeners of any objects underneath.
return true
end
local onTouch = function(event)
if event.phase == "began" then
local tile = {}
img = display.newRect(event.x,event.y,100,100)
img:addEventListener( "touch", dragBody )
snapToGrid(img)
--top right corner and top middle solid
topRight = {16,-16,16,50,50,50,50,-16}
--top left and left middle solid
topLeft = {-16,-16,-16,-50,50,-50,50,-16}
--bottom right and right middle solid
bottomRight = {16,16,16,50,-50,50,-50,16}
--bottom left and bottom middle solid
bottomLeft = {-16,16,-16,-50,-50,-50,-50,16}
physics.addBody( img, "static",
{shape=topRight},
{shape=topLeft},
{shape=bottomLeft},
{shape=bottomRight}
)
--new tile created
examine(img)
return true
end
end
function examine(img)
print("--------------------------------------------------")
if img ~= nil then
print("X: "..img.x..", Y: "..img.y)
end
print("--------------------------------------------------")
end
local img
local physics = require( "physics" )
physics.setDrawMode( "hybrid" )
--draw gridlines
for i = 49, display.contentHeight, 100 do
local line = display.newLine(0,i,display.contentWidth,i)
local line2 = display.newLine(0,i+2,display.contentWidth,i+2)
end
for i = 49, display.contentWidth, 100 do
local line = display.newLine(i,0,i,display.contentHeight )
local line2 = display.newLine(i+2,0,i+2,display.contentHeight )
end
--init
physics.start()
Runtime:addEventListener("touch", onTouch)
There several possibilities. Firstly, since there are no integers in Lua, all numbers are double floating point values. According to FloatingPoint on Lua wiki,
Some vendors' printf implementations may not be able to handle
printing floating point numbers accurately. Believe it or not, some
may incorrectly print integers (that are floating point numbers). This
can manifest itself as incorrectly printing some numbers in Lua.
Indeed, try the following:
for i=1,50,0.01 do print(i) end
You will see that a lot of numbers print exactly as you would expect, by many print with an error of 10^-12 or even 2 x 10^-12.
However, your x prints fine when you don't give it to physics module. So surely the physics module does some computation on object position and changes it. I would certainly expect that for dynamic objects (due to collision detection), but here your object seems to be "static". So it must be that physics adjusts x even for static objects. The adjustment is so small that it would not be visible on the screen (you can't perceive any motion less than a pixel), but you're right that it is interesting to ask why.
The SO post Lua: subtracting decimal numbers doesn't return correct precision is worth reading; it has some links you might find interesting and gives the neat example that decimal 0.01 cannot be represented exactly in base 2; just like 1/3 can't be represented exactly in base 10 (but it can in base 3: it would be 0.1 base 3!). The question shows that, although Lua (or possibly, the underlying C) is smart enough to print 0.01 as 0.01, it fails to print 10.08-10.07 as 0.01.
If you really want to shake your understanding of floating point values, try this:
> a=0.3
> b=0.3
> print(a==b)
true
> -- so far so good; now this:
> a=0.15 + 0.15
> b=0.1 + 0.2
> print(a,b)
0.3 0.3
> print(c==d)
false -- woa!
This is explained by the fact that 0.15 in binary has a small error which is different from that of 0.1 or 0.2, so in terms of bits they are not identical; although when printed, the difference is too small to show. You may want to read the Floating Point Guide.
Actually this problem only occurs if you add the physics, so I think it is fair to say that the issue is caused by transferring control to box2d, not by Corona handling of the number alone. I asked on Corona forums and got this answer.
http://forums.coronalabs.com/topic/46245-display-object-that-has-static-physics-body-moves-very-slightly-when-rotated/
I am trying to make a simple platform game, and obviously I need tile collision. The problem with the code I have so far is that it moves the character first, then checks to see if it is colliding with something, but sometimes it thinks its colliding at the wrong times depending on if I check the x-axis for collisions first or the y-axis first. Am I going about this the wrong way? Here's some code.
function checkCollision(val, axis, oldPos)
if axis == "x" and char.tX then
local tileX = math.ceil(val/absoluteTileSize)
local tileY = math.floor(oldPos/absoluteTileSize)
local tl, tr, bl ,br = getTouchingTiles(tileX, tileY)
local isOnFlatSurface = math.abs(oldPos/absoluteTileSize-tileY) <= .00001--might not be a good i
if isOnFlatSurface then
if tr.canCollide then
char.tX = nil
char.x = tileX * absoluteTileSize - absoluteTileSize
end
else
if br.canCollide then
char.tX = nil
char.x = tileX * absoluteTileSize - absoluteTileSize
end
end
elseif axis == "y" then
local tileX = math.ceil(oldPos/absoluteTileSize)
local tileY = math.floor(val/absoluteTileSize)
local tl, tr, bl ,br = getTouchingTiles(tileX, tileY)
if bl.canCollide or br.canCollide then
char.tY = nil
char.y = tileY * absoluteTileSize --// - absoluteTileSize
--/////////////idk why i don't need to subtract that but it works
elseif not char.tY then--start falling if walk off something
char.tY = love.timer.getTime()
char.yi = char.y
char.vyi = 0
end
end
end
local tileX = math.ceil(val/absoluteTileSize)
local tileY = math.floor(oldPos/absoluteTileSize)
It seems strange that you would use math.ceil for the x values and math.floor for the y. This may be why you are getting some strange occurrences. I would recommend this little debugging trick that may help you:
-- Since you are using LÖVE, this is what you would use:
love.graphics.setColor( 255, 0, 0, 255 )
love.graphics.rectangle( 'line', ( tileX - 1 ) * absoluteTileSize, ( tileY - 1 ) * absoluteTileSize, absoluteTileSize, absoluteTileSize )
-- assuming absoluteTileSize represents the width/height of the tiles?
This would go at the end of your drawing function and would draw a red box in the "tile" your player is currently inside.