我对２维码的设计又思考了一下，加上了一点碌亩鳌? 2 }( u2 V% S! `$ S% |+ c
这就是校验码。为了便于理解，我制做了一张设计图。
* z; t1 Q0 a4 s这是一张４Ｘ４象素的图，这４Ｘ４象素代表一个字母，也就是１个２维码，同时对应一个ＡＳＣＩＩ码。 8 Q* e. k8 M0 i* f6 g0 Z1 ]
* T0 E% b5 e1 M( _; c. J" R8 E5 q
为什么要使用校验码呢。其实略为思考一下就很容易想到，我们的２维码是显示在有背景的游戏画面上的，所以不可避免可能发生２维码的有色点和背景颜色相同的情况，如果一个像素原本应该是透明的，但是背景的颜色和有色点的颜色正好相同的话，我们的２维码识别程序就会把这个点识别为有色点，这样的话，整个２维码就识别错了。 6 O% m$ _* c F3 G
; L& f& C2 O7 @让我们来看一下示意图．首先让我们来估算一下字幕的数量，不满２５５的话可以使用８像素的２维码，就是图上的浅黄色的点．如果＞２５５的话就要使用９像素的２维码．校验码表示的是有色点的个数，对应的，使用８像素的２维码的时候使用３像素的校验码，使用9像素的２维码的时候使用4像素的校验码．因为３个２进制数字可以表示１－８，４个２进制数字可以表示１－１６．
Z# ^- ]5 A: W q8 A, L F# o- e2 J/ h" g- W, g! B) @
当我们的识别程序发现校验码和２维码的有色点的个数不同的时候，可以输出ｌｏｇ，从而找到被错误识别的那个ＩＤ。
9 |; ~: Y! | u" x) Y* p( f7 y+ e0 _! X) H6 \ U) F
---------------------------------------
, F4 O! k( O3 m) V, X2009.6.6 更新 , c9 K3 S! R4 F
/ V9 a. b4 S. F8 ]1 T+ L( v9 H看了肥牛还没有完全理解,或者是理解了没有表达清楚.
. `, E1 l e/ P$ r! g% a我再补充说明一下. 5 q" _% B" W1 K9 Q0 }0 X
# Y2 f4 R" p1 b我们不妨做一个比方,我们把图片字模库tga看作为一个函数，其中每个象素的前3个字节 FF FF FF就好比是函数的参数，是形参。 0 w. P$ t6 ~; k' X6 r3 y. f0 ~
那么实参是什么呢。实参是设定在游戏配置文里的字体颜色。那么函数值是什么呢？函数值是显示到游戏画面上的字体。根据实参，也就是设
8 s: r# C) v5 i1 i4 h' Y3 k+ Y定的字体颜色的不同，那么函数值，也就是最后显示出来的字体颜色也不同。 9 c' I; U8 s, T) a$ U( P
上面的应该比较容易理解，接着我来说明肥牛可能有误解的地方。 6 u0 y. {/ G* N2 T% ?
我说有色点是FF FF FF FF，透明点是FF FF FF 00，这仅仅是指tga图片字库里的数据是这样的。 + m" s& d, _# G$ Y
你可以看作一个函数的内部有这些数据。 : j% P/ \8 Q) u- v, X$ k
一旦字体被显示出来，相当于显示的是上面这个tga图片字库函数的值。 / D7 X) X3 d. z2 ^
假设我们设定的字体颜色是 AA AA AA,那么上面的有色点被变换为AA AA AA FF,而透明点则把游戏画面上对应位置的像素颜色显示出来。
' e# {1 i* h$ {' g所以，一旦字体被显示到屏幕上以后，那个3X3的小块里面的颜色状况就 4 O" r# d: `0 z% x, e
! i) t- |; I: J N; D不是 有色点是FF FF FF FF，透明点是FF FF FF 00
( v2 I, L4 P8 S) O/ r而是 有色点是AA AA AA FF，杂色点是 游戏原来像素的颜色 （32bit） 9 |* w) w" a6 h% F5 f
9 X' |# l0 n1 x- p) }! D我们从log里可以看出，游戏是运行在32bit模式下的。 1 M" _: u v) T
22:11:58: D3D9 : Created D3D9 Rendering Window 'Ankh - Heart of Osiris' : 1024x768, 32bpp
; z+ i( l% H7 L0 }: {3 n6 k+ C
8 N! @9 \- L. ~$ y6 x* E3 v好，我们再回过头来看看。对于透明色的问题，解释到这里，应该明白了吧。 4 g! t& M' `/ N `/ G; x
" C% s+ B6 U( _: ]; ]+ H
我就没想明白透明像素叠加到背景上以后怎么再读取出来。 ' v3 W5 }# V+ r/ t6 u3 {
透明像素叠加到背景上以后就不是透明的了，我们自然可以把它和字体的颜色区分开来。
$ S" O3 o& c3 D2 a3 X8 z' F为了防止通过透明像素透出来的游戏原来的像素的颜色和字体的颜色一样，我们引入了校验码。 . S' Z( ^% I8 y
校验码的读取也很简单，校验码和字体是用同一种颜色显示的，比方说字体颜色是AA AA AA FF，那校验码的颜色也是AA AA AA FF。 , m5 }+ p$ h R3 p: W
7 A1 J) w! e* w$ T+ v5 |0 c
从设计图上可以看出，校验码显示的位置是固定的，所以我们可以判断出校验码的3，4个点中有几个点是AA AA AA FF。校验码的每一位的颜色和AA AA AA FF是否相同的状态，可以看作0和1，这样就可以表示8或16种状态，表示3X3 2维码中的和设定字体颜色相同的点的个数。如果这个 ( k7 l) z& h" j8 `$ o3 v
个数和实际的3X3 2维码中的和设定字体颜色相同的点的个数不同，那么就表示校验不通过，有识别错误。 9 n( l+ x# R" ~+ ]
: R# H3 U- C6 Y, r7 j6 s [
有人也许会说，校验码本身被识别错误了怎么办？ u6 y4 ^1 k9 v' E
这种情况是存在的。校验码不能校验出全部的错误，但是从概率上说，能校验出绝大部分错误。
/ u8 Q& f, [' _为什么这么说呢？因为发生错误识别的情况只能是，某个点被多识别了。这里说的某个点是指在游戏背景上和字体颜色相同的点。
: A- S4 N+ y+ ~! L$ g0 F6 i; J所以，校验码校验不出来的情况只有一种，这就是校验码和2维码都被多识别了几个点。然后错误的校验码表示的数值和错误的2维码的和字体颜色相同的点的数量碰巧相同。这种情况应该是很低概率的。 ~! x7 w9 T T/ F8 c4 F
- _! B8 M' u- O# g6 N
最后要说的是，校验码只在游戏测试阶段有用，汉化补丁发布时最好把校验逻辑从proxy dll中去掉，以免影响速度。tga图片本身可以不修改，但是xml文件要修改，把每个字母的划分改动一下。
' f" E# N3 V \从4X4 改为 3X3。就是说要改x,y width,heigh.
7 ]0 Q3 O# |- Q% m, h9 b
6 z2 M- q2 f0 N( t* Q4 B--------------------------------------------------------
. o% Q6 `5 I8 J5 ^# v; O2009.6.15 更新 " [) E$ L9 o2 e
最近又想了一下2维码的部分，又冒出了新的想法。 5 E6 B+ n% l* H* Q5 ?. e
如果能实现的话，能把现有的方法大大简化，彻底抛弃比较复杂的2维码，还能做到误识别率为0。
5 k/ X+ w4 z+ n说出来很简单，我们把原来显示在屏幕中部的字幕向下挪动到底部的黑色背景上就行了。 6 v; M: F; o' ^. d- @5 e8 l/ w
具体怎么挪动只要修改xml里面在y方向的修正值就行了。
Z! x: \5 }4 \5 R一旦我们能把原来显示在屏幕中部的字幕向下挪动到底部的黑色背景上的话，我们就能用原来条形码的那套判断方法来判断了。比较复杂的2维码也可以抛弃了。
' x; N7 |% r8 e* o当然，我们判断出ID以后，在proxy dll中还是要把对应中文字幕显示在屏幕中部的。
$ j' ?0 d4 Z1 p, v由于字幕的判断都统一到条形码上，我们只要把除主菜单ID外的所有ID都对应到一个12或13位的条形码上即可。 |
发表于 2009-6-5 18:52
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
分享
很美好
很差劲
楼主
发表于 2009-6-6 13:06
