呵呵，有点丑，没办法，俺不是美工……谁是美工请举手！！
这个是调试窗口，上面那一块的东西早就已经OK了，这次的重点是下面那一块Trace，可以看到效果还是可以D。说实话这个Trace窗口给我调试思考调度契合动作调度器给了不少的帮助——多线程加上同步确实比较难调，有时候会有莫名其妙的问题出现，等发现的时候断点已经来不及了，运行之前设置断点也不行（问题不会出现）。这时候就依赖于Trace窗口和临时添加的一些MessageBox.Show这样的代码来完成调试。
简单说明一下上图：里面的Tank#... 表明思考调度器调度了Tank#0000001C进行思考，因为我在Tank的思考代码里面添加了一句frmDebug.Instance.Trace(...);，也就是显示这些代码的内容。
而另外的那个sleep = 100... 则是输出游戏主循环线程的睡眠情况。目前游戏内容简单，而且对象稀少，因此活动量非常的小，这个时候总不能够让CPU不停的循环吧，总得要保持一个基本的速度或者接拍吧。为了这个我没有少费功夫，这行输出就是为了进行这个调试的。
sleep = 100表示一共睡眠了100ms，实际上目前限定一次循环的节拍就是100ms，可见几乎没有任何运动量。不过不要以为这就是最初的结果，最初的结果相当的混乱。由于睡眠采用的单位是ms，而Ticks则是0.001ms，因此总是有问题（我没有发现单位不一样），要么就是常睡不起，要么就是节拍不固定。此外，一开始Trace的代码本身没有经过很好的优化，因此几乎每一次循环都会占用超过100ms。经过一次优化之后发现会越来越慢，因为跟踪的信息越来越大了，后来经过再一次调整，每一次循环消耗的时间终于缩小到20到30ms之间。最后我又对Trace进行了更新时间间隔控制（现在控制在每隔1秒钟进行一次输出），就得到了上面的结果——几乎没有任何消耗。
当然，这个Tracer的功能会日益完善的，我希望能够超过Terrarium的那种跟踪能力。不过现在也凑和，可以用，所以目前不打算进行功能完善的操作了。
这个是调试窗口，上面那一块的东西早就已经OK了，这次的重点是下面那一块Trace，可以看到效果还是可以D。说实话这个Trace窗口给我调试思考调度契合动作调度器给了不少的帮助——多线程加上同步确实比较难调，有时候会有莫名其妙的问题出现，等发现的时候断点已经来不及了，运行之前设置断点也不行（问题不会出现）。这时候就依赖于Trace窗口和临时添加的一些MessageBox.Show这样的代码来完成调试。
简单说明一下上图：里面的Tank#... 表明思考调度器调度了Tank#0000001C进行思考，因为我在Tank的思考代码里面添加了一句frmDebug.Instance.Trace(...);，也就是显示这些代码的内容。
而另外的那个sleep = 100... 则是输出游戏主循环线程的睡眠情况。目前游戏内容简单，而且对象稀少，因此活动量非常的小，这个时候总不能够让CPU不停的循环吧，总得要保持一个基本的速度或者接拍吧。为了这个我没有少费功夫，这行输出就是为了进行这个调试的。
sleep = 100表示一共睡眠了100ms，实际上目前限定一次循环的节拍就是100ms，可见几乎没有任何运动量。不过不要以为这就是最初的结果，最初的结果相当的混乱。由于睡眠采用的单位是ms，而Ticks则是0.001ms，因此总是有问题（我没有发现单位不一样），要么就是常睡不起，要么就是节拍不固定。此外，一开始Trace的代码本身没有经过很好的优化，因此几乎每一次循环都会占用超过100ms。经过一次优化之后发现会越来越慢，因为跟踪的信息越来越大了，后来经过再一次调整，每一次循环消耗的时间终于缩小到20到30ms之间。最后我又对Trace进行了更新时间间隔控制（现在控制在每隔1秒钟进行一次输出），就得到了上面的结果——几乎没有任何消耗。
当然，这个Tracer的功能会日益完善的，我希望能够超过Terrarium的那种跟踪能力。不过现在也凑和，可以用，所以目前不打算进行功能完善的操作了。
