Java游戏学习

这几天一直在看 <<Killer Game Programming in Java>>,非常经典的好书,现在对游戏有了一个基本的认识,过几天就写个贪吃蛇出来.
因为看得有点快,真正准备写代码的时候又发现自己对一些基本知识点还是比较模糊,又返回去看前面.边看边做笔记,感觉确实理解得要更加清楚了.

*FPS 和 按时间准确的Sleeping*
============================

FPS
--------
  一个测量animation速度的常用指标就是桢速(每秒显示桢的数量:frames per second),简称FPS.在下面的
代码中,做一次gameUpdate和gameRender的循环就对应一个桢.
  比如100FPS表示run()中的每次迭代应该用1000/100 == 10ms.这个迭代时间存在period变量中.

//code example:

public void run() {
  long beforeTime, timeDiff, sleepTime;
  beforeTime = System.currentTimeMillis();
  running = true;
  while(running) {
    gameUpdate();//计算game中的model
    gameRender();//画一个image, "double buffer"
    paintScreen();//在screen上显示image
    
    timeDiff = System.currentTimeMillis() - beforeTime;
    sleepTime = period - timeDiff;//计算需要sleep的时间

    if (sleepTime <= 0)
      sleepTime = 5;

    try {
      Thread.sleep(sleepTime);
    }catch(InterruptedException e);

    beforeTime = System.currentTimeMillis();
  }
}

--------
Timer Resolution
  连续调用两次timer中间必需的最小时间.这样才能保证每次调用返回不同的时间.
  比如:
          long t1 = System.currentTimeMillis( );
        long t2 = System.currentTimeMillis( );
        long diff = t2 - t1;  // 实际输出是0,单位是ms

  在win95和win98上,resolution值是55ms,说明只有在每隔55ms后调用timer才会返回不同的值.
  在animation loop中,resolution的会导致animation比期望的要慢而且减小了FPS.因为如果gameUpdate
和gameRender的时间小于55ms,那么timeDiff变量就会设为0,那么sleepTime就会比实际需要的时间要大.
  为了防止这个问题,每个循环周期时间必须大于55ms,表示最高限制是大约18FPS.这个frame rate被广泛接
受,因为屏幕刷新过慢会表现得象闪屏(excessive flicker)一样.
 
  在Windows2000, NT和XP上, currentTimeMillis()的resolution是10到15ms,这样就可以获得67-100FPS.
这个值对游戏来说是可以接受的.在Mac OS X和Linux上的resolution是1ms,相当好了.

--------
改进过的J2SE Timers

  J2SE 1.4.2有一个没有被写入到文档的精确到微秒的timer class: sum.misc.Perf.
  Pref计算diff的方法:

      Pref perf = Perf.getPerf();
    long countFrep = perf.highResFrequency();
    
    long count1 = perf.highResCounter();
    long count2 = perf.highResCounter();
    long diff = (count2 - count1) * 1000000000L / countFreq;
                    //转换成纳秒nanoseconds
  nanoseconds:十忆分之1秒

  J2SE 5.0中解决了这个timer的问题,System.nanoTime(),可以象Pref timer一样来计算时间.
      long count1 = System.nanoTime();
    long count2 = System.nanoTime();
    long diff = (count1 - count2);//单位是纳秒

--------
Non-J2SE Timers

  Java 3D timer的计算方法:
      long t1 = J3DTimer.getValue();
    long t2 = j3DTimer.getValue();
    long diff = t2 - t1;//单位是纳秒


*更好的Sleeping*
================
  animation循环依赖一个好的timer和精确的sleep方法调用.现在在前面的基础上改进代码,以保证需要
的桢速.
//code example:

private static final int NO_DELAYS_PER_YIELD = 16;

public void run() {
  long beforeTime, afterTime, timeDiff, sleepTime;
  long overSleepTime = 0L;
  int noDelays = 0;

  beforeTime = J3DTimer.getValue();
 
  running = true;
  while(running) {
    gameUpdate();
    gameRender();
    paintScreen();

    afterTime = J3DTimer.getValue();
    timeDiff = afterTime - beforeTime;
    sleepTime = (period - timeDiff) - overSleepTime;

    if (sleepTime > 0) {
      try{
        Thread.sleep(sleepTime/1000000L); //nano -> ms
      }catch(InterrruptedException ex){}
      overSleepTime = (J3DTimer.getValue() - afterTime) - sleepTime;
    }else {    //sleepTime <= 0; 桢的时间大于期望的period,
        //不sleep直到sleepTime > 0 或 连续运行了NO_DELAYS_PER_YIELD次
      overSleepTime = 0L;
     
      if (++noDelays >= NO_DELAYS_PER_YIELD) {
        Thread.yield();
     noDelays = 0;
      }
    }
    
    beforeTime = J3DTimer.getValue();

  }
}

  如果sleep()设置成sleep 10 ms,但是确用了12 ms,那么overSleepTime会被设置成2 ms,下次就会少
sleep 2ms.
  如果桢的时间大于期望的period,那么就不浪费时间sleep,而是一直循环,一定次数后调用Thread.yield(),
这样来节省时间而又保证其它线程有机会运行.

*FPS和UPS*
==========

  除了FPS,还有一个有用的测量animation速度的指标:UPS. 在现在的animation循环中每次迭代拥有一次
update和render.但是这个对应不是必需的.在循环中,可以每一次render前做两次updates.
 
//code example:
 
public void run() {
  ...
  running = true;
  while(running) {
    gameUpdate();//update 游戏状态
    gameUpdate();//再一次update 游戏状态
 
    gameRender();
    paintScreen();

    //sleep
  }
  System.exit(0);
}
  在上面的代码中,如果游戏提供了50FPS,那么就每秒就会做100次updates.

从Rendering中分离Updates
--------

  对于高FPS速率的一个限制是update和render所需要的时间.假设period = 5ms(1000/5 == 200FPS),如果
update和render需要的时间大于5ms,那么200FPS就不可能达到.而它们所需要的时间中大部分是被render所消耗的.
  在这种情况下,增加游戏速度的方法是增加UPS的速率.在编程中,也就是在每次迭代中增加gameUpdate的次数.
但是注意,如果增加gameUpdate的次数过多的话会造成游戏不连续,因为有许多游戏状态没有显示出来.

新的代码:

//code example:

private static int MAX_FRAME_SKIPS = 5;

public void run() {
  long beforeTime, afterTime, timeDiff, sleepTime;
  long overSleepTime = 0L;
  int noDelays = 0;
  long excess = 0L;

  beforeTime = J3DTimer.getValue();
 
  running = true;
  while(running) {
    gameUpdate();
    gameRender();
    paintScreen();

    afterTime = J3DTimer.getValue();
    timeDiff = afterTime - beforeTime;
    sleepTime = (period - timeDiff) - overSleepTime;

    if (sleepTime > 0) {
      try{
        Thread.sleep(sleepTime/1000000L); //nano -> ms
      }catch(InterrruptedException ex){}
      overSleepTime = (J3DTimer.getValue() - afterTime) - sleepTime;
    }else {    
      excess -= sleepTime;
      overSleepTime = 0L;
     
      if (++noDelays >= NO_DELAYS_PER_YIELD) {
        Thread.yield();
     noDelays = 0;
      }
    }
    
    beforeTime = J3DTimer.getValue();

    int skips = 0;
    while((excess > period) && (skips < MAX_FRAME_SKIPS)) {
      excess -= period;
      gameUpdate();
      skips++;
    }

  }
}

  如果update/render实际需要12ms,但是需要的period是10ms,那么sleepTime会是-2ms(由于引入overSleepTime,
所以可能会更小一点).额外的执行时间被加到excess变量中.
  当excess达到period大小时,那么相当于丢失了一个桢,在while循环中,为每次丢失执行gameUpdate.但是限制在
MAX_FRAME_SKIPS里.
  这样做的优点是,如果一个游戏的update/render速度不能满足期望的FPS时,那么就会另外执行gameUpdate.
这样改变了游戏的状态但是没有马上显示出来,最后用户会看见游戏移动更"快"了,虽然每秒钟显示的桢数并没有
改变.