越来越多的人选择用Mac或者Linux环境进行跨平台项目开发。但是仍然有大部分人习惯于在Windows环境下进行开发，毕竟Windows在各方面使用还是较为方便，特别像文件版本管理（Git，SVN等）

在跨平台下开发游戏或软件，就需要有一套方便的自动化工具。Windows下需要使用批处理，虽然有PowerShell加持，但这东西学了也不靠谱，只有一个平台能用。大家还是习惯Linux Shell。连Mac平台都可以用Shell，Windows上要做自动化脚本就显得非常尴尬。

我曾经在项目中使用go编写了一套将配置转为批处理和Linux Shell的工具。使用过程较为复杂，但是能跨平台进行表格导出和协议编译等工作。

但是，这个工具还是需要对不同的平台编写多套模板进行代码生成，非常繁琐。如果有一套跨平台的Shell，编写一次就可以跨平台运行那该多好。

查阅资料后，一共有几个方案：

1. 使用Python作为自动化工具 这个方案其实就是使用python把批处理和Shell干的事情用代码来解决。但前提是要重新学习Python，也需要一部分熟悉简单的Python语法，人为学习成本较高，也比较费事。

2. 自己编写一套独立的自动化工具 这个方案需要长时间的适配过程，差什么指令补什么指令，对项目进度有一定干扰。

3. 自己编写Linux Shell的解释器 这个就更难了，要做到100%兼容，基本不可能。

4. 使用Cygwin和Mingw 需要一个微型运行时进行Linux Shell的解释，msys大概是18M左右，可行性较高。

在研究Cygwin和Mingw如何整合的过程中，我误操作点击了一个sh后缀的Linux Shell，这是我希望让Mingw运行的Shell。结果呢，sh后缀的文件居然能在Windows下运行。我马上编写了一系列的例子，发现几乎完全兼容常用的Shell指令。 经过研究，我发现Windows下能运行sh文件是由Git自带的msys2提供的。MSYS2 （Minimal SYStem 2， http://www.msys2.org/） 是一个MSYS的独立改写版本，主要用于 shell 命令行开发环境。同时它也是一个在Cygwin （POSIX 兼容性层） 和 MinGW-w64（从"MinGW-生成"）基础上产生的，追求更好的互操作性的 Windows 软件。

那就是说，只要安装了Git（https://git-scm.com/），那么就可以在Windows下直接运行Linux Shell，只需要将文件后缀命名为sh即可。

问过周边友人是否知道这一功能，都说知道，只是没有广播而已，害我研究很久……

基本概念

• Golang的热更新采用什么机制?

  使用go1.8提供的plugin包机制实现

• plugin包本身设计的目的是热更新么?

  plugin包其实只是支持将代码分别编译为多个动态库,动态加载后运行 并不能完全支持类似C/C++的动态库方式处理代码

• 带状态的进程热更新的基本概念及范围是什么?

  数据部分(model)不更新, 只更新逻辑部分(函数)

• 表格和配置更新算热更新么?

  算, 但不是本文描述范围

• 热更新能在windows上使用么?

  不支持

代码及结构

• 我能将原来一个exe的代码编译为so提供给plugin使用么?

  可以, 但是必须仍然保留main包作为插件入口, 并在main包内添加提供给plugin调用入口.

• 如果动态库中没有main包, 编译出的so能用么?

  不能, 包必须包含main, 否则输出的是.a的文件, plugin包加载会报错

• 动态库中, 非main包的的代码修改能做热更新么?

  不能!(崩溃了吧, 我提了一个issue: https://github.com/golang/go/issues/20554)

  如果确实做了修改, 底层会报错: plugin was built with a different version of package

  解决方法: 修改plugin包底层实现并重新编译 打开runtime/plugin.go, 注释以下代码 for _, pkghash := range md.pkghashes { if pkghash.linktimehash != *pkghash.runtimehash { return "", nil, pkghash.modulename } } 执行/usr/local/go/run.bash 重编译+测试

• 代码中哪些可以被更新? 方法可以被更新么? 闭包呢?

  只能更新拥有静态地址的结构.例如: 包级别函数(类似于静态函数)

  例如: svc_0.so里有一个Foo函数, svc_1.so修改了Foo函数实现, 热更新可实现

  闭包=函数+捕获变量, 实际上是一个动态结构, 没有静态地址, 无法被更新

  各种包级别变量, 结构体变量, 结构体方法, 局部变量均不能被热更新, 但是变量值不会被影响

  新增结构可以被运行

• 使用结构体方法调用了包级别函数, 包级别函数能被更新么?

  可以, 虽然方法不能被更新, 但方法被调用的包级别函数的地址是固定的, 所以可以被热更新

• init包初始化函数能用么? 能被热更新么?

  官方这样描述:

  When a plugin is first opened, the init functions of all packages not already part of the program are called. The main function is not run. A plugin is only initialized once, and cannot be closed

  插件第一次被打开时, 其关联的, 没有成为程序的一部分的所有的包的init函数将被调用. 插件的main函数不会被调用. 插件只会被初始化一次, 不能被关闭

  因此, 需要手动将init函数改成自己的函数, 统一在so的main包里调用

编译

• 如何编译获得plugin包支持的动态库

  SVCNAME=$1 SVCVER=$2 TIMESTAMP=`date '+%Y%m%d_%H%M%S'` go build -v -buildmode=plugin --ldflags="-pluginpath=${SVCNAME}_${TIMESTAMP}" -o ${SVCNAME}_${SVCVER}.so ${SVCNAME}

  -buildmode=plugin是重要参数

  --ldflags里的-pluginpath的作用是: 每次编译的内部识别路径都是不同的, 避免重复加载的警告

  参考: https://github.com/golang/go/issues/19004

相位技术大规模出现在魔兽世界WLK版本, 现在应用已经广泛应用在各种MMORPG游戏中. 下面对相位技术的做法进行简单归纳汇总

表现分类

副本相位

早期副本的出现, 避免抢怪问题. 所以, 副本其实本身就是一种相位技术. 只不过实现时, 我们一般会将小队和怪物直接预分配在独立的一个副本实例中(所以副本原文也是实例的意思)

分线相位

相位技术还没有正式命名时, 同一个场景, 玩家进到不同的分线看到的玩家不一样, 也是属于相位的一种. 当然, 如果是组队玩家, 服务器默认会分配所有队伍玩家在同一个线(位面)

真相位

副本相位和分线相位其实都是静态相位, 一旦进入, 中途不会有切换或者混合查看的过程. 真相位可以在一个场景中,动态切换相位, 相位内和相位外所以不同

我们常见的真相位表现为: 相位中的角色+玩家+队伍成员

在护送任务时, 还会在上面所见角色中叠加世界中的所有角色, 也就是说, 你和队伍成员可以看到的角色, 其他人看不到, 其他人也看不到你和你的队伍成员

为了清晰的简单的描述, 我为相位创建如下概念与名词

相位客体

表现为除玩家外的角色(怪物,交互物体与相位可见场景)

私有客体

这是最常见的一种相位内角色

• 持有变量

  取PhasingID时,为PhasingTargetID

• 生成规则

  当玩家开启相位后, 在玩家相位内生成的角色为私有客体.

  此时, 将 PhasingTargetID设置为相位生成者的实例ID

• 删除规则

  如果玩家退出相位, 私有客体会存在一段时间或按照需求删除

公共客体

一般指提前放置在场景中, 世界内不可见, 但是能被同相位玩家可见,且同相位玩家都可以互相可见 比如: 只要接了同一个任务的玩家, 都可以看到的NPC

• 持有变量

  取PhasingID时,为PublicPhasingID

• 生成规则

  通过场景编辑器, 放置角色时, 设置其可被观察到的任务ID

  角色被加载后, 将任务ID设置到StaticPhasingID

• 删除规则

  场景删除, 角色删除

相位主体

包含玩家与同队伍玩家

• 开启相位后, 可见私有客体+公有客体

• 队长视为相位主体, 单人时, 自己为队长

• 队伍其他成员共享队长的私有相位客体

• 队伍其他成员根据自己的PublicPhasingID匹配目标对象的PublicPhasingID时可互相可见

• 持有变量

相位开启时, 取PhasingID时, 为角色实例ID

相位关闭时, 取PhasingID时, 为0

PublicPhasingID

可见规则

当两个角色的PhasingID相等时, 主体与私有客体互相可见

当两个角色的PublicPhasingID相等时, 主体与公有客体互相可见

可以通过开关设置, 是否在可见的相位客体基础上, 叠加世界角色(护送任务)

约束

• 玩家同时只能看见1个相位

解决方法:

在ParticleSystem组件上勾选SubEmitter, 不要问为什么, 做就好

相关官方链接

http://answers.unity3d.com/questions/218369/shuriken-particle-system-not-rendering-particles-w.html

天煞的, 4.X程序无法访问粒子系统的参数, 所以只能辛苦美术兄弟们了

基本注意点

• ios ipv6适配无需修改服务器, 也就是说, 如果你的服务器依然是ipv4的也是可以使用的
• 苹果的适配方案是将ipv4的地址转换为ipv6, 到了路由层再转回去继续利用ipv4网络传输

测试网络环境搭建

转载请注明:http://www.cppblog.com/sunicdavy战魂小筑

网上有很多翻译了苹果官方的搭建ipv6测试网络环境的文章, 例如:
http://www.cocoachina.com/ios/20160525/16431.html
注意以下几点

• 无需路由器支持ipv6, 但猫(modem)必须要支持ipv6. 因为现在大多数都是光猫
  以下截图是光猫管理端
  
  光猫里的ipv6支持默认是关闭的, 所以需要手动打开, 按默认值配置即可

• 请确认mac os系统必须是osx 10.11以后的版本才可以打开NAT64

• 正确连接mac的ios设备应是如下截图示意
  

• 默认连接上wifi时看连接信息时, 一般只会有红色DNS地址或者根本不显示
• 只有在第一次访问网络, 例如打开浏览器进入任意网站时, 才会显示上面的几条信息
• 如果只有DNS没有IP地址和子网掩码, 一般是光猫没有打开ipv6的DHCP, 没有分配IP
• 还有一种测试ipv6 DHCP是否正常工作的方法: 关闭NAT64时可以上网, 但打开NAT64无法上网

转载请注明:http://www.cppblog.com/sunicdavy战魂小筑

Unity3D的Socket适配

WWW类本身已经支持了IPV6, 无需处理, 这里讲解使用C#原生Socket的处理

• 测试用的设备的iOS版本必须是9.3以上的
• Socket构造时, AddressFamily 设置为InterNetworkV6时只支持ipv6网络, 传入InterNetwork时只支持ipv4网络

• 4.7.2和5.4.3的当前版本在mono层并未支持ipv6代码适配的核心函数getaddrinfo, 因此需要通过oc层做转换, 以下是代码
  这段代码将getaddrinfo的地址转换成一个完整字符串, 格式是:
  ipv4|ipv4地址|ipv6|ipv6地址|

P.S. copyStr这种用法参考了http://www.codeinsect.net/blog/2016/05/26/unity-ipv6-socket-%E6%94%AF%E6%8C%81%EF%BC%8C%E5%B7%B2%E6%B5%8B%E8%AF%95%E9%80%9A%E8%BF%87/
会造成内存泄露, 如果有更好的方法欢迎反馈

转载请注明:http://www.cppblog.com/sunicdavy战魂小筑

iosaddrinfo.mm

   1:  #include <sys/socket.h>
   2:  #include <netdb.h>
   3:  #include <arpa/inet.h>
   4:  #include <err.h>
   5:  #define OUTSTR_SIZE 4096
   6:  extern "C"
   7:  {
   8:      const char* copyStr( const char* str )
   9:      {
  10:          char* s = (char*)malloc(strlen(str) + 1);
  11:          strcpy(s, str);
  12:          return s;
  13:      }
  14:      const char* IOSGetAddressInfo(const char *host )
  15:      {
  16:          if( NULL == host )
  17:              return copyStr("ERROR_HOSTNULL");
  18:          char outstr[OUTSTR_SIZE];
  19:          struct addrinfo hints, *res, *res0;
  20:          memset(&hints, 0, sizeof(hints));
  21:          hints.ai_family = PF_UNSPEC;
  22:          hints.ai_socktype = SOCK_STREAM;
  23:          hints.ai_flags = AI_DEFAULT;
  24:          printf("getaddrinfo: %s\n", host);
  25:          int error = getaddrinfo(host, "http", &hints, &res0);
  26:          if (error != 0 )
  27:          {
  28:              printf("getaddrinfo: %s\n", gai_strerror(error));
  29:              return copyStr("ERROR_GETADDR");
  30:          }
  31:          memset( outstr, 0, sizeof(char)*OUTSTR_SIZE );
  32:          struct sockaddr_in6* addr6;
  33:          struct sockaddr_in* addr;
  34:          const char* solvedaddr;
  35:          char ipbuf[32];
  36:          for (res = res0; res; res = res->ai_next)
  37:          {
  38:              if (res->ai_family == AF_INET6)
  39:              {
  40:                  addr6 =( struct sockaddr_in6*)res->ai_addr;
  41:                  solvedaddr = inet_ntop(AF_INET6, &addr6->sin6_addr, ipbuf, sizeof(ipbuf));
  42:                  strcat ( outstr, "ipv6|");
  43:                  strcat ( outstr, solvedaddr);
  44:              }
  45:              else
  46:              {
  47:                  addr =( struct sockaddr_in*)res->ai_addr;
  48:                  solvedaddr = inet_ntop(AF_INET, &addr->sin_addr, ipbuf, sizeof(ipbuf));
  49:                  strcat ( outstr, "ipv4|");
  50:                  strcat ( outstr, solvedaddr);
  51:              }
  52:              strcat ( outstr, "|");
  53:          }
  54:          return copyStr(outstr);
  55:      }
  56:  }
转载请注明:http://www.cppblog.com/sunicdavy战魂小筑

iosaddrinfo.h

   1:  #pragma once
   2:  extern "C"{
   3:      const char* IOSGetAddressInfo(const char *host );
   4:  }

• C#层的处理假设多个地址中都是统一的地址类型,要么全是v4要么全是v6
  返回给定的host内多个IP地址, 可以供处理复杂的北网通,南电信问题

   1:  using System;
   2:  using System.Net;
   3:  using System.Net.Sockets;
   4:  using System.Runtime.InteropServices;
   5:  using UnityEngine;
   6:  using System.Collections;
   7:  using System.Collections.Generic;
   8:  public class IOSIPV6
   9:  {
  10:      [DllImport("__Internal")]
  11:      private static extern string IOSGetAddressInfo(string host );  
  12:      public static IPAddress[] ResolveIOSAddress(string host, out AddressFamily af)
  13:      {
  14:          af = AddressFamily.InterNetwork;
  15:          var outstr = IOSGetAddressInfo(host);
  16:          Debug.Log("IOSGetAddressInfo: " + outstr);
  17:          if (outstr.StartsWith ("ERROR")) 
  18:          {
  19:              return null;
  20:          }
  21:          var addressliststr = outstr.Split('|');
  22:          var addrlist = new List<IPAddress>();
  23:          foreach (string s in addressliststr)
  24:          {
  25:              if (String.IsNullOrEmpty(s.Trim()))
  26:                  continue;
  27:              switch( s )
  28:              {
  29:                  case "ipv6":
  30:                      {                        
  31:                          af = AddressFamily.InterNetworkV6;
  32:                      }
  33:                      break;
  34:                  case "ipv4":
  35:                      {
  36:                          af = AddressFamily.InterNetwork;
  37:                      }
  38:                      break;
  39:                  default:
  40:                      {
  41:                          addrlist.Add(IPAddress.Parse(s));
  42:                      }
  43:                      break;
  44:              }
  45:          }
  46:          return addrlist.ToArray();
  47:      }
  48:  }
转载请注明:http://www.cppblog.com/sunicdavy战魂小筑

参考链接

官方文档
https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW1

某人的解决方案
http://www.codeinsect.net/blog/2016/05/26/unity-ipv6-socket-%E6%94%AF%E6%8C%81%EF%BC%8C%E5%B7%B2%E6%B5%8B%E8%AF%95%E9%80%9A%E8%BF%87/
注意, 此方案中的方法可用, 但是地址并不能解决南北互通的问题

1. 技能部分的特效可以遍历动作表播放的所有特效id, 提前预载

2. buff类特效是动态确定的,无法分析. 需要通过角色表添加资源id在加载角色时加载特效

这种做法的缺点:

当角色特效效果调整时, 美术和策划需要调整特效id表. 多出来不用的特效也加载是感觉不出来的, 分析也是很困难的

所以这种以传统的电子表格配置为中心的方式在Unity3D里, 内存, 包优化会是个大问题.

那么, 什么是Unity3D的开发核心思想?

除了组件思想外, 就是Prefab, 贯彻整个编辑器及引擎自始至终

处理角色携带特效加载后播放的这个case, 用Prefab为中心的资源管理来做的话, 大概就是这样:

1. 程序编写一个角色特效列表脚本, 把List暴露出来可以在编辑器里使用

2. 美术在做技能时, 把要用到的特效拖拽到List中

3. 特效无需再编制全局ID编码

4. 策划根据这个角色挂接的特效索引, 在配置表里添加播放指令

这样做的优点:

角色引用到的资源才会被打到最终游戏包内, 不使用的资源是不会被加载的

类似的, 在UI特效里, 也应该是将要播放的特效挂接到对象中, 而不是动态通过代码去加载

在Unity3D中, Prefab将图片,Shader, 特效, 脚本等一切平等看待, 只要有引用, 一次性加载.

同时, 也可以通过静态工具分析Prefab.

如果是通过代码加载的效果, 则只能让程序员做优化, 这种过程无法让Unity3D官方后期提供的工具进行优化

所以, 推荐使用Prefab为中心的资源管理模式

下面介绍下proto3的一些细节变化

Proto3的语法变化

语法标记

这个版本的protoc的protobuf编译器已经可以支持proto2语法和proto3的语法

如果你的proto文件没有添加syntax说明的话, 用这个版本的编译器会报错, 提示你默认proto2支持, 请添加语法标记

syntax = "proto2";

optional不需要了

只保留repeated标记数组类型, optional和required都被去掉了

实际使用证明, required的设计确实是蛋疼, C++的调试版会弹出assert,release版和optional也没啥区别

map支持

map编写格式为

map<key_type, value_type> map_field = N;

例如:

map<string, Project> projects = 3;

代码生成确认支持map, 这对于很多语言来说又可以偷懒了

字段default标记不能使用了

位于proto2语法的字段number后的[default=XX]

这个东西不能用了, 理由是:

对于同一段序列化后的数据, 如果序列化端的default和反序列化端的default描述不一样会导致最终结果完全不一致

即: 同一个数据两个结果, 这是不可预测的结果, 因此干掉这个特性

不过本人觉得, 对于游戏来说, 这个功能本身可以压缩很多数据,虽然会有隐患

枚举默认值一定是0

proto2里的默认值是枚举的第一个value对应的值, 不一定为0

proto3在你定义value时, 强制要求第一个值必须为0

这个修改为避免隐患还是有帮助的

泛型描述支持

any类型, 可以代表任何类型, 可以先读进来, 再进行解析, 没具体用, 步子跨大了怕扯到蛋

支持json序列化

这个极好, json再次被同化了

增加了多种语言支持

js, objc, ruby, C#等等

然而, C#版本的基础runtime库是用C# 6.0的语法写的,这对于Unity mono祖传2.0来说, 确实扯到蛋了,没法用

Protobuf现在使用CMAKE做配置系统

编译起来稍微麻烦, 还要下个被墙掉的cmake…

第三方库里对于proto3的变化

Golang的官方protobuf支持: https://github.com/golang/protobuf

生成代码中的结构体字段类型变化

对于proto2的文件, 生成的go代码中的结构体依然使用类型指针作为默认存储, 兼容老的系统

对于proto3的文件, 生成的go代码中的结构体直接使用字段作为默认存储, 不再使用GetXXX来作为字段值访问, 赋值时也无需使用proto.类型() 函数进行指针类型字段值创建.

这个调整很是方便, 但丢失了optional判断功能, 对应C++里就是hasXXX的功能, 不过好歹这个逻辑现在用的不多了

这个修改大概也是配合json序列化来做的, go默认的json序列化时, 无法使用proto2生成的结构体的, 因为都是指针,无法赋值..

新版protoc-gen-go的插件会生成descriptor的压缩数据

新插件会给每次生成的文件添加这样一段代码

var fileDescriptor0 = []byte{
    // 220 bytes of a gzipped FileDescriptorProto
    0x1f, 0x8b, 0x08, 0x00, 0x00, 0x09, 0x6e, 0x88, 0x02, 0xff, 0x64, 0x8f, 0xcd, 0x4e, 0xc5, 0x20,
    0x10, 0x85, 0x53, 0xbd, 0x35, 0x32, 0xb7, 0xdd, 0x4c, 0x5c, 0xb0, 0x70, 0x71, 0xd3, 0xb8, 0x70,
    0x75, 0x17, 0xfa, 0x04, 0xc6, 0xd8, 0xb8, 0x50, 0x63, 0xa8, 0x2f, 0x80, 0xed, 0x44, 0x89, 0x28,
    0x04, 0xc6, 0xbf, 0x47, 0xf1, 0x6d, 0x95, 0x49, 0x8d, 0x4d, 0x5c, 0x01, 0xdf, 0x39, 0x7c, 0x30,
    0x00, 0x1c, 0x82, 0xdf, 0xc6, 0x14, 0x38, 0xe0, 0xaa, 0xec, 0xbb, 0x37, 0x68, 0x2e, 0x3e, 0x62,
    0x48, 0x7c, 0x49, 0x76, 0xa2, 0x84, 0x47, 0xd0, 0xde, 0x96, 0xf8, 0xee, 0x33, 0xd2, 0x8d, 0x7d,
    0x26, 0x5d, 0x6d, 0xaa, 0x63, 0x65, 0xda, 0xb8, 0x84, 0xd8, 0x41, 0x63, 0xc2, 0x7b, 0xef, 0xc8,
    0x4f, 0x52, 0xda, 0x91, 0x52, 0x93, 0x16, 0x0c, 0x0f, 0x41, 0x89, 0xa9, 0x77, 0x9e, 0xf4, 0xae,
    0x14, 0x54, 0xfc, 0x05, 0xdd, 0x57, 0x05, 0x4a, 0xba, 0xd7, 0xc4, 0x16, 0xb7, 0x80, 0x03, 0x27,
    0xf7, 0xf2, 0x70, 0x72, 0xe5, 0x32, 0x0f, 0xd1, 0x3b, 0xa6, 0x34, 0x5b, 0x31, 0xff, 0x4b, 0x70,
    0x03, 0x6b, 0x43, 0x91, 0x2c, 0x9f, 0x3f, 0xd2, 0xf8, 0x24, 0xf6, 0x7d, 0xb3, 0x4e, 0x7f, 0x08,
    0x0f, 0xa0, 0x3e, 0xf3, 0xce, 0x66, 0xbd, 0x12, 0x49, 0x6d, 0xcb, 0xa1, 0x4c, 0x37, 0xbf, 0xf3,
    0xb3, 0xbc, 0x8e, 0xac, 0x6b, 0xb9, 0xd9, 0xe6, 0x25, 0xbc, 0xdf, 0x93, 0x6f, 0x9e, 0x7e, 0x07,
    0x00, 0x00, 0xff, 0xff, 0x0c, 0x9f, 0x10, 0xa8, 0x2e, 0x01, 0x00, 0x00,
}

对于meta信息的提取还是很方便的

然而

对于多个文件的生成, 这样做非常的麻烦, 因为这个字段会重复导致编译错误

很多人在论坛里吐槽, 官方给出的解决方法是, 使用protoc一次性传入一个package下的所有的proto直接生成一个go

而不是现在的一个proto一个go

生成代码会自动注册到全局, 并可以方便的查询

以前这个代码需要自己来做, 现在官方提供了支持, 很是方便

然而, 为什么不支持遍历… 残念啊, 又要自己动手了

首先我们来看下

RSA的几个标准用法

非对称加密解密

假设A要把内容传输给B

1. B生成RSA的公钥和密钥, 这是成对出现的, 密钥由B保存, 把公钥告诉A

2. A用B的公钥加密内容, 并把密文内容传输给B

3. B用密钥解密

验证

证明某个内容是你发的, 而不是被别人冒名顶替, 例如git的push中就带有这个功能

假设A有内容,  B要验证内容确实由A发出

1. A生成公钥和密钥

2. A将内容做一个hash, 把hash码用自己的密钥加密并把这段密文发给B

3. B用A的公钥对密文进行验证, 即可确认密文是否由A发出

可以看出, 两种用法都是典型的非对称用法

但PP助手却干了件神奇的事情:

非对称当对称算法加解密

在PP SDK官方文档里, 我们找到了PHP语言的验证方法, 方法里使用了这样一个API

openssl_public_decrypt

从官方文档看得出这个使用openssl的算法库

类似的, 还有Java, C++, Python语言的处理方法

其中, C++也是用的openssl, Python则是需要预编译C库，在Ubuntu下需要手工patch M2Crypto的_ssl.c文件.

先不说这些非正规的编译,patch方法会造成多大的问题, 单就这个用公钥解密就很蛋疼

从之前的RSA算法中了解, 只有对公钥进行验证的方法, 也就是只能得到是还是不是的结果. 但PP的SDK则要求必须用公钥解密…

解出的数据为一段json, 以对比是否有订单篡改.

那么这种做法就等效于, 用最简单的异或+一个公钥进行订单加密, 然后同样用这个公钥进行解密

只不过用RSA感觉很高级…

这种做法一旦公钥在PP助手服务器或者玩家的开发服务器, 甚至源代码泄露, 那么马上就有很大的伪造订单的危险

我把这个做法发给朋友看, 他们说, 其实PP助手的开发者只管用了RSA, 跟传输不是明文就好了, 至于什么信息安全, 都是屁!

问题

每次Unity3D编辑器打开时, 连接服务器都会有一定几率失败, 需要反复关闭再打开编辑器3~4次后, 才能正常接收到封包

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

探索

我们的网络库基于C#的Begin/End系的异步Socket, 这种socket更接近C++的asio模型, 撸起来特爽.

1. 根据经验, 这个诡异问题多半跟多线程有关系. 复查代码, 无效.

2. 找友人更换网络库, 换阻塞Socket实现和SocketAsyncEventArgs这种实现都试过, 仍然无法解决问题.

3. 接下来还是对Begin/End系的网络库进行日志追踪. 发现, 发送会总是成功, 连接成功和接收封包有一定几率会断掉

我们并没有单独开线程来处理, 而是利用底层异步通知, 然后有线程安全队列切换到主线程进行投递. 因此底层的线程正常性是整个问题的焦点

由于一直无法找到原因, 这个问题搁置了

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

解决方案

直到有一个偶然的机会, 取过同事代码后. 突然发现第一次打开Unity3D编辑器可以直接登录. 但之后又不行. 同事提醒, 会不会是优先度问题.

马上打开Edit->Project Settings->Script Execution Orders. 提高了网络组建优先度

测试, 通过, 问题解决

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

总结

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

一直怀疑这个问题跟Mono版本过老有关系, 但由于5.2版本到年底才更新, 之前只能自己啃bug.

在这个问题发生后解决前, 我们还有一个相关见闻: 我们将网络部分比较稳定的代码拆分放到dll中, 通过Unity3D的机制进行加载

结果, 网络无法初始化. 估计也是跟这个问题有关系

总之, 有类似问题时, 可以试用脚本执行顺序大法进行尝试

我们的项目一直使用MySQL作为数据库. 无论是从C++的服务器, 还是到Golang服务器. 当年搞服务器时, 看大部分人都是用SQL(MySQL/SQLServer), 而Mongo感觉像邪教一样, 再加上服务器还是Linux比较正统, 所以果断选了MySQL.

刚开始感觉,游戏服务器的数据存储其实应该是蛮神圣的过程. 那么多的数据, 需要按照MySQL一样分表, 分字段存储, 为了查询, 还要乖乖的学一下SQL的语法

就这么折腾了几年. 在云DB的蒙蔽下, 一直认为MySQL就是做游戏服务器存储的专业技术. 分布式和存储压力一定交给云DB来做. 直到真正试了下NoSQL在游戏服务器开发里的思路.

用了Golang, 才发现同步写逻辑是多么的优雅.

用了NoSQL系列的数据库, 才意识到: 游戏服务器的数据存储和游戏服务器的存盘两个概念差异其实蛮大的.

MySQL中, 背包其实跟角色完全没有关系, 只是通过1个角色id映射过去, 人为的割裂了数据的关联性. 还硬生生的整出个概念叫结构化查询让你学

NoSQL中, 只是把数据库当成是存储点, 每个角色的数据是完整的一块. 里面怎么存随你便. 每个角色通过id来查询, 其他都没有了

于是乎, 游戏开发变得异常简单. MySQL角色进门查询4~5次才能搞定要的数据.而NoSQL一口气全查出来, 存盘也无需增量, 直接存盘就可以了

所以现在觉得, NoSQL的思路对于游戏服务器存储来说简直是完美的!

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

NoSQL数据库方案对比

NoSQL下实现方案很多, 游戏常用的就这么3家: mongo, redis, memcached

下面说下优缺点

mongo

磁盘映射内存数据库

value为document类型, 基于BSON的value序列化

应用场景:

适合多写少读, 例如日志和备份

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

redis

内存数据库

单核

value限制512M

多种value类型, 游戏用途使用私有的序列化协议(例如protobuf)

支持落地(bgsave)

用户: 新浪, 淘宝, Flickr, Github

应用场景: 适合读写都很高, 数据处理复杂等

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

memcached

内存数据库

多核

value限制1M

不支持落地(持久化)

用户: LiveJournal、hatena、Facebook、Vox

应用场景: 动态系统中的缓冲, 适合多读少写

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

个人评价

memcached 适合网页缓冲, 游戏里很少有使用. 目前只有腾讯云支持云memcached

redis非常适合游戏的内存数据库, 但是落地策略会比较复杂, 需要具体分析, 可以参考后面的链接看下云风怎么处理这个问题

mongo数据库在早期还是非常不错的NoSQL的数据库. 工具比较方便, 可视化. 但是随着近年来游戏的并发度越来越高, 所以为了一次到位, 很多人还是选择了redis

下图参考自知乎问题. 链接在后面有提示, 若侵权请联系删除

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

参考链接:

    谈谈陌陌争霸在数据库方面踩过的坑( Redis 篇)

http://blog.codingnow.com/2014/03/mmzb_redis.html

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

Memcache,Redis,MongoDB（数据缓存系统）方案对比与分析

http://blog.csdn.net/suifeng3051/article/details/23739295

http://www.zhihu.com/question/31417262

基于C/C++游戏服务器框架总体设计的还是不错的, 兄弟们总体使用效果都是好评. 因为在技术上喜欢"偷懒", 所以在很多设计上, 都是力求简单, 高效(开发效率).

基于任务的异步DB查询系统, 带多重异步的同步

代码示例:

   1:   

   2:  void BatchQueryPlayerInfo( uint32 ClientID, const std::string& AccountName, int64 CharID )

   3:  {

   4:      GDBExecutor->Commit

   5:          (    

   6:          dynamic_cast<DBDataTask*>( (new DBQueryCharInfo(  ClientID, CharID ) ) 

   7:          ->LinkAtomTask( new DBQueryQuest( ClientID, CharID ) )

   8:          ->LinkAtomTask( new DBQuerySkill( ClientID, CharID ) )

   9:          ->LinkAtomTask( new DBQueryHero( ClientID, CharID ) )

  10:          ->LinkAtomTask( new DBQueryAccountInfo( ClientID, AccountName ) )

  11:          ->LinkAtomTask( new DBQueryEquip( ClientID, CharID ) )

  12:          ->LinkAtomTask( new DBQueryObject( ClientID ,CharID ) )

  13:          ->LinkAtomTask( new DBQueryLevel(ClientID, CharID))

  14:          ->LinkAtomTask( new DBQueryChapter(ClientID, CharID))

  15:          ->LinkAtomTask( new DBQueryActivity( ClientID, CharID ))

  16:          )

  17:          );

  18:   

  19:  }

这段主要处理玩家在登陆时, 需要从DB查询大量的不同分类的数据. 为了保证效率, 我让每个Task并行执行, 然后通过一个机制, 让所有任务完成后, 回调第一个任务的一个函数. 这样就无需手动实现很多粘合代码, 避免了反复调试和错误

基于protobuf反射机制的语句自动合成

   1:  DBUpdateCharInfo::DBUpdateCharInfo( int64 CharID, const std::string& Buffer )

   2:  {

   3:      char buffer[256];

   4:   

   5:      sprintf( buffer, "update tb_char set $FIELD$ where charid = %lld;", CharID );

   6:          

   7:      ExecuteCommand( buffer, Buffer, dbopr::FET_Equation );

   8:  }

这段就是一个典型的DB任务, 构造函数提供了CharID和一个由结构体序列化好的buffer, $FIELD$字段, 是通过反射根据Buffer内容, 自动填充字段

这段例子中, $FIELD$可以填充为 hp=100, mp=100之类的. 自动填充避免了因为添加字段的到处添加代码, 还需要调试, 容易搞错

配置系统概念

基于同一个配置系统, 分层实现不同的需求. 更简单的说, 解决的1个实际问题是:

自己改了配置文件中的ip, 上传svn后, 覆盖了别人的配置, 很多人的解决方法都是, 本地配置不提交. 但同时问题又来了:

当配置中有别人新加的系统配置, 怎么保证每个人都能更新到?

上线后, 服务器交付运维, 他们会对配置有一定程度的修改, 这个时候怎么合并程序配置和运维配置?

其实对于冲突的需求, 只要对系统进行分层就可以解决问题,我的处理方式:

配置分为:

全局配置: 所有服务的总体配置

单服务配置: 本服务的配置, 涉及网络及逻辑

本地配置: 这个配置每个人一份, 不上传SVN

命令行配置: 格式和前面的一致, 这块就可以通过运维进行配置

总体结构其实就是OO的派生概念, 下层可以覆盖, 修改上层的配置

服务器互联及识别框架

基本功能: 基于一些简单的配置就可以将多台服务器, 同种类的不同服务器互相连接起来, 断线自动重连.

服务器连接后, 所有服务器可知晓并可自动按需连接

逻辑端也很方便的进行广播或者单独发送等

也就是说, 每个服务器的连接和接受端都是带识别名称或id的.

后面觉得这套东西实在是做的复杂, 多整出一台中心服务器来做. 但好歹框架稳定下来了, 也就好了.

基于lua的服务器web后台框架

思想是很不错的,  C++ 配合lua本身绝对是个失败

问题出在web处理,本身都是一个同步阻塞过程, 而这个后台框架是异步方式来做, 所以特别别扭

不过比起以前的本地GM系统, 这块的设计是伟大的进步

现在正在设计基于golang的服务器框架, 基本框架已经完工, 等待编写逻辑后的实战测试

以上的很多思想在golang的服务器框架都有改进, 特别是golang本身做web也是优秀的, 外加martini这种牛X框架, 更是水到渠成

如果你对服务器框架设计有特别的认识, 或者想碰撞思想, 可以加博客群 309800774或者我的qq: 20998333讨论

TexturePacker的自定义插件目录位于其安装目录的bin\exporters\下, 但有一些插件属于内建支持, 例如cocos2dx的plist格式, 因此无法找到对应插件

本人参考shiva3d插件, 对应导出界面的DataFormat中的Shiva3D, 快速学会了如何导出

官方文档位于http://www.codeandweb.com/texturepacker/documentation/#customization

插件的基本格式及原理是:

bin\exporters\下的某一目录下存在的一个名为exporter.xml文件作为插件的描述,例如:

<exporter version="1.0">

    <!-- identifier of the exporter -->

    <name>shiva3d</name>

    <!-- display name of the exporter for the combo box -->

    <displayName>Shiva3D</displayName>

    <!-- description of the exporter -->

    <description>Exporter for Shiva3D.</description>

    <!-- exporter version -->

    <version>1.0</version>

    <!-- currently only one file allowed - more to come with update -->

    <files>

        <file>

            <!-- name of this file variable -->

            <name>xml</name>

            <!-- human readable name (for GUI) -->

            <displayName>XML</displayName>

            <!-- file extension for the file -->

            <fileExtension>xml</fileExtension>

            <!-- name of the template file -->

            <template>shiva.xml</template>

        </file>

    </files>

    <!-- target framework supports trimming -->

    <supportsTrimming>false</supportsTrimming>

    <!-- target framework supports rotated sprites -->

    <supportsRotation>true</supportsRotation>

    <!-- rotated sprites direction (cw/ccw) -->

    <rotationDirection>cw</rotationDirection>

    <!-- supports npot sizes -->

    <supportsNPOT>true</supportsNPOT>

    <!-- supports file name stripping (remove .png etc) -->

    <supportsTrimSpriteNames>yes</supportsTrimSpriteNames>

    <!-- supports texure subpath -->

    <supportsTextureSubPath>yes</supportsTextureSubPath>

</exporter>

在Template字段中, 描述同目录的导出文件格式模板. TexturePacker使用一种叫Grantlee的模板引擎,类似于Python使用的Django模板引擎, 文档参见:Grantlee Documentation. 简单的文本格式可以参考shiva.xml快速学会

这里我们使用protobuf的文本格式(极为类似json)导出plist, 下面是导出模板

{% for sprite in allSprites %}

Sprite {

    Name: "{{sprite.trimmedName}}"

    FrameX: {{sprite.frameRect.x}}

    FrameY: {{sprite.frameRect.y}}

    FrameWidth: {{sprite.frameRectWithoutRotation.width}}

    FrameHeight: {{sprite.frameRectWithoutRotation.height}}

    OffsetX: {{sprite.cornerOffset.x}}

    OffsetY: {{sprite.cornerOffset.y}}

    OriginalWidth: {{sprite.untrimmedSize.width}}

    OriginalHeight: {{sprite.untrimmedSize.height}}

    {% if sprite.rotated %}Rotated: true {% endif %}

}

{% endfor %}

导出的结果类似于:

Sprite {

    Name: "car01"

    FrameX: 100

    FrameY: 129

    FrameWidth: 76

    FrameHeight: 47

    OffsetX: 0

    OffsetY: 0

    OriginalWidth: 76

    OriginalHeight: 47

    Rotated: true 

}

Sprite {

    Name: "car02"

    FrameX: 100

    FrameY: 51

    FrameWidth: 76

    FrameHeight: 47

    OffsetX: 0

    OffsetY: 0

    OriginalWidth: 76

    OriginalHeight: 47

    Rotated: true 

}

...

导出插件还支持js扩展, 具体内容请继续参考官方文档, 但对于简单的文本格式, 这种方式已经足够了

对比plist后, 发现plist中的垃圾信息极为多, 而且作为spriteframe的name居然带有扩展名...  因此脱离plist,编写自己的导出插件才是王道!

我们的项目的客户端和服务器均由C++开发，由于HG设计的理念是1个工程对应1个库， 因此我们的客户端和服务器是分开的两个HG代码库。这种思想和SVN管理的代码有很大不同。SVN时代的游戏工程大多是这样安排目录的：

common <-客户端和服务器共享的库

client<-客户端的代码

server<-服务器的代码

通过SVN强大的权限控制给不同的前后端赋予权限，前后端程序将获得不同的目录组合。SVN下的这种工程组织方法能很好的解决单一语言跨工程的代码，协议共享问题。虽然现在各种Erlang，Java的服务器语言与as3,lua的不同客户端脚本语言混杂的时代已经无所谓这种老式设计思想。但是对于我们纯C++的手游来说，还是必须面对分布式代码管理工具下的代码跨库共享问题。

我就这个问题与多年前被我推荐过HG的朋友讨论起来，他们也存在我们这个问题，但是他们的解决方法就是每个工程一个库。然后被我问到：“同步一次代码，一次次的打开不同的库（他们客户端+服务器一共6到7个HG代码库），进行同步， 完成后， 还要反向pull，不累啊？”， 朋友回答：“习惯就好”

随后，我也翻查了git对多项目的支持。得到的答案也是跟HG一样的， 这类分布式代码管理工具本身的设计理念只有账号，而无权限， 本身就是基于开源代码精神设计的工具， 如果分了权限，岂不是违背开源精神（这是我想的）。因此如果想管理多个项目代码， 要么多库，要么合库。

文本格式的解析错误不能使用捕获错误来获取, 因此,我们需要使用自定义的错误收集器进行收集, 看代码:

#include <google/protobuf/text_format.h>

#include <google/protobuf/io/zero_copy_stream_impl_lite.h>

#include <google/protobuf/io/tokenizer.h>

class PBTextErrorCollector : public google::protobuf::io::ErrorCollector

{

public:

    PBTextErrorCollector( const std::string& FileName )

        : mFileName( FileName )

    {

    }

    virtual void AddError(int line, int column, const string& message)

    {

        CCLog("%s(%d:%d) %s ", mFileName.c_str(), line, column, message.c_str() );

    }

    virtual void AddWarning(int line, int column, const string& message) 

    {

        CCLog("%s(%d:%d) %s ", mFileName.c_str(), line, column, message.c_str() );

    }

private:

    std::string mFileName;

};

解析代码

google::protobuf::TextFormat::Parser P;        

    P.RecordErrorsTo( &PEC );

    P.Parse( &AIS, &AF );

另外: 文本格式的注释使用unix shell风格: 以#开头

下面是我的文本格式的配置文件

AnchorPointX: 0.5
AnchorPointY: 0

SpriteScale: 2

ComponentName: "ActorActionManager"
ComponentName: "ActorFrameEventDispatcher"
#ComponentName: "SoundFXController"
ComponentName: "RoleDeltaMoveController"
ComponentName: "RoleBehaviorDirector"

InitAction: AA_Idle

Animations 
{
  AnimationName: "mai_idle"
  AnimationInterval: 0.067
}

态度篇
1. 做实事
不要抱怨，发牢骚，指责他人，找出问题所在，想办法解决。对问题和错误，要勇于承担。
2. 欲速则不达
用小聪明、权宜之计解决问题，求快而不顾代码质量，会给项目留下要命的死角。
3. 对事不对人
就事论事，明智、真诚、虚心地讨论问题，提出创新方案。
4. 排除万难，奋勇前进
勇气往往是克服困难的唯一方法。
学习篇
5. 跟踪变化
新技术层出不穷并不可怕。坚持学习新技术，读书，读技术杂志，参加技术活动，与人交流。要多理解新词背后的所以然，把握技术大趋势，将新技术用于产品开发要谨慎。
6. 对团队投资
打造学习型团队，不断提高兄弟们的平均水平。
7. 懂得丢弃
老的套路和技术，该丢，就得丢。不要固步自封。
8. 打破砂锅问到底
不断追问，真正搞懂问题的本质。为什么？应该成为你的口头禅。
9. 把握开发节奏
控制好时间，养成好习惯，不要加班。

开发流程篇
10. 让客户做决定
让用户在现场，倾听他们的声音，对业务最重要的决策应该让他们说了算。
11. 让设计指导而不是操纵开发
设计是前进的地图，它指引的是方向，而不是目的本身。设计的详略程度应该适当。
12. 合理地使用技术
根据需要而不是其他因素选择技术。对各种技术方案进行严格地追问，真诚面对各种问题。
13. 让应用随时都可以发布
通过善用持续集成和版本管理，你应该随时都能够编译、运行甚至部署应用。
14. 提早集成，频繁集成
集成有风险，要尽早尽量多地集成。
15. 提早实现自动化部署
16. 使用演示获得频繁反馈
17. 使用短迭代，增量发布
18. 固定价格就意味着背叛承诺
估算应该基于实际的工作不断变化。
用户篇
19. 守护天使
自动化单元测试是你的守护天使。
20. 先用它再实现它
测试驱动开发其实是一种设计工具。
21. 不同环境，就有不同问题
要重视多平台问题。
22. 自动验收测试
23. 度量真实的进度
在工作量估算上，不要自欺欺人。
24. 倾听用户的声音
每一声抱怨都隐藏着宝贵的真理。

编程篇
25. 代码要清晰地表达意图

代码是给人读的，不要耍小聪明。
26. 用代码沟通
注释的艺术。
27. 动态地进行取舍

记住，没有最佳解决方案。各种目标不可能面面俱到，关注对用户重要的需求。
28. 增量式编程
写一点代码就构建、测试、重构、休息。让代码干净利落。
29. 尽量简单
宁简勿繁。如果没有充足的理由，就不要使用什么模式、原则和特别的技术。
30. 编写内聚的代码
类和组件应该足够小，任务单一。
31. 告知，不要询问
多用消息传递，少用函数调用。
32. 根据契约进行替换
委托往往优于继承。

调试篇
33. 记录问题解决日志
不要在同一地方摔倒两次。错误是最宝贵的财富。
34. 警告就是错误
忽视编译器的警告可能铸成大错。
35. 对问题各个击破
分而治之是计算机科学中最重要的思想之一。但是，要从设计和原型阶段就考虑各部分应该能够很好地分离。
36. 报告所有的异常
37. 提供有用的错误信息
稍微多花一点心思，出错的时候，将给你带来极大便利。

团队协作篇
38. 定期安排会面时间
常开会，开短会。
39. 架构师必须写代码

不写代码的架构师不是好架构师。好的设计都来自实际编程。编程可以带来深入的理解。
40. 实行代码集体所有制
让开发人员在系统不同区域中不同的模块和任务之间轮岗。
41. 成为指导者
教学相长。分享能提高团队的总体能力。
42. 让大家自己想办法

指引方向，而不是直接提供解决方案。让每个人都有机会在干中学习。
43. 准备好后再共享代码
不要提交无法编译或者没有通过单元测试的代码！
44. 做代码复查
复查对提高代码质量、减少错误极为重要。
45. 及时通报进展与问题

主动通报，不要让别人来问你。

转载自: 逍遥自在的CSDN博客 http://blog.csdn.net/xoyojank/archive/2011/04/10/6313422.aspx

测试对象：RTTI的dynamic_cast和自己实现的RTTI系统，代码如下

        template<typename TClass>

        TClass* Cast( )

        {

            return IsKindOf( TClass::StaticGetClassInfo() ) ? (TClass*)this:null;

        }

    bool RTTIObject::IsKindOf( RTTIClass* ClassInfo )

    {

        RTTIClass* ThisClass = GetRTTIClass();

        if ( ThisClass == null )

            return false;

        return ThisClass->IsKindOf( ClassInfo );

    }

    bool RTTIClass::IsKindOf( RTTIClass* ClassInfo )

    {

        RTTIClass* ThisClass = this;

        while ( ThisClass != null )

        {

            if ( ClassInfo == ThisClass )

                return true;

            ThisClass = ThisClass->mParentClass;

        }

        return false;

    }

测试代码：

class ClassA : public RTTIObject

{

public:

DECLARE_RTTI_CLASS( ClassA )

int a;

private:

};

IMPLEMENT_RTTIROOT( ClassA )

class ClassB: public ClassA

{

    DECLARE_RTTI_CLASS( ClassB )

public:

int b;

private:

};

IMPLEMENT_RTTI_CLASS( ClassB, ClassA )

class ClassC : public ClassB

{

    DECLARE_RTTI_CLASS( ClassC )

public:

int c;

private:

};

IMPLEMENT_RTTI_CLASS( ClassC, ClassB )

class ClassD: public ClassA

{

    DECLARE_RTTI_CLASS( ClassD )

public:

int d;

private:

};

    ClassC c;

    ClassD d;

    ClassA* fakeC = &c;

    ClassA* fakeD = &d;

    const int TestTimes = 10000;

    float t1 = TimeSource::GetAppTime();

    for ( int i = 0;i<TestTimes;i++)

    {

        ClassC* realC = dynamic_cast<ClassC*>(fakeC);

        ClassD* realD = dynamic_cast<ClassD*>(fakeD);

    }

    float t2 = TimeSource::GetAppTime() - t1;

    for ( int i = 0;i<TestTimes;i++)

    {

        ClassC* realC = fakeC->Cast<ClassC>( );

        ClassD* realD = fakeD->Cast<ClassD>( );

    }

    float t3 = TimeSource::GetAppTime() - t2;

    SimpleLog log;

    log.Debug(L"%f  %f", t2, t3);

可以看得出来，没有优化过的Cast代码性能极差，但是优化过的Cast性能超越了系统的dynamic_cast,跟踪汇编发现系统有做个一些异常及bad_cast的处理

建议：可以做一个宏，在不支持RTTI的编译器及平台下使用自己的Cast

这里参考了mybios博客中的文章,给CEGUI字符串做一个patch

然后需要找到vs2008的autoexp.dat文件

XP下位于:C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\autoexp.dat

用记事本等工具打开, 在AutoExpand段中像这样添加:

[AutoExpand]
; CEGUI String
CEGUI::String = str =<d_quickbuff,su> length =<d_cplength>

即可在VC调试器中看到CEGUI字符串内容, 不过中文还是暂时无法支持

首先,我们得弃用CPU蒙皮, 虽然兼容性好,但是面对现今多核但并不提高单核速率的情况下,GPU还是王道.而且GPU蒙皮代码可能更简单,不过也有一点小缺点, 对于小引擎来说,Shader必须给静态模型和骨骼动画模型写两套.

其次我们需要加强一个SubSkin的骨骼支持数量. 骨骼动画上的每个SubSkin都是一次Draw, 但是按照传统骨骼动画系统,每个骨头对应一个矩阵传入,那么SM2.0保守计算只能支持50根骨头. 不过在我前段时间的文章中有提到这个技术.并且已经在我的骨骼动画系统及OGRE中实现,效果很好.

美术也许很反感一个人物做1个SubSkin, 他们更新好多个SubSkin,也就是说身体每个部分都是一个SubSkin, 这样方便修改, 同时系统支持的骨骼数量还可以有一定量的上升.不过我们还需要做一个索引工作. 传统的GPU骨骼动画中总是在渲染SubSkin前传入所有这些SubSkin需要用到的骨骼矩阵. 但是每个SubSkin并不一定能用到所有的这些矩阵,这明显是一种浪费. 因此在OGRE中做过一次索引预处理,也就是将每个SubSkin用到的骨骼统计出来, 在渲染这次SubSkin时才重新传到GPU. 很明显,这是用速度还空间和兼容性. 如果在DX10以上,有ConstantBuffer还好. DX9实在太慢了

使用Marker点的换装系统很难处理例如贴身衣物这类物件换装. OGRE中有一种共享骨骼的技术, 可以支持, 不过从代码分析看来,这种技术对CPU端骨骼计算量实在是大的惊人. 因此我们决定将整个SubSkin(也就是SubEntity)换掉,这样由美术根据不同换装类型来将衣服在MAX中直接绑定好后直接替换原始模型中的SubSkin即可达到换装效果.可以说这是从动态计算到静态预处理的转变,效率提升很多.

各位可以下载看下

从直观个人分析该引擎技术包括:

1. 基于SlimDX的.NET引擎

2. JavaScript脚本

3. 场景剔除效率还不错

4. 手感非常棒, 不亚于WOW

他博客里还有几篇关于保留模式引擎的讨论. 个人觉得这大概是以后的趋势. 微软的WPF首先当了炮灰, 庆幸.

float4x4 matBoneArray[40]; //  这是传输的瓶颈

VS_OUTPUT vs_main( SkinnedVS_INPUT In )

{

    VS_OUTPUT Out = (VS_OUTPUT)0;

    float4x4 skinTransform = 0;

    skinTransform += matBoneArray[In.BoneIndices.x] * In.BoneWeights.x;

    skinTransform += matBoneArray[In.BoneIndices.y] * In.BoneWeights.y;

    skinTransform += matBoneArray[In.BoneIndices.z] * In.BoneWeights.z;

    skinTransform += matBoneArray[In.BoneIndices.w] * In.BoneWeights.w;

    float4 localpos = mul(In.Position, skinTransform);

    Out.Position = mul( localpos, matViewProj ); 

    Out.TexCoord = In.TexCoord;

    return Out;

}

matBoneArray这个数组是骨骼的LocalRot和LocalTranslation 通过以下函数build出来

    Matrix4& Matrix4::FromTranslationRotation( const Vector3& translation, const Quaternion& rotation )

    {

        float xx = rotation.x * rotation.x * 2.0f, yy = rotation.y * rotation.y * 2.0f, zz = rotation.z * rotation.z * 2.0f;

        float xy = rotation.x * rotation.y * 2.0f, zw = rotation.z * rotation.w * 2.0f, xz = rotation.x * rotation.z * 2.0f;

        float yw = rotation.y * rotation.w * 2.0f, yz = rotation.y * rotation.z * 2.0f, xw = rotation.x * rotation.w * 2.0f;

        m[0][0] = 1.0f - yy - zz; m[0][1] =        xy + zw; m[0][2] =        xz - yw; m[0][3] = 0.0f;

        m[1][0] =        xy - zw; m[1][1] = 1.0f - xx - zz; m[1][2] =        yz + xw; m[1][3] = 0.0f;

        m[2][0] =        xz + yw; m[2][1] =        yz - xw; m[2][2] = 1.0f - xx - yy; m[2][3] = 0.0f;

        m[3][0] =  translation.x; m[3][1] =  translation.y; m[3][2] =  translation.z; m[3][3] = 1.0f;

        return *this;

    }

从这里你可以发现, 本来每根骨头只需要2个float4 传递变换信息的,现在却需要4个float4,也就是一个矩阵来传递,矩阵中还有很多不使用的变量也被传输到GPU中,这里就是优化的点.

重新调整后的Shader代码:

float4x4 BuildFromTransRot( float4 translation, float4 rot )

{

    float4 rotation = rot;

    float xx = rotation.x * rotation.x * 2.0f, yy = rotation.y * rotation.y * 2.0f, zz = rotation.z * rotation.z * 2.0f;

    float xy = rotation.x * rotation.y * 2.0f, zw = rotation.z * rotation.w * 2.0f, xz = rotation.x * rotation.z * 2.0f;

    float yw = rotation.y * rotation.w * 2.0f, yz = rotation.y * rotation.z * 2.0f, xw = rotation.x * rotation.w * 2.0f;

    float4x4 m = { 

    {1.0f - yy - zz,             xy + zw,             xz - yw,         0},

    {xy - zw,              1.0f - xx - zz,             yz + xw,         0},

    {xz + yw,                      yz - xw,     1.0f - xx - yy,         0},

    {translation.x,       translation.y,       translation.z,         1}

    };

    return m;

}

float4x4 GetBoneElement( float index )

{

    return BuildFromTransRot( vecBoneLocalTrans[index], vecBoneLocalRot[index] );

}

VS_OUTPUT vs_main( SkinnedVS_INPUT In )

{

    VS_OUTPUT Out = (VS_OUTPUT)0;

    float4x4 skinTransform = 0;

    skinTransform += GetBoneElement(In.BoneIndices.x) * In.BoneWeights.x;

    skinTransform += GetBoneElement(In.BoneIndices.y) * In.BoneWeights.y;

    skinTransform += GetBoneElement(In.BoneIndices.z) * In.BoneWeights.z;

    skinTransform += GetBoneElement(In.BoneIndices.w) * In.BoneWeights.w;

    float4 localpos = mul(In.Position, skinTransform);

    Out.Position = mul( localpos, matViewProj ); 

    Out.TexCoord = In.TexCoord;

    return Out;

}

我们将骨头的local旋转及偏移传递至GPU,然后在GPU内重组,虽然对GPU性能计算有部分损耗,但是骨骼数量就能保守提高到100个.

CORE              DLL

ENGINE           DLL

GAME             EXE

D3DRENDER      DLL

其中D3DRENDER是GAME动态载入的，其需要链接CORE,ENGINE

这是一个很常见的模式，但是不好的是，因为CORE和ENGINE均是DLL，代码中的Symbol都被导出才可使用。任何人使用DEPENDENCE工具就可以将DLL中引用的东西查看的清楚，虽然这不至于造成技术泄漏，但从速度和DLL大小来说都是不划算的。

现在很多游戏主exe一般都是10M+甚至20M+的大exe，这都是使用静态链接而成。但是对代码结构也必须做出一定的调整。所有工程必须都是静态库，这样才能保证像CORE这样的静态库中的全局/静态变量不至于被链接2份而造成内存段逻辑错误。

当然，使用全静态库还需要注意一点：所有的lib都是在最后的game工程里来做链接。

UDK是unrealengine develpoment kit 的缩写，简单来说就是大名鼎鼎的虚幻３引擎的免费商业版本．不过虚幻３毕竟还是４年前的dx9的入门级引擎，在商业上取得
巨大成功，技术上也显得落后．目前Epic想榨干虚幻３的最后一点潜力，于是干脆发布了这个免费版本．任何人都可以用ＵＤＫ开发游戏，但是如果游戏牟利的话每年还是要向
Epic交纳一定数量的技术授权费用的．先不管这个，还是来看看它的官方视频教程吧．
　　[attach]44[/attach]
链接如下：　　
http://udn.epicgames.com/Three/VideoTutorials.html
一共５个教程　从引擎配置介绍开始，到关卡和人物编辑器，以及最后一个完整的小游戏的制作，对于入门来说完全足够了．
视频说的还比较详细，听力不好的同学可以对照下开发文档　http://www.udk.com/documentation　里面基本说的很详细．
最后附上ＵＤＫ的下载地址：　March 2010 UDK Beta (548 MB .exe)　
好了，ＵＤＫ对于初学者来说还是比较适合的．对于游戏的开发人员来说引擎的整体架构还是很值得学习的．希望你学的愉快．

OGRE的Compositor其实就是用于解决绘制PostEffect的，简单的说，就是一种RenderTarget的流程控制脚本

这是OGRE compositor文件的片段

compositor Bloom

{

    technique

    {

        // Temporary textures

        texture rt_output target_width target_height PF_R8G8B8

        texture rt0 target_width_scaled 0.25 target_height_scaled 0.25 PF_R8G8B8

        texture rt1 target_width_scaled 0.25 target_height_scaled 0.25 PF_R8G8B8

        target rt_output

        {

            // Render output from previous compositor (or original scene)

            input previous

        }

        target rt0

        {

            // Start with clear texture

            input none

            // Horizontal blur pass

            pass render_quad

            {

                // Renders a fullscreen quad with a material

                material Ogre/Compositor/BrightPass2

                input 0 rt_output

            }

        }

        target rt1

        {

            // Start with clear texture

            input none

            // Horizontal blur pass

            pass render_quad

            {

                // Renders a fullscreen quad with a material

                material Ogre/Compositor/BlurV

                input 0 rt0

            }

        }

        target rt0

        {

            // Start with clear texture

            input none

            // Horizontal blur pass

            pass render_quad

            {

                // Renders a fullscreen quad with a material

                material Ogre/Compositor/BlurH

                input 0 rt1

            }

        }

        target_output

        {

            // Start with clear output

            input none

            // Draw a fullscreen quad

            pass render_quad

            {

                // Renders a fullscreen quad with a material

                material Ogre/Compositor/BloomBlend2

                input 0 rt_output

                input 1 rt0

            }

        }

    }

}

大概我们知道，一个Compositor分为资源定义与绘制步骤（target xxx）

而一个绘制步骤又分别定义：

1. （输入）绘制的是什么东西？

2. （效果）绘制成什么样子？

3. （输出）往哪里绘制？

输出方式在这个例子有2种：纹理（RT）和屏幕

输入方式有2中：纹理及场景

我们可以使用一个回调来对一个绘制步骤提供绘制输入

绘制效果就是一大堆的Shader，这些shader都是基于一个quad来做的，也就是一个矩形，使用变换后的顶点和一个纹理坐标作为顶点定义

不过这里是不需要做vertexshader的，仅仅ps足矣。

绘制的最后，是将前面绘制的RT（纹理）混合起来

当然，如果步骤比较多和复杂时，RT之间跟寄存器一样，可以反复使用

显示茶壶法线的场景加上 Blur 的PostEffect

<?xml version="1.0" encoding="gb2312" ?>

<Compositor name = "bloom" >

  <Resource>

    <RenderTarget name ="rt_source" size="screenquad" />

    <RenderTarget name ="rt0" size="screenquad" />

    <RenderTarget name ="rt1" size="screenquad" />

  </Resource>

  <Step target="rt_source">

    <Geometry type ="callback" callback = "rt_input"/>

  </Step>

  <Step target="rt0">

    <Geometry type = "screenquad"/>

    <Effect name ="material\blurH.xml">

      <Texture name ="mTexture" value ="rt_source" />

    </Effect>

  </Step>

  <Step target="rt1">

    <Geometry type = "screenquad"/>

    <Effect name ="material\blurV.xml">

      <Texture name ="mTexture" value ="rt_source" />

    </Effect>

  </Step>

  <Step>

    <Geometry type = "screenquad"/>

    <Effect name ="material\combine.xml">

      <Texture name ="mTexture1" value ="rt0" />

      <Texture name ="mTexture2" value ="rt1" />

    </Effect>

  </Step>

</Compositor>

MAX插件导出的模型资源分：Mesh/Skin, Skeleton, Animation

不同动作按照不同的动画文件保存

ResourceHandle 包含基本id
        >NamedResourceHandle 带有名称资源，包含hashA, hashB， 使用暴雪hash函数生成
        >ModelHandle       
        >MeshHandle           
        >SkeletonHandle       
        >AnimationHandle

获取资源，如果资源不存在时，自动加载
ModelMaster.ManualCache( &ModelHandle )

直接资源访问：
RawSkeleton = ModelMaster.ManualCache( &SkeletonHandle("a.skl") )
RawSkeleton->GetMarker(...)

异步资源加载，异步id保存于ModelHandle中，在callback中根据id确认
ModelMaster.AsyncCache( &ModelHandle )

获取资源指针，未加载时，返回空
ModelResource = ModelMaster.Fetch( &ModelHandle )

模型资源加载器
    在模型句柄中绑定对应加载器
    可以自行编写带换装的ModelLoader，通过读取自己的配置文件，自行加载资源后生成RawModel
ModelLoader
    ModelHandle         ---mapping--->    ModelLoader         ---generate--> RawModel
    MeshHandle          ---mapping--->    MeshLoader             ---generate--> RawMesh
    SkeletonHandle     ---mapping--->    SkeletonLoader      ---generate--> RawSkeleton
    AnimationHandle    ---mapping--->    AnimationLoader   ---generate--> RawAnimation

引用计数类   
ModelResource
    >RawModel
    >RawMesh
    >RawSkeleton
    >RawAnimation

RawModel中不保留Handle，只保留指针
RawModel
    +MeshVB    从模型文件中直接读取顶点格式，包含 静态,GPU,CPU类型顶点
        +RawMesh
        +MeshIB        一次性填充IB
        >GPUMeshVB    一次性填充VB
        >CPUMeshVB    每帧计算
    +Animation            运行期数据（时间/帧）
        +RawAnimation    原始动画内容
    +Skeleton
        +RawSkeleton

最近在写D3D9模拟D3D10接口的渲染系统中碰到大量的渲染状态对象，不仅成员多，枚举也多的要命。

    struct CORE_API RasterizerState : ResourceHandle            
    {
        eFillMode            mFillMode;        
        eCullMode            mCullMode;
        bool                mFrontFaceCCW;
        float                mDepthBias;
        float                mSlopeScaledDepthBias;
        bool                mDepthClipEnable;
        bool                mScissorEnable;
        bool                mMultisampleEnable;

        RasterizerState();
    };

而要从配置文件中读取数据并填充到这个结构体，对于C++来说完全就是吃力不讨好的，写出来的代码也是极为过程，修改和扩展极为麻烦的。

因此决定使用反射的方法来填充数据，先总结一下我的C++反射系统

class RTTIObject // 动态类型识别对象基类，对象通过一些宏后可以很方便的通过字符串创建出类实例，并且可以查询注册时的类型和其他绑定信息
class NameRef  // 名字表，类似于虚幻中的FName，可以定义Const和普通Name，比较和拷贝只是一个dword耗费的时间
value_parse，value_tostring，value_typename // 一系列类型模板函数，提供对类型的ToString，Parse及类型名查询

首先需要处理的是枚举查询，这里将枚举通过宏做成一个个枚举对象，并可以通过名字创建实例

#define DECLARE_ENUMOBJECT( TEnum ) \
    struct EnumObject_##TEnum : EnumObject\
    {\
    DECLARE_RTTIOBJECT( EnumObject_##TEnum );\
    EnumObject_##TEnum( );\
    };


#define IMPLEMENT_ENUMOBJECT_BEGIN( TEnum, TEnum_prefixoffset, TMember_prefixoffset ) \
    IMPLEMENT_RTTIOBJECT_STRING( EnumObject_##TEnum, #TEnum + TEnum_prefixoffset, #TEnum + TEnum_prefixoffset, "EnumObject" )\
    EnumObject_##TEnum::EnumObject_##TEnum(){ const int member_prefixoffset = TMember_prefixoffset;

#define ENUMOBJECT_ADD( enumkey ) AddMember( #enumkey + member_prefixoffset, (dword)enumkey );

#define IMPLEMENT_ENUMOBJECT_END }

#define ENUMOBJECT_STATICINIT( TEnum ) EnumObject_##TEnum::StaticInit();

EnumObject 中通过宏将枚举的名称和值保存在这个对象中

IMPLEMENT_ENUMOBJECT_BEGIN( eFillMode, 1, 3 )  // 这里的1，3是将eFillMode及FM_Point转成字符串后去掉前缀
    ENUMOBJECT_ADD( FM_Point )
    ENUMOBJECT_ADD( FM_Line )
    ENUMOBJECT_ADD( FM_Fill )
IMPLEMENT_ENUMOBJECT_END

// 注册到RTTIObject系统

ENUMOBJECT_STATICINIT( eFillMode )

 

// 通过枚举对象可以查找到字符串对应的值
dword v;
EnumObject::GetEnumValue( "FillMode", "Point", v )

下一步是将结构体成员信息记录

    void SettingObject::BindMember( const NameRef& objname, void* instancePtr, void* dataPtr, SettingProxy* proxy )
    {
        proxy->mOffset = dword(dataPtr) - dword(instancePtr);

        MemberList& memberlist = mSettingMap[ objname ];
        memberlist[ proxy->mName ] = proxy;
    }

这里记录的是结构体成员的内存偏移

使用大量的宏，可以让结构体绑定变得漂亮

#define BIND_SETTINGOBJECT_BEGIN( TClass ) \
    { const NameRef& soname = TClass::StaticGetClassInfo()->mClassName;TClass soobj;

#define BIND_SO_MEMBER( TMemberType, TMember ) \
    so.BindMember( soname, &soobj, &soobj.TMember, new TSettingElement<TMemberType>(#TMember + 1 ) );

#define BIND_SO_MEMBER_NAME( TMemberType, TMember, TName ) \
    so.BindMember( soname, &soobj, &soobj.TMember, new TSettingElement<TMemberType>(TName) );

#define BIND_SO_ENUM( TEnumType, TMember ) \
    so.BindMember( soname, &soobj, &soobj.TMember, new TSettingEnum(#TMember + 1, #TEnumType + 1) );

#define BIND_SO_ENUM_NAME( TEnumType, TMember, TName ) \
    so.BindMember( soname, &soobj, &soobj.TMember, new TSettingEnum(TName, #TEnumType + 1) );

#define BIND_SETTINGOBJECT_END }

绑定代码如下

        BIND_SETTINGOBJECT_BEGIN( RasterizerState )
            BIND_SO_ENUM    ( eFillMode    , mFillMode )
            BIND_SO_ENUM    ( eCullMode    , mCullMode )
            BIND_SO_MEMBER    ( bool        , mFrontFaceCCW )
            BIND_SO_MEMBER    ( float        , mDepthBias )
            BIND_SO_MEMBER    ( float        , mSlopeScaledDepthBias)
            BIND_SO_MEMBER    ( bool        , mDepthClipEnable)
            BIND_SO_MEMBER    ( bool        , mScissorEnable)
            BIND_SO_MEMBER    ( bool        , mMultisampleEnable)
        BIND_SETTINGOBJECT_END

所有结构体的信息被记录在SettingObject中，读取配置文件填充结构体的任务就变得异常的简单了

    SettingObject settings;
// 将所有的结构体信息记录
    InitRenderStateObjectSetting( settings );

    const NameRef& rzname = DepthStencilState::StaticGetClassInfo()->mClassName;

    DepthStencilState a;
 // 这里就是将配置文件的信息填充到结构体
    settings.SetMember( rzname, &a, "BackFace.StencilFunc", "Equal" );

Lemon系统特性：

1. 支持 Canvas,Sprite,ImageSet（图片帧存储于一张图片，等大小）

2. ImageSetEx（自由摆放的图片帧于一张图片）*

3. 支持对象无关键帧时使用静态属性进行设置，类似于HGE里的精灵

4. 每个对象均可成为Container，并拥有Child Node

5. 动画关键帧类型支持：缩放，旋转，位移，颜色，动画帧，锚点，音效*

6. 支持拾取

7. 基于XML存储的文件格式

8. 基于Squirrel松鼠脚本的高速面向对象脚本*

9. 图形系统Graphics抽象，适用于任何渲染设备

10. 控件系统*

11. 视频回放*

所有对象均由RTTI创建，枚举均有NamePool+Hash，并由于PropertySet的反射系统

 

LemonComposer编辑器特性

界面基于我去年开发的MotionUI，lua

8+1控制点点对象调节属性

类Adobe Flash的帧编辑。

类3DS Max的分轨道关键帧编辑，有助于优化art assert

自由调节对象层级及父子关系

全功能无限制自由Redo,Undo

 

*将在未来版本支持

2D游戏是独立游戏的主流，也是创意，投入比最小的一个维度。但是基于2D的大多是一些类似于HGE，IndieLib等开源免费2D引擎。但是面对游戏中大量的动画而言，开发者大多是使用图片帧来制作，虽然效果很好，但是设备资源好用和制作难度也是很难控制的。

流行于去年的植物对僵尸和2004年发行的RO Offline经过资源分析，就是使用类似于Lemon系统，或者说Flash的系统制作而成，因此效果和扩展性非常好。

这就是Lemon存在的理由。

Flash面向的是GDI+Web，那么Lemon就是针对游戏专有的，基于硬件加速的游戏框架

Flash Action Script 对应的就是Lemon的Squirrel脚本

FlashIDE 对应的就是Lemon Composer

Lemon的目标就是让2D游戏开发更简单，让游戏中充满更多的动画, 让游戏开发难度降低

Render Target Alpha (Direct3D 9)

The frame buffer blender can now blend alpha channels independent from color-channel blending on render targets. This control is enabled with a new render state, D3DRS_SEPARATEALPHABLENDENABLE.

When D3DRS_SEPARATEALPHABLENDENABLE is set to FALSE (which is the default condition), the render-target blending factors and operations applied to alpha are the same as those defined for blending color channels. A driver needs to set the D3DPMISCCAPS_SEPARATEALPHABLEND cap to indicate that it can support render-target alpha blending. Be sure to enable D3DRS_ALPHABLEND to tell the pipeline that alpha blending is needed.

To control the factors in the alpha channel of the render-target blenders, two new render states are defined as follows:

D3DRS_SRCBLENDALPHA 
D3DRS_DESTBLENDALPHA 

Like the D3DRS_SRCBLEND and D3DRS_DESTBLEND, these can be set to one of the values in the D3DBLEND enumeration. The source and destination blend settings can be combined in several ways, depending on the settings in the SrcBlendCaps and DestBlendCaps members of D3DCAPS9.

The alpha blending is done as follows:

renderTargetAlpha = (alphain* srcBlendOp) BlendOp (alphart* destBlendOp) 

Where:

• alphain is the input alpha value.
• srcBlendOp is one of the blend factors in D3DBLEND.
• BlendOp is one of the blend factors in D3DBLENDOP.
• alphart is the render-target alpha value.
• destBlendOp is one of the blend factors in D3DBLEND.
• renderTargetAlpha is the final blended alpha value.

翻译如下：

   使用 D3DRS_SEPARATEALPHABLENDENABLE渲染状态可以让Frame Buffer 混合器将RT中的Alpha通道与颜色通道分开混合。

当D3DRS_SEPARATEALPHABLENDENABLE 设置为 FALSE（默认），RT渲染参数和操作会跟颜色通道一样被应用到Alpha通道。 这项特性需要显卡支持D3DPMISCCAPS_SEPARATEALPHABLEND 特性。记住，在之前设置D3DRS_ALPHABLEND以便打开Alpha混合。

   RT混合器的Alpha通道混合因子渲染状态如下：

D3DRS_SRCBLENDALPHA

D3DRS_DESTBLENDALPHA

其被定义在D3DBLEND枚举中，D3DRS_SRCBLEND 和D3DRS_DESTBLEND也是这样定义的。来源色与目标颜色将会有很多组合方式，主要依赖于D3DCAPS9中的SrcBlendCaps 和DestBlendCaps

Alpha混合公式如下：

renderTargetAlpha = (alphain* srcBlendOp) BlendOp (alphart* destBlendOp)

其中：

    alphain为输入alpha值

    srcBlendOp是D3DBLEND中的一个混合因子

    BlendOp是 D3DBLENDOP中的一个混合因子

    alphart是RT的alpha值

    destBlendOp是D3DBLEND中的一个混合因子

    renderTargetAlpha是最后混合后的alpha值

最简单的方法莫过于判断鼠标点是否在2个三角形中。但是很多判定方法都是有问题的，比如说

copy自IndieLib

bool Triangle2D::Inside2( const Vector2& p )
{
    Vector2 v0 = mP3 - mP1;
    Vector2 v1 = mP2 - mP1;
    Vector2 v2 = p - mP1; 

    // Compute dot products
    float dot00 =  Vector2::DotProduct( v0, v0 );
    float dot01 =  Vector2::DotProduct( v0, v1 );
    float dot02 =  Vector2::DotProduct( v0, v2 );
    float dot11 =  Vector2::DotProduct( v1, v1 );
    float dot12 =  Vector2::DotProduct( v1, v2 ); 

    // Compute barycentric coordinates
    float invDenom = 1 / (dot00 * dot11 - dot01 * dot01);
    float u = (dot11 * dot02 - dot01 * dot12) * invDenom;
    float v = (dot00 * dot12 - dot01 * dot02) * invDenom; 

    // Check if point is in triangle
    return (u > 0) && (v > 0) && (u + v < 1);
} 

  

Google出的某人代码

float Triangle2D::CrossProduct3(const Vector2& p1,const Vector2& p2, const Vector2& p0 )
{
    return (p1.x-p0.x)*(p2.y-p0.y)-(p2.x-p0.x)*(p1.y-p0.y);
} 

bool Triangle2D::Inside( const Vector2& p )
{
    return (CrossProduct3(mP1,p,mP2)*CrossProduct3(mP3,p,mP2)<0) &&
           (CrossProduct3(mP2,p,mP1)*CrossProduct3(mP3,p,mP1)<0) &&
           (CrossProduct3(mP1,p,mP3)*CrossProduct3(mP2,p,mP3)<0);
} 

这2个方法都有缺陷，当点在三角形边上时，就无法得出。当用在一个正方形判断时，正方形中心点就判定为没有在其内部，显然是一个错误。

之后，又Google出某几个大侠的算法和思想，考虑了下，判定点与四边形重心点的线段是否与四边形4条边相交，相交时，其在四边形外部，反之亦然。

bool Quadrangle::Inside2( const Vector2& p )
{
    Vector2 c = Segement2D::GetCrossPoint( mP1, mP3, mP2, mP4 ); 

    return !(Segement2D::Intersect( mP1, mP2, c, p) || 
           Segement2D::Intersect( mP2, mP3, c, p) ||
           Segement2D::Intersect( mP3, mP4, c, p) ||
           Segement2D::Intersect( mP4, mP1, c, p) );
} 

bool Segement2D::Intersect( const Vector2& p1, const Vector2& p2,const Vector2& p3, const Vector2& p4 )
{
    float gradab, gradcd, ycptab, ycptcd, interceptX, intercepty; 

    // In order to avoid divisions by zero
    //if (mP1.y == mP2.y)
    //    mP2.y += 0.0001f; 

    //if (mP1.x == mP2.x)
    //    mP2.x += 0.0001f; 

    //if (seg.mP1.y == seg.mP2.y)
    //    seg.mP2.y += 0.0001f; 

    //if (seg.mP1.x == seg.mP2.x)
    //    seg.mP2.x += 0.0001f; 

    // Calculates the intersection between the two lines
    gradab = (p1.y - p2.y) / (p1.x - p2.x);
    gradcd = (p3.y - p4.y) / (p3.x - p4.x); 

    ycptab = p1.y - p1.x * gradab;
    ycptcd = p3.y - p3.x * gradcd;
    interceptX = (ycptab - ycptcd) / (gradcd - gradab);
    intercepty = (ycptab - (gradab * ycptcd) / gradcd) / (1 - gradab / gradcd); 

    // Checking in the intersection is inside the segment
    if (!((interceptX >= p1.x && interceptX <= p2.x) || (interceptX >= p2.x && interceptX <= p1.x)))
        return 0; 

    if (!((intercepty >= p1.y && intercepty <= p2.y) || (intercepty >= p2.y && intercepty <= p1.y)))
        return 0; 

    if (!((interceptX >= p3.x && interceptX <= p4.x) || (interceptX >= p4.x && interceptX <= p3.x)))
        return 0; 

    if (!((intercepty >= p3.y && intercepty <= p4.y) || (intercepty >= p4.y && intercepty <= p3.y)))
        return 0; 

    return 1;
} 

Vector2 Segement2D::GetCrossPoint(const Vector2& p1, const Vector2& p2, const Vector2& q1, const Vector2& q2)
{
    //必须相交求出的才是线段的交点，但是下面的程序段是通用的 

    /*根据两点式化为标准式，进而求线性方程组*/
    Vector2 crossPoint;
    //求x坐标
    float tempLeft = (q2.x - q1.x) * (p1.y - p2.y) - (p2.x - p1.x) * (q1.y - q2.y);
    float tempRight = (p1.y - q1.y) * (p2.x - p1.x) * (q2.x - q1.x) + q1.x * (q2.y - q1.y) * (p2.x - p1.x) - p1.x * (p2.y - p1.y) * (q2.x - q1.x);
    crossPoint.x = tempRight / tempLeft;
    //求y坐标
    tempLeft = (p1.x - p2.x) * (q2.y - q1.y) - (p2.y - p1.y) * (q1.x - q2.x);
    tempRight = p2.y * (p1.x - p2.x) * (q2.y - q1.y) + (q2.x- p2.x) * (q2.y - q1.y) * (p1.y - p2.y) - q2.y * (q1.x - q2.x) * (p2.y - p1.y);
    crossPoint.y = tempRight / tempLeft; 

    return crossPoint;
}

这个算法效率并不是很高，但对于设计器来说无所谓了，如果有好的准确算法，可以讨论