我现在是以帧数，也就是6作为除数来平滑移动，我之前也用过dt作为除数来平滑移动，但是发现这样卡顿更严重，我现在的方法反而流畅多了
在第1帧移动了，那么就会在第1帧同步，不可能到第6帧才同步的。
第一帧移动：收到服务端下发的第0帧–>验证操作，如果没有则无视，获取摇杆方向、A键按下并发送到服务端–>服务端下发第1帧–>验证操作，得到摇杆方向和A键按下，移动人物1帧，创建子弹（假设A键是射击）
以上的帧是指逻辑帧（根据服务端帧频，一般15fps-30fps，固定的），不是渲染帧（客户端帧频一般60fps，根据性能不固定）
dt是不可能卡顿的，等于把帧跟帧之间不固定的时间差给平滑碎片化了，如果缓存逻辑帧几帧，那么不可能不平滑。。我现在不缓存也非常平滑。
你是没有区分好逻辑帧和渲染帧update的区别。逻辑帧做计算，而渲染帧只处理渲染不做任何计算，任何计算都在逻辑帧中处理，比如说玩家在该逻辑帧后的位置、子弹是否与人物碰撞，将计算结果放到渲染帧update里面显示就可以了。由于逻辑帧都是每100ms同步一次，每100ms计算一次位置、碰撞，所以所有客户端可以在同一个逻辑帧保持同步，这就是帧同步、状态同步的原理。你这里的描述是明显都是在渲染帧update处理了计算了，所以没法同步。
你的游戏摄像机会跟随主角玩家移动吗
抱歉，回复错人了
您的玩家移动是先表现出来，再上传给服务器的吗？
玩了一下，穿墙很频繁，有时都穿墙到地图外面去了
现在这样的体验也就ok了，要再优化，就得网络延时的时候做预测，而预测就会有纠正，纠正又涉及到平滑修复，涉及的点还是很多的。
你看上面几楼回复你的第二点，是先将位置上传给服务端，服务端广播帧消息到客户端，然后客户端再表现
感谢提醒，我也有发现这个bug，但是好像并不频繁吧
帧同步不应该上传位置，而应该上传操作
mark,回头学习一下
如果同步位置那就是状态同步了
1赞
插值移动
当前帧和下一帧之间有延迟，你得让当前帧继续向前走，等下一帧来得时候再调整位置。
不然在等待下一帧的时候，就卡了。
拜托了,这个函数库也给我一份. 
谢谢，我看看
我卡着不能动