最终选定了独眼龙的素材，因为他的行走动画前进和后退相同，而且只有4帧，而出腿动画多达7帧，这比较符合我这个游戏的需要。左右两个小人还是相同算了，这样一是程序上便于处理，二是竞技平衡性更容易达到。
我把这11帧动画装进一个2*7的格子阵列里，这样引用更方便。
按前文中第一篇参考文章的做法，仅用windows画图来对图片进行对齐处理，效果异常的妙。对齐点的确定我是计算出坐标后用铅笔在图上一个个标黑点，这个大家可以尽量发挥自己的聪明才智。
很容易想到，出腿动画的对齐点在站立不动的那只脚。而行走的就有点麻烦了，我先前说过这个需要程序和美工间对步长等因素达成一致，而我必然是完全无法知晓街霸原美工的想法的，所以只能先凭自己的经验猜测对齐点在头部，因为不管是实际拳赛中还是以前玩街霸的时候，人物头部和上身都是保持一个稳定状态匀速前进，鲜有摇头晃脑的那种。假如是选了那个长手长脚喷火怪咖，那确定对齐点真是要费一番功夫了，恐怕得通过反复在屏幕上播放实验来调整到正确值。
一开始把每帧尺寸定在长160高130，后来尴尬的发现装不下，改成长180高140。
然后单独新建个工程，把原来第六章动画显示的程序搬来，稍作修改，看了下自己编辑好的素材图以动画显示的效果，发现还是靠谱的。恩，又前进一小步。
接下来我在一个问题前困惑了好久，因为游戏设定人物的速度会变化，我很担心程序做的不好的话会出现滑步现象。
最后思维终于逐渐明晰，答案浮现了出来。
第一，素材图是固定死的，这个没法改了。
第二，同一帧显然不能滑步平移，只能不同帧按素材图确定的步长间距依次出现。
第三，速度的变化，只能以同一时间内行走动画循环更多次来表现。
先来按这个思路实验走路效果，这次直接在原程序上改动。我将步长值设为一个可调量，这样可以在程序运行中方便的根据实际效果确定出最佳步长。
原来的设计，移动速度啊什么的都是以像素为最小单位，但是现在以步长为最小单位似乎更合理一些。这里就出现了一个问题，原先帧率是设置在50左右，就是1秒做50次按键检测及画面刷新。步长大约在20个像素左右，这样1秒内人物就会移动过整个屏幕。初步决定直接将帧率大幅降低，因为没有什么快速变化的动画，所以可以降到24以下。
（2013.8.11注：其实这个问题可以将按键检测周期和画面刷新周期分离解决）
修改后的程序运行效果很不理想，持续按键时会保持一个姿势滑动，我将frame变量显示出来，发现间断单次按键，结果还算正常，持续按键时，其值就会在0、2或者1、3间跳变，导致要么大踏步前进要么滑步。很诡异。
不管怎么调节步长值或是刷新时间，甚至是把绘图程序直接放到frame++后头，都还是一个现象，这实在是有点头疼。
这是我做这个项目至今遇到的最想不通的bug，卡住动弹不得，想带着程序去武汉请教同学的心都有了。所幸后来猪哥灵机一动，大致判断应该是按键检测完毕后绘图部分程序并未运行，导致检测两次图像才更新一次，于是在绘图部分前面用了个while循环，同时设置一个变量来保证每次按键检测完必须更新画面一次，果真就把这个问题给解决了。呵呵，传说中的dirty code大法？
事后想来可能是持续按键影响到了d3ddev->BeginScene()语句的执行，具体原因现在没法明确，只能等待日后对windows编程更了解或是请教高人了。
（2013.8.11注：这个bug是《游戏编程入门》一书源码的谬误所致，以后会详细论述）
这个坎算是过去了，以后不知道还会遇见多少这样的难题。不过这也是编代码的乐趣所在，永远都要去思考解决各种各样的问题，脑子不好使还真干不来。
计划照旧，用加入调节程序的办法来确定最佳步长果真很有效，快速连续移动时感觉不出明显的滑步，不过慢速一步步测试显然更合理，判断的依据就是两帧动画间支撑地的那只脚位置是否不变。最终发现步长设置为8最合适，和我先前丈量出的18左右差了一半，什么原因先不管了，一切以实际为准。在6-10之间变动其实效果都无明显失真。即便是调节到3-20，效果看起来也都不是不能接受。
（2013.8.11注：这里步长的像素值诡异的差了一半，多半也是上文中的bug导致）
这里也给了我一个启发，先前计划是速度的变化以步长为最小单位，这样速度而可调节范围就有限而且变化不连续可选值就很少了，现在看来，最小单位仍可采用像素，速度的变化可以通过步长变化进行调节，这样原先的耐力衰减机制能够很好的得以保留。具体如何权衡留待以后数值设定时一并确定。
行走动画解决了，接下来搞定踢腿动画。
当然过程中仍要想一些办法，仍会不断犯一些常规的逻辑错误，比如注意踢腿键松开后腿要收回并变回站立姿态等，这些就不详述了。
不知不觉就搞定了动画这个大难题，算是又跨进了一大步。虽然前方的路还很漫长，不过我相信离整体完工也是指日可待了，可喜可贺啊，哈哈。
2845
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
