different behavoir of time when game halts

Comments

• iarwain

  November 2010 edited November 2010

  tdomhan wrote:

  I'm not sure if this is a bug, or intended ^^
  
  I have a character that shall have a fixed position on the screen.(while "moving" to the right) Furthermore there are several background objects that should move from the right to the left, as the character moves with a fixed speed to the right. I hope that was clear

  
  It is. At least I think.
  

  I know that I could use something like the ParentCamera attribute.

  
  An even more flexible way is to have the camera attached to a dummy object and then manipulate this dummy object (setting speed, parents, physics, etc...). I did that on Mushroom Stew to be able to add FXs to the camera (the camera shake has been implemented like this but it'd work for other things like spinning camera, pulsating zoom, etc...).
  

  But I didn't. What I did is the following:
  I move the camera in a update method according to the time that went by since the last update.
  furthermore I assigned the same speed to an orxOBJECT representing the character. So far everything works fine.

  
  Well, here we are. What do you mean according to the time that went since the last update? If you want to enforce time coherency you have to use the info given by the orxCLOCK_INFO, not any internal timer. Also I'd recommand using the fDT field of it only as this DT can be modified by orx (time stretching, min frequency, ...) and will internally be used for all the behind the scene computation: physics, sound distorsion, etc...
  
  Now if you used it and it still doesn't work, it's a bug.
  

  When I click the title bar of the game window the whole game halts until I release it. This is fine so far.

  
  Still annoying, I keep wanting to spawn a new thread in a portable way to remove this issue but it's not very high on my todo list right now.
  

  However:
  The character does not take account for the time the whole game was halted. Whereas the camera does. This means the character will fall behind or even leave the screen on the left.

  
  Yep, not good I guess. But even if this works you should really update your camera position on the core clock with a function registered as a normal priority if you want to make sure there won't be any frame of delay between your character and your camera. Here too, the trick of having the camera on a dummy object and manipulating this object should help as both objects positions will be updated at the same time.
  

  This can easily be fixed by using the same method as is used for the camera for the character.
  However I though this might be regarded as a bug.

  
  If your computation is using the fDT provided by the clock in orxCLOCK_INFO, it's definitely a bug. Maybe you could show us the camera update code?
  

  I'm using a rather new SVN snapshot on a windows 7 machine. I compile the game using mingw.

  
  Thanks for the precisions! The last release is getting pretty old, as soon as the Android build and the sound recording branches will be integrated back to the trunk it'll be time to release a new version.
• tdomhan

  November 2010 edited November 2010

  ok, I think it was not 100% clear what I do. so let the code speak. Here is what I do for my character object once it was initialized:

  orxVECTOR vec;
  orxVector_Set(&vec, speed_, 0.0f, 0.0f);
  orxObject_SetSpeed (object_, &vec);
  

  This is what I do for the camera in a update function registered to a clock with normal priority:

  orxVECTOR dvector;
  double dx = speed_ * clock_info->fDT;
  orxVector_Set(&dvector, dx, 0.0f, 0.0f);
  orxVector_Add(&camera_position_, &camera_position_, &dvector);
  orxCamera_SetPosition(camera_, &camera_position_);
  

  I think the camera is working perfectly fine. After the halt the time difference is rather great, which is what is expected.
  
  (However, attaching the camera to a object in order to enable some effects sounds interesting nevertheless.)
  
  The thing that is weird, is the character moving according to it's speed attribute.
  this is where the time glitch, caused by the halt, is not being accounted.
  it's like the player stays still whereas everything else moves while the game is halted. meaning the time difference is reset after the game is resumed.
• iarwain

  November 2010 edited November 2010

  Thanks for the details.
  So yes it's a bug.
  Last question: does your character has a body or not? (If it has one its position is updated by the physics module otherwise its emulated by orx, so as to keep a consistent API).
  
  What happens, behind the scene, is that we maximize the DT so as to keep the physics simulation under control and avoid any divergence. There's apparently a discrepancy there.
  I'll check that tonight!
• tdomhan

  November 2010 edited November 2010

  nope it does not have a body. I didn't specify any physics stuff.
• iarwain

  November 2010 edited November 2010

  Oh wait wait, is your camera on the same clock or not?
  
  If not it's normal, the main core clock uses a maximize DT whereas any user created uses a regular DT by default.
  That's the Render::MinFrequency property in config. If you don't provide one it's 10Hz by default.
  Then the render plugin sets a a modifier on the core clock this way:

        orxClock_SetModifier(sstRender.pstClock, orxCLOCK_MOD_TYPE_MAXED, (orxConfig_HasValue(orxRENDER_KZ_CONFIG_MIN_FREQUENCY) && orxConfig_GetFloat(orxRENDER_KZ_CONFIG_MIN_FREQUENCY) > orxFLOAT_0) ? (orxFLOAT_1 / orxConfig_GetFloat(orxRENDER_KZ_CONFIG_MIN_FREQUENCY)) : orxRENDER_KF_TICK_SIZE);
  

  
  If you're using a different clock for your camera update you could set the same modifier but that wouldn't suppress the potential frame of delay, whereas using the main core clock as support should.
  
  If they both are on the same clock (ie. on the main core one), then it's definitely a bug.
• tdomhan

  November 2010 edited November 2010

  the update of the camera happens in a user clock:

  orxClock_Create(orx2F(0.01f), orxCLOCK_TYPE_USER);
  

  
  ok if I get it correctly, this would explain the whole thing. But this also explains some behavior I noticed when implementing the timestamp for the sound capturing. I ended up using orxSystem_GetTime, because I needed the real time that elapsed.
  
  stupid question: why is the possibility that the user clock and the core clock diverge intended?
  
  so do I get this correctly:
  the orxCLOCK_INFO of a update function registered to a user clock will provide me the real time?
  Because for my project it is extremly important to base everything on the real time.
• iarwain

  November 2010 edited November 2010

  tdomhan wrote:

  the update of the camera happens in a user clock:

  orxClock_Create(orx2F(0.01f), orxCLOCK_TYPE_USER);
  

  
  That'd be the issue in our case.
  

  ok if I get it correctly, this would explain the whole thing. But this also explains some behavior I noticed when implementing the timestamp for the sound capturing. I ended up using orxSystem_GetTime, because I needed the real time that elapsed.

  
  Even if it makes sense, I'd rather use the clock time instead, either using a custom clock or by removing the maxed DT on the core one, which is something I'll try tonight.
  

  stupid question: why is the possibility that the user clock and the core clock diverge intended?

  
  When it's intentional, to achieve relative time stretching. But in this case it's not intentional and not even obvious, so that's an issue.
  

  so do I get this correctly:
  the orxCLOCK_INFO of a update function registered to a user clock will provide me the real time?
  Because for my project it is extremly important to base everything on the real time.

  
  Yes, that's right. And tonight I'll change it so that it'll be also the case for the core one unless a MinClockFrequency is explicitly provided. I'll also add some doc about that in the wiki.
  
  I'll try simulating a couple of steps in the physics instead of maxing the DT, which should avoid diverging when there's been a big hickup while still making sure all the clocks have the same default behavior.
• iarwain

  November 2010 edited November 2010

  Btw, I made the changes on the svn and added more info on the wiki a couple of days ago.
  
  By default, as written earlier, it'll still behave like this unless you explicitely specify a MinFrequency of 0 or less.
  
  In this case the physics simulation will try to catch back by doing multiple small update steps, but this solution is still less stable with Box2D than the "freezing" one.
• tdomhan

  November 2010 edited November 2010

  ok, I think it's perfectly fine, as long as you aware of this fact. which I am now and others hopefully will be through the wiki entry.
  
  I don't need any physics, I just thought it was neat to use the setspeed function, instead of setting the position myself.
  
  but yeah, it's better to have those diverging clocks then a failing physics simulation.
• tdomhan

  November 2010 edited November 2010

  btw, there is a interesting article about physics simulation and the timestep I found:
  http://gafferongames.com/game-physics/fix-your-timestep/
  I don't know if it helps in any way, but I just found it intersting^^
• iarwain

  November 2010 edited November 2010

  Thanks for the link. I remember reading this article a couple of years ago when I got the issue with the physics simulation in the first time.
  
  I didn't try the last option as it requires the additional interpolation and Box2D isn't deterministic to begin with (if one is to trust their forum), so it sounded like a waste of time.
  
  Anyway right now there are 2 options available, the ones mentioned in my previous post, hopefully that'll be enough for most users.
  
  As for the SetSpeed/SetAngularVelocity you chose well, it's better than doing it on your side, especially if you attach a clock to an object and want to do some time stretching on it.
  
  Also the orxFX can have slots linked to speed so I had to support a minimalistic physics update for objects without bodies.