Immediate Mode Physics
Posted: Mon Feb 28, 2011 4:44 am
I have in the recent years been intrigued by the power of Immediate Mode APIs for our game projects. The advantages of Immediate Mode APIs (IM) over Retained Mode (RM) are already heavily appreciated in graphics APIs like OpenGL and DirectX.
It was first when I stumbled across Immediate Mode GUI I came to realize that this pattern could be extended to other fields of programming - and provide the same benefits.
When I wanted to add some physic effects to our latest project I was amazed that all physics libraries I came across used a RM API. Being a stubborn programmer (what game programmer isn't) I spent some weeks conforming the Chipmunk API to be IM - and I am very pleased with my initial results.
So what are the advantages I see in my fork compared to Chipmunk's current RM API:
Pros
I realize that my current test examples are not extensive and that there might be edge cases I currently do not support - and that's why I want to propose the idea of IM Physics to this board. If you are new to the idea of an IM API this post may read like ramblings. Hopefully though I have listed some pros that got you interested in the idea - and curious enough to ask questions.
Maybe an Immediate Mode API could be in the future of Chipmunk?
It was first when I stumbled across Immediate Mode GUI I came to realize that this pattern could be extended to other fields of programming - and provide the same benefits.
When I wanted to add some physic effects to our latest project I was amazed that all physics libraries I came across used a RM API. Being a stubborn programmer (what game programmer isn't) I spent some weeks conforming the Chipmunk API to be IM - and I am very pleased with my initial results.
So what are the advantages I see in my fork compared to Chipmunk's current RM API:
Pros
- No redundant states: No need to add and remove objects from cpSpace to make sure the physics library is in the same state as your game code - if you don't want to test against a object that frame, don't add it to your tests that frame.
- No need to create the whole physics world - only provide the physics objects required for that one frame. This enables you to stream physics data and minimize data redundancy - create the physics object once it's actually needed.
- You implement cpSpaceStep yourself - no need for cpBody's callbacks or cpShapes flags: If you need a different update function for cpBody that is the update function you call. If you only want to test collision between certain object's that's the only collision tests you call.
- You may optimize the use of physics beyond what the library writer forsee - you are always the best suited to evaluate what physics code you want called
- Chipmunk components become more reusable: cpSpaceHash, cpBody, cpShape, cpCollision are even less dependent on cpSpace. Start using physics code where you ordinary wouldn't because it is lightweight - use only the components you need for the task at hand.
- You are inn full controll of all memory allocated: No need for userdata fields - it's you memory. If you need additional fields just add cpShape to your own structure along with your other members.
- You implement cpSpaceStep() yourself
I realize that my current test examples are not extensive and that there might be edge cases I currently do not support - and that's why I want to propose the idea of IM Physics to this board. If you are new to the idea of an IM API this post may read like ramblings. Hopefully though I have listed some pros that got you interested in the idea - and curious enough to ask questions.
Maybe an Immediate Mode API could be in the future of Chipmunk?