[Day16] 再战SAT

今天花了一整天Debug,一直看为甚麽「Not Work」,单纯纪录一下流程。

今日目标

  • 修好昨天的SAT范例

简单纪录Debug的流程(?)

依照昨天的文章把SAT碰撞侦测分成几个步骤,开始算(演算法)之前会需要一些资料。

先说结论,其实目标蛮简单的,图形也就两个矩形而已,怎麽花了这麽长的时间Debug

  1. 没搞懂向量的运算
  2. 没有善用Debug工具,例如简单的画线标示向量
  3. 当预设范例不成功时,没有拆解更小或更简单的范例去实作

第一点,没话说,数学基础差,只能多多接触跟多算。第二点,除了之前的Log,还标示了座标位置与法向量的「点」,对阿...我怎麽没想到是标示「线」呢。

最後第三点才是我找出问题的关键,昨天有提到「AABB是一种SAT」,他的法向量就是XY两轴,原本是设定两个旋转45度矩形互撞,发现有Bug,印出Log看看顶点、边、法向量等资料,看不太出来,於是把两个矩形转回正的,再印输出一次Log,发现到法向量不是X或Y轴,结果发现是之前写的求单位向量的功能,是错的(因为之前写完就没有一一测试呢....ˊ_>ˋ)。

再来是救是SAT的核心演算法了,要求出每个顶点对各个法向量的正投影,如果XY两轴为可能的分离轴,四个顶点又是没有旋转的矩形的四个点,以X轴为例,其正投影就会是该点X轴的分量,用点积算出来也就只会是X纯量,结果出来,也是错的....,到头来也是之前写的点积算法错了.....(ˊ_>ˋ)

最後...终於修好了范例(ˊ_>ˋ),对!只有范例,没测过其他的情况。

计画敢不上变化

原本预计碰撞之後,可能开始进行物件的移动,以及物理的部分,但最近这几篇发现原本设计的架构,写的绑手绑脚的。明明是C,却以OOP的思维,用了最OOP最令人诟病的部分,刻意把一些数据用类似private的部分封装。

加上原本设计DrawRectangleDrawTexture就是想要单纯的封装实作,只要填一些数据就好...

或许是要调整整体设计了。不然之後可能会有更多坑...

这是完成的结果,相当凌乱,没有整理


<<:  [Day 11]在你顺利的时候来一拳才是标配(前端篇)

>>:  11 - Metrics - 观察系统的健康指标 (5/6) - 使用 Metricbeat 掌握 Infrastructure 的健康状态 Kubernetes 篇

D10-(9/10)-荣成(1909) 纸箱需求旺

注:发文日和截图的日期不一定是同一天,所以价格计算上和当日不同,是很正常的。 声明:这一系列文章并无...

【从零开始的 C 语言笔记】第二十四篇-程序设计的流程图制作

不怎麽重要的前言 上一篇介绍了比较少使用到的switch条件式,其实也可以用if条件式代替使用,不过...

Day36 ( 游戏设计 ) 钓鱼游戏

钓鱼游戏 教学原文参考:钓鱼游戏 这篇文章会介绍,如何在 Scratch 3 里使用多个角色、函式、...

DAY 30 资安裁罚案件汇整:共26件裁罚案,其中22件保险局,2件证期局,2件银行局

以下为笔者针对2019/01~2020/10为止的资安裁罚案件整理表,共26件裁罚案,其中22件保险...

【Day16】TestBench 的撰写技巧

透过 Verilog 完成一个具有特定功能的电路後,并不代表你的工作已经完成了,TestBench...