Hi! This is a remake of a clock made by Devine Lu Linvega.
Check out the original clock here!
I made it as a distraction when I was learning to code in uxn, because I felt it would look pretty cool as a screensaver on my RGB-30 (though it doesn't really work as a screensaver if the clock border is static lol)
The clock uses a date and time format described in detail here. Basically, the letter of the alphabet marks each 2-week period since the start of the year (26 letters * 2 = 52 weeks) and the 2-digit number immediately following is the day of each period. Days are then divided into a 1000 beats with a 1000 pulses each. (e.g. 500:000 is noon)
Since pico8 doesn't have a way to measure miliseconds (or at least I couldn't find anything), I implemented sub-second measurements in a hacky way which is simply counting frames and pretending each frame is 1/60th of a second. I noticed it sometimes makes the clock go slightly backwards for a frame or two though I haven't tried to debug it thoroughly, maybe the line draw code is wrong idk.
Hope you enjoy!
There is an alternate way to get the miliseconds, but it's not really any better than what you are already doing :
the time() function returns how much time has elapsed since the start of the program.
Its return value increases by steps of 1/60 if you are using update_60, and by steps if 1/30 if you are using _update.
There is still no way to know the time distance between stat(95) and the integer part of time() other than watching stat(95) for a change every frame, but once you've saved the timestamp of change, you can do a subtraction
second_fraction=time()-time_of_last_change
The subtraction works even when time() overflows in the negatives.
Note that if you wanted the elapsed time between seconds in frames, you'd be off by one most of the time due to rounding errors with just multiplication by 60:
fc=flr(60*(time()-time_of_last_change))
is not accurate
to get proper rounding to the nearest integer :
fc=flr(0.5+60*(time()-time_of_last_change))
So if you want miliseconds with most precise possible rounding :
mili=flr(0.5+1000*(time()-time_of_last_change))
Problem is it won't look good :
the last digit will have a 0 7 3 0 7 3 ... cycle
the middle digit will cycle 0 1 3 5 6 8 0 1 3 5 6 8 ...
For a more convincing milisecond display, add a random value between 0 and 15 to even out the chance of the occurrence of every digit between 0 and 9.
The result FEELS much more precise and high tech, a bit like on LCD timer watches were the blur of digits in 1/100 of a seconds feels super precise due to the relative intensity of the segments after image.
[Please log in to post a comment]
