How many UpdateWorlds?
Blitz3D Forums/Blitz3D Programming/How many UpdateWorlds?
| ||
| People on the forums always say never use more than one update world per game loop. For my program this is unavoidable and I’m currently using five every game loop! I have an outdated set-up as well but still get 100fps. I just wondered how many other people used. (Ignore the specs below (I’m sure I didn’t need to tell you) I have a 550Mhz P3) |
| ||
| UpdateWorld [anim_speed#] Parameters: anim_speed# (optional) - a master control for animation speed. Defaults to 1. Description: Animates all entities in the world, and performs collision checking. The optional anim_speed# parameter allows you affect the animation speed of all entities at once. A value of 1 will animate entities at their usual animation speed, a value of 2 will animate entities at double their animation speed, and so on. For best results use this command once per main loop, just before calling RenderWorld. IMO you really should do it only once per loop... doing it several times might screw up collisions etc. |
| ||
| And it will definitely screw up animation. When playing animations, the animation frame is incremented every time you call UpdateWorld. So calling it multiple times between RenderWorld calls will screw up your animation. |
| ||
| But it does day it has a master control for animation speed. So if you want to call it four times, you could call it with an anima speed of (1.0 / 4.0), ie: 0.25. But that assumes you know how many times you're going to call it per loop before you actually start calling it. Then again... Maybe you cal call it with an anim speed of 0 as many times as you like, and only call it with an anim speed of 1 at the end. After all, you DO NOT want your objects moving while you are in the middle of updating your physics, which calling it with a number other than 0 would do, IF you were using render tweening. Also, calling it with 1 all the time is okay as well, because the first time you call it everything would go to it's "final resting position" and from there could not move. Hm... But if you moved things with physics and called it again, they would move. But you want them to move when you move them with physics because you want to check that the collision occured as expected. Hm. This makes me think that doing physics with render tweening isn't going to work very nicely. If my physics says to move the box to position X, and the next time I update my physics it's not yet at position X like I expect it to be, that's not good. Probably. I think the solution here is to ignore Blitz's render tweening system which is woefully inadequate and broken, and just go with variable framerate updates, which are much easier to code, or write your own render tweening system. Though that will require you to write a lot of code for animating entities and brushes and things between a set of values. Convieniently I recently released a couple systems which would be perfect for that though. :-) And they're free so you can't complain about that. :-) |
| ||
| actually i use an update world after any collsiions checks and it kept me from ahving inaccurate collisions. although ive been using the tweening method and have to agree with swift. Im trying to figure out a fps timeing system to. |
   |