Getposition() and Drawn Sprite
by DragonSix · in Torque Game Builder · 04/03/2007 (12:26 pm) · 11 replies
I'm surprised nobody asked about that, but I saw this in my game...
Setlinearvelocity is not as smooth as it was before, sprites are moving little by little (skipping many pixels each time) instead of regularly moving. It's particularly ugly when I have a mounted camera to it.
Why is it like this ? And what can I do to fix that ?
Setlinearvelocity is not as smooth as it was before, sprites are moving little by little (skipping many pixels each time) instead of regularly moving. It's particularly ugly when I have a mounted camera to it.
Why is it like this ? And what can I do to fix that ?
#2
It sounds to me like you may be experiencing problems with the Fixed Time-step physics simulation in 1.5. Can you provide an example project that demonstrates the inconsistency in a .zip file per chance? Being able to clearly see what you're talking about, rather than trying to best-guess reproduce it on our end would...
1) Save us time debugging your issue
2) Allow us to confirm that any fixes we make solve exactly the issue you're experiencing as well.
Thanks!
-Justin
04/04/2007 (2:36 pm)
Hi Benjamin!It sounds to me like you may be experiencing problems with the Fixed Time-step physics simulation in 1.5. Can you provide an example project that demonstrates the inconsistency in a .zip file per chance? Being able to clearly see what you're talking about, rather than trying to best-guess reproduce it on our end would...
1) Save us time debugging your issue
2) Allow us to confirm that any fixes we make solve exactly the issue you're experiencing as well.
Thanks!
-Justin
#3
In fact, the sprite is running smoothly, but it is its collision polygon which is not.
My camera system is positioning the camera object relative to the player position at each frame.
But, "getposition()" return only the position of the collision polygon, not the sprite itself (which is at a little different position while moving). Thats why my game is ruined and look cheap on 1.5.
So if I was able to take the position of the sprite instead of the collision poly, it would resolve my issue.
Am I right ?
If you still need a demo, give me an email address so I can send it to you.
04/04/2007 (11:03 pm)
I think I found what is the problem !In fact, the sprite is running smoothly, but it is its collision polygon which is not.
My camera system is positioning the camera object relative to the player position at each frame.
But, "getposition()" return only the position of the collision polygon, not the sprite itself (which is at a little different position while moving). Thats why my game is ruined and look cheap on 1.5.
So if I was able to take the position of the sprite instead of the collision poly, it would resolve my issue.
Am I right ?
If you still need a demo, give me an email address so I can send it to you.
#4
04/04/2007 (11:11 pm)
I don't know if you have maybe missed it but you can actually mount the SceneWindow to a SceneObject for the purpose of a camera. 
#5
04/05/2007 (12:12 am)
Hm, I just saw this thread. I posted a problem in www.garagegames.com/mg/forums/result.thread.php?qt=60150 that might be something similar?
#6
@Magnus
It doesn't seems to be the same thing (mounting is working as much as expected with me), what I encounter here is about getposition(), which return the collision polygon position and not the actual sprite position (since these 2 are a little different, while moving, with 1.5).
Having an alternative to getposition() related to the actual drawn sprite would save me.
04/05/2007 (12:23 am)
@OliverQuote:I don't know if you have maybe missed it but you can actually mount the SceneWindow to a SceneObject for the purpose of a camera.Of course... Unfortunately I'm speaking about a more advanced and personalized camera system, which may require to know the real position of one or more sprites for positioning itself according to the game context and for precise parallax backgrounds.
@Magnus
It doesn't seems to be the same thing (mounting is working as much as expected with me), what I encounter here is about getposition(), which return the collision polygon position and not the actual sprite position (since these 2 are a little different, while moving, with 1.5).
Having an alternative to getposition() related to the actual drawn sprite would save me.
#7
That sounds very interesting. Did you make a camera similiar to the one in the old platformer Gizmo(if you know it)? The camera always trying to catch all the important action...
04/05/2007 (12:33 am)
@Benjamin:That sounds very interesting. Did you make a camera similiar to the one in the old platformer Gizmo(if you know it)? The camera always trying to catch all the important action...
#8
Not every time (I don't know Gizmo), but better than a simple "mounted to player" with some times where the camera is able to lock on to important point while still following the player movement at the same time.
But the real big issue is that I need to be able to have a good parallax system, and, if I try to somehow fix the issue by scripting a workaround, I'll lose that. Because nothing is better than having a camera object for that purpose (using getCurrentCameraPosition() is far less reliable and cause many junkiness on parallax movement because the returned position is never exact).
I really hope there'll be a solution.
04/05/2007 (6:02 pm)
@OliverNot every time (I don't know Gizmo), but better than a simple "mounted to player" with some times where the camera is able to lock on to important point while still following the player movement at the same time.
But the real big issue is that I need to be able to have a good parallax system, and, if I try to somehow fix the issue by scripting a workaround, I'll lose that. Because nothing is better than having a camera object for that purpose (using getCurrentCameraPosition() is far less reliable and cause many junkiness on parallax movement because the returned position is never exact).
I really hope there'll be a solution.
#9
I send you a mail to justindgaragegames[dot]com with a demonstration of the issue.
Please, take a look at it and tell me what I can hope about that issue :)
04/11/2007 (4:37 am)
@JustinI send you a mail to justind
Please, take a look at it and tell me what I can hope about that issue :)
#10
An update to the beta should be coming out in the near future. Hopefully these issues can be dealt with until then.
04/11/2007 (3:14 pm)
I have a fix for this, but it depends on a couple of different things that have changed since the release. Basically what's happening is you're setting the position of the camera to the position of the object at the last tick. But, this isn't necessarily the exact position that the object is rendered. The position of the object is interpolated between ticks for smoother animation.An update to the beta should be coming out in the near future. Hopefully these issues can be dealt with until then.
#11
"getrenderposition" didn't go for me because the camera is mounted to the "cameraobject" with a force of 5.
I discovered the getrenderposition is indeed getting my "cameraobject" at the right position, but it is the mounted real camera that is not placed right.
So the issue is caused by mounting. The mounted camera is not placed right each frame, it is trembling.
06/05/2007 (12:40 am)
Alright, after using 1.3 some time after this bug, I came back to 1.5, to find out what was not right. As the new getrenderposition thing didn't helped me."getrenderposition" didn't go for me because the camera is mounted to the "cameraobject" with a force of 5.
I discovered the getrenderposition is indeed getting my "cameraobject" at the right position, but it is the mounted real camera that is not placed right.
So the issue is caused by mounting. The mounted camera is not placed right each frame, it is trembling.
Torque Owner DragonSix
I can't get to fix it.
After many tests, its not my fault but the linearvelocity which is really not smooth anymore.
I don't know if that is clear enough :
Can anyone reply about that ? Why is this and what can I do ?