Fix undefined reference when using make

[svercl]

This fixes compilation on GNU/Linux.

[RandyGaul]

Thanks!

[RandyGaul]

By the way it’s all in a good state to play with now. I still need to add feature for sloped tiles and falling off edges. Also going to use some free art packs to try and brighten the world and character. Depending on time I might also add in some features like wall grabbing. Let me know if you had any comments!

[svercl]

This is coming along quite nicely! I keep checking back on it, and I see you keep adding more. Is there anything else I could help with?

[RandyGaul]

If you want to add something, please do! This is a demo I'm writing for a presentation I'm giving this Friday at a local university. So it is just a toy, and I am adding in pretty much whatever I feel like :)

Right now I'm hooking up some animations for the hero. There is run/idle/jump. Then I will implement sloped tiles.

Here's my personal TODO list:

• ~Fix bug with z-fighting~
• Hook up ~run~/~idle~/~jump animations for the hero~
• ~Resize the player's geometry to match the hero animations~
• Implement sloped tiles
• Use the editor to place tile sprites around, and make a nice screen-sized scene
• Manually edit the map.txt file to place slopes/boxes over the tile sprites
• Add a button to toggle on/off the debug rendering
• Hook up and render the background sky
• [STRETCH GOAL] Place some dynamic boxes with the crate art, so the hero can push them around
• [STRETCH GOAL] Get the project running in browser via emscripten. I actually started this, but had to deprioritize the idea since I got stuck properly initializing GLES3.

Once these are finished, I will be pretty much done!

What kind of things would you like to add? I am not sure what you would be interested in. So here are some random ideas you might like:

• Play some audio for jumping, or other sound effects. cute_sound.h is a good candidate for very quickly hooking up audio: https://github.com/RandyGaul/cute_headers
• Implement a "dash" effect for the player. Since the player controller is swept, it should gracefully handle very high speeds.
• Implement an enemy -- it can perhaps push the player or make the player flash when touched. Maybe the spike tiles can be used, instead of some kind of enemy.
• Use the editor to make a nice tile scene. The controls print to stdout.
• Wall grabbing.
• Double jumping.

In general I'm open to ideas, and would be happy to merge in any pull request (as long as it doesn't bring in giant dependencies) :)

[svercl]

I just have a couple questions.

• Will this project continue after your presentation?
• Will the presentation be streamed anywhere?

Also, I am working on crates, but I'm not very good with physics in general. You can find my current progress here.

[RandyGaul]

1) I will likely finish up a few polish items on the demo, like put in some music, jump sound effect. Other than this, the only plans I have right now are to try and get it running on the browser. I want to create a webpage to demonstrate all the cute_headers by showcasing all the different examples in the browser. That is why I had made an attempt to compile this project with emscripten. 2) I don't think the presentation will be streamed, but it might be recorded. If it is not recorded, that's not a big deal since I will release the slides with all my notes on them.

I'll take a look at your crates progress and post some feedback.

Edit: Tonight I need to implement sloped tiles, and use the editor to finish the map. I might also put in music + jump sound fx if I have time.

[RandyGaul]

Great crate progress! I can't run the code here but can take a look when I get home. I'm very excited to have crates for the demo! I will share my thoughts on how I think the best strategy for implementing crates would look like:

• Only let crates react to the player, and do not apply any changes to the player's velocity or position when interacting with crates. In this way, it is as if the player has "infinite mass".
• Take a look at my NGS code here. You current code is quite close to this. The idea is to calculate a normal to push the player away from a tile by some small factor. The player requires a skin_factor, but crates do not (unless crates need to use c2TOI, then they need a skin_factor). But I do not recommend using c2TOI for crates.
• Resolve collisions by inspecting the manifold (from the c2AABBtoCapsuleManifold function), grab the normal, and gently push crates away from the player along the normal. Since crates are going to be the c2AABB or c2Poly shape (however you implement them), they can create one or two contact points in the manifold. If you go for the AABB route, you can ignore the second contact point and only deal with the collision normal. If you want the crates to rotate (which I don't recommend), you need to inspect both collision points and apply position adjustments using the cross product.
• In order for crates to properly stack upon one another, make sure when you resolve the collision, you apply a resolution factor that is much less than one, like 0.2f, and perform resolution in a loop. I also recommend scaling the resolution factor by the manifold's depth value (scaling by depth was omit from the player resolution code for c2TOI tuning reasons, but should not be omit for crates). Performing many small adjustments is what I meant by "gently". Something like this:

    for each iteration from 0 to N
        for each crate
            for each collision
                gently push crate away from the other shape

• This is called the Non-Linear Gauss Seidel method. After adjusting positions one final step is necessary: the velocity must be updated. A good strategy is to record each crates' position before resolution, and calculate the difference after resolution, and use this as the new velocity. Something like so:

    record each crate position in crate.old_pos

    for each iteration from 0 to N
        for each crate
            for each collision
                push crate away from the other shape

    for each crate
        v_delta = crate.pos - create.old_crate_pos
        create.vel = v_delta

• The player can not stand on crates with this strategy alone. I would consider the player standing on crates an isolated feature, to be solved with entirely different code as a specific case. This feature would be fairly difficult to implement. Roughly speaking, my preferred strategy would be to detect (with c2TOI) if the player will hit a crate, then tentatively move the player to the TOI, calculate a manifold, and inspect the manifold. If the manifold says the player will be "standing" on the crate (for example, the normal is pointing up and the contact point is near the player's feet), then the crate can be considered static and unmovable. From here the same algorithm used on tiles can be applied to the player, until the player starts interacting with the create from a new configuration (like from the player's side), where the previous crate pushing algorithm can be used.
• I won't be implementing crate standing for the demo, since it's quite a bit of work, and will just clutter the demo with unnecessary details.

If you have other questions please ask! You are already very close to implementing some good crate pushing, and there would not need to be a lot more code to get it working. It is just a matter of picking good algorithms, and a little bit of fine-tuning :)

[svercl]

Okay, I think I am starting to understand this a little more. I just pushed some changes. It's essentially the same code from player2d.h. I still have to do the collision between two or more crates. EDIT: Just thought I'd add that it's not quite perfect yet.

[RandyGaul]

Cool! If you want feedback make a PR, I'll merge it in, and take a look.