LÖVE

Posted: **Fri Oct 07, 2016 6:09 pm**

removed

Posted: **Sat Oct 08, 2016 5:33 am**

Hello there. First, I would like to say that collisions are a difficult problem.
Also, I have tried making my own physics lib in the past:
viewtopic.php?f=5&t=7844
In my opinion, it's best to keep your library small so that it can do one thing really well.
Having said that, your project needs a lot of work.

For example:

Code: Select all

function Map:move(e, dx, dy)
  if not self:collision(e, dx, 0) then e:move(dx, 0) end
  if not self:collision(e, 0, dy) then e:move(0, dy) end
end

A more 'correct' approach would be to handle the collisions based on shortest separation rather than per axis.

Using meta tables for "entities" is not really necessary in my opinion (unless you plan on using inheritance).
You have an empty "entity.draw" function which you really shouldn't since it's not called anywhere in the code.

Some of terminology is confusing, for example:

Code: Select all

  --- x Acceleration
  xa = 0,
  --- y Acceleration
  ya = 0,

Do you mean "velocity" as in the change in position over time?
Acceleration is the change in VELOCITY over time!

In short, your effort is good, but you should really consider doing more research and study the existing techniques.

Posted: **Sat Oct 08, 2016 7:32 am**

removed

Posted: **Sat Oct 08, 2016 4:06 pm**

gamedevaton wrote:I chose to check separate axis ... it doesn't affect the collision handling negatively in any way.

It does in a subtle way: typically you want to separate the two colliding shapes
using the shortest separation axis in order to prevent jitter and objects getting stuck.
It depends on the game you are making, but it may be more apparent
if you try an overhead game with rows and columns of blocks.

gamedevaton wrote:For my implementation there is a benefit to using meta tables for entities, inheritance and overriding functionality. See Player.lua and Elevator.lua which override the update and collision response functions. A meta table implementation also gives you the benefit of having each Entity point to a shared "copy" of a function rather than that same function being redefined on each Entity table.

I haven't studied the code a lot, but with inheritance through metatables -
you don't have to re-assign all of the functionality like you do in the elevator.lua/player.lua files.
One approach is to pass the elevator/player sub-metatable up to entity.lua.
There are elegant ways to do this, take a look at 30log or the other minimal OO libraries.

I use those variables in Player.lua in the example to accumulate gravity (acceleration) and therefore it is velocity. I have updated the comment thank you. It is also completely optional to use those variables in your Entity implementation. The only essential things an entity needs is location and dimension variables, an update function, collision response and movement response functions.

Velocity is always added to position and acceleration to velocity.
both "dy" and "yv" in your case works as velocity, and could probably be combined:

Code: Select all

  -- gravity acceleration
  self.yv = self.yv + self.gravity <-- needs *dt here too
dy = dy + self.yv

Also, make sure to include delta in your code unless you use a constant time step.
Good luck.

LÖVE

Phyzzle Physics

Phyzzle Physics

Re: Phyzzle Physics

Re: Phyzzle Physics

Re: Phyzzle Physics