Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualBUnzaga

Posted 08 May 2013 - 07:44 AM

....teleport both the new position and the old one to the other side of the screen. In this way the ship seem to enter from the edge. Alternatively you can implement the wraparound logic after the interpolation step, i.e. storing an "absolute" ship position and then computing the modulus when computing the ship position on the screen

 

I currently have implemented the first suggestion, but would like more information on how I would go about doing your second suggestion properly. biggrin.png  I don't expect you guys to do the work for me, but just a keyword or two to look up in google would be highly appreciated.

 

So in my demo, I have 'previous', 'current', and 'rendered'(a better word would be interpolated).  In your second idea, I would use the interpolated position AFTER the physics calculation, not DURING it.  I like how that sounds.  Something like...

 

 

 while (accumulated >= TIC) {
  interpolated = oldPos = newPos
  newPos += TIC * Velocity
  accumulated -= TIC
 }
 ticLeft = accumulated / TIC

 smooth = 1.0 - ticLeft
 interpolated = (newPos * ticLeft) + (oldPos * smooth)
// handle the wrap around logic here?
// if interpolated > screen extents, set interpolated & oldPos & newPos to the teleported position?

#3BUnzaga

Posted 08 May 2013 - 07:44 AM

....teleport both the new position and the old one to the other side of the screen. In this way the ship seem to enter from the edge. Alternatively you can implement the wraparound logic after the interpolation step, i.e. storing an "absolute" ship position and then computing the modulus when computing the ship position on the screen

 

I currently have implemented the first suggestion, but would like more information on how I would go about doing your second suggestion properly. biggrin.png  I don't expect you guys to do the work for me, but just a keyword or two to look up in google would be highly appreciated.

 

So in my demo, I have 'previous', 'current', and 'rendered'(a better word would be interpolated).  In your second idea, I would use the interpolated position AFTER the physics calculation, not DURING it.  I like how that sounds.  Something like...

 

 

 while (accumulated >= TIC) {
  interpolated = oldPos = newPos
  newPos += TIC * Velocity
  accumulated -= TIC
 }
 ticLeft = accumulated / TIC

 smooth = 1.0 - ticLeft
 interpolated = (newPos * ticLeft) + (oldPos * smooth)
// handle the wrap around logic here?
// if interpolated > screen extents, set interpolated & oldPos & newPos to the proper position?

#2BUnzaga

Posted 08 May 2013 - 07:41 AM

....teleport both the new position and the old one to the other side of the screen. In this way the ship seem to enter from the edge. Alternatively you can implement the wraparound logic after the interpolation step, i.e. storing an "absolute" ship position and then computing the modulus when computing the ship position on the screen

 

I currently have implemented the first suggestion, but would like more information on how I would go about doing your second suggestion properly. biggrin.png  I don't expect you guys to do the work for me, but just a keyword or two to look up in google would be highly appreciated.

 

So in my demo, I have 'previous', 'current', and 'rendered'(a better word would be interpolated).  In your second idea, I would use the interpolated position AFTER the physics calculation, not DURING it.  I like how that sounds.  Something like...

 

 while (accumulated >= TIC) {
  interpolated = oldPos = newPos
  newPos += TIC * Velocity
  accumulated -= TIC
 }
 ticLeft = accumulated / TIC

 smooth = 1.0 - ticLeft
 interpolated = (newPos * ticLeft) + (oldPos * smooth)
// handle the wrap around logic here?
// if interpolated > screen extents, set rendered & oldPos & newPos to the proper position?

#1BUnzaga

Posted 08 May 2013 - 07:40 AM

....teleport both the new position and the old one to the other side of the screen. In this way the ship seem to enter from the edge. Alternatively you can implement the wraparound logic after the interpolation step, i.e. storing an "absolute" ship position and then computing the modulus when computing the ship position on the screen

 

I currently have implemented the first suggestion, but would like more information on how I would go about doing your second suggestion properly. :D  I don't expect you guys to do the work for me, but just a keyword or two to look up in google would be highly appreciated.

 

So in my demo, I have 'previous', 'current', and 'rendered'(a better word would be interpolated).  In your second idea, I would use the interpolated position AFTER the physics calculation, not DURING it.  I like how that sounds.  Something like...

 

 

 while (accumulated >= TIC) {
  interpolated = oldPos = newPos
  newPos += TIC * Velocity
  accumulated -= TIC
 }
 ticLeft = accumulated / TIC
 smooth = 1.0 - ticLeft
 interpolated = (newPos * ticLeft) + (oldPos * smooth)
// handle the wrap around logic here?
// if interpolated > screen extents, set rendered & oldPos & newPos to the proper position?
 
It seems to work fine for a scrolling background, but what about for 'real' physics implementation, like several moving objects reacting to collisions or whatever?  I guess that wouldn't be a problem, because they would be reacting to forces and not being instantly teleported around the screen, right?

PARTNERS