Hardoncollider with tilemap

[Refpeuk]

Sorry, posted too soon. Just wondering why now when pressing against an edge my character jitters.

[TechnoCat]

It jitters because of the order you handle input, resolve collisions, and draw.
I'm assuming right now it is resolve collision -> handle input -> draw.
Try doing handle input -> resolve collisions -> draw instead.

[Refpeuk]

Actually, that's not it. That was an issue earlier, but I fixed it. Right now here's the relevant code from my love.update():

Code: Select all

Keyboard:use(dt)  --includes character:move for keyboard controlled character

  collider:update(dt)

  cameraupdate(dt)

Thanks for the reply.

EDIT:
Here's one that you can change the tiles you place. 0 is blank, 1 is solid (map loads all solid) and 2-5 are corners that act the same as 1 collisionwise. The jittering seems to get worse the more I change the map, for some reason.

Any ideas?

[TechnoCat]

The jitter is caused by a combination of:

1. Colliding with more than one object at the same time.
   • You end up resolving 2 collisions and moving too far away.
   • You can verify by running into the corner and seeing it doesn't jitter.
   • Fix this by setting the map tiles to passive and the actor to active. (Well actually, that might not fix it )
2. Updating the image's position instead of the shape.
   • Only update the shape, draw the image at the shape's location. Otherwise you can have position sync issues.

[Refpeuk]

Thanks, the double-solving must be the problem, but how would I solve it? Also, why does my editing not work? It makes the bouncing worse and doesn't clear collision objects properly . . .

All my tile shapes are already set as passive, which boosted me from 3-6 fps up to 60.

As for the position sync issues, what I do is I have an x and y position in my character "class" that is solved with the minimum translation vector, and then I move both the image and the shape accordingly. Neither has precedent over the other.

[molul]

I'm using HOC on a tiled based platformer and had to change many things. The main reason for using it was for detecting sloped grounds properly. For instance, previously I moved the sprite with my velocity X and Y variables, and then the shape to the sprite's coordinates, but I found a better approach: moving the shape and then drawing the sprite with the shape's X and Y coordinates. I learnt this from vrld's "Not a game": http://vrld.org/downloads/notagame.love

I currently update the player's position, then calculate collisions and move the player with the minimum translation vector, and then draw the player's sprite with its shape's X and Y. There's still a few fixes pending, but it's working much better than before.

I can't have a look to the code now, but I'll do when I come back from work

[molul]

I've modified your character.lua (and I think main.lua too) so the character's shape is moving, not the sprite. It still doesn't fix the "vibration" when colliding, but I finished my coffee break and have to go back to work

[Refpeuk]

OK, thanks. I'll take a look at what you did. Since you've actually looked at my code do you have any helpful pointers about my methods/style?

I don't know if this will work in the long term, but to fix it I just only ever solve the collisions by half the mtv each frame. The maximum the player can collide with on the tilemap in the same direction is two, so this solves the whole collision in one frame, and a single-block collision in two frames, which is unnoticeable. This has solved the bouncing, but I still don't know if it's a permanent solution.

[molul]

Actually I found the code pretty neat. I prefer moving libraries (AnAL, HOC, hump, camera) to a "lib" directory, and classes like the player (character.lua) to a "class" directory, and leave just main and conf in the root directory, but it doesn't make the code better.

Not too much to add, honestly.

[tentus]

You do a lot of this:

Code: Select all

	if key == "w" then
		keyboard.w = 1
	end

it'd probably be easier conceptually if you used true and false, and a tiny (tiny) bit more efficient.