FastJ
FastJ copied to clipboard
fastjengine
[Feature Request]: 2D Physics Implementation
Origins of the Feature
Well, most Game Engines or Frameworks have some basic Physics implementation, like collision detection, rigid bodies, gravity and some of those sorts. And I think adding these features will be very helpful shortly.
The New Feature Idea(s)
A Physics Engine within FastJ to have Physics Simulation. Something basic to start could be good, like Collision detection between sprites, and basic Rigid Bodies collision and impact and stuff.
This could be implemented with some other library like JBox2D or LiquidFun (though, LiquidFun is mostly for Soft Body simulation) libraries, or if possible, FastJ's own Physics Engine.
A video demonstration of a basic feature :
https://user-images.githubusercontent.com/64217426/136381687-9773eb7e-7caf-4eb0-a32a-b986cb4136f8.mp4
This is a basic RigidBody simulation present in LiquidFun's Testbed.
Alternatives
In my opinion, there is no alternative for a Physics Engine 😅 !
However, to lower the pressure and the complexity and worriedness of this feature, because there are a lot of features yet to be implemented and improved, we can have this as a separate feature, which is just in the works. Maybe make a separate branch for it, work on it slowly. Also for the initiative, as I am opening this issue, I would love to work on this feature myself, if that's permissible 😅 !!
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Tasks needed to be achieved :
- [ ] Adding Box2D as a Physics Library. (Later in the future, if possible, FastJ would have its Physics Engine)
- [ ] Addition of Basic Physics Features :
- [ ] Rigidbodies -> Sprites or GameObjects which are required to have Physics are Rigidbodies.
- [ ] Gravity Implementation -> When in the air, GameObjects should fall to the ground, if Gravity is enabled.
- [ ] Mass Implementation -> GameObjects with heavier mass would fall down faster, whereas lighter objects fall slower.
- [ ] Force Generation -> Generating force which would make GameObjects move when any force is applied.
- [ ] Collision Detection -> Basic Collision detection between two GameObjects.
- [ ] Collision Impact -> When two bodies Collide, there is an impact on them and they move.
More features will be thought upon later.
That is certainly a larger task to take on. If you are sure you'd like to head this task, feel free to do so! That being said, I'd like to see you edit your original comment to include the different tasks you'd like to complete. We'll continue from there.
With how big of a project this would be, I don't see it being added in full to FastJ for another version or two. You've a lot of time to work on it as you like.
With how big of a project this would be, I don't see it being added in full to FastJ for another version or two. You've a lot of time to work on it as you like.
Well I know 😅 ! I know this, and I forgot to state that lets have it as a side project, and not make it tied to any specific version release of FastJ, so there is no worries or tension.
Well, so I include the features as tasks in the original Comment?
Yes! We'll want to see you update these as you make progress on the system.
Hi! I've been researching a bit and found a pure-java based physics engine called dyn4j. It is very well documented and has a lot of usage examples, so I feel that this might be easier to integrate into the engine, compared to JBox2D
Hi! I've been researching a bit and found a pure-java based physics engine called dyn4j. It is very well documented and has a lot of usage examples, so I feel that this might be easier to integrate into the engine, compared to JBox2D
Looking into it, it seems like a really nice alternative for JBox2D. Thank you very much!
Hello @Sammie156, after trying out the engine for a bit, it seems that is isn't possible (or is very difficult) to get a physics object's position while the physics simulation is running... otherwise it is a very good physics engine. To work around it, we may have to find a way to directly calculate it or convert the getChangeInPosition() that it gives into pixels (using Pixels Per Meter ideology) for pixel coords.
That is an interesting search! Thank you very much for doing this research!! Will look into working on this as soon as my table is cleared of other work!
For now, I'm going to delete the physics branch. Physics will definitely still play a substantial role in FastJ's future -- however, incoming repository changes require that there are no other branches to directly consider, especially not ones that are months out of date.