1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | #include <iostream> const int ArSize = 6; int main () { using namespace std; float naaq[ArSize]; cout << "Enter the NAAQs (New Age Awareness Quotients) " << "of\nyour neighbors. Program terminates " << "when you make\n" << ArSize << " entries" << "or enter a negative value.\n"; int i = 0; float temp; cout << "First value: "; cin >> temp; while (i < ArSize && temp >=0 ) { naaq[i] = temp; ++i; if (i < ArSize) { cout << "Next Value: "; cin >> temp; } } if (i == 0) cout << "No data--bye\n"; else { cout << "Enter your NAAQ: "; float you; cin >> you; int count = 0; for (int j=0; j < i; j++) if (naaq[j] > you) ++count; cout << count; cout << " of your neighbors have greater awareness of\n" << "the New Age than you do.\n"; } return 0; } |
#include <iostream> const int Cities = 5; const int Years = 4; int main() { using namespace std; const char * cities[Cities] = { "Gribble City", "Gribbletown", "New Gribble", "San Gribble", "Gribble Vista" }; int maxtemps[Years][Cities] = { {95, 99, 86, 100, 104}, {95, 97, 90, 106, 102}, {96, 100, 940, 107, 105}, {97, 102, 89, 108, 104} }; cout << "Maximum temperatures for 2002 - 2005\n\n"; for (int city = 0; city < Cities; ++city) { cout << cities[city] << ":\t"; for (int year = 0; year < Years; ++year) cout << maxtemps[year][city] << "\t"; cout << endl; } return 0; }
半夜三更,挑灯夜战….
这么多的初始化数据..能不让我这么纠结么?
这两天对智能寻路算法比较感兴趣
去搜了搜,都说A星算法是最完美的…那好吧..我就研究研究A星….
个人理解A星算法的核心思想就是评估当前点附近可以移动的点到终点的移动代价
然后选择代价更低的点作为当前点
如此循环,直到到达终点或者没有可移动的点
理解A星算法的时候是没有问题的,但是如何建立数据结构和地图模型却耗费了我不少时间
最后选择的方法是创建一个了一个包含父坐标,G/H/F值的结构体,然后用这个结构体创建了一个和地图大小等同的二维数组
这样的好处就是每个坐标的坐标位置也是它在数组中的位置,这样就方便很多…
在建立数据结构之前最好把算法吃透,这样才能保证数据结构的合理性…
像我上面的方法其实也有不合理的地方..每次寻找开放列表的时候要逐个判断一番
包括还没有进入开放列表的点,它也会进行最少一次判断,明显浪费了很多时间
现在特别大的地图还是很慢,正在研究如何使用二叉堆,据说提速效果很明显
如果将1000*1000的地图寻路速度保持在100MS以内,应该就可以满足应用要求了
放几张图…
另外附上源码……
注意,左键选择起点,右键选择终点
#include <iostream> int main() { using namespace std; int a; int b; cout << "请输入一个数字:"; cin >> a; cout << "请输入第二个数字:"; cin >> b; if (a == b) { cout << "第一个大!" << endl; } else { cout << "第二个大或相等!" << endl; }; return 0; }
最近一直需要研究星际争霸二的信息格式。。15093补丁的更新让我纠结的欲仙欲死……
以前的分析全没用了,该死的暴雪改变了整个录像信息存储格式……好吧……我们来看看暴雪有多YD……
一般来说,在文件里保存一段数据,肯定会在字节之前某个位置储存数据的长度……恩,一直以来暴雪也是这样……
15093更新之前也是这样……
15093更新放弃了replay.info文件,而是把信息存放在了一个新文件replay.details里面。。令人诧异的是,在一些明文信息比如玩家名称、地图名称等字符串的前面我找不到长度在那……这是很令人沮丧的事情,毕竟没有长度我的程序就不知道应该读多少个字节,不知道何时停止………………在我N+1次欲仙欲死后……终于发现了一点端倪,数据长度不是明文表示的……它的数据长度是真实长度*2保存在文件里………………!比如MiniMap.tga总共11个字节,16进制则为0×0B,该死的暴雪竟然把它储存为0×0B*2=0×16……好吧……虽然这时我已经可以保证读取出正确的数据了……但是真的是一点愉悦的心情都没有……深深折服在暴雪的YD里……长度*2储存……难道这是暴雪的加密?我只感觉它在玩人……
另外暴雪这次位运算使用的很多,记录时间用的是位运算,新版的颜色信息也用的位运算。新版的颜色也耗掉了我不少时间,不过主要分析不是我在做……终于还算轻松了……逆向的哥们儿把星际拖得一丝不挂,却也看了半个多钟头才看明白暴雪怎么储存的颜色……也很YD……不过感觉没有那么玩人。在每个玩家的种族数据后,必定可以看到两个字节0×00,0×09,而之后百分之九十九是0xFE,0×03……在旧版的录像格式里我们知道暴雪的玩家颜色是由四个数据段组成的,分别是透明通道和RGB信息,一般是调整不了透明通道的,所以第一个肯定是0xFF……这里0xFE,0×03对应的其实就是0xFF。跳过0xFE,0×03后我们会看到[0x02,0x09,0x??,0x??,0x04,0x09,0x??,0x??,0x06,0x09,0x??,0x??]看到这里大家想必已经看出点规律了,每个0×09后面的两个数据应该就是RGB数值了……好吧,你猜对了,但是他们的算法却没有这么简单。暴雪将0×09后的第一位数据右移两位,将第二个数据左移16位,然后将结果位或,得到的才是真实的结果……
举例[0xFE,0x03],0xFE右移两位得0×3F,0×03左移十六位得到0xFF,0xFF OR 0×3F = 0xFF = 255,其他数据亦是此算法…………恩。。你想到了吗?我反正是囧了……不逆向估计没多少人能看出来……
恩……纠结的暴雪…………
附个replay.details颜色数据图



最新评论