What is actually the best, most accurate, most reliable way to start an event every second.
I know using frameCount is not good, but i also cant use millis() cause millis%1000 doesnt work cause they only get updated in draw...
any ideas ?

Quote:

millis() is updated independently of draw(), but you can check it only if draw() is there (either checking in draw or needing draw to activate keyboard/mouse events where you can also check it).
Now, indeed, that's only in draw() that you can check it reliably, since that's the heart beat of your sketch. In general, it is called more often than 1s, so it can work.

But I wouldn't use millis() % 1000 to check one second, indeed, because draw() isn't called that often. You have to use the good old (millis() - timeSinceLastEvent >= 1000) pattern. So you get a precision equals to the current frame rate, which isn't so bad.
Do you really need super precise time beating (ie. below 17ms precision for the default 60FPS)?

Another solution to try is to spawn another thread, making it sleep for 1s, then calling the method of your choice. Although you can get a drift if that method takes time to process... Or the sleep time must be adjusted to clock time.

Actually, strictly speaking, one could definitely achieve a 1000-milli countdown between two discrete events within a single function, using delay(1000), right?  It wouldn't work for visual events, because draw() is necessary, but maybe a "tick" sound could be played.  I also am not sure what would happen if you started a separate thread with a delay(1000); in it, and used it to increment a counter...

edit: Oh, I guess that is basically what the class NoahBuddy mentioned does.

int lastTime = 0;

void draw(){
if( millis() - lastTime >= 1000){
doEvent();
lastTime = millis();
}
}

questioned answered i guess...
so what TfGuy44 wrote is better than the

frameRate(60);
if(frameRate%60==0)

i used before. right?

Quote:

Certainly, since you should use frameCount instead!  
Which is OK for rough control but not for precise control (as some frames might be delayed by long computations).