next »

[George Michaels]

Make it so that when Entity2 goes too close to Entity1, Entity 1 shoves 2 away, stating that it needs it's privacy.

+1

That gave me an idea. Right now the collision is resolved by penetration (circle-circle), so if I make Entity1 be offset by less and Entity2 by more then it might work. I'll try it out in the morning

[R.D.]

I really like Java for the most part. But if you want to go more hardware to make somthing faster... it punches you right were you stand.
I mean, how can it be that Java is SO slow to notice that there a midi device is sending data. A whole second, wtf

[Geti]

That gave me an idea. Right now the collision is resolved by penetration (circle-circle), so if I make Entity1 be offset by less and Entity2 by more then it might work. I'll try it out in the morning

Fwiw if you have a high enough tickrate (ie 30Hz or above) and you offset both by +-0.5x the penetration you'll get reasonably stable stacking physics, and none of that A pushed B pushed C through wall shit, unless you're warping objects on top of each other.

[George Michaels]

Fwiw if you have a high enough tickrate (ie 30Hz or above) and you offset both by +-0.5x the penetration you'll get reasonably stable stacking physics, and none of that A pushed B pushed C through wall shit, unless you're warping objects on top of each other.

That's kinda how it worked in the first place, I offset both by half the penetration in opposite directions from each other. I fixed it now by scaling the velocity of whatever is checking if it's moving toward the other entity (since the other entity will check too and adjust its own velocity).

The resolution code looks like this now (penetration is returned from the check):

Code:

// CALCULATE OFFSETS
s_Vec distance_norm = n_Vec::normalize(n_Vec::subtract(pc->position, entity_pc->position));
s_Vec position = n_Vec::scale(n_Vec::abs(distance_norm), penetration * 0.5);

// OFFSET ENTITY POSITIONS
pc->position = n_Vec::add(pc->position, position);
entity_pc->position = n_Vec::subtract(entity_pc->position, position);

if(n_Vec::dot(pc->velocity, distance_norm) < 0) {
    pc->velocity = n_Vec::multiply(pc->velocity, n_Vec::abs(distance_norm)); }

[Geti]

Seems janky that you're not returning directional information from the penetration check tbh.

I generally use a function that gets the minimum separation vector between shapes A and B, in the direction A should move, and then pass that to a callback along with A and B themselves - the callback can do what you're doing there (but adapted to any convex shape, not just circles as implied by your collision norm calc using positions) as well as any "physical" logic (eg bounce, friction, whatever) - means if I just want an overlap check I can build that as a callback and keep all my code nice and unified.

There's overhead from each step here, but that's a way I've found is reasonably reusable and easy to plug custom logic into on a case by case basis.

In semi-modern C (ie has stdbool and a game engine included) that might look something like

Code:

typedef bool (*collisionCallback)(const Shape&, const Shape&, const Vec2f&);

bool Collide( const Shape& A, const Shape& B, collisionCallback callback)
{
static Vec2f penetration;
Shape_getPenetration(A, B, penetration);
/* note that the callback is called even if penetration is (0,0) */
return callback(A, B, penetration);
}

(man I should add more disclaimers to make you REALLY trust this code, haha)

[George Michaels]

-snip-

I wanted to use callbacks but found (so far) that I haven't needed them. My circle-circle detection function simply checks if there is a collision and returns how far the circles are penetrating. It's up to the caller to deal with the response. In this case it's the entity-collision component.

[Geti]

That's the same thing as mine except A) you don't return a vector, you just return a distance of penetration (-> it only works for circles) and B) you have to write boilerplate every time, instead of just writing a function to pass the relevant information to.

[makerimages]

Im grupmy cuz Im in hospital and cant code! Luckily I should be out tomorrow

[Quarry]

What happened?

[makerimages]

Heart surgery (not open chest thankfully)tomorrow, I came in for a consultation, ill go out with a surgery-yay!

[George Michaels]

That's the same thing as mine except A) you don't return a vector, you just return a distance of penetration (-> it only works for circles) and B) you have to write boilerplate every time, instead of just writing a function to pass the relevant information to.

The way it is now, I don't need to return a seperation vector, just the penetration. I have other detection functions that return data relevant to their detection like circle-line returns penetration into the circle and the closest point on the line. But so far I've only got entity collisions (the circle-circle check we've been talking about) and world collisions (circle-line which uses a different response), so it's not an issue to write boilerplate code and I haven't really got a need for callback functionality just yet. The only situation I can think of that needs a different response is between the entity and a power up which I can do by just making collision response optional and letting the event handler deal with applying the powerup. I appreciate your help, I really do, but my game is pretty simple and I like my code pretty simple

[Geti]

I appreciate your help, I really do, but my game is pretty simple and I like my code pretty simple

No worries

Not really grumpy at the moment, just tired from porting a bunch of code from C++ to scripts, then realising various design issues with the original port so rewriting the functionality as nicer scripts, but it's mostly fallen into place, just been a drain. Always fun when you can attach something you've cleaned up to a catapult and have it function as a factory as well as a siege engine. I've got a feeling modders are going to have a field day upon release.

[pixhead]

Hey guys, I usually bash my head against the keyboard to try and solve my problems, but I'm completely stuck this time, I even posted on stack overflow, but haven't gotten any help yet. Do any of you know how to get a reference to a C++ object, from another C++ object, inside a Lua script? I don't really know how to summarize that in words properly, so let me elaborate with a Lua example first:

Code:

    function doSomething()
        compo = a:getComponent()
        compo:setVariable(0)
    end

a is a C++ object, and the function getComponent returns a pointer:

Code:

    // inside A.h
    Component* A::getComponent();

It seems the problem is that getComponent() is passing a copy of the Component object to Lua, instead of a reference. I come across the same problem with every function that returns a pointer, Lua cannot modify the original object.

Object a seems to be working correctly, if I modify a variable from within Lua, it's outcome is mirrored in C++.

Am I missing something syntactically or is there more to it than that?

I am using luabind, Lua 5.1, and MinGW for compiling. If anybody can help out, that would be quite swell.

[ThemsAllTook]

When something is almost perfect but has one or two fatal flaws, I think it bothers me a lot more than when something which is mediocre or poor all around.

Ruby is a really nice language...almost. It's crippled by the ridiculous anti-documentation culture surrounding it. It's nearly impossible to find reasonably complete documentation for pretty much anything beyond the bare bones basics. I can look at the source for pretty much everything, sure, but the dynamism of the language sometimes makes it completely impossible to follow. Rails is particularly bad in accepting arbitrary key-value pairs as function arguments, without providing you any help to know the exact set of values that are acceptable and what effects they all have.

On top of that, since there's no compiler to check my code before it runs, I have to actually execute a particular code path to find out of I've made a typo anywhere. Not a pleasant experience.

[Crimsontide]

When something is almost perfect but has one or two fatal flaws, I think it bothers me a lot more than when something which is mediocre or poor all around.

Ruby is a really nice language...almost. It's crippled by the ridiculous anti-documentation culture surrounding it. It's nearly impossible to find reasonably complete documentation for pretty much anything beyond the bare bones basics. I can look at the source for pretty much everything, sure, but the dynamism of the language sometimes makes it completely impossible to follow. Rails is particularly bad in accepting arbitrary key-value pairs as function arguments, without providing you any help to know the exact set of values that are acceptable and what effects they all have.

On top of that, since there's no compiler to check my code before it runs, I have to actually execute a particular code path to find out of I've made a typo anywhere. Not a pleasant experience.

I've never worked with Ruby, but Lua made me realize how much I love statically typed languages.  So I certainly can sympathize.

[ThemsAllTook]

I've never worked with Ruby, but Lua made me realize how much I love statically typed languages.  So I certainly can sympathize.

Indeed. Static typing ftw! I'm going to go write a nice C program and try to forget about Ruby for a while.

[George Michaels]

Just learnt that OpenGL 3.1+ has completely removed immediate mode glBegin-glEnd rendering...

Guess who's got to learn VBO's!....

[ThemsAllTook]

VBOs have a bit of a learning curve, but they're actually quite lovely once you get to know them.

[George Michaels]

VBOs have a bit of a learning curve, but they're actually quite lovely once you get to know them.

I can see the benefits and I'm definitely going to learn them, I'm just peeved that I have to relearn a large part of gl and rewrite my renderer

[powly]

If you weren't using vertex arrays before you learned this, you were already doing something wrong! I found them pretty straight forward, the only thing to really learn is to animate in vertex shader - which is very nice compared to doing it on the CPU anyway.