[WIP] Crates

[svercl]

This PR adds in very basic crates.

I ran into some weird issues with indents in my code so I converted them to spaces.

[RandyGaul]

Hmm I would like to take a look, but it's impossible to diff since all the indentation was changed. If you can revert your indentation changes, then we can get a diff and do a merge.

[svercl]

Indentation commit is reverted.

[RandyGaul]

Hmm were the tile indices changed? It seems my map is not rendering the same after merge.

[RandyGaul]

Ah I see, it is here: https://github.com/RandyGaul/player2d/pull/6/commits/bd94421307419d765009ec5eaa0d1164b68cb958

Could you explain the idea of this change, so I can understand it?

[RandyGaul]

Ok for now I reverted the tile load function, and remapped your crate indices to show up properly again. I'll take a look at your crate physics code now :)

[svercl]

Thanks! I was having troubles with the indices, because it looks like there's gaps in the image filenames.

[RandyGaul]

Yep there definitely is gaps. I see what you were up to. So the strategy I had was to write out one of each crate to the sprite_map file with the editor, and then look into the text file to see the indices.

There are gaps in the tile names because I deleted a huge number of empty tiles that were exported from the original tilemap texture atlas.

[RandyGaul]

Wow you did a pretty good job with the crates! This turned out really nice! Thank you very much for the contribution :)

I went ahead and applied some minor tuning to your crate code to enhance the feel. Here are my tuning edits: https://github.com/RandyGaul/player2d/commit/7bae63d2c4934351deda1a8fdeea8145e18e4858

I made some small modifications. I noticed you were trying to use c2TOI from the player falling code. Since the player isn't the best example for crate stuff, I can see why you wanted to also copy it.

Luckily crates do not need TOI stuff, so it is safe to delete it. Also was able to safely delete the on_ground flag.

I gave the crates some gravity in the crate update function.

I moved the player to crate code out into its own loop. It does not need very many iterations to converge, because the crates are always moving away from the player. Also if we solve crate to player first, then do tiles, the effect is the solutions from crate to player will be invalidated by the tile solutions. This is a good thing to make sure the tile solutions are the strongest. This way the player can not easily push crates through tiles.

You can experiment by solving player to crate after crate to tile finishes, and see it lets the player more easily push crates through tiles.

I tuned down the resolution vector for the player to crate code. I also scaled the resolution vector by the manifold depth. This will push crates harder if the player is heavily overlapping the crate, and less otherwise. This makes the crate pushing feel a little more organic instead of rigid.

I fixed a bug with hit_something flag for early-out optimization.

Try it out and let me know what you think!

[RandyGaul]

Some notes for crate vs crate: I would make a similar loop to player vs crate, and solve it after player to crate. This way the priority is:

1) Crate to tile (top priority, so crates do not fall out of level) 2) Crate to crate 3) Crate to player

To enforce this priority, solve the lowest priority first, and highest priority last.

You will want to solve crates in the middle, player first, and tile last. Crates in the middle, because crate to crate scenarios can be much more complicated than crate to player, and you will want crates to converge nicely. You will need higher iteration count, and a higher resolution factor compared to crate vs player.

[RandyGaul]

Did a little more tuning of crate code. I noticed the crates didn't carry velocity properly -- it's because I forgot to describe one more step: velocity fixup step. I also added in some strong damping to simulate friction, and extra strong damping on the x-axis, as well as an overall velocity clamp.