くつした的个人资料

多边形的连续碰撞检测真是麻烦个人demo里的平面几何算法纯属个人创作、优化，应该有比我更快的。如果只是质点，质点的移动轨迹（扫掠形）就是线，连续碰撞检测就是线段与线段相交，点碰撞在交点；在地形上移动为单接触点移动。下图，线段相交算法 cpu tick(通过rdtsc指令读取)平均为52/次而下图，到地形索引块碰撞上几乎乘以20，当然普通速度不会这么巨大以平常跑步速度为例如下图，【不跨索引块】，地形部分只有一条多段线，如下图，tsc为300多以平常跑步速度为例如下图，【跨索引块】，地形部分只有一条多段线，如下图，tsc会比上面多25%左右----------------------------------------------------------------------------------------------------------------------------------------------- 而线段的移动轨迹（扫掠形）是平行四边形，连续碰撞检测就是段线扫掠段线（多段线简化），线段碰撞扫掠距离最短点，直接看下图，文字表达太烦；在地形上移动为1~2接触点移动。凸多边形的话，只取移动方向上的边，其移动轨迹（扫掠形）是多段线的移动构成的一并的平行四边形，连续碰撞检测就是多段线扫掠多段线，多段线碰撞扫掠距离最短点，直接看下图，文字表达太烦；在地形上移动为1~2接触点移动。线段扫掠碰撞算法 cpu tick(通过rdtsc指令读取)平均为122/次，原理上讲符合线段相交的3倍左右而目前卡在讨人厌额与地形索引块融合的阶段，质点根据索引块边界任一时刻只会属于一个索引块，凸多边形则会占据多个，想要性能好真麻烦。估计最优要到3000~4000 tick

按设计来讲，跑步时可以刹车应该是常见的这个还原出来的移动状态的状态机更新函数从代码功能设计上讲跑步时长大于等于80且按住前进方向键的【同时】按反方向键就可以触发跑步时刹车动画但作者的玩家操控函数中的写法导致右方向比左方向优先级高，也就是左右同按时永远是右，而不按照谁先谁后来判断因此按住左【往左跑】达到80帧后【同时】按住右才会出现刹车动画直至转身而按住右【往右跑】达到80帧后【同时】按住左，【再】松开右才会出现刹车动画直至转身【结合第一天爱跑步的小男孩的话，玩家应该马上就能体验到各种跑步刹车】可以说【同时】这个条件配合左右优先级导致条件严苛，按道理说并不该如此因此没有达到作者的设计意图，而这个问题被作者忽略掉了作者没有未刹车做单独状态

做了个给ID2D1Bitmap描边的功能，可以看到现存占用在增加因为为了优化，ID2D1Bitmap用的是裁剪透明像素后的，所以描边前要扩边（增大图像尺寸），所以显存占用增加原因是看到了这个描边，所以做个描边功能，顺带开启用CPU修改现存贴图的技能

修bug好累，造轮子好累，啥功能都要自己做剩下的这种随机穿透bug原因不好找啊注意箭头选项切换鼠标功能点显示模式下左键标记，右键取消标记没法通过复制位置和速度数据、以及时间线后退再前进来复现再附上ce结构结构文本内容在2楼，文本文件名：THING SIMPLE.csx

关于Effect对象基类Object对象的Confused属性有时间想起来去玩弄一下Effect对象基类Object对象的Confused属性以前看着这个阻拦其它Effect就想到底是哪个Effect才会混乱Confuse一开始以为Object基类里这个Confused独立与角色状态属性里的ConfusedTimer只是为了角色而设置的，想着是不是命名为攻击友方才好，但看到如下还是觉得这个属性没其他效果这个Effect对象没有debug信息表示它的名字，巧合的是“Effect”在debug信息中是指的粒子对象，可见是被作者用来命名粒子对象，而我用的Particle 没有反内联切整理好的汇编的C码就是难看以下是现阶段整理好汇编的AI控制函数

关于这个还原出来的到处内联的贯穿所有属性数值计算的函数，我是实在想不出源码的写法该是怎样的两年前整理好的这个函数的汇编代码到现在也就这样了，再去看看原始的汇编代码的神奇控制流

想要持久玩弄自动模式的场景门导航挺麻烦场景门导航是个门ID数组[20] 通过设置传送触发的话传送完会进入结束事件，要么设置初始场景最右边那个转折点到想要的场景并更改门导航，要么直接初始化演示数据后直接调试断点并修改后继续 20个门走完还是看难度，当然，有不停加血之类甚至完全体技能等等的神之力，主角们就没什么压力了，如果想要循环下去就只能写个自动脚本了

屎待拉的跳崖现象原因还没找到总听到いたいじゃない，这不是你自己跳不准么。游戏的寻路系统的依据就是连续地面和悬崖跳跃标记，公用一个地图寻路对象，每个角色对象里都有用这个寻路对象计算好的寻路数据。作者对于内存空间的使用毫不吝啬啊，角色的附加数据里，像是技能数据技能条件数据技能按键数据等等都是成员定长数组，都是array[lbk]64[rbk]，很多空间都用不上，却不用长度不固定的数组的指针。 AI的基本移动（包含躲避和近身）函数已分析完。剩下就是技能魔法

分析游戏AI已进展到中后期，vc++6真是造屎器逆向这个用vc++6编译的游戏的AI，面对的主要问题就是函数被各种姿势内联导致的代码分析量巨大，以及栈变量的重用产生的生存周期判断，几乎只能反内联，恢复消失的函数和函数调用，以及手动扩栈分离重用的具有不同抽象意义的栈变量，当然少不了为了可读性而建立本不存在的switch跳转表。成为人形编译器而一直敲键盘。寄存器使用真懒，很多不必要的内存读写和寄存器交换。

好久没更新小demo了正在搞多边形CCD算法http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fpan.baidu.com%2Fs%2F1OlEOe6LcCzHRYy2CUkSRyw%3Fpwd%3Dmqfd&urlrefer=eae1d9b570c88feee744ea3e8407797a 质点位移bug不太想修了操作 Esc: 退出程序主键盘0~1：地形切换 A：动画信息显示开关 E：碰撞能量损失开关 F：技能脚步位移开关 G：重力开关 K：按键记录显示开关 M：地形k值显示开关 N：地形矢量信息显示开关 P：技能缓速开关 S：技能速度开关 T：地形索引块显示开关 ins：四倍缓速开关 pageup：缓速倍速加1 pagedown：缓速倍速减1 pause：暂停/继续 space：下一逻辑帧 backspace：上一逻辑帧 tab：显示标记 ctrl：鼠标到地图表面最近点 capslock：小键盘5：重置视口位置小键盘8246：上下左右移动视口小键盘0：视口更随鼠标中键：拖拽视口鼠标滚轮：缩放视口 F12：重置缩放视口 F1：不显示其它尔茄 F2：显示你的过去和未来鼠标左右键功能0：GJK凸多边形重叠测试，点击左键画最多两个多边形，拖拽第二个多边形，右键确认当前绘制或删除已绘制的鼠标左右键功能1：地形质点碰撞测试，左键拖拽一条矢量（暂停），所有尔茄以此矢量为速度，以出发点为起点，右键取消暂停 F3：切换鼠标左右键功能 F4：显示角色的点模式（目前地形碰撞实际使用中的模式）对象 F5：改变那个做技能动作的尔茄的动画 F8：显示键盘状态示意图，如果连接手柄则顺带显示手柄信息，没有做手柄控制，想搞多手柄与键盘分别控制不同 ←或→：行走 ←←或→→或shift←或shift→：奔跑 ↓：蹲 ↑：防 C：跳（长按短按高度不同） ↓C（无先后）：下穿地形 →→C：远跳奔跑时→C：远跳【以面朝右为例】在执行不可打断动作时按住要做的指令不放可以在动作结束时马上做新动作 ←←（直到快静止）：高优先级转身（可配合上一条做一些方便的转身配合操作）斩、刺、回旋斩时↑X（无先后）：二段斩上斩、刺、回旋斩时→X（无先后）：二段回旋斩以下和原游戏无区别 X：斩（未启用）X（长按）：吟唱 Z：收剑/拔剑 ↓→：前滚 ↓←：后翻移动时←：迅速减速静止时←：转身 ↓X无先后：刺奔跑时↓X（无先后）：骑枪刺下落时↓X（无先后）：下刺 ←X（无先后）：刺 →X（无先后）：回旋斩 ↑X（无先后）：斩上跳跃上升时↑X（无先后）：圆月斩 →↑X：飞踢 →↓X：车轮斩 ↑→X：跳跃回旋斩 ←↓X：真空斩上

想要有后方向键搓招的同时又能快速转身的话就只能分离魔法和平A的按键了比如，原先按X并松开是斩，按住X时再按方向或先按方向再按X是其他单方向组合键的招式，先按顺序按多个方向再按X是多方向组合键的招式；那么现在就可以全部统一成按住X时按顺序按单、多个方向键（之前一定时间内的方向键也可以生效），至于完成这个招式按键的判断可以是X松开或者达成方向键组合，前者自由度高，后者迅速但造成可用方向组合的限制；魔法则另用别的按键，甚至吟唱时可以以增加一定吟唱后续时间来切换魔法。

最近一直在看3等身绘画，没有绘图板也要重拾画画的技能 RT

请叫我尔茄时间穿梭者本来只保留主控的尔茄的debug功能，并优化到更新一个尔茄只花费平均0.66微秒，单线程2048个尔茄每帧耗时也不过几百到三千微秒完全不掉帧。加入256个过去也毫无压力，只不过移动一下指针的事，可以不计耗时。但全部加入计算未来1秒（64帧）的功能后，给绘图开独立线程的话满算就只能平均不到400个尔茄了。就算追求纳秒级优化也没啥显著的优化效果了。本来这个过去未来轨迹主要就是为了debug而生，从动图可见，主控的尔茄未来轨迹产生了变化，这个问题原因还没揪出来，必须解决掉。

为了解决找到float和int的适用误差而使劲折腾

为了压榨性能，不得不屈服，我也来搞TileMap 回归原初，拿TileMap做碰撞的索引，这样就能用不多的乘法运算换取巨少的线条遍历了

除了二段斩上和二段回旋斩，加一些其他cancel也挺有意思刺和回旋斩从动画上看能接二段斩上和二段回旋斩斩、刺和回旋斩要接刺能看得过去，最早得比上一行的时机再延后一图像帧（只比原先提前4~6逻辑帧，几乎看不出来）新demo试试 pan.baidu.com/s/1OlEOe6LcCzHRYy2CUkSRyw?pwd=mqfd

法阵文字

搞了个足部帧位移机制，对比一下先要定重心，才能定位移

一直没做攻击盒展示，看看斩的第一段攻击盒是如何被受击盒针对的以庆祝飘带的中心为受击盒（黄）攻击盒（红）角点看看斩的第一段攻击盒是如何被受击盒针对的，可以参照墙的分界线斩上对真空斩上表示不公平真空斩上对斩上表示你太夸张

换装暗魔女一楼喂熊

武装奥古的霸体居然不是用引擎读取类成员估计是代码硬编码的

龙的姿势好sao啊 1L放图会被吞

游戏的时间管理大师，名其为TimeMGR 抽抽抽，摆渡继续抽今天心血来潮将其逻辑镇更新间隔由16毫秒改为1（最大100就不更新了）及其鬼畜。比较适合快进的是改为4或8，慢放则32。对于快进，即使渲染帧会给逻辑帧让位，丝毫没有减慢到渲染帧的进行，但因为平时渲染帧速度是128fps，相当于渲染1帧间隔7毫秒，用对战模式AI2v2看逻辑帧比渲染帧快8倍完全神仙对决。对于慢放，因游戏响应玩家操作的代码只是与逻辑帧同步，逻辑帧速度变慢会让游戏错过更新玩家的输入操作，对于稳定地观察攻击盒到是很方便。这里GIF是缩减帧数并加快过时间，不然太大摆渡不吃

看了NOCD.exe对sotesp.dllpatch的地方就是改了dll入口点到新加的洞穴函数，这个函数从sotes.exe内存开头寻找两个检查授权的函数patch成返回1，以及patch所有场景剧情函数开头比较授权凭证信息的地方。

开始解析图像资源数据

不细看真注意不到史黛拉跳跃上升停止时是察觉到裙子就要飘起来感觉按下去

尔茄的妈妈和索菲亚老师是设置了行走属性的但没有行走动画，一移动就崩溃

试着根据栈结构修复oep 本来想动态跟一下作者ep怎么绕的，看到不少函数和各种控制流一想就算了

分析下来，作者本打算在对战模式team2加入敌对角色就是怪和boss之类，应该就是练习用的，可以说类似训练场，可惜了，没有空间加入数据

感觉婴儿法师·红本来是科拉特村隐藏山东的boss的

想让CE显示NTLEA加载的日文版的日文似乎只能想到这么搞了，这里拿productkey的地址当buffer 要是拿整个密钥对象当buffer用的话，字符串空间可以达到1040字节

测试发现让水上升的话，AI被淹没后不会去离开水，恩有让水上升的老是改汇编挺烦的，不改的话ida反不出简洁形式真不知道vc++6.0的锅还是themida的锅，后者应该没这能耐吧改过后不是计算量更少了吗

花了6小时反编译了40个激活用的函数我算是学到了这种字符串转换方式。原理分5层，密文从第5个字符开始按字查字节表，查表前各高低字节减31并搞颠倒，把位置对应ascii作为字符，每组字依次查32个表到找到为止，根据找到的哪个表再加料。总结出来后看挺简单，只不过汇编代码迷惑性有点强分析时挺需要直觉不能看代码表面。直接调用游戏的函数返回密文的明文

通过这三个月对1000多个函数的反汇编体会到作者从刚开始的精致风格到后来的糊弄的转换。人啊，以兴趣为目的可以越来越精致，以利益为目的则逐渐丧失追求。

这样翻译才对哈哈，大摇大摆的说是因为我藏在别的地方啦

一直造轮子，还是得写个call调用监视有些函数调用太多，不这么搞不好定性

以现在对游戏的理解实现了开局5尔茄存档除了不会放开头精灵石外，真正的从开头开始开头演出不会自动散开似乎没啥乐趣了下载地址 http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fpan.baidu.com%2Fs%2F1o69FJlC&urlrefer=5e66d3405492479debf8ab7798a042d4 里的这个用法和普通存档一样

夏尔特北关去往王都的门是存在的只不过门id在当前场景数据中没有设置时不会显示提示进入的箭头其实场景就没做，其实就是没做完就准备卖比如巴厘村最左边也是有这样的转折点（通常不需要按上的门）科拉特村第二个洞穴里是有隐藏门的显示出来这样科拉特村外面岔路右边空气墙最右也是有一样情况的转折点除了东奇尼镇和夏尔特都，其他镇子已经北关都没有做门窗灯光发光点，居民都身处黑暗中百度你再删

先利用ce的断点函数做了导出对话和对话者的功能看起来就像剧本似的正好可以把剧情文字按日目切分，并且分成做主线剧情和额外可以出发的对话。这样结合中日对照调整翻译就舒服多了。

史莱姆之舞

可能翼龙除了1级和二级以外，原本有3级因为在初始化对象数据时，使用了第三个角色代码来初始化语音（第一个为1级翼龙，第二个为2级的），但用这个代码来召唤时报未知对象类型。

游戏引擎缺乏很多优化就比如

关闭角色的魔法阵后还挺好看魔法粒子聚集中心在角色精灵石处，3主角位置不一样，这个特效在低画质不生成只能说魔法阵喧宾夺主了

直接改掉前滚后翻以及萨娜史黛拉的后步的40毫秒按键间隔太烦了，直接修改push 的 40为 0，这样就没有太大延迟了。还有后斩的 50 毫秒改为 10，明明后刺以及所有单方向组合键可以x在方向键之前按。

游戏引擎其实是支持多人操控的按键记录器在allocmem时有类似数组数量设置，一直设置为1个按键记录器。再比如游戏会检测3个ControlPad。而且每个角色是有单独的操作指针指向按键记录器，并且只要不是设为AI操控就会检查响应操作，可以设为游戏分配的这唯一一个按键记录器来同时操控场景里的所有角色。队伍长度也许可以不止于于故事模式的一组队伍和对战模式的两组队伍。也许一开始就考虑了双人玩对战。总之游戏引擎里藏着很多功能。从反汇编生成的c码看，作者的编码追求不怎么高啊，难不成是编译器优化的锅。

游戏是这么检查存档的

我觉得可以改造成一台电脑双人操作的

还是要做个鼠标拖拽地形贴图，再根据贴图生成碰撞的算法输入一片贴图引用数据生成一片贴图到屏幕中央上方，然后鼠标拖过去（复制），最后先直接导出内存数据，可以再写入，游戏如何读取地图和保存地图以后考虑。

地图贴图引用数据结构已解，是5维数组，即改即生效要好好改的话还需要把引用码和贴图对应起来，这可比人物、物品、特效这种大块规则的要难多了。

解了一部分地图信息这就是分块信息了换个形式

不知道为什么前滚后翻按键要设个40毫秒间隔下蹲对受击盒的降低有很大延迟，车轮斩没有，前滚因为40毫秒的存在而相当于产生了延迟。受击盒降低特别克制斩的第一段小攻击盒（头前上方），真空上斩和上斩同样的其实动作，前者却能降低受击盒。狗头人和高级狗头人的回旋斩只有第二段攻击盒，在后手情况下选择对技能不可能受伤。 ida反出来的算法太蛋疼，不想整理了。

这样搞还挺调皮非暂停模式下有重力速度不好搞

已经用实现了场景初始化好了之后运行函数接下来就试试根据尔茄萨娜的目标怪物来动态更改其AI吧先要各种观察AI如何打怪来针对优化了，还是先移除怪物的AI限制呢

突然想到汉化时可以处理一下Mutex多开进行校对我也只能看到了错误才修正得到

突然想到已经可以去实现自动生成不思议迷宫的路径信息了

FS Map Screenshot.zip http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fpan.baidu.com%2Fs%2F1o69FJlC&urlrefer=5e66d3405492479debf8ab7798a042d4 内容为 jpg 格式文件名为：地图代码 - 地图尺寸尺寸为严格的真实尺寸，不显示主角和UI，原生截图无图像更改，室外未处理中景背景，来猜猜看是哪里吧

暂停时可以拖拽视口，那就直接全地图截图吧正好实现了任意地图传送，又能隐藏队伍和ui，去除所有怪后，直接发送f11逐行截屏后移动视口整个屏幕大小

AI尔茄对AI尔茄总体来讲还是后手1逻辑帧出招好基本都能反制和躲掉，老是相杀太没观赏性。 AI似乎是能用技能就马上用技能，对人读指令占了时间优势是很有效，如果能加入观望迂回行为就有意思了。而且演员的技能条件就是为尔茄对尔茄而设计的，为对怪而优化技能条件后在对战原始AI尔茄时有一小段时间全是劣势。

给IDA整得心累，搞个鼠标中键拖拽视图居然出现画面撕裂

有时很想对照导出的日文字符串表重新汉化可惜工作量太大，以前只是简单的写了从c字符串\0反向推算字符串的函数，一直没去优化字导出函数的符判断逻辑，导出很多其它数据格式的内容，而且首位错位1个字节都可能导致整个字符串显示不对，校对量太大。感觉圆桌的exe就是dump下来的，毕竟包含了内存里后加载的内容