- 博客(13)
- 收藏
- 关注
RSS订阅原创 工作记录2023/9/1
之前子弹被销毁时是直接将表现层的脚本一并销毁了，这样的话即使创建预制体的回调在子弹销毁后才调用，由于引用已经消失，也不会执行相关的操作。但是还有一种情况，就是该回调在执行的时候，原有的表现层脚本已经从取用->回收->取用，即回调执行时该脚本已经再一次从对象池中被取出来使用了，显然该脚本肯定没有被标记为销毁，这使得回调顺利执行，但是新的事件也已经被调用，等新的回调执行完毕后，会将原来的指向旧预制体的变量指向新的预制体，这就导致了丢失了对旧的预制体的控制，从而产生了子弹无法销毁的情况。
2023-10-28 11:45:00
49
原创 预乘alpha小记
并且由于结果始终为不透明，所以混合后的a值是没有意义的值(计算的结果也是错误的)，可以利用其位置储存其他的值。 预乘alpha可以减少纹理过滤产生的失真：假设有两个颜色：（1，0，0，1），（0，1，0，0.1）不透明红色和透明绿色，如果没有使用预乘alpha将其进行双线性过滤：(Ca + Cb) / 2 = (0.5, 0.5 ,0 , 0.55)可以发现，透明度仅为0.1的绿色却和不透明的红色贡献了相同的颜色强度，这显然是不正确的。
2023-10-26 08:15:00
362
原创 环境光照小记
L是复杂的光照，显然是一个高频的，而diffuse的brdf，由于其变化很小，显然是低频的。可以预先将环境光图片进行不同程度的模糊（核取1* 1，2* 2， 4* 4，···），之后在使用的时候可以根据brdf影响的范围在相应的图上获取光照，没有的也可以在相邻的两张图之间进行插值得到。对于一张图，颜色变化不大的区域被称为低频部分（脸），颜色变化剧烈的部分被称为高频区域（边缘）将图片转化维频谱图，高亮部分即为低频部分，其他部分即为高频部分。并且这些函数的频率是越来越高的，越高频率的函数意味着越丰富的细节。
2023-10-24 11:15:00
67
原创 图形处理单元
动态分支的使用（使用了varying inputs 的 if，循环），由于warp-swapping会对warp中的每一个线程使用相同的命令，这就导致了如果有个别线程采用了不同的分支，GPU必须对其使用相应的命令，而其他的线程也必须执行相同的命令，然后抛弃各个线程不需要的结果后才能继续执行，严重影响了效率。顶点数据包含很多有用的数据，其中的法线会有一些不同，某些三角形顶点的法线并不是真正意义上的三角形的法线，而会有些偏差，这是因为某些模型中，该三角面代表的其实是一种曲面，而它的法线也是该曲面在该点的法线。
2023-10-23 12:00:00
54
原创 工作记录2023/8/15
处理方案：对于子弹绘制的限制实际上是为了放弃绘制重叠的子弹，对于不会重叠的子弹不应该进行限制。目前采用的方案是为每一个子弹添加一个flag，该flag由子弹的轨迹，开火点等可能导致轨迹，特效不同的因素构成。在一帧内，允许不同flag的子弹发射，而不允许相同flag的子弹发射两次。由于之前做了一帧内的绘制的子弹数量限制，出现了一个bug，策划那边出了新的角色手持两把枪，而且开火间隔很短，这就导致了有可能两把枪的子弹很有可能在同一帧发射，由于之前做的优化就导致有一颗子弹被吞掉了，只能看见一颗子弹。
2023-10-22 22:38:07
32
1
原创 工作记录2023/8/11
角色的增强值由于之前只采用了一个总的值，又因为服务器每次同步的是增强的总值，这就导致没法判断上一次和这一次到底增加了多少，只能把原来的boost值覆盖掉，但是这就导致了一个问题，从其他地方添加进来的boost值会因为覆盖而直接丢失，导致增强值错误。解决方案：将boost值拆分为一个字典，新建一个表，每个增强属性的来源都对应表中的一个id，也就是让每个增强属性的来源都独自使用一个boost值，这样就可以避免boost值因覆盖而丢失的问题。
2023-10-22 22:37:34
28
1
原创 工作记录2023/8/10
为了解决此问题为每一个封装了角色属性为一个类，由base，value和boost3部分组成，base为基础值，即为服务器发过来的角色基本数值，value为最终值，为基础值和增强的数值组合而成，boost为增强的值。游戏的角色基本属性是由服务器计算好发过来直接使用的，但是还有一些服务器不好计算的属性以及一些短时buff等属性需要客户端根据服务器或者表中的提供的加成的值本地计算。
2023-10-22 22:36:57
36
1
原创 工作记录2023/8/21
处理方案：目前是对子弹进行一个预测计算，tick的时候会计算下一帧子弹和目标敌人的相对位置，如果子弹经过了敌人则认为其在这一帧就命中了敌人，直接进行相关的后续处理。这样可以解决子弹飞到敌人身后甚至往回飞的问题。但是由于预计算了一帧，会导致子弹的飞行轨迹少了一帧，在某些极端情况下会对子弹的飞行轨迹造成影响，表现不好。由于子弹的飞行是按照dt进行计算的，当子弹速度过快然后dt过大的时候，会产生前一帧子弹在敌人身前很远，下一帧子弹就飞到敌人身后的问题。
2023-10-22 22:36:19
33
1
原创 工作记录2023/8/8
这样便可以有效的避免生成多个重叠的子弹，白白浪费性能。优化方案：对于伤害数字，每个伤害数字的产生是通过一个事件执行的，这个事件监听位于表现单元中，所以在表现单元中缓存一个储存了生成伤害数字数据的结构体，产生伤害数字的事件不再直接产生伤害而是给结构体赋值，结构体会在tick时产生伤害数字，无论这一帧收到了多少个事件，都只会储存一个伤害最高的数字，便这样就成功的将伤害数字限制在了一帧一个。
2023-10-22 22:35:15
44
1
原创 工作记录2023/8/8
这样便可以有效的避免生成多个重叠的子弹，白白浪费性能。优化方案：对于伤害数字，每个伤害数字的产生是通过一个事件执行的，这个事件监听位于表现单元中，所以在表现单元中缓存一个储存了生成伤害数字数据的结构体，产生伤害数字的事件不再直接产生伤害而是给结构体赋值，结构体会在tick时产生伤害数字，无论这一帧收到了多少个事件，都只会储存一个伤害最高的数字，便这样就成功的将伤害数字限制在了一帧一个。
2023-10-22 22:34:41
40
1
原创 工作记录2023/8/18
解决方案是将对象之间的直接引用改为索引，用的是逻辑单元本身的唯一uid，在逻辑单元管理器中维护了逻辑单元的对象数组，所有其他类需要访问逻辑单元需要从逻辑单元管理器中通过uid进行查找，这样就避免了逻辑单元被对象池回收后还能被访问的问题，但是由于每次访问需要进行一次查找，增加了计算量。在将逻辑层和表现层的直接引用拆分的时候，发现有一些表现层的操作只需要逻辑层状态改变时进行一次操作就行，但是却在tick中每帧进行检测，随即将其改为事件驱动，大大减少了计算量。
2023-10-22 22:34:03
39
原创 工作记录2023/8/7
这样即可保证每次cd减少的值不会有多余的时间被浪费，通过状态机的循环，即可完成在一帧内进行多次普工的效果。又因为技能cd可能会少于dt，而状态机在tick时只是粗暴的将技能cd减去dt来计算剩余冷却时间，这使得当技能cd小于dt时有很大一部分的dt被浪费了 => 导致的效果就是一帧最多只能进行一次普工，30帧的游戏相对于60帧少了一半的伤害。战斗系统中的dt会随着帧数，战斗速度而变化，而平a的攻速如果过快则会出现平a的cd比dt还小的情况。而之前的战斗系统的技能状态机的设计会让整个流程至少执行3帧 =>
2023-10-22 22:32:09
43
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人