bump.lua - minimal collision detection lib

[ishkabible]

The parentheses are merely for grouping, it's just a limitation of the parser. That said, everything is treated the same, (table):method() works too, and the colon syntax works for every kind of variable. Now, what you are mistaken not being able to use it for, is not being able to set a metatable. (So (3):something() could work, but since you can't set a metatable, you can't tell it where to look.)

what? I didn't say anything about metatables. my issue was specifically with syntax so yes, the parser is all that is concerned. I never stated that the colon syntax doesn't work on variables(in fact I stated just the opposite that it only works for variables and '(expr)' type expressions). No 3:somthing() wouldn't make much sense but I'm arguing the consistency of the syntax not semantics.

my argument is that there should be a production like...

Code: Select all

primaryexp ::= Number
                     | String
                     | tableconstructor
                     | nil
                     | false
                     | true
                     | '(' exp ')'

and anywhere any of those would be used; just use <primary_exp> instead as it would make the language more consistent in syntax. as the language is right now I have to remember specifically what types of expressions are viable in certain instances and there is a mixture of different answers to that.

there is at least 1 ambiguity that arises from my idea but it could be resolved without harm to existing code

the production(from the Lua manual)

Code: Select all

args ::=  `(´ [explist] `)´ | tableconstructor | String 

would be converted to...

Code: Select all

args ::=  `(´ [explist] `)´ | primary_exp

but because primary_exp also has the form '(' exp ')' it can be undecidable which production to use. luckily however these would have the same effect so if the '(' [explist] ')' production took precedence over primary_exp no harm would be done.

edit:
also when I said "special function call syntax" I wasn't very clear; I meant when you don't have to use () becuase you only have 1 argument and it's either string literal or table constructor.

[Kadoba]

The new demo is acting really weird for me. The old demo worked fine.

I'm not able to move and the coins will float in the air at a set y location and slide around as if they are on the ground but without friction. If I hold the window to pause the update for a couple of seconds then the coins will fall, bounce, and at their peak get stuck again. When I turn on fly I can move but only upwards.

[kikito]

Well, that's weird. I'm pretty sure that the new demo doesn't "block" the user if he's moving left/right. There is just no code for doing so. And the code that handles the vertical movement of coins has not changed; they should work the same in both versions.

Please check again that you have downloaded the latest version. Maybe it's a browser cache issue?

[Kadoba]

I've downloaded the one here: https://github.com/kikito/bump.lua/downloads. I'm sure it isn't a browser cache issue. Actually, the demo in your opening post works fine.

[kikito]

I've re-compressed and re-uploaded the .love file in the github downloads section. I hope this clears this up.

[tsturzl]

Not trying to bash you library, maybe I'm not completely understanding, but why not just use a simple Bounding Box solution. It offers the same benefits.

[kikito]

That's a good question. There are several differences.

• With a conventional bounding box algorithm you only get "whether two boxes collide or not". A boolean value. With bump.lua you also get a displacement vector, that you can use to align the boxes easily. But that is the smallest change - you could do a "single bounding box" function that returns the displacement vector (in fact, you can see that here).
• Bump.lua also uses a spatial hash, just like HC. This reduces the amount of tests that you do when checking an individual object for collisions. If you turn on the debug mode in the demo, the boxes and coins that are checked for collisions against the player are only those that "touch" the cells the player is in (4 at maximum). This means that for checking the player position, you do between 1 and maybe 10 bounding box checks against other objects. The same goes for each of the 20 coins. The demo has around 240 solid blocks. With a "bounding box only" it would have to do around 4500 bounding box checks per frame. With bump, it does a max of around 200, and usually less than that. The difference would be bigger with more moving objects. If all the blocks moved, it would be around 50000 vs 2600.
• That's the big advantage. An "extra" one is that you can also do "queries" in bump. You can tell it "invoke this function in all the items on this region". It will parse the cells on that region and give you the items on it, without having to parse all the objects. In the demo, this is used to update and draw only the objects on the screen, while the rest are ignored. This comes "for free" - it's used internally by bump to do certain tasks anyway. With a traditional approach, you would either have to parse all the objects and check whether they should be drawn/updated or not.
• Finally, you can also do the "check for collisions" in one region only. In the demo, only the visible items are checked for collisions. The rest are ignored - they don't get updated anyway.

You can check this last assessment by locating a falling coin, and moving away from it until it leaves the screen. Wait a few seconds, go back, and you will see it falling again, where it was before (this is approximate, since internally this uses the cells).

I hope this answered your question.

EDIT: I almost forgot: I put some extra time in getting the order in which the collisions are calculated so it worked "intuitively" for videogames. It's what I called "heuristics" previously. It basically means that you will get the collisions more or less in the order you would expect. This is useful when walking over a tiled floor. If you get the wrong tile first, your character might get "stuck".

EDIT2: Getting the "these two objects have stopped colliding" is also nice, and requires some work if you use the "traditional" approach. In bump.lua, you define a callback, and are good to go.

[Kadoba]

I've re-compressed and re-uploaded the .love file in the github downloads section. I hope this clears this up.

Yes it's working again.

[tsturzl]

Ah, that's actually really cool. I may use this in the future. I'm usually experimenting with physics engines in my games. If I'm not using box2D I'm usually just doing bounding box. Perhaps in future projects I can use this instead, sounds like it would save me a lot of hassle.

[kikito]

Let me know if you need help! I've investigated this for nearly a month. I reviewed HardonCollider pretty throughly, as well as a couple others. I even maintained some correspondence with the N tutorials guy, who was very helpful - most of the heuristic part comes from him. With this I mean that I have made a good deal of investigation.

Nevertheless, your message reaffirmed me in that I need to do some sort of performance testing. It's true that the amount of bounding box checks is smaller, but there is some overhead in parsing the 4 cells and updating every item. It could happen that the overhead is big enough to cancel the benefits. vrld uses luaprofiler to test speed in HC. I need to do something similar.