To my surprise, this compiled
fmt.Println(time.Second * time.Second)
The result is nonsense
277777h46m40s
It doesn't make any sense to multiply a duration by duration and get another duration.
What's going on?
The Duration type is simply an int64 representing the duration as a nanosecond count
type Duration int64
A Duration represents the elapsed time between two instants as an int64 nanosecond count.
So multiplying one duration by another gives the result of multiplying the number of nanoseconds in each. In my example, this gives a billion billion nanoseconds, or 277777h46m40s. Nonsense, but well-defined!
Related
I am trying to do some operations on MIDI tracks, such as increasing/decreasing the playback speed.
For those who want more detail: To change playback speed, I need to divide 'delta times' of each track by the multiplier. Eg. If I want to speed up the track x2 then I divide the delta times by 2. Delta times are stored as variable length qualities so if I divide the delta times, I need to update the track's size by reducing the size in bytes so as to keep the state of the track consistent (because shorter delta times mean less number of bytes needed to store variable length quantity).
In my struct, the track length (size in bytes of the entire track) is stored as uint32_t. The problem occurs when I try to store the changed track size back. So lets say if my original track size was 3200 and after reducing the delta times the difference in bytes is 240, then I simply subtract this difference from the original length. However, when I use the 'du' command to check the new file size, the file size inflates heavily. Like it goes from somewhere like 16 kB to 2000 kB. I dont understand why.
I'm writing some PIC assembly code to compute the remaining time of a CD track based on elapsed minutes and seconds and total track length (16 bit unsigned value, in seconds).
The elapsed minutes and seconds are two 8bit unsigned values (two GPR register), the total track length is a two bytes value (hi-byte and lo-byte).
I need to compute the remaining time, expressed in minutes and seconds.
I tried computing the total elapsed seconds (elapsed_minutes * 60 + elapsed_seconds) subtracting it to the total track length. Now I face the problem how to convert back such result in a MM:SS format. Do I have to divide by 60? take the quotient (minutes) and the remainder (seconds)?
Yes, you divide by 60 to get minutes and the remainder is seconds. It's just algebra, not magic!
I've started looking into lwjgl and I'm particularly having trouble understanding how Delta works. I have browsed other questions and websites related to this but it is still a confusing topic to wrap my head around. It would be great if someone here can help me out so please bear with me.
I understand that the Delta time for 60fps would be 16, around double that if the frame-rate is 30. I don't understand how this is calculated. Is it the time it takes between frames? Sorry for the noobish question.
private long getTime() {
return (Sys.getTime() * 1000) / Sys.getTimerResolution();
}
private int getDelta() {
long currentTime = getTime();
int delta = (int)(currentTime - lastTime);
lastTime = getTime();
return delta;
}
As opiop65 already said, the delta time is simply the time spent between your last frame's beggining and your current frame's beggining.
How does it work?
Delta time can be any kind of unit: nanoseconds, milliseconds (<- usually this is the standard) or seconds. As you said delta time is 16 when the game is running on 60FPS and 32 when the game runs on 30FPS. As for the why, it's simple: In order for a game to run at 60 frames per second it has to produce a frame every 1000/60 (= 16.666667) milliseconds, but if it running at 30 frames then it has to produce a frame every 1000/30 (= 33.333333) milliseconds.
But why do we use delta time?
We use delta time because we want to do movement and all sorts of stuff time dependant and not frame depentdant. Lets say that you want one of your game's character to move 1 unit horizontally per second. How do you do that? Obviously, you can't just add 1 to the character's location's X value, because it would get moved 1*x times per second where x is equal to your FPS (assuming that you would update the character every frame). That would mean that if somebody runs the game on 1 FPS his character would move 1 units per second, where if somebody runs the game on 5000 FPS his character would move 5000 units per second. Of course that is unacceptable.
One could say that he would move the character 1/16.6667 units on every update but then again if somebody has 1 FPS he moves 1/16.6667 units per second, opposed to that guy who runs on 5000 FPS, thus moving 5000*(1/16.6667) units per second.
Yes, you can enable V-Sync but what if somebody has a 120Hz monitor (or even higher) and not 60Hz?
Yes, you can lock the framerate but your players wouldn't be too happy about that. Also that wouldn't stop the character from slowing down when the game drops below 60FPS. So what now?
Delta time to the rescue!
All you have to do is just to move your character 1*delta on every update.
Delta time is low if the game runs on a high FPS and high if the game runs on a low FPS thus making those character go slower who runs the game on a higher FPS (so he would move smaller amounts but more frequently) and those character faster who runs the game on a lower FPS (so he would move larger amounts less frequently) and in the end they would move equal distances over the same time.
Please note that it does matter what unit you use when multiplying with the delta time:
If you use millis then at 60FPS your delta would be 16.6667 ending up with 1*16.6667 = 16.6667 movement every frame. However, if you would measure your delta time in seconds then at 60FPS your delta time would be 0.016667 meaning that your character would move 0.016667 units every frame.
This is not something you should worry about, just keep it in mind.
Delta time is simply the time it takes for one frame to "dispose" of itself and then another to display on the screen. Its basically the time between frames, as you put it. From Google:
Mathematics. an incremental change in a variable.
Let's pick apart your code.
return (Sys.getTime() * 1000) / Sys.getTimerResolution();
This line simply returns the current time in (I believe) milliseconds?
long currentTime = getTime();
int delta = (int)(currentTime - lastTime);
lastTime = getTime();
return delta;
The first line simply gets the current time. Second line then calculates delta by subtracting the current time (which is the time when the current frame was displayed) by the lastTime variable (which is the time when the last frame was displayed). Then lastTime is set to the currentTime, which is when the current frame is displayed. Its really simple when you think about it, its just the change in time between frames.
I'd like to program my own clock based on an octal numeral system. From what I've gathered, javascript is browser friendly but inaccurate at time intervals. What's a good program to code something like this? To give an example for this specific time system, there would be 64 hours in a day, 64 minutes in an hour, and 64 seconds in a minute. This would result in 1 octal second being equivalent to 0.32958984375 ISU second.
(Excuse for My english it's freak i´m from LA)
I'm trying to finish a trascoding process in VB6.0 , i'm working with ffmpeg , its a very good transcoder , to finish the project i want a progress bar for the trascoding process but it's so very hard , first i need to understand , how a program can calculate the time remaining to the process if i have the inputs
Average Bitrate
Frame rate
Start file Size.
I'm trying with : File size (KB) / Average Bitrate Kb/s.
In theory this must to work , but the calculated time it`s very small than the real time processed. Somebody have any idea about this , what is the formula (snipped) to calculate the time remaining in a trascoding process. in this wonderfull web i find many answer to mys projects..
The bitrate won't help you in calculating progress.
If you have the file length in seconds, and the frame rate, and ffmpeg outputs what frame its processing right now, you can calculate the approximate time.
The general solution for "time remaining," given:
A number total_units that represents the size, number of units, etc. to be processed
A number units_processed that represents how many M's have been processed so far
A number start_seconds that gives the time, in seconds since the operation started
is:
seconds_elapsed = current time - start time
seconds_per_unit = seconds_elapsed / units_processed
units_left = total_units - units_processed
seconds_remaining = unit_left / seconds_per_unit
This algorithm does best when the times to process each unit are nearly the same, or at least when the time/unit has little correlation with elapsed time. It stinks on ice if time/unit varies with elapsed time.