now there is a method in lwjgl’s base tutorial Timing
public long getTime() {
return (Sys.getTime() * 1000) / Sys.getTimerResolution();
}
what I want to know is that why Sys.getTime() need multi with 1000 and then div with Sys.getTimerResolution()?what does it mean?
please explain it to me step by step!! thx!!
from the api:
static long getTime()
Gets the current value of the hires timer, in ticks.
static long getTimerResolution()
Obtains the number of ticks that the hires timer does in a second.
so getTime gives you just some arbitrary number which represent some time interval you don’t know about. With getTimerResolution you can calculate the time in seconds. Now if you multiply everything with 1000 you get the time in milliseconds.
to make code like this more clear to others I like to use TimeUnit so you can write it like this
public static long getTime()
{
return SECONDS.toMillis(Sys.getTime() / Sys.getTimerResolution());
}
uh thx for help me
but I still can’t understand why any number multi with 1000 it will be millisecond?
milli comes from Latin and means 1000(thausend), like Millenium(1000 years) millimeter (1/1000th of a meter) and so on.
so because of this; 1000 milliseconds are 1 second; 1 millisecond is 1/1000th of a second.
To help you further with this basic, basic math:
1s = 1000ms
so i.e.
45,3s = 45,3(1000ms) = 45300ms
342ms = 342(1/1000s) = 0,342s
thx for explain
I’m sorry I was really stupid …
for example when I call Sys.getTime() it return 6034252
then I multi it with 1000
it became 6034252000
finally I divide it with Sys.getTimerResolution() which return 1000
then the result is 6034252
so I don’t know why we need multi 1000…
sure in this case it is not necessary, because it seems as if the number you get from Sys.getTime() is already in milliseconds, but…!!
When you are offered from a lib such methods use them, because you don’t have a guarantee that you will always get 1000 from Sys.getTimerResolution(), maybe you get on another PC another value. Or they change it with a newer version of the libary.
Your programm should never depend on internals of a lib, always depend on the contracts the libary is offering you.
Here the only thing say is that if you want the time in seconds divide, so divide^^
The tutorial here has an explanation about it.
You are correct about Sys.getTime() returning milliseconds on some platforms, however since LWJGL is cross platform its not guaranteed that every platform will do the same and the value could even change on current platforms in future LWJGL releases.
Ticks can have a lower accuracy than milliseconds (can be harware related, like some old arcade machines had hardware timers that ran at 60 ticks a second as games on it only need 60fps) or might even have higher accuracy than milliseconds (like nanoseconds or more in the future), it all depends on the underlying platform.
So Sys.getTime() will return the number of ticks (whatever the implementation underneath thinks is best for platform) and then Sys.getTimerResolution() will tell you how many of those ticks there are in a second. From which you can calculate the timer resolutions you require (millisecond, microseconds, nanoseconds, picoseconds, femtoseconds, etc).
which of course is bad api design, because everything of this should get abstracted away
edit:
sry, to tired ampy today I guess^^
It is ok as is in someway, but in the end there is no reason why the user would need to have access to those both values. Just provide the time in seconds(floating point).
The only bad part of the API is the misleading method name, as getTime() does not return time, it returns ticks and therefore it should be named getTicks(), and getTime() should have called both existing methods, returning something the developer would expect.
LWJGL itself is a low level API and just exposes API’s otherwise not available, its really the job of the library that sits on top of it to do any abstraction. Besides why should a low level API limit you to a fixed resolution ? e.g. milliseconds or nanoseconds, especially considering that these are not available on all hardware
The above API was added in a time when System.currentTimeMillis() was the only timer available in Java and the OS’s at the time couldn’t even provide millisecond accuracy. Even though we have System.nanoTime() now the LWJGL timer still continues to work equally well and will do so for even higher level of timer resolutions well after both System.nanoTime() and System.currentTimeMillis() become obsolete.
If standing the test of time like that isn’t a sign of solid low level API design I’m not sure what is.
@Riven agreed, good point however technically it is still returning the current time, just in ticks.
thx now I had read yours replys
so I had learn more…
but the lwjgl 's timer tutorial still don’t explain why Sys.getTime() * 1000 then / Sys.getTimerResolution() will return millisecond?
then how can i calculate nanosecond?
Its pretty simple, there are 1000 milliseconds in a second. Sys.getTime() will return the current time in ticks. To convert from ticks to milliseconds you simply multiply by 1000 and divide by the number of ticks in a second (Sys.getTimerResolution()).
Sys.getTime() * 1000000000 / Sys.getTimerResolution(); will give you time in nanoseconds since there are 1 billion nanoseconds in a second.
Incidentally, I’d advise using a constant for that 1000000000 or using the java 7 feature allowing underscores in numbers and write it 1_000_000_000. I can’t tell you how many times I’ve accidentally left a zero out or stuck an extra one in – tho in the latter case for this one number you’re a little safer, since it’s a compiler error if you don’t have an L suffix.
How about the nice and simple 1e9? 
Oh yer one of dem fancy-schmancy egghead types wid all yer sciencestistic notating! :cranky:
1e9 is a double
Hey, it’s better than missing a zero…unless you accidentally type 8 instead of 9 XD
Ok then: (int)1e9 or (long)1e9 
and how exactly is that an improvement?
It was a response to sproingie’s post about forgetting a zero.
Also @sproingie, an int can store 1000000000, it’s not a compiler error if there isn’t an L.
You traded one error prone approach with another.
Pre-java-7 I did: 1000L1000L1000L, now I do 1_000_0000_000L