开源游戏掌机——3# GUI的模块和实现逻辑设计

北方. · 发表于 2022-8-30 11:25:21

开源游戏掌机——3# GUI的模块和实现逻辑设计

1、概述
这次是一篇纯文章，没有代码。但是不表示没有写代码和看代码，主要是搞了搞lvgl的源代码和touchgfx导出后的代码。看完后，就不打算用这些了。这个就是一些心得的记录和框架的实现，按照这个框架，大家都可以很快搞出自己的2D嵌入式驱动引擎。
2、GameEngine简述
2.1 通常大家都喜欢拿来主义，直接调用API，并且使用GUI工具如GUI builder等，但是过于简单的GUI其实并不友好，自己如果有想法，其实实现不了，尤其是涉及到动态演示的时候。
本次游戏就打算用开源的框架，然后测试的时候很优雅，但是一到真游戏进行，调用资源多，加载页面复杂的时候，就悲惨了。经常性的超过内存容量，超限，然后我就压缩图片，优化代码，数据重载。很显然，这样的过程反而废了时间。
对于GameBoy这样的街机，其实都是自己有图形驱动的，不会用商业的驱动。

2.2 GameEngine的逻辑——定位
GE的驱动，综合各家的模型很简单，就是围绕所谓显存空间实现的。按照RGB565进行图像编码是比较折衷的方法，比RGB8888要节省非常多，效果还很OK。显存，是自定义的存储空间，可以是内部Flash，也可以启动程序后的RAM，还可以是SPI接口的外部SPI Flash。其中，使用RAM是最常用的，就是可以定义一片空间，对于嵌入式，不设计内存分配，程序都是用动态分配，在程序中自动定义一个一维数组变量，那么其实也可以独占一片存储页，这个需要更低层的访问，但是效率更高。即使是EPIC这样的巨型三维引擎，也是遵循着这样的逻辑，起点是显存。
这个变量是一维的，比如320x240分辨率，采用RGB565的格式，就需要38400个0xFFFFFFFF的数据组成。通常，这样的LCD左上角是原点（0，0），那么就要首先搞一个二维变换，对应出每个数字的显示点。二维数据(x,y)，转换成320*x+y这个下标，就可以访问到控制这个点的数据，直接改写，就改写了这个点的颜色。

2.3 GameEngine的逻辑——流程
这个显存数据，根据不同的LCD选择，使用不同的输出和访问方式，最简单的就是用SPI或者I2C的lcd，内置了真正的显存，通过数据传输，更新lce显存的数据就可以放手不管，如il9341，ssd3306等驱动的。但是，最麻烦的就是无驱动显示屏，如使用VGA，或者lvds接口的显示屏，就需要自己搞驱动，这个驱动逻辑上也简单，就是增加了行同步和列扫描的功能，Hsyn和Vsyn，分别需要深入了解VGA协议和LVDS协议，这个确实搞死人了。我用FPGA的Verilog语言模拟了一通，没有调试成功，直接放弃，因为通畅MCU也无法支持这么高速的扫描和通道，但是LPC55S69是可以支持的。问题是，搞成驱动，游戏就没有办法支持了，资源都被占用了。在搞了很多事情后，只能折衷用ili9341作为优选方案作为本项目的LCD方案。等搞成后，还是要搞到直接驱动。因为受SPI最大速率的限制，无法支持超过800x640这样分辨率的高速刷新。
GE的核心逻辑超级简单，就是按照指定的刷新频率，不断地传输数据。保持没有频闪的情况，使用60Hz是比较适合的，最低30Hz已经感受很不好了。就是一边在游戏的逻辑下，刷动态数据的变化，另一边自动把这个数据刷到真正的硬件显存中区，对于支持DMA的就非常省事，在初始化端口后，定义了DMA读取的内存区段，直接刷入SPI缓存，让lcd不断自动读取。可惜，目前基于ARM-M4的NXP内存都没有这个功能，只能自己去手动。

3、游戏模型建模
3.1 这个驱动的框架基本完成后，就进入游戏建模。驱动模型是和硬件相关的，这个和游戏模型是需要隔离的，不能把这两个模块的代码混合编写。所有，游戏部分，就需要建模。
简单的游戏模型核心只包括两部分，模型和渲染（modeling & Render)。复杂的模型，只是增加了滤镜，动态，非线性轨道，人工智能交互，核心和简单的完全一样。

3.2 模型定义。
这个比较有意思，经过对于Avatar等模型的分析，折算成人性的模型并简化后为10点模型，就是两个W用L串起来。

这个折算成数据，就可以简化成一个12维向量（a,b,c,x1,x2,x3,x4,x5,x6,x7,x8,x9），定义一个唯一的火柴人模型。那么其他的造型，也可以参照这个样子，定义任意维度的向量，什么狮虎龙豹，虫鸟鱼蛇都是要定义一个骨架，用一维数组表示。
模型出来，就要动起来，那么就分解动作，分为平移(shift)，旋转(rotary)，伸缩(ratio)这三种变换。具体如下。
平移(shift)，对应变换（Δx,Δy）,（x+Δx,y+Δy）
旋转(rotary)，对应变换角θ，

P'x=Cx+(Xo-Cx)×cosθ-(Yo-Cy)×sinθ

P'y=Cy+(Yo-Cy)×cosθ+(Xo-Cx)×sinθ

伸缩(ratio)，公式过于简单，不写了。
这三种变换的组合就构成了模型的变换，因此，初始模型，和模型变换两者的组合就是模型建模部分的逻辑。

3.3 渲染
渲染通常是最花费算力的，要看渲染的负责程度。
以上述火柴人12维向量的模型来看，最简单的渲染就是把关联点连接直线，那么就是用两点式，已知两点求线上每个点的坐标，临近这个参数取整，一个点一个点地更新显存的数据。把火柴人的每个线连接起来，那么就可以完成最简单的渲染。显存变量的更改，可以直接用在lcd的显示上，这个部分已经在硬件用gameEngine实现了，就不在这个模块考虑。
在本游戏的逻辑，甚至更复杂游戏的渲染中，就要面临另一个问题就是overlap，重叠的过程。那么在这个游戏中非常有趣，对战游戏中，发现渲染到另一个未知的图像，就是表示两个小人打到一起了，就判断collision碰撞。把两个重叠的像素用不同的透明度赋值综合计算一下写入显存。
这个碰撞的数值，就可以直接进行胜负计算和判断，至于谁赢谁输，那么可以设置任意算法，也可以吹黑哨，毕竟各种游戏外挂，搞得就是这个名堂。
所以，渲染就包括渲染，和碰撞判断。在火柴人建模中就完毕了。
那么，我们推演一下更复杂的三维建模怎么办？其实是凉拌，也是要逐个建模的模型计算，计算材质反射率，发射光强和方向，然后计算其他模型的反射光影响参数，碰撞计算和碰撞混合处理。所谓英伟达的超级追光技术，让人感觉更真实，本质就是计算了多次反射光的综合效应，精度高，以至于水滴的反射点高光都可以精确再现，周围物体的反射影像光，也在水滴的球形面上再次反射出来，这样就形成了魔幻的追光效果。其实就是高速并行计算的强大算力支持的。