范安崇的博客

背景最近，对 go 版本战斗 API 服，做了性能优化。使用 C++ 重写了 战斗 API 服战斗 API 服 逻辑功能很简单：有 gRPC 服务Cgo 调用客户端提供的 .a 战斗库而用 C++ 重写的理由，大致有以下几个方面考量：Cgo 调用，比纯 C++ 调用会有消耗根据服务特点，每次 Cgo 调用涉及了较多的 go cgo 间的内存拷贝C++ 可以严格控制线程切换，减少线程间切换消耗测试结构对比C++ 版本：Go 版本：分析说明：C++ 版本性能是 Go 版本

历史问题对浮点数处理，涉及编译器、硬件等对浮点数2进制表示的细节不一致，都有可能，对同一输入的浮点数计算，产生不同的结果。 但是如果你愿意做大量的工作，让你的编译器“严格”符合IEEE 754编译模型以及限制你所使用的浮点数操作的集合，你或许可以让不同的编译器和不同架构的机器能都对浮点数计算得到完全一致的结果。这通常会导致显著降低浮点计算的性能以上摘至 游戏网络开发(五)：浮点数...

平滑位移前面在IO游戏同步系列文章中介绍过客户端影子追随算法：渲染球追着逻辑球位移逻辑球没更新，则渲染球保持逻辑球当前速度继续做位移（当前速度为0，即为停止状）这样在可以接受的网络中，画面可以保持流畅。上述 影子追随算法，在帧同步游戏中同样适用。帧同步游戏本身就是 游戏逻辑与渲染逻辑相分离 为基础；影子追随算法也是这样。2者有天然的契合度。可以接受的网络前...

问题帧同步中的逻辑层使用的简单包围盒做碰撞。渲染层要表现出”拳拳到肉”的效果。比较直接的方法是 逻辑层有一套完备的定点物理引擎。这里讨论的是，是否能在现有技术上，达成”拳拳到肉”的效果。逻辑层与渲染层的关系先理清逻辑层与渲染层的关系，有助于本文后面要讲的实现方法。服务端与客户端的关系 传统端游，1 份游戏服逻辑 + N 份客户端逻辑。N 份客户端逻辑根据 游戏服逻...

测试代码https://github.com/fananchong/test_udp/tree/master/test1测试内容服务器以 66 毫秒 发送 400 字节的数据包，查看客户端前后 2 个包的时间间隔弱网模拟本次测试做以下2种测试：服务器输出方向模拟类似：tc qdisc add dev $NETCARD root netem delay 100m...

常见的验证方案一般有以下 2 种方法：apk 包加壳好处是，通用方案，不需要考虑具体项目细节坏处是，专业性太强，加壳是否可行未知（本人）服务器端验证1 个玩家，服务器端跑战斗逻辑，做验证2 个及以上玩家，服务器端比对结果或跑战斗逻辑，做验证下面针对 服务器端验证 来分析下做法、是否可行先分析下原理验证原理 - 1 个玩家ClientServer开始战斗发送...

ARQ 协议TCP 、 KCP 都是基于 ARQ 协议原理实现的，达成在不可靠的网络服务基础上，实现可靠传输ARQ 协议包括 2 种形式：形式工作方式特点停止等待 ARQ发送数据包，等待 ACK 包；超时重复发送数据包网络带宽利用率低；实现简单连续 ARQ连续发送 N 组数据包，等待 ACK 包，超时重复发送数据包网络带宽利用率高；实现复杂需要考虑是否会造...

libfixmathlibfixmath 是一个将浮点数用整数表示的开源库github: https://github.com/PetteriAimonen/libfixmath.git使用整数表示浮点数，并提供了常见算术函数：函数说明fix16_abs求绝对值fix16_floor下取整fix16_ceil上取整fix16_min求最小值...

帧同步工作流上的问题由于帧同步战斗部分逻辑，需要同时在客户端、服务器上跑。 2 端需要保持一致如果不提供某种联调机制。会对客户端战斗库开发、服务器更新，都会造成不便设想下以下这种情况：2 个客户端都做帧同步战斗部分的相关工作服务器的开发服又必须提供稳定的，对所有工作人员提供服务势必无法协调 3 者的协作关系本文提供一种机制，解决该问题示意图+------------------------------------------------------+ +---