_25_11_2024_15_40_33.jpg)
|
Socoder -> Blitz -> Maintaining the same timing on different systems |
|
| Thu, 19 Apr 2012, 21:49 | |
|
dna |
ST=MilliSecs():ET=MilliSecs() I=0 While Not KeyDown(1) If ET+1000> MilliSecs() I=I+1 Else Exit EndIf Wend Print I WaitKey():I=0:ST=MilliSecs():ET=MilliSecs() -=-=- DNA |
| Thu, 19 Apr 2012, 22:24 | |
9572AD
|
I've never been one for trying to count cycles to figure out how many frames the system will do per loop then forcing the game to update according to that. I generally express motion as a vector and use the actual number of cycles taken by the loop to determine how far something moved. Makes more sense to me, but most of the industry seems to do it the former way and I've never really finished a project so I can't claim superiority. (One thing with my way is variations in the number of cycles per loop will cause un-smoothness in the motion visually, while the other way would cause slight slow-down instead. But that's why I use an average of the last several loops instead of the actual cycle count to smooth it out.) -=-=- All the raw, animal magnetism of a rutabaga. 
|
| Thu, 19 Apr 2012, 22:26 | |
|
9572AD
|
Of course, whatever you do will depend on the machines' timers being precise or there will be differences in speed between machines.
-=-=- All the raw, animal magnetism of a rutabaga.
|
| Fri, 20 Apr 2012, 02:50 | |
shroom_monk
|
Basing your timing on clock cycles can be quite tricky. What exactly do you want to do with this? There might be an alternative way of doing it.
-=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Fri, 20 Apr 2012, 12:32 | |
|
dna |
I was trying to measure the number of loops made in the same timed cycle. Let's say we use a 5 second interval, counting the number of loops in that interval on a particular machine. But on a different machine, faster or slower, the same number of cycles counted in that 5 second interval would be different. I used the variable I for checking the algorithm. -=-=- DNA |
| Fri, 20 Apr 2012, 12:40 | |
|
shroom_monk
|
OK, but what do you actually want to do with this code? What do you want to use it for once you have the number of loops?
-=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Fri, 20 Apr 2012, 12:55 | |
|
dna |
I just need it to work in the fashion that I mentioned using the variable I, thereafter I will reuse the code for something else, in something else. I was worried about the syntax being correct. -=-=- DNA |
| Fri, 20 Apr 2012, 16:14 | |
|
dna |
I get different values each time I run the program. This time I got 17272844 Does this have to do with the so called machine cycles that poll the system every so often? What I wanted was for the timing interval to be exactly the same and so the value of the variable I should not change in that instance. -=-=- DNA |
| Fri, 20 Apr 2012, 17:13 | |
|
shroom_monk
|
You will get a different value each time because the number of clock cycles or whatever that your loop takes for one iteration will be dependant on other background processes, a certain degree of randomosity, and the alignment of the stars. This isn't a value you can really measure with any degree of accuracy, I don't think.
-=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Fri, 20 Apr 2012, 17:37 | |
|
dna |
So how do the big game programmers keep time measurement for events in an interval the same for their games on any speed machine and platform? At least they claim to keep the same time. Different language? -=-=- DNA |
| Sat, 21 Apr 2012, 04:19 | |
|
shroom_monk
|
Like I said, you want to use a completely different method. A good way is to use a time delta. You measure the amount of time that passed since the last tick, and use that to control how much things change. For instance, say you have a player character who should be walking at a speed of 64 pixels per second. If the time that passed since the last frame was 0.01 seconds, then you would move the character 64 * 0.01 = 0.64 pixels in that next tick. That method is relatively accurate at not that difficult to implement. (The only caveat is with collision checks if you need them, because if the computer freezes for a moment then 2 seconds might pass, meaning in this example you would move 128 pixels, causing you to phase through a wall, so you may wish to do collision checks in smaller steps.) -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Sat, 21 Apr 2012, 07:08 | |
JL235
|
Shroom is right, about using delta time, although I believe I use a different approach. In an ideal and perfect world, my game would run at 60fps. So the time for 1 ideal frame would be 1/60 (1 second divided by 60 frames). You then get the actual amount of time between now and the last frame. Dividing that time by your 'ideal' frame time gives you 'delta time'. delta is just a multiplier you use in calculation, like speed or acceleration. What values would you expect? Well if the game really is running at 60fps, then the last frame divided by the ideal frame will just give you 1. This means it should run at 1 times the speed. If your game is running at 30fps, then the previous frame time takes twice as long, and dividing it by the ideal frame gives you 2. Your game should run twice as fast, to compensate for the halved frame rate. You then multiply movement by this delta value, and your done. i.e. An alternative method, which I'm finding myself using more and more, is to use timers. This is very useful for when you know where you are moving to, and how long it should take. You can then just work out what location you are on each frame as you move from point a to point b. Timers have a number of small advantages, such as being able to easily tell you when you reach point b, and being able to ensure you don't go past point b. That is useful for fade-ins, swipes, switching between frames in an animation, and other effects that have a specific time frame to run. |
| Sat, 28 Apr 2012, 11:56 | |
|
dna |
I've decided to simplify the original code problem
-=-=- DNA |
|
|
| |||
|
| ||||