movingSquares

edited February 2017 in Share Your Work

I was experimenting with OOP and arrays. A bunch of squares eating one another out.

https://www.openprocessing.org/sketch/404134

Comments

  • edited February 2017

    Interesting! re: the sketch opening statement:

    "Bet on which one will survive until the end"

    It might be interesting to let the user click on a square and change its color, making it easy to track visually. Then a user could "place a bet" -- when their chosen square finally dies the sketch could display how many squares still alive have outlived the chosen square (rank), and/or how many other squares died since the bet was placed (score).

  • Impressive!

    But no colors?

    The eating and the eaten color could be averaged in the eating rect?

  • edited February 2017

    It might be interesting to let the user click on a square and change its color, making it easy to track visually. Then a user could "place a bet" -- when their chosen square finally dies the sketch could display how many squares still alive have outlived the chosen square (rank), and/or how many other squares died since the bet was placed (score).

    I accidentally left the tab on my browser on overnight and realised over time, all of them will eventually die (and get replaced by the younglings). So that is actually a sure-lose bet, but well, that is simply to induce curiosity. It seems like as the old one grows bigger, it is more likely to get eaten by the small ones, and no matter how many square you start off with, they seem to reach some sort of equilibrium eventually.

  • Impressive!

    But no colors?

    The eating and the eaten color could be averaged in the eating rect?

    It would be hard to control random colours to make sure they are eye pleasing. Shades of grey are easier to control. Anyway this is only a practise, I intend to make something more resolved (as a piece of online interactive art).

  • Great animation with lots of interesting possibilities for variation by modifying the 'rules' or movement / eating.

  • Just wondering, any simple method to keep track of time? Like say spawning a new square every half second. I am curring using frameCount% to count the number of frames, but I am worried about FPS varying due to processor load. I tried millis()% but it does not seem to work:

    void setup(){
      size(800,600);  
      rectMode(CENTER);
    }
    
    void draw(){
      background(255);
      fill(20);
      if(millis()%500==0){
        rect(width/2, height/2,50,50); 
      }
    
    }
    
  • int   lastTime; 
    void setup() {
      size(1200, 1000, P3D);
      background(111);
      println (TAU + "=" + TWO_PI);
      lastTime=millis();
    }
    
    void draw() {
      if ( millis() - lastTime > 2600) {
        println ("hello " + millis());
        lastTime=millis();
      }
    }
    //
    
  • Thanks @Chrisir ! Just wondering, will variables like millis() and frameCount get too large to be represented by standard integers?

  • Certainly not. The standard integer in Java is way too large to be overflown. It has 4 bytes, and you can keep going for about 20 days before trouble can occur.

  • edited February 2017

    @cygig --

    At 60fps, frameCount runs for over a year (~414 days) before it wraps around to the negative range of a signed int. It keeps going... after 2.3 years (~828 days) the frameCount hits frame 0 again, which skips draw() for a frame and automatically re-runs setup(). Depending on the sketch re-running setup might do nothing, or reset / partially reset your sketch, or crash your sketch. Assuming no errors, it keeps running, and does it again ~2.3 years later!

    For more details and test sketches to see what happens on frameCount overflow, see:

  • And the millis() can go on for about 20 days, before it ends up as a negative value. Another 20 days and it becomes 0 again.

  • I see, so it can overflow, just that it takes a long time to.

  • edited February 2017

    @GoToLoop -- interesting. Does anything special happens in Processing when it rolls over to negative or to 0 (like with frameCount=0) -- or is that just something to watch out for in sketch timing code? I was able to quickly test this with frameCount because the frame number is assignable, but I believe millis() is not assignable....

  • edited February 2017

    Does anything special happens in Processing when it rolls over to negative or to 0?

    Negative I dunno. But 0 triggers some internal initialization! :-S
    If we set frameCount to 0, on next draw() it's gonna be 1. #:-S
    However, frameCount = -1 would get frameCount to 0 on next draw()! :-SS

  • edited February 2017

    If y'all worrying 'bout millis() running out before the month is over, currentTimeMillis() is always an option, b/c it returns long instead of int: O:-)

    http://docs.Oracle.com/javase/8/docs/api/java/lang/System.html#currentTimeMillis--

  • But using long to store means that all your math in the sketch will be based on long and double, yet you will have to convert them back to int or float before using them in Processing functions because Processing uses only int and float for most of its functions and classes.

  • This blog post will explain how to perform animation independent of the frame rate

Sign In or Register to comment.