Forums » Impact Engine » Slope entities?

@arantor

Depending on how you look at it, you&039;re correct. To be clear, starting with #entity.js, this is what happens within an entity&039;s #update:

var res = ig.game.collisionMap.trace( 
  this.pos.x, this.pos.y, mx, my, this.size.x, this.size.y
);
this.handleMovementTrace( res );

For each entity update, ig.game.collisionMap.trace returns a res object after doing the "simple lookup" you describe while handleMovementTrace actually adjusts velocities and such depending on the properties of the res object.

An entity&039;s #update happens when the Game object&039;s #updateEntities is called within the Game object&039;s #update method.

After that, within the Game&039;s #checkEntities method, we sort out Entity collisions.

Isolating collisionMap tile collisions from Entity collisions is indeed simpler. But normally, both happen on every game update.

To answer your question, I&039;m doing essentially this in my Game's #update:

// grab a snapshot of the collisionMap data
var tmpData = ig.copy(ig.game.collisionMap.data);

// ensure that "row" 9 is always solid
tmpData[9].shift();
tmpData[9].push(1);

// randomly drop a "wall" in on row "8"
if (Math.floor(Math.random() * 2) != 0) {
  tmpData[width-1] = 2;
}

ig.game.collisionMap.data = tmpData;

// update the background map to reflect changes made to the collisionMap
ig.game.groundMap.data = ig.game.collisionMap.data;

I've also tried, without success, a similar approach that swaps out the entire collision map:

// grab a snapshot of the entire collisionMap
var tmpCm = ig.copy(ig.game.collisionMap);

// do stuff to its data

// use it as the new collisionMap
ig.game.collisionMap = tmpCm;

My next approach is going to be run the debugger when loading a collisionMap compared to modifying a collisionMap so I can see where the two differ. That's going to be somewhat tedious, but at this point I'm not sure there's much else I can do.

EDIT: fixed code formatting issues.

What's width, exactly? tmpData[width-1] is being updated but it's never clear what width is, are you sure that width is the same as tmpData.length?

@arantor

Sorry - I mangled the code snippet as I pasted it here.

It should read more like this:

var width = Math.floor(ig.system.width / this.tileSize);

// grab a snapshot of the collisionMap data
var tmpData = ig.copy(ig.game.collisionMap.data);

// ensure that "row" 9 is always solid
tmpData[9].shift();
tmpData[9].push(1);

// randomly drop a "wall" in on row "8"
if (Math.floor(Math.random() * 2) != 0) {
  tmpData[8][width-1] = 2;
}

ig.game.collisionMap.data = tmpData;

// update the background map to reflect changes made to the collisionMap
ig.game.groundMap.data = ig.game.collisionMap.data;

Also, I began to wonder, after explaining how collisions worked, if what I said was actually accurate.

On second pass, it's sort of right.

While its actually a bit tangential to this thread, it might but useful for those who might have been confused by what I'd said earlier if I tried to describe how collisions work. If anything I say isn't right, please do mention it - it's not the easiest thing to follow through the code.

Game#update calls the Game#updateEntities function. Game#updateEntities calls Entity#update on each entity. Entity#update calls ig.game.collisionMap.trace, passing in that entity's position, velocity, and size.

This is where it gets tricky.

ig.game.collisionMap.trace creates a res template, then populates that res template's properties using CollisionMap#_traceStep.

CollisionMap#_traceStep checks to see if the entity has horizontal velocity. If it has horizontal velocity it tries to determine if there&039;s a type of tile it can do something with at the collision map tile sharing the same space as the entity. If there is, it sets the #res object's properties accordingly.

It essentially does the same thing for vertical velocity.

During the trace it&039;ll call CollisionMap#_checkTileDef. If CollisionMap#_checkTileDef determines the tile it finds is a slope, it changes the #res.slope property from false to an object containing values that describe the "line" of the slope.

If it's not a slope, CollisionMap#_traceStep does other stuff not exactly relevant to slopes.

Then we're back to Entity#update. Now, keep in mind that so far we've not even done anything with Entity to Entity collisions.

Entity#update kicks off Entity#handleMovementTrace, passing in the results of the collision trace.

Entity#handleMovementTrace sets the entity&039;s horizontal and vertical velocity based on what it finds in the passed in #res object (which was populated in CollisionMap#trace).

Then it sets the horizontal and vertical velocity depending on the res.slope properties (if there are any) as well as the angle of the entity. Finally, it sets the entity&039;s position to be the same as that found in the #res object. Initially, during the CollisionMap#trace, res.pos is set to that of the entity it's checking collisions for. During the course of tracing, the res position can change, which is why it's eventually used in Entity#handleMovementTrace to set the entity's position.

Again, we've not yet dealt with Entity to Entity collision.

Once every entity in the game has been updated (each following the path I just described) Game#update calls Game#checkEntities.

Game#checkEntities then solves collisions for each Entity in the game. Entity collision is solved by calling Entity#checkPair, passing in entities that haven't been checked for collision yet, but have positions that overlap.

It's at this point I'll skip over some details for a bit because they definately get complicated. Entity#checkPair determines what kind of collision to apply, then solves that collision using Entity#solveCollision.

This is where it gets interesting. Regardless of the axis or type of collision, Entity#solveCollision ultimately uses CollisionMap#trace to work out the resolution to the collision, using that resolution to set properties (like velocity and position) on the affected pairs of entities.

So, to be accurate, slopes based on collisionMap tiles is simpler than slopes based on entities. ;)

OK, so again, how are you sure that width is right?

Sounds to me as though you need to push an item onto the list, rather than doing it that way.

That level of depth is great for understanding how collisions work in detail, but I think the problem you're having is that the collision map is being updated incorrectly rather than anything else. (And I stand by my original statement that an entity vs collision map will be faster than entity vs entity collisions, heh)

I figured out what my original problem was and I have to say - it takes a lot to come back here and admit it.

You know that thing about Occum's Razor?

Well, I give you exhibit A (aka, my original code):

update: function() {
this.parent();
/*
  do all sorts of stuff here
*/
}

And exhibit B (aka, the right way, at least in this case):

update: function() {
/*
  do all sorts of stuff here
*/
this.parent();
}

I knew that if you&039;re going to do anything to the "physics" of an Entity, you do so before you call #this.parent(). I just blindly pushed on, seeing it in the wrong place, not even thinking about it.

Ugh.

The silver lining is that I wrote and deleted a lot of amazing code in an effort to figure this out. All of which is safely stashed away in a git repo. I'll have to drag some of it back out and see if it would have worked after all.

Ouch! Having been bitten by such things in the past, I can fully understand the head-meeting-desk moment that would have ensued!

I'm just glad you figured it out :)