TGB Physics issues
by Chris Labombard · in Torque Game Builder · 05/10/2006 (3:23 pm) · 24 replies
Ok, continued from Justin's .plan :
I have found the physics engine in TGB to very unstable when dealing with anything beyond the simplest physics interactions. I have also had discussions with several people on irc who own the engine and are having the same issues, as well as seen posts from people on the forums with issues.
The issue is that the physics engine becomes unstable when doing any kind of physics simulation.
2 very notable things:
First, when the game loses focus, the physics just go nuts. If you have objects colliding with any others they gain momentum and bounce all over the place. This happens with both rigid and bounce collision types.
Secondly, I made a contianer with walls that had clamp collision type, and allowed several balls, with collision type rigid (or bounce) to freely fall under gravity to the bottom.
When they come to rest, they jitter, and if you pile too many up they will actually push the bottom ones out of the container in a huge jittery mess.
If you, at this point lose focus of the app, and come back, the balls that were sitting at the bottom, mostly at rest (besides jitter) have momentum and have bounced all over the place.
Also, when an object collides with 2 collision polys butted together it jitters back and forth.
I have tried everything I can think of to fix this, and asked several people who have had the same issues how they solved it, and they hadn't.
I have found the physics engine in TGB to very unstable when dealing with anything beyond the simplest physics interactions. I have also had discussions with several people on irc who own the engine and are having the same issues, as well as seen posts from people on the forums with issues.
The issue is that the physics engine becomes unstable when doing any kind of physics simulation.
2 very notable things:
First, when the game loses focus, the physics just go nuts. If you have objects colliding with any others they gain momentum and bounce all over the place. This happens with both rigid and bounce collision types.
Secondly, I made a contianer with walls that had clamp collision type, and allowed several balls, with collision type rigid (or bounce) to freely fall under gravity to the bottom.
When they come to rest, they jitter, and if you pile too many up they will actually push the bottom ones out of the container in a huge jittery mess.
If you, at this point lose focus of the app, and come back, the balls that were sitting at the bottom, mostly at rest (besides jitter) have momentum and have bounced all over the place.
Also, when an object collides with 2 collision polys butted together it jitters back and forth.
I have tried everything I can think of to fix this, and asked several people who have had the same issues how they solved it, and they hadn't.
About the author
I have been a professional game programmer for over 5 years now. I've worked on virtually every platform, dozens of games and released a few of my own games, including 2 iPhone titles and a title waiting release on Big Fish Games.
#2
Thanks for the feedback... you and others have been talking about the physics a lot lately, and as long as the feedback is constructive, it's helpful for us to hear how people are trying to use the physics in their games. Let me give you an update on all this stuff, and offer some advice and some solutions you can persue:
First off, we should be clear that the physics in TGB are going to stay as-is for the initial release. We will, in the future, be doing a pass at enhancing them. The main solution to the problems you are experiencing involves a few things: implementing regular-time tick simulation counting, doing some specialized stabilization / at-rest-condition code, and perhaps also pausing the simulation entirely if you take the game winow out of focus (or using another solution, such as elapsedTime thresholding, which can trade saved processor time for adherence to keeping physics objects in real-time sync).
On that last bit, we will likely release a resource in the coming weeks that you can easily integrate into your project so that your simluation pauses when the game loses focus... and that alone will fix a lot of the problems you mentioned. Justin implemented this solution for a game using TGB, and we want to share it with everyone, even if it can't go in to the full, official release.
However, in the overall scope of things... we view these kinds of physics changes as much, much, much lower priority than focusing on features like tools, better workflow overall, other engine features (some very cool stuff on deck that I won't discuss yet). I think everyone would agree that that is a smart way to go, given that only a small percentage of people need to use physics at all, and that only a some of even those need to use them in ways they don't currently handle well.
The physics system, as it exists today, is intended to enhance your ability to make certain kinds of games, and it is ****FAR**** beyond anything else provided by any 2D engine (and most any 3D engine). That said, it is by no means a guarateed way to do absolutely any and every kind of physics simulation possibly imaginable. It's not even close to that, and we don't claim it to be. But even the most advanced physics SDKs often have problems simulating stacks of objects in a stable way, and even the big 3rd party SDKs (Havok, PhysX, etc) can have problems with energy remainders in the system, etc.
What it comes down to is... physics is a ridiculously complicated thing to simulate in real-time. All physics sims are just gross approximations at reality, and each simluation solution has its own quirks. Our system is leagues above many other solutions available (especialy in 2D), but it's far from perfect. It never will be. So, as with any physics simulator, game developers who want to use physics in their game should take a careful look at what the physics system they plan on using does and does not do well, and then make their plans accordingly (or, decide to use a different physics system... there's nothing stopping you from plugging other physics systems into TGB, whether they be custom-built or 3rd party drop-in).
Again, the physics system as it exists today is pretty rockin.. it is not good at handling stacks of objects in a stable manner, you are right... nor a couple other kinds of things. So, it is good to point that out. And it's good for us to let you know we're aware of it, and that we're intentionally prioritizing our development plan around providing the most benefits to the most users. So, the solution, as withany physics system is... don't try to make games that require things it doesn't do well. :)
The built-in physics response system in TGB is being used to great effect in some very, very cool games that I've seen recently. In fact, it is a vital part of the gameplay in at least two games I know of, and I think both of them play great, they're both very stable and nearing completion, and I expect them to be extremely popular. :) So, clearly, it does some things right, and I'm glad it's in there, because otherwise these games (and I expect lots of others in the future) probably couldn't have been made.
I hope that helps clear things up. Hopefully I'm coming off the right way... just trying to explain how things work presently, and our reasoning on physics improvements going forward. Relative to other things we can spend our time on... the physics system is already in great shape, and we can help more people make more games by continuing to focus on tools and other more important engine features. To be clear, I do plan to make sure the physics system is further enhanced in the future. However, I wouldn't feel right about offering a timeline on that at the moment-- hate to say something and have people plan on it, and then not be able to come through for some reason.
Anyway, it is good to have this feedback on physics. It is helpful, especially when its phrased constructively. :) I think the quick simulation pause update that we will hopefully get out in the near future as a resource will be helpful for a lot of the issues you mentioned specifically, Chris. That'll also address a lot of the issues other people have mentioned. Beyond that, the best route is either to not make your game design dependent on features that the physics system doesn't handle well at the moment, to fix those issues (for stack stability in particular, there are definitely ways to work around it... turning off physics response once you're in a stack condition, etc), or to find another solution altogether if your dead-set on a particular set of functionality that the current physics system doesn't handle well.
05/10/2006 (4:01 pm)
Chris,Thanks for the feedback... you and others have been talking about the physics a lot lately, and as long as the feedback is constructive, it's helpful for us to hear how people are trying to use the physics in their games. Let me give you an update on all this stuff, and offer some advice and some solutions you can persue:
First off, we should be clear that the physics in TGB are going to stay as-is for the initial release. We will, in the future, be doing a pass at enhancing them. The main solution to the problems you are experiencing involves a few things: implementing regular-time tick simulation counting, doing some specialized stabilization / at-rest-condition code, and perhaps also pausing the simulation entirely if you take the game winow out of focus (or using another solution, such as elapsedTime thresholding, which can trade saved processor time for adherence to keeping physics objects in real-time sync).
On that last bit, we will likely release a resource in the coming weeks that you can easily integrate into your project so that your simluation pauses when the game loses focus... and that alone will fix a lot of the problems you mentioned. Justin implemented this solution for a game using TGB, and we want to share it with everyone, even if it can't go in to the full, official release.
However, in the overall scope of things... we view these kinds of physics changes as much, much, much lower priority than focusing on features like tools, better workflow overall, other engine features (some very cool stuff on deck that I won't discuss yet). I think everyone would agree that that is a smart way to go, given that only a small percentage of people need to use physics at all, and that only a some of even those need to use them in ways they don't currently handle well.
The physics system, as it exists today, is intended to enhance your ability to make certain kinds of games, and it is ****FAR**** beyond anything else provided by any 2D engine (and most any 3D engine). That said, it is by no means a guarateed way to do absolutely any and every kind of physics simulation possibly imaginable. It's not even close to that, and we don't claim it to be. But even the most advanced physics SDKs often have problems simulating stacks of objects in a stable way, and even the big 3rd party SDKs (Havok, PhysX, etc) can have problems with energy remainders in the system, etc.
What it comes down to is... physics is a ridiculously complicated thing to simulate in real-time. All physics sims are just gross approximations at reality, and each simluation solution has its own quirks. Our system is leagues above many other solutions available (especialy in 2D), but it's far from perfect. It never will be. So, as with any physics simulator, game developers who want to use physics in their game should take a careful look at what the physics system they plan on using does and does not do well, and then make their plans accordingly (or, decide to use a different physics system... there's nothing stopping you from plugging other physics systems into TGB, whether they be custom-built or 3rd party drop-in).
Again, the physics system as it exists today is pretty rockin.. it is not good at handling stacks of objects in a stable manner, you are right... nor a couple other kinds of things. So, it is good to point that out. And it's good for us to let you know we're aware of it, and that we're intentionally prioritizing our development plan around providing the most benefits to the most users. So, the solution, as withany physics system is... don't try to make games that require things it doesn't do well. :)
The built-in physics response system in TGB is being used to great effect in some very, very cool games that I've seen recently. In fact, it is a vital part of the gameplay in at least two games I know of, and I think both of them play great, they're both very stable and nearing completion, and I expect them to be extremely popular. :) So, clearly, it does some things right, and I'm glad it's in there, because otherwise these games (and I expect lots of others in the future) probably couldn't have been made.
I hope that helps clear things up. Hopefully I'm coming off the right way... just trying to explain how things work presently, and our reasoning on physics improvements going forward. Relative to other things we can spend our time on... the physics system is already in great shape, and we can help more people make more games by continuing to focus on tools and other more important engine features. To be clear, I do plan to make sure the physics system is further enhanced in the future. However, I wouldn't feel right about offering a timeline on that at the moment-- hate to say something and have people plan on it, and then not be able to come through for some reason.
Anyway, it is good to have this feedback on physics. It is helpful, especially when its phrased constructively. :) I think the quick simulation pause update that we will hopefully get out in the near future as a resource will be helpful for a lot of the issues you mentioned specifically, Chris. That'll also address a lot of the issues other people have mentioned. Beyond that, the best route is either to not make your game design dependent on features that the physics system doesn't handle well at the moment, to fix those issues (for stack stability in particular, there are definitely ways to work around it... turning off physics response once you're in a stack condition, etc), or to find another solution altogether if your dead-set on a particular set of functionality that the current physics system doesn't handle well.
#3
Will
05/10/2006 (5:15 pm)
@ Josh: I couldn't have said it better myself.. and I totally agree with what you said.Will
#4
I've got a physics based game in TGB as well. After more hours then it should have took, I managed to get the simulation mostly stable. It involved locking objects at certain times and using a lot of variance. It doesn't work the way I would have liked :( but I managed to adjust around the physics of the engine.
It's too bad time is so limited, or I would dive into the physics code and fix it. I don't imagine it would take too much. You've got the majority of what you need in there already. There's just not enough time :(
05/10/2006 (6:24 pm)
Thanks for the response. I'm glad phyics will be under your focus when the time is right. I understand why you're not working on it yet.Quote:
The built-in physics response system in TGB is being used to great effect in some very, very cool games that I've seen recently.
I've got a physics based game in TGB as well. After more hours then it should have took, I managed to get the simulation mostly stable. It involved locking objects at certain times and using a lot of variance. It doesn't work the way I would have liked :( but I managed to adjust around the physics of the engine.
It's too bad time is so limited, or I would dive into the physics code and fix it. I don't imagine it would take too much. You've got the majority of what you need in there already. There's just not enough time :(
#5
Really appreciated your message, certainly it took time and patience to write it all down.
I do agree that the physics engine is great and much more that's availble in the average maker. But It also has some very strange bugs.
In my case I'm doing just a pac-man like maze. Not really much involved, just collisions to stop the player from running over a wall. But instead, sometimes the player sticks to the wall and sometimes it's teleported to the opposite side or even the inside of the wall polygon.
I would love to dig into the code and try to solve the bug, but I don't know absolutely nothing, nada, of physics. So my suggestion would be to try to fix at least a small part of the physics code before releasing new stuff.
05/10/2006 (7:50 pm)
@Josh,Really appreciated your message, certainly it took time and patience to write it all down.
I do agree that the physics engine is great and much more that's availble in the average maker. But It also has some very strange bugs.
In my case I'm doing just a pac-man like maze. Not really much involved, just collisions to stop the player from running over a wall. But instead, sometimes the player sticks to the wall and sometimes it's teleported to the opposite side or even the inside of the wall polygon.
I would love to dig into the code and try to solve the bug, but I don't know absolutely nothing, nada, of physics. So my suggestion would be to try to fix at least a small part of the physics code before releasing new stuff.
#6
Thanks for bringing this discussion to the forums. I see much more clearly what you're talking about now that you are able to speak freely. I've thrown together a simple, unsupported patch to pause the simulation when the window loses focus on the windows platform (not sure if this is an issue on mac/linux?)
Hope this helps out in someway!
Cheers,
-Justin
Pausing TGB When the window loses focus
05/10/2006 (8:55 pm)
Chris,Thanks for bringing this discussion to the forums. I see much more clearly what you're talking about now that you are able to speak freely. I've thrown together a simple, unsupported patch to pause the simulation when the window loses focus on the windows platform (not sure if this is an issue on mac/linux?)
Hope this helps out in someway!
Cheers,
-Justin
Pausing TGB When the window loses focus
#7
@ Josh... thank you for dedicating so much for TGB . I hope to see the engine grow and the physic fixed :)
here is my post before about the TGB physic
www.garagegames.com/mg/forums/result.thread.php?qt=42426
As been said the physic is very unstable .Some times bugs just come out from nowhere . The engine code is very complicated for me as C++ is not my best field. Fixing one problem in the engine lead to another problem ( for me).What I think is the new animation builder and level builder integreted in TGB beta 3 should have less priority than the physic bugs. As the physic is very important to the game play and can not be miss calculate.
I would if I could fix the pyhsic bugs myself but I just can't get everything all corrected.
@ GG crew ..Keep up the great work. You guys are the best !!!
@Chris .. I wanna ask you what type of problems you had in you game and how you fixed it .Thank you in advance..:)
Aun
05/10/2006 (9:18 pm)
@ Will ... I know the engine is cheap and i think it is worth buying it ,no question about that but I don't think i can relax from the bugs i met in TGB wonder why? Because my company just shift from the J2me bussiness to the PC cansual game trend. I mean totally shifted ,totally quit making J2me games and moving forward for some PC games with TGB . For now,we planed that our main income will be coming from games made from TGB. So waiting for bug fixes for months might not be acceptable in my case.@ Josh... thank you for dedicating so much for TGB . I hope to see the engine grow and the physic fixed :)
here is my post before about the TGB physic
www.garagegames.com/mg/forums/result.thread.php?qt=42426
As been said the physic is very unstable .Some times bugs just come out from nowhere . The engine code is very complicated for me as C++ is not my best field. Fixing one problem in the engine lead to another problem ( for me).What I think is the new animation builder and level builder integreted in TGB beta 3 should have less priority than the physic bugs. As the physic is very important to the game play and can not be miss calculate.
I would if I could fix the pyhsic bugs myself but I just can't get everything all corrected.
@ GG crew ..Keep up the great work. You guys are the best !!!
@Chris .. I wanna ask you what type of problems you had in you game and how you fixed it .Thank you in advance..:)
Aun
#8
Thank you. That will help a lot. That alone makes it so I can work out the physics jitters if I decide to. I couldn't before because even if I got them worked out when it lost focus my simulation was toast.
Aun,
I described my problems in the first post of this thread. The balls in my simulation, under constant force, jitter very bad when sandwiched between the floor of the container... and when the game loses focus the simulation goes nuts and the balls gain momentum and fly all over.
The second problem will be fixed with Justin's patch.
The first problem, there is no fix for it. This is a match 3 game, so what I did was every time a ball collides with something I check to see if it is within a locking tolerance distance to set lock point markers. If it's close enough and will be sitting on top of another ball then it locks into place. It doesn't give me the gameplay I wanted, but the gameplay it gives is still fun.
05/11/2006 (6:35 am)
Justin,Thank you. That will help a lot. That alone makes it so I can work out the physics jitters if I decide to. I couldn't before because even if I got them worked out when it lost focus my simulation was toast.
Aun,
I described my problems in the first post of this thread. The balls in my simulation, under constant force, jitter very bad when sandwiched between the floor of the container... and when the game loses focus the simulation goes nuts and the balls gain momentum and fly all over.
The second problem will be fixed with Justin's patch.
The first problem, there is no fix for it. This is a match 3 game, so what I did was every time a ball collides with something I check to see if it is within a locking tolerance distance to set lock point markers. If it's close enough and will be sitting on top of another ball then it locks into place. It doesn't give me the gameplay I wanted, but the gameplay it gives is still fun.
#9
The pause on lose focus pach will help me greatly, however, has anyway come up with a solution to the jitters yet?
I had code to set the collision type from RIGID to STICKY when the object touched the bottom of the well, but unforunately, which this solution may have only worked if I had round objects, which I do not.
Thanks.
05/18/2006 (7:36 am)
Just curious...I'm also developing a game with a 'well' that involved dropping objects in. I also am having an issue with the 'jitters' when the objects come to rest. I tried playing with the damping, friction, mass, etc, etc, all to no avail. I also see the issue where when there's many objects, they push the bottom ones out of the well.The pause on lose focus pach will help me greatly, however, has anyway come up with a solution to the jitters yet?
I had code to set the collision type from RIGID to STICKY when the object touched the bottom of the well, but unforunately, which this solution may have only worked if I had round objects, which I do not.
Thanks.
#10
What you need to do is code some rest code or stabalization code... and then share your work :)
05/18/2006 (8:05 am)
Quote:he main solution to the problems you are experiencing involves a few things: implementing regular-time tick simulation counting, doing some specialized stabilization / at-rest-condition code
What you need to do is code some rest code or stabalization code... and then share your work :)
#11
05/18/2006 (8:19 am)
I'll try and figure something out tonight.
#12
after i tried playing the prototype i made . I found out the physic is too unstable .It was very hard for me to decide that i would stop with TGB and go with the sexyapp framework .
if any one could find a way to fix all the pyhsic bugs i would be really happy ... and give that person a big hug and kiss
:)
05/18/2006 (10:16 am)
Just a conclusion to my game developmentafter i tried playing the prototype i made . I found out the physic is too unstable .It was very hard for me to decide that i would stop with TGB and go with the sexyapp framework .
if any one could find a way to fix all the pyhsic bugs i would be really happy ... and give that person a big hug and kiss
:)
#13
You sure do give up easily ;)
05/18/2006 (10:50 am)
Well, with the focus fix the only problem is really determining when and how to make objects come to rest properly. If you know a little about physics and can program, you can probably come to a solution fairly quickly. You sure do give up easily ;)
#14
meaning when i create 200 objects moving around my screen ,chances are that 2 objects collision call back will not be call at all when they are collided.
i tried with the space scroller on my note book and tested the collision call back and notice 1 collision call back missed.. meaning the enemy missle is runing is the direction that must hit the player's ship but the collision call back wasn't called ...
well when i was doing the j2me bussiness i usally code 1 game in no more than 2 weeks but this pyhsic stuff in the engine i been trying to fix for about 2 weeks already and got nothing from it.
I don't think wasting more time trying to fixsomething that (the engine's code) complicated will do me any good . Using a framed-base framework like sexyApp might be easier for me and checking the collision myself might give me the result i need.
Ok saying what i just said, doesn't mean I think the engine is not good and not worth what I paid. I think the TGB engine is the best 2d engine I had ever used. But the game I am doing is just not suitable with the TGB engine. If I have my next project I will use the TGB engine for sure.
@ GG crew , please know that I am not trying to complain or so. I really appreciate your work and love it. Just want you to know there are some problems in the engine ,that my skills can not fix.
Aun :)
05/18/2006 (8:58 pm)
@ Chris ..in my game there could be up to about 200+ objects and from the prototype the collision call back will miss with the ratio about 1 in 100...meaning when i create 200 objects moving around my screen ,chances are that 2 objects collision call back will not be call at all when they are collided.
i tried with the space scroller on my note book and tested the collision call back and notice 1 collision call back missed.. meaning the enemy missle is runing is the direction that must hit the player's ship but the collision call back wasn't called ...
well when i was doing the j2me bussiness i usally code 1 game in no more than 2 weeks but this pyhsic stuff in the engine i been trying to fix for about 2 weeks already and got nothing from it.
I don't think wasting more time trying to fixsomething that (the engine's code) complicated will do me any good . Using a framed-base framework like sexyApp might be easier for me and checking the collision myself might give me the result i need.
Ok saying what i just said, doesn't mean I think the engine is not good and not worth what I paid. I think the TGB engine is the best 2d engine I had ever used. But the game I am doing is just not suitable with the TGB engine. If I have my next project I will use the TGB engine for sure.
@ GG crew , please know that I am not trying to complain or so. I really appreciate your work and love it. Just want you to know there are some problems in the engine ,that my skills can not fix.
Aun :)
#15
How many collision iterations are you using?
is what I'm using.
Perhaps that might help you out.
Not all games are :) Let me know how your other solution works out. SexyApp or whatever it is.
05/18/2006 (9:29 pm)
I find that odd, since most objects I'm using call more collisions then they need to... If one of my objects collides with another, I usually get multiple collision call backs. How many collision iterations are you using?
%object.setCollisionMaxIterations(2);
is what I'm using.
Perhaps that might help you out.
Quote:
But the game I am doing is just not suitable with the TGB engine.
Not all games are :) Let me know how your other solution works out. SexyApp or whatever it is.
#16
Well, right now, any project with many collisions in real time is not suitable for TGB.
The collision callback miss too often to be reliable at all. Less FPS you have, worth it get (try your game while running an antivirus scan, and you'll see that its not only a FPS dropoff hapening to your game, collisions are heavily affected by the drop, and any "setCollisionMaxIterations" wont do anything).
I dont own the source code, so all I can do is waiting until an official patch :/
08/08/2006 (11:47 am)
Quote:Ok saying what i just said, doesn't mean I think the engine is not good and not worth what I paid. I think the TGB engine is the best 2d engine I had ever used. But the game I am doing is just not suitable with the TGB engine.
Well, right now, any project with many collisions in real time is not suitable for TGB.
The collision callback miss too often to be reliable at all. Less FPS you have, worth it get (try your game while running an antivirus scan, and you'll see that its not only a FPS dropoff hapening to your game, collisions are heavily affected by the drop, and any "setCollisionMaxIterations" wont do anything).
I dont own the source code, so all I can do is waiting until an official patch :/
#17
Could you provide me with a simple code example so that I can see exactly what is happening?
- Melv.
08/09/2006 (7:39 am)
Benjamin,Could you provide me with a simple code example so that I can see exactly what is happening?
- Melv.
#18
I precise that I'm pretty new to Torque (got T2D 1 month ago), but not new to circumvent source code with only limited scripting languages, it is something that I have some past experience with:
In a plateformer, constantforceY with buggy CLAMP physics are no good when the player is on the ground, it will stick, or slide, or a little of the both. Of course, I tried first to follow the platformer tutorial, but this is how it gets.
I suppose that as long as you have angular flat platform, Clamp may be ok.
But, I wanted my game to have slopes, and the player to be able to run on it naturally, but the player get stuck every time with CLAMP or slide down with the gravity. My main focus was only ground, walls comes after.
I tried to simply not use physics at all.
I disabled receive and send physics for the $player class and I wrote a very simple code for starter:
"constantForceY" is active, but, when player collide with a platform, "setlinearvelocityy(0)" override it and stop the player, and if you go out of the platform the player will fall again (without any additional code).
It's good, but for the player to go up the slope I needed to do a little trick. I mounted a little dummy object just upper of the feet of the player imagemap like this:
dragon.six.free.fr/deviantgames/gnia1.jpg
And I tweaked the script like this:
$dummymount is the dummy object mounted to the player. If it collides with a platform, it means that the player is getting in it, so it will go up.
With this, I'm getting a player that run, and fall nicely. Jumping needed another little trick to work, since "setlinearvelocityY" is also used in player collision.
It is a very basic jump function, copied from the tutorial in TDN. But with some additional things:
And finally
The final result run pretty silk on my computer, but it highly depends on FPS.
If FPS drop, the player go INTO the ground after a jump, and higher is the jump, worth it get.
I tested it on a lower config (a 1500mhz Celeron with low-end CG): I don't even see the player character: it go thru the ground on the first second.
Now, what can I do to have walking and jumping character without any issues?
If i cant rely neither in built in physics (clamp...) or collision detection (depend on FPS), what can i do ?
And, what if I must again rely on collisions if I go thru this ?
(Sorry if I'm not very clear in my explanations, I'm trying my best)
08/09/2006 (10:01 am)
(Sorry for my bad English, I'm trying my best to be understandable)I precise that I'm pretty new to Torque (got T2D 1 month ago), but not new to circumvent source code with only limited scripting languages, it is something that I have some past experience with:
In a plateformer, constantforceY with buggy CLAMP physics are no good when the player is on the ground, it will stick, or slide, or a little of the both. Of course, I tried first to follow the platformer tutorial, but this is how it gets.
I suppose that as long as you have angular flat platform, Clamp may be ok.
But, I wanted my game to have slopes, and the player to be able to run on it naturally, but the player get stuck every time with CLAMP or slide down with the gravity. My main focus was only ground, walls comes after.
I tried to simply not use physics at all.
I disabled receive and send physics for the $player class and I wrote a very simple code for starter:
function player::oncollision(%srcobj, %dstobj, %srcref, %dstref, %time, %normal, %contactcount, %contacts)
{
if(%dstobj.class $= "Platform")
{
$player.setlinearvelocityy(0);
}
}And, well, it works XD"constantForceY" is active, but, when player collide with a platform, "setlinearvelocityy(0)" override it and stop the player, and if you go out of the platform the player will fall again (without any additional code).
It's good, but for the player to go up the slope I needed to do a little trick. I mounted a little dummy object just upper of the feet of the player imagemap like this:
dragon.six.free.fr/deviantgames/gnia1.jpg
And I tweaked the script like this:
function dummymount::oncollision(%srcobj, %dstobj, %srcref, %dstref, %time, %normal, %contactcount, %contacts)
{
if(%dstobj.class $= "platform")
{
$Player.dummycollide = true;
$Player.setlinearvelocityy(-25);
}else
{
$Player.dummycollide = false;
}
}
function Player::oncollision(%srcobj, %dstobj, %srcref, %dstref, %time, %normal, %contactcount, %contacts)
{
if(%dstobj.class $= "platform")
{
if(!$Player.dummycollide)
{
$Player.setlinearvelocityy(0);
}
}
}$dummymount is the dummy object mounted to the player. If it collides with a platform, it means that the player is getting in it, so it will go up.
With this, I'm getting a player that run, and fall nicely. Jumping needed another little trick to work, since "setlinearvelocityY" is also used in player collision.
It is a very basic jump function, copied from the tutorial in TDN. But with some additional things:
function Playerjumpbutton()
{
if(!$Player.nojump)
{
$Player.nojump = true;
$Player.jumpbegin = true;
$Player.setlinearVelocityy(-15 * $Player.heightjump);
$Player.schedule (100, "jumpend");
}
}
function Player::jumpend(%this)
{
$Player.jumpbegin = false;
}And finally
function dummymount::oncollision(%srcobj, %dstobj, %srcref, %dstref, %time, %normal, %contactcount, %contacts)
{
if(%dstobj.class $= "platform" && !$Player.nojump)
{
$Player.dummycollide = true;
$Player.setlinearvelocityy(-15);
}else
{
$Player.dummycollide = false;
}
}
function Player::oncollision(%srcobj, %dstobj, %srcref, %dstref, %time, %normal, %contactcount, %contacts)
{
if(%dstobj.class $= "platform")
{
if(!$Player.dummycollide && !$Player.jumpbegin)
{
$Player.setlinearvelocityy(0);
$Player.nojump = false;
}
}
}"$player.jumpbegin" is used to stop the oncollision reaction. The function "player::jumpend" is used to set "$player.jumpbegin" to false after a schedule of 100 (enough time to leave ground).The final result run pretty silk on my computer, but it highly depends on FPS.
If FPS drop, the player go INTO the ground after a jump, and higher is the jump, worth it get.
I tested it on a lower config (a 1500mhz Celeron with low-end CG): I don't even see the player character: it go thru the ground on the first second.
Now, what can I do to have walking and jumping character without any issues?
If i cant rely neither in built in physics (clamp...) or collision detection (depend on FPS), what can i do ?
And, what if I must again rely on collisions if I go thru this ?
(Sorry if I'm not very clear in my explanations, I'm trying my best)
#19
08/16/2006 (5:03 pm)
Benjamin, Im also new to TGB and I have the same problem, did you resolve it?
#20
Don't call "player.update" (or player.updatemovement) anywhere else than here :
08/16/2006 (5:10 pm)
Yes, use CLAMP for physics and dont use my dummy mounted object. You can keep the idea of "setlinearvelocityY(0)" if you found it usefullDon't call "player.update" (or player.updatemovement) anywhere else than here :
function t2dscenegraph::onupdatescene()
{
$player.update;
}put this code and you wont get stuck anymore.
Torque 3D Owner Will Zettler
Just a thought after reading all your posts about the engine's physics... you do know first off that the engine is low priced for what you get, I got in on the $80 deal myself and found the engine to do everything primised. Now as far as your notes go... sure there may be a few probs still with the engine but someone, maybe yourself, may make a fix for what your thinking is a major problem. Relax a little, as you are stressing over something that may show a fix in the coming weeks or months. The GG fan base (Including myself) are always releasing MODs or some kind of add-on to help improve the engines in some way or another.
My point, just relax a little and see what comes from the coming months. Who knows you may see something come about in the physics area that improves it better then what you even expect it to do. Sure there are bugs but they (GG) are working to kill them in the final release. If they see your problem in the engine they will fix it. Good luck with your game and hope this helps some...
Sincerely,
Will Zettler
Digital Lightstorm
dlstorminc@yahoo.com
http://dlstorminc.fortunecity.com