在游戏系统开发中使用适配器 (Adapter) 模式

在讨论标题问题之前,可以先看一个 VS Code 调试器使用适配器例子:https://code.visualstudio.com/api/extension-guides/debugger-extension

VS Code Debug Architecture
VS Code Debuger Adapter

若要实现一个 VS Code 的调试器,调试器进程通过 Debuger Adapter 库以调试协议与真实的 VS Code 通讯交互来实现。

通过中间的适配器层,调试器与 VS Code 调试UI相互不知道对面的具体实现。

VS Code 只要关注适配器发出的所有协议来作调试响应,而调试器不关注 VS Code 是如何处理这些调试命令的。双端都不知道对面如何处理这些信息,也不必关心。

继续阅读“在游戏系统开发中使用适配器 (Adapter) 模式”

独立游戏到目前为止的所做的内容

到目前为止主工程已经有 241个提交,从2019年12月20日起到2021年3月。讲实话,很佛系的开发速度。

不过从多年的挖坑经历来看,已经坚持最久的一个了。

2019年12月~2020年2月底

虽然不能说完全不会 U3D,但是并没有系统性的学习过,这一时期主要还通过U3D自己的一个FPS项目来学习一些基本概念以及资产之间的交互。添加基础场景和角色单位进行移动,阴影设置,光照探针,场景烘焙测试,内置UI,以及光源和下雨特效等。

嗯,墙就是N个CUBE拖出来的

可以看出墙体因为是直接 CUBE 改缩放得来的,所以UV不会变,烘焙的效果会有点奇怪,意识到可能还是得自己建模。于是决定跑去学 Blender。

继续阅读“独立游戏到目前为止的所做的内容”

一个用来看世界的配置

需要通过 docker-compose 部署,提供了三组配置脚本。需要两台服务器,其中一台作为稳定的中继。中间套了kcp/udp2raw 协议。

实际编写的时候有个坑,udp2raw 无法解析dns,需要手动解析dns才能访问其它容器,通过 docker-compose 编排略有不方便。

https://github.com/frimin/dockerapp-shadowsocks

lua table 源码阅读

近日配置了下终端下的 vim 插件,把 c 相关的开发插件都弄的勉强可以用了,为了熟悉下 GDB 的一些基本操作,就拿读 lua 部分源代码来练手了。

这里所有的内容均基于 lua 5.3 版本。

table 的内部操作定义于文件 ltable.h / ltable.c 中,有以下相关的函数构成:

  • luaH_new : 构造一个新的 table

1.初始化

Table *luaH_new (lua_State *L) {
  GCObject *o = luaC_newobj(L, LUA_TTABLE, sizeof(Table));
  Table *t = gco2t(o);
  t->metatable = NULL;
  t->flags = cast_byte(~0);
  t->array = NULL;
  t->sizearray = 0;
  setnodevector(L, t, 0);
  return t;
}

首先由 lua gc 模块分配一个被托管的垃圾回收对象 GCObject *o, 然后转为一个指向实际的 table 结构的 Table *t 进行初始化操作。

一个 lua table 被分为两个部分:数组部分和哈希表部分。

数组部分的初始化比较粗暴,直接置零。

t->array = NULL;
t->sizearray = 0;

则哈希表的部分由 setnodevector 函数来初始化,由于传入的特殊表大小 0,哈希表部分被指向一个 所有哈希部分为空的 table 所共享的一个静态变量 dummynode (此处为一个宏)

static void setnodevector (lua_State *L, Table *t, unsigned int size) {
  int lsize;
  if (size == 0) {  /* no elements to hash part? */
    t->node = cast(Node *, dummynode);  /* use hashnode 'dummynode' */
    lsize = 0;
  }
  else {
  ....
继续阅读“lua table 源码阅读”