LoginLogin
Nintendo shutting down 3DS + Wii U online services, see our post

Timing Sources

Root / Submissions / [.]

snail_Created:
There are multiple ways of keeping track of time in SmileBASIC, each with its own purpose, benefits, and drawbacks.

TIME$ and DATE$

TIME$ and DATE$ are two system strings storing the current time and date. DATE$ is formatted as YYYY/MM/DD and TIME$ is formatted as hh:mm:ss. The most obvious benefit of these is that the time is tracked based on the system clock, meaning that passage of time can be checked between runs of your program, between SmileBASIC sessions, and even if the system is off. Assuming that the system clock is working and correctly set, you will always know what the current real-world time is in your program. As a simple example, here is a clock program that prints the current date and time:
ACLS
WHILE TRUE
 VSYNC
 CLS
 PRINT DATE$
 PRINT TIME$
WEND
If your game stores DATE$ and TIME$ in its save file, you can make it seem as though your game world continues to run even when you aren't playing. Games like Animal Crossing take advantage of this technique to create an illusion of real-world time. The drawbacks are that the precision only comes down to one second, and that tracking real-world time differences is cumbersome in this format.

DTREAD and TMREAD

The DTREAD and TMREAD functions serve to ease the pain of working with date and time strings. Simply put, they break down the strings into individual numbers.
TMREAD OUT hour%,minute%,second%
DTREAD OUT year%,month%,day%
By default these functions read TIME$ and DATE$ for their output, but you can pass any correctly-formatted string you wish.
VAR EXAMPLE$="1999/01/01"
DTREAD EXAMPLE$ OUT Y%,M%,D%
PRINT Y%,M%,D%

MAINCNT

MAINCNT is a system value that tracks how many frames have passed since SmileBASIC has started. As the SmileBASIC environment runs, it counts every time it produces a frame update. Many elements of the system are tied to this timing, such as sprite animations, display refreshes etc. This is what makes MAINCNT so useful: it is synchronized to the "heartbeat" of the system. SmileBASIC produces frame updates at 60Hz, so it counts up once roughly every 17ms. This program should count up by 1 every time a line is printed. If the argument to VSYNC is changed to 2 or 3, for example, the program will count up by 2 or 3.
ACLS
WHILE TRUE
 VSYNC
 PRINT MAINCNT
WEND
MAINCNT is best used to track frame timing in games locked at a fixed frame rate (e.g do something after x frames) or situations that rely on being synced to the refresh rate. However, since it starts at 0 and counts up whenever SmileBASIC is launched, it is not useful for real world or "persistent" timing. Additionally, in rare situations SmileBASIC itself slows down and is unable to run at 60Hz, and as a result MAINCNT counts more slowly. For these reasons it should not be used for any form of real-world precise timing.

MILLISEC

Introduced in version 3.3, MILLISEC is a system value that keeps track of how long SmileBASIC has been running, in milliseconds. When SmileBASIC starts, it starts a timer, in milliseconds, that counts up forever as long as it is running. This timer appears to be tied to hardware, so it is independent of the refresh rate. This program will print how long it has been running, in milliseconds.
VAR START%=MILLISEC
ACLS
WHILE TRUE
 VSYNC
 CLS
 PRINT "Running for ";MILLISEC-START%;"ms"
WEND
Its high precision and independent nature make it useful for tracking some amount of real-world time elapsed (e.g. a lap timer in a racing game) or as a timing source for programs that do not run at a fixed framerate (e.g. performance testing.) However it is similar to MAINCNT in that it only tracks time relative to SmileBASIC so it is not useful for games where a real-time clock is required.

The information about MILLISEC shoud be updatet, because this system value shows frames, since Smilebasic was launched. It is fixed to the Hardware-framerate, and is independent from your program-framerate. But it dont shows real miliseconds. The deviation is low, but measurable if you used it for a longer time. Also, if you are not shut down yor 3DS-system for a very long time it can be negative.(look at https://smilebasicsource.com/forum?ftid=1949 )

Replying to:S_DE_Solutions
The information about MILLISEC shoud be updatet, because this system value shows frames, since Smilebasic was launched. It is fixed to the Hardware-framerate, and is independent from your program-framerate. But it dont shows real miliseconds. The deviation is low, but measurable if you used it for a longer time. Also, if you are not shut down yor 3DS-system for a very long time it can be negative.(look at https://smilebasicsource.com/forum?ftid=1949 )
MAINCNT is the frame timer, MILLISEC is the hardware millisecond timer. The value going negative is irrelevant because the basic concept of overflow exists and SB has to be running for 22 days straight for it to even overflow. There might be a deviation in the timer from real time, but it's so small that I've never encountered it and I'm sure it needs to be measured over extended timescales to detect it. MILLISEC is properly used over short timescales, anyway.

Replying to:S_DE_Solutions
The information about MILLISEC shoud be updatet, because this system value shows frames, since Smilebasic was launched. It is fixed to the Hardware-framerate, and is independent from your program-framerate. But it dont shows real miliseconds. The deviation is low, but measurable if you used it for a longer time. Also, if you are not shut down yor 3DS-system for a very long time it can be negative.(look at https://smilebasicsource.com/forum?ftid=1949 )
The deviation in the timer from real time, are round 2 seconds in one hour, if I remember rightly.

Replying to:S_DE_Solutions
The information about MILLISEC shoud be updatet, because this system value shows frames, since Smilebasic was launched. It is fixed to the Hardware-framerate, and is independent from your program-framerate. But it dont shows real miliseconds. The deviation is low, but measurable if you used it for a longer time. Also, if you are not shut down yor 3DS-system for a very long time it can be negative.(look at https://smilebasicsource.com/forum?ftid=1949 )
It's more than I expected, but I wouldn't suggest using MILLISEC for an hour anyway. It's not entirely clear in the page but I feel you should only be using it for at most measuring time over a few minutes (like time spent in a level.) If you update the reference time each level I think your drift would be a bit less. 2 seconds per hour is a bit concerning so I'll edit the section in a bit.

Don't forget 2x precision MICPOS timers

Replying to:S_DE_Solutions
The information about MILLISEC shoud be updatet, because this system value shows frames, since Smilebasic was launched. It is fixed to the Hardware-framerate, and is independent from your program-framerate. But it dont shows real miliseconds. The deviation is low, but measurable if you used it for a longer time. Also, if you are not shut down yor 3DS-system for a very long time it can be negative.(look at https://smilebasicsource.com/forum?ftid=1949 )
Sorry, I was wrong. The 2 Seconds was generatet by a Bug in my code. I forgot, that each comand needs time to execute. So l had put to much code between setting (start-) value and calculation. (I such a fool...) Now I wrote it again, with the shortest code, that i think it's possible. The deviation is now by 0.2 seconds in one hour. You are right, that MILLISEC is generatet by Hardware. But in practis you can't use it without loosing a littel bit precision. (Unless you just want to print it.)