Supertux: Replace built-in physics engine with Box2D

[tobbi]

Our engine contains various physics bugs, most of which are hard to fix because I don't have any knowledge when it comes to physic engines.

I'd suggest replacing stuff with Box2D.

Check this out: http://box2d.org/

[busybody42]

WHAT?! Why? You can't just do that! Think of how many levels could be ruined and bugged if you changed it! You could just find another fan of Supertux that is good at physic engines!

[giby]

Hi buddy!

If you have a friend who is fan of supertux, and good at coding, with serious knowlege in physic engine, you are more than welcome to introduce him to the team… Tobbi is our only real coder… So help is welcome!

---

De : busybody42 [e-mail]
Envoyé : dimanche 25 mars 2018 19:18
À : SuperTux/supertux
Cc : Subscribed
Objet : Re: [SuperTux/supertux] Replace built-in physics engine with Box2D (#794)

WHAT?! Why? You can't just do that! Think of how many levels could be ruined and bugged if you changed it! You could just find another fan of Supertux that is good at physic engines!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/SuperTux/supertux/issues/794#issuecomment-375995784, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGNI8xyaxUBLmKjEq0NMvc2zaN3G86raks5th-2cgaJpZM4S6F5v.

[brmbrmcar]

I don't know much about the engine, but I'd be worried about the effects of this, and also the possible limitations of the Box2D engine, there are just things that happen in SuperTux I can't imagine are easy to implement on other engines. Also one day far in the future if a load of developers come along they might just want SuperTux to have its own engine.

But you can probably safely disregard everything I've just said.

[busybody42]

YEAH! I agree with brmbrmcar! It may ruin many add-ons, like matties world!

[christ2go]

There has been a discussion about this in 2010 (see irc log , around 18:30 ) . I don't know if points raised there are still relevant (grumbels general disliking of physic engines and an issue about tilemaps).

[maxteufel]

Just to update and document this: for now, the goal is to slowly refactor or at least update the physics code, so that we understand it better. If this is done, we can still decide whether to switch it out for a library (which should be easier at that point) or to leave it.

[J-128]

I have a proposition: How about adding an option in CMakeLists, where you can select to use either ST internal physics OR Box2D? I'm not sure just how you would do that, but I think it could work. Just an idea I had. Any opinions/thoughts?

[Alzter]

While you're at it, can you fix the entire game too?

[busybody42]

Ummm... WHAT DID YOU JUST SAY ABOUT THE GAME!?!?!? (UNACCEPTABLE!!!!)

[g--o]

As someone who developed a few basic physics engines myself, I must say it's one of these things that if you don't have to implement just don't bother. It's too easy to mess up and the payoff is mostly gaining knowledge and experience, and only very rarely a sufficient product.

I wouldn't mind help fixing it, as I encountered some of the bugs you've got here before, but I'm not sure it's the right way to go, especially to keep the project alive and easily maintained.

[Alzter]

http://makegames.tumblr.com/post/1136623767/finishing-a-game

[g--o]

@Alzter
I'm not saying I haven't finished the engine to the degree I wanted to or that we shouldn't if we want to. I'm saying that it's easy to find yourself reinventing the wheel once a new need for a feature arises. Physics engines constantly expand needlessly re-creating what already exists. A generic and feature ritch system built to be used on way more than one game.

[Mathnerd314]

So expanding on my tilemap comment from IRC all those years ago, Box2D doesn't support tilemaps currently. And it seems it would be a fair amount of work to add them. Erin in his Box2D discord said a month ago, "tile based games with box shaped characters are a real challenge." This was in reference to a post about ghost collisions: https://box2d.org/posts/2020/06/ghost-collisions/. Tilemap collisions are worst-case for the style of continuous collision that Box2D uses, because they have lots of internal edges and sharp corners. For this reason most Box2D games use circles for the character and a special edge-chain polygon shape for terrain that handles CD properly.

Also, Box2D doesn't accept contributed code, so the only way to add support for tilemaps would be to use an algorithm that turns the tilemap into an edge-chain, or to fork Box2D.

Personally, I lean towards forking Box2D, but if we fork it then there's the question of how much of it to preserve. We really only need the core rectangle algorithms and can skip most of the API. So in the end what's needed is actually writing a new physics engine from scratch, with references to Box2D and other continuous collision systems .