I had resolved myself to not post anymore but I now feel I must clarify somethings
for historical sake.
Quote: "I can't imagine that you seriously suggest rewriting all of Lee's work done over half a decade. I'm familiar with impressive physics related stuff you have shown us in the past but nothing much past that and I just know that this would take ages and probably dissolve in sand. This leads me to believe that you wish to recode all physics related elements of this engine which seems like a more reasonable undertaking."
First let me say I have not really done any thing that impressive with physics.
All I have done with physics was learn as much as I could about the Bullet Physics engine
and learn thru trial and error how to properly hook it up to a rendering engine(DBPro/AGK).
On top of that I took some other peoples (Open Source)work for example the V-HACD library
and used it to automatically create compound collision shapes. The only thing I have actually impressed
myself with is finding and fixing some bugs in the core of the Bullet physics engine but this was
done out of necessity while trying to use Bullet. Bullet is open source and I did contribute these fixes
back to the Bullet code.
Allow me to clarify, I am not suggesting rewriting all the work done on GG that would be insane and
probably not possible. For those that have not looked at the GG source let me explain GG is made
up of Libs mostly the original DBPro libraries and some extras for things like terrain and physics.
Code from these libs are called in the main engine. When the main engine was moved form DBPro
basic syntax to C++ it was not done correctly by C++ standards in my opinion. This makes it very difficult
and very time consuming to hook up to and debug. Some of that code would need to be put into proper
C++ classes and not left as a global soup of variables. The real slow down was with the way the Bullet Engine
was modified forcing it to fight itself for positioning of objects which would slow down any game engine.
The code that wraps the Bullet engine was also contradicting itself by trying to move kinematic objects with forces.
Enough about the errors, Over the past month I have actually solved this by removing the damaged Bullet
engine and replaced it with a newer version I have created the wrapper needed to call the basic physics
and I have it running in GG with a better terrain collision and correct dynamic and static objects.
Also I have kinematic objects which GG did not have before and a character controller which is not
slowing down the FPS when bumping into objects. Unlike most other users of GG I have been able to tell
that the physics was not right and was slowing down the whole engine. Until seeing the source code I could
not determine the exact problem. Over the past several years I have given Lee advice on how to use the
Bullet physics engine but without actually working on the code it was the best I could do.
Quote: "I'm fine with that. Personally I am just okay with the way physics are handled in GG. Enemies ragdoll, objects react to impact and can be thrown around. "
For those who may not be aware I was working on and using the Bullet physics engine in DBPro before
Lee was even using physics in Reloaded. I had already developed the ragdoll interface before ragdoll was
talked about in Reloaded. The current ragdoll in GG is the code I gave Lee for Reloaded and he was able to drop it in
and get it working.
Quote: "However, with the memory related issues we are currently facing I think improved physics are something not worth poking at. At least not now."
GG currently does not reuse collision shapes and you might say it is not a big deal but they use memory.
Every bit counts.
Quote: "I also have the feeling that minor flaws are being blown out of proportion here."
Maybe they are but from my knowledge and point of view GG is limping along.
I do not like being the bearer of bad news but Lee was well aware when he exposed the source code
that someone like me would look at the code and easily see the problems. Forget any physics you think
are fancy features a FPS game engine needs a properly working character controller for the player
and enemies and a properly working static terrain and static objects that do not slow down physics.
Good memory conservation and this intern makes it easy to have more enemies navigate the scene.
I am not asking any members for money, what I have done so far I have done without any promise
of compensation( more than 160 hours). I was just wondering like all of the community what is the future
of GG development and thought the community should be aware of my research of the source code.
I could have just looked at the code for 15 minutes and posted the problem but instead I put in the
time to prove what the problem was and I have a faster working GG.
The coffee is lovely dark and deep,and I have code to write before I sleep.