WohlSoft Forums

A 2D Physics Engine for Games.

engine will have this for physcis ( needs for koopa's shell etc.)

Wohlstand wrote:Box2d, i s a physical engine http://box2d.org/, this will help to make good physics faster and easer.
But it is only calculator and doesn't doing graphics. The graphics render will be a SDL's and OpenGL's part.

Wohlstand can explain more..


from official site:

Spoiler

About
Box2D is an open source C++ engine for simulating rigid bodies in 2D. Box2D is developed by Erin Catto and has the zlib license. While the zlib license does not require acknowledgement, we encourage you to give credit to Box2D in your product.

Box2D Features

COLLISION
Continuous collision detection
Contact callbacks: begin, end, pre-solve, post-solve
Convex polyons and circles.
Multiple shapes per body
One-shot contact manifolds
Dynamic tree broadphase
Efficient pair management
Fast broadphase AABB queries
Collision groups and categories
PHYSICS
Continuous physics with time of impact solver
Persistent body-joint-contact graph
Island solution and sleep management
Contact, friction, and restitution
Stable stacking with a linear-time solver
Revolute, prismatic, distance, pulley, gear, mouse joint, and other joint types
Joint limits, motors, and friction
Momentum decoupled position correction
Fairly accurate reaction forces/impulses
SYSTEM
Small block and stack allocators
Centralized tuning parameters
Highly portable C++ with no use of STL containers
TESTBED
OpenGL with Freeglut
Graphical user interface with GLUI
Easily switch between tests using GUI
Test framework for easily adding new tests
Mouse picking and the bomb!
CMake build system files
DOCUMENTATION
User manual
Doxygen document with code comments
Active user forum

http://box2d.org/about/

I assume we will be making some changes to the physics though, right? I've used this engine a little bit before, and Mario's physics are much simpler, and the gravity, movement, friction, etc. is much slower in Mario games than in Box2D.

CaptainSwag101 wrote:etc. is much slower in Mario games than in Box2D.

...because some people used native graphics render instead OpenGL. And also if we will not use all Box2d's features, speed will be height.
But with Box2d you can control physics of A LOT OF items on one space:
there are a ~10000-30000 blocks, ~8000 BGOs and ~5000-6000 NPC's, but all NPC's will be inactive when level was started, and will activated by contact with player's camera's look. And also, will be DEactivated after 4secounds offscreen timeout, but bosses, and other items which are markered by "disable deactivation" will be activated all level play time before the level ends or it will be destroyed/killed.

CaptainSwag101 wrote:I assume we will be making some changes to the physics though, right? I've used this engine a little bit before, and Mario's physics are much simpler, and the gravity, movement, friction, etc. is much slower in Mario games than in Box2D.

Having advanced physics is nice, through, especially for those who prefer "innovative" over "vanilla" levels.
Because this will be a general platforming game engine, we need to give people freedom to customize the physics as far as possible. Do you think we can do a Sonic game being locked to Mario physics? If we're making a "space adventure" game with this engine, is gravity needed at all?

tb1024 wrote:

CaptainSwag101 wrote:I assume we will be making some changes to the physics though, right? I've used this engine a little bit before, and Mario's physics are much simpler, and the gravity, movement, friction, etc. is much slower in Mario games than in Box2D.

Having advanced physics is nice, through, especially for those who prefer "innovative" over "vanilla" levels.
Because this will be a general platforming game engine, we need to give people freedom to customize the physics as far as possible. Do you think we can do a Sonic game being locked to Mario physics? If we're making a "space adventure" game with this engine, is gravity needed at all?

I think the words "gravity"and "space" are the two words I'm looking at most here. Now Super Mario Galaxy was famous for introducing "sphere walking" or walking on small round planets where the gravity is much more than that used in standard side-scrolling platformers. If we could essentially make a 2-D type of "sphere walking" in PlatGEnWohl, not only would it be and incredible feat of engineering, but it would be probably one of the first "fan-mades" to actually use something so sophisticated. I don't know if it would be possible for this type of platformer or at least the SMBXtended side of things, but it could open up possibilities for Sonic fan-games since they use loop-da-loops quite frequently, and that is the 2-D "sphere walking" that I'm talking about.

Box 2d which will be created with this engine! Good resolution 800 * 600 or more and allow more?

ImperatoreXx wrote:Good resolution 800 * 600 or more and allow more?

800x600 is a SMBX's standard. I will make config settings:
- fixed resolution (for SMBX's configs), will play games with fixed 800x600 resolution but on resize of screen, it will be scalable.
- dynamic resolution, which will set your camera's size equal to your screen/window size.

very good! I have a lot of hope to see it in larger sizes!

Squishy Rex wrote:I think the words "gravity"and "space" are the two words I'm looking at most here. Now Super Mario Galaxy was famous for introducing "sphere walking" or walking on small round planets where the gravity is much more than that used in standard side-scrolling platformers. If we could essentially make a 2-D type of "sphere walking" in PlatGEnWohl, not only would it be and incredible feat of engineering, but it would be probably one of the first "fan-mades" to actually use something so sophisticated. I don't know if it would be possible for this type of platformer or at least the SMBXtended side of things, but it could open up possibilities for Sonic fan-games since they use loop-da-loops quite frequently, and that is the 2-D "sphere walking" that I'm talking about.

Yeah, that would be so awesome! However, I wonder how that would work with the editor, enemy algorithms, warps, etc. I imagine that it would be very difficult to program an enemy algorithm to seamlessly move around between flat and circular gravity.