Fizz X

[kikito]

I don't think lines should be used that way. A line is something without dimensions. The real-life equivalent would be a gamma ray or tachyon emission; they go through matter with very rare interactions, and when those occur the result is not movement.

If you really want to move the bounding boxes though, then the most adequate criteria would be: Move the AABB in the direction of the normal where its center resides. The magnitude is calculated like this: Take all the AABB corners which are on the "other side" of the center, if you cut the aabb in two by the segment. Calculate the distance between the line and each of those. The movement is the longest distance.

[ivan]

I don't think lines should be used that way. A line is something without dimensions. The real-life equivalent would be a gamma ray or tachyon emission; they go through matter with very rare interactions, and when those occur the result is not movement.

You're right, lines don't have an area or volume.
That's why two intersecting lines can't be "solved" in a reasonable way.
I was hoping to use lines for slopes and one-sided platforms but I guess it might not be the best idea.

If you really want to move the bounding boxes though, then the most adequate criteria would be: Move the AABB in the direction of the normal where its center resides. The magnitude is calculated like this: Take all the AABB corners which are on the "other side" of the center, if you cut the aabb in two by the segment. Calculate the distance between the line and each of those. The movement is the longest distance.

Yes, something like that would work.
I've thought of similar methods, but checking each corner of the AABB is not very elegant IMO.
I think you're right that maybe I'm generally using lines in an incorrect way.
In this case, they should be used strictly for raycasts and stuff like that.

[ivan]

Version 7 is out. It fixes the inside edges problem for rects. Check out the original post for a download link.

[Johannes]

Probably doing something wrong here (still a total LUA/Löve newb) but when I try to run version 7 I get an error:

4aVRzrI.png (85.34 KiB) Viewed 734 times

but version 6 works just fine

gtDZbYx.png (39.02 KiB) Viewed 734 times

[ivan]

Oops, thanks for pointing that out.
I just repackaged the file so it should be ok now.

[Carocrazy132]

Dunno about anyone else but I'm having major issues with this framework :\

It seems to be testing my static circles against the player as if they were both rectangles.

[ivan]

Hey, sorry about the late reply.
Here's the readme of the module, perhaps it may help out if anybody decides to use fizz:

Code: Select all

fizz
====
.gravity
Global gravity value. 0 by default.

.maxVelocity
Maximum velocity for shapes. 1000 by default.

.addStatic("rect", x, y, w, h)
.addStatic("circle", x, y, r)
Creates a static shape at a given position where x and y define the
center of the shape. w and h define the width and height for
rectangle shapes whereas r defines the radius for circle shapes.
Static shapes are immovable.

.addDynamic("rect", x, y, w, h)
.addDynamic("circle", x, y, r)
Creates a dynamic shape at a given position where x and y define the
center of the shape. Dynamic shapes can move and collide with other
shapes.

.addKinematic("rect", x, y, w, h)
.addKinematic("circle", x, y, r)
Creates a kinematic shape at a given position where x and y define the
center of the shape. Kinematic shapes have a velocity but do not
respond to collisions. This can be useful for making moving platforms
and such.

.removeShape(s)
Removes a shape from the simulation.

.moveShape(a, dx, dy)
Moves shape a by the given amount dx, dy.

.getVelocity(a)
Returns the velocity of shape a.

.setVelocity(a, xv, yv)
Sets the velocity of shape a.

.update(dt)
Updates the simulation. To avoid tunnelling, you want to use a
constant delta value.

.queryPoint(x, y)
Finds and returns the first shape that intersects against the given
point x, y.

.queryRect(result, x, y, hw, hh)
Returns all shapes that intersect against a rectangle area specified
by a center position x, y and half-width/height hw, hh. result is a
table where the intersecting shapes are to be stored.

.queryShape(result, a)
Returns all shapes that intersect with the shape a. result is a table
where the intersecting shapes are to be stored.

Shapes
======
.x .y
Defines the position of the shape. Generally, you don't want to
change these values manually unless you want to teleport a given
shape to a particular position.

.xv .yv
Defines the velocity of a dynamic/kinematic shape.

.friction
Friction value applied when the edges of two shapes are touching.
Must be between 0 and 1.

.bounce
Bounce or restitution value of the shape. Must be between 0 and 1.

.damping
Linear damping of the shape. The damping value slows the velocity of
moving shapes over time.

.gravity
Gravity scale of the shape which is multiplied by the global gravity
value. Set this to 0 and your shape will not be affected by gravity.

.r
Radius for circle shapes.

.hw .hh
Half-width and half-height for rectangle shapes.

.left .top .right .bottom
Defines which edges of a rectangle shape can be passed through.

.onCollide(a, b, nx, ny, pen)
Collision callback providing the two colliding shapes, the collision
normal and the penetration depth. This callback must return true or
the collision will be ignored. Shapes should not be moved or destroyed
during this callback!


Limitations and problem cases of FizzX
======================================
    __
   /  \
   \__/
    /  \
   _\__/
  /  \
  \__/
Stacking
Piling two or more dynamic shapes on top of each other is a problem,
because there is no simple way to figure out which collision pair
should be resolved first. This may cause one shape to overlap another
in the stack even after their collisions have been resolved.
        __
   <---/  \
__ ____\__/___
  |    |    |
  |    |    |
Ledges between rects
This issue occurs with rows of static rect shapes. When a dynamic
shape is sliding on top of them it may get "blocked" by the ledge
between rects. The issue is resolved by explicitly specifying which
sides of the rect should ignore collisions, for example:
 rect.left = true
 rect.right = true

[Murii]

Can Fizz X be updated to support slope collision detection? If so where should i start looking for makeing changes?

[ivan]

Can Fizz X be updated to support slope collision detection?

I have thought about this and yes I might add support for it later on.
- One solution might be to add triangle shapes. Right angle triangles are fairly easy to support but if you want any type of triangle it becomes more complicated.
- Another solution which may be easier is to support is line shapes. Basically if you are on one side of the line you can pass through it, if you are on the other side of the line you can't. Lines could be used for representing walls or one-sided platforms and don't have the 'inside edges' problem like rects do. Another thing about lines is that they could be used for static shapes only.

If so where should i start looking for makeing changes?

For starters, make sure you have the latest code:
https://github.com/2dengine/fizzx
Open "fizz.lua" and look at lines 94-113. You can add new shape types there.
Next, look at 260-264. This is the collision table which has 3 tests: testRectRect, testRectCircle and testCircleCircle.
If you want a new shape type, you obviously need to add new tests.
These functions check if the two shapes are intersecting and return the collision normal and penetration depth.

[Murii]

Thanks for the info i'll definitely try to implement slopes.But only 45 degree and no slope vs circle because i dont think im capable of doing something like that.

P.S: I love how Fizz X works <3