How big is the systemvariable frameCount?

jogepe

Hallo, sorry for my bed English, hope you understand me anyway. How big is the systemvariable frameCount? How many frames can I count with it? Thank you!

colouredmirrorball

It's an int so it should be 2^31 = 2,147,483,647

jogepe

Thank you!!! is it possible to reset the variable without restarting the program?

koogs

just define your own global long and increment it in draw()

_vk

According to the javaDoc frameCount is public so:

void draw(){println(frameCount); frameCount = 0;} // prints 1 forever

At least worked on sketchpad.cc, BUT as it is js, perhaps won't work in java mode...

jogepe

Thank you!!!

GoToLoop

We can fearlessly reset it back to 1. Resetting to 0 is possibly problematic (or not). 8-X

GoToLoop

If you're afraid frameCount might over carry beyond 2**31 - 1, just check for it: :-SS
if (frameCount == MAX_INT) frameCount = 0;

jogepe

It works fine - thanks again!

quark

void draw(){println(frameCount); frameCount = 0;} // prints 1 forever

Of course it prints 1 for ever, because it is being reset to zero very frame!

This works

void draw() {
  println(frameCount);
}

void keyTyped() {
  if (key == 'r')
    frameCount = 0;
}

Chrisir

after how many days would processing crash because of frameCount when we forgot to reset it...?

quark

24855.135 days or a little over 69 years ;))

Chrisir

I'll worry about this later then...

koogs

2,147,483,647 frames / 60fps =
35791394 seconds / 60 seconds in a minute =
596523 minutes / 60 minutes in an hour =
9942 hours / 24 hours in a day =
414 days

quark

My mistake I forgot the 60fps :\">

Chrisir

so over a year....

thanks!

_vk

Of course it prints 1 for ever, because it is being reset to zero very frame!

Of course... Was intended. :)

jeremydouglass

TL;DR: the frameCount on a 60fps Processing sketch keeps going forever BUT it re-runs setup every 2.3 years.

Re: frameCount's range, and setting it, I wanted to contribute a few additions / corrections. I learned a few things when I took a look at the PApplet source:

• https://github.com/processing/processing/blob/90522aa75fc85c4fcec84165c689d279167fa7ce/core/src/processing/core/PApplet.java#L2387

1. frameCount==0 runs setup()
2. frameCount!=0 runs draw() (as well as any library pre() and post(), mouse positions, events, etc.)
3. because frameCount is incremented after draw()
   • resetting it to 0 causes the next frame to be 1
   • resetting it to -1 causes the next frame to be 0, triggering a re-run of setup()

So, a sketch running at ~60fps should run at least 828 days and probably indefinitely (although it may partially or completely restart).

1. frameCount runs from 0 to 2147483647 (414 days)
2. frameCount rolls over to -2147483648
3. frameCount runs from -2147483648 to -1 (+414 more days)
4. frameCount rolls from -1 to 0
5. setup() is called on frame 0 (draw() does not run)
6. repeat from 1

Depending on what code is present in the sketch setup() and how it reruns then the sketch may restart, or it may partially restart, or it may generate an error. However by default a sketch will just keep going indefinitely. Here is an example of a sketch going indefinitely, at high speed. It jumps forward in time in 100 day increments (always being sure to execute the 0 frame when required):

void setup() {
  println("setup");
  frameRate(1);
  textAlign(CENTER, CENTER);
}
void draw() {
  background(0);
  text(frameCount, width/2, height/2);
  println(frameCount);
  int newCount = frameCount + 518399999; // add 100 days
  if(frameCount<0 && newCount>0){ // // always execute frame 0
    frameCount=-1;
  } else {
    frameCount = newCount;
  }
}

We can see from the output how it is looping:

setup
1
518400001
1036800001
1555200001
2073600001
-1702967295
-1184567295
-666167295
-147767295
setup
1
518400001
1036800001

Watch what happens when we skip 414 days into the future to the moment of a sketch frameCount overflow -- in slow motion at 1 fps:

void setup(){
  frameRate(1);
  frameCount = 2147483640;
  textAlign(CENTER,CENTER);
}
void draw(){
  background(0);
  text(frameCount,width/2,height/2);
  println(frameCount);
}

...frameCount rolls over to negative and keeps incrementing up until (~414 more days later) it counts up to -5, -4, -3, -2, -1 , 0. When frameCount hits 0, setup() reruns.

Here is an example that jumps to the moment before the setup re-run at frame 0. Note that because of its setup this particular sketch then jumps back to -5 and loops endlessly from -5 to -1:

void setup(){
  println("setup");
  frameRate(1);
  frameCount = -6;
  textAlign(CENTER,CENTER);
}
void draw(){
  background(0);
  text(frameCount,width/2,height/2);
  println(frameCount);
}

Note in the above that frame 0 does not call draw, however it does take one full unit of time (one clock tick) to execute. As a result the "-1" sits on the screen for two beats. If Processing sketches did count on looping through frameCounts (whether at ridiculously high frameRate or for an extremely long run times) it would be easy to introduce an off-by-1 error in looping sketches by forgetting that draw is not called for one time unit each loop.

Playing with frameCount-based setup re-running can create some odd behaviors. Here is a short example: a sketch that reruns setup every frame, and uses setup to color-cycle the background. It is always on frame 1. Press any key to toggle off the reset behavior -- at which point frameCount advances normally in draw, however the background ceases to change because setup is no longer incrementing it.

int myColor = 0;
boolean resetup = false;
void setup() {
  colorMode(HSB, 360, 100, 100);
  myColor = (myColor+2)%360;
  textAlign(CENTER, CENTER);
} 
void draw() {
  background(myColor, 100, 100);
  text(frameCount,width/2,height/2);
  if(!resetup) frameCount = -1;
}
void keyPressed() {
  resetup = !resetup;
}