Fishfray永存心中之幻想乡v0.2alpha: 知识积累

练手：广州地铁票价查询

Tue, 22 Jul 2008 17:49:43 GMT

练手：广州地铁票价查询
原因：女友某日说需要这种软件。
结果：今晚花了1个多小时完成这个小软件。别指望我还有心情去美观这东西。

分析：软件逻辑本身十分钟就写完了。最麻烦的是建立那个价格表。因为这个价格不是公式算出来的，而是根据实际地铁站点之间的距离算出来的，所以只能建立价格表格才行。。。但是网上没有制作好的文档表格，所以不得不自己做表格。网站地图缩小后看不清，所以也要自己做图这些花费了不少时间。

理论上全机型适应（MIDP1.0，导航键不能用的用2,4,6,8也能控制方向）。切换地图的时候可能载入需要几秒钟（图不小），大概就是这样。

下载地址：
http://www.comicfishing.com/_fish/gzmtr_price.rar

本身是没什么难度的东西，东西实用是最重要的。。。。
与其绚丽多彩的外观空有外壳，不如实实在在的快速做功能。毕竟是非商业的东西。
程序也是如此，人也如此。

------------------

风云决很好很强大，绝对是近几年来中国最好的动画电影，没有之一。
美版360很好很强大，只能玩英文+全区游戏。不能玩中文+日文游戏。。昏倒
鲁鲁修很强大，剧情实在是忽悠的很。看得我吐槽不能。
渔场很强大。走了近5年了，人还真的不少。
手机很强大。android，塞班，WM,J2ME移动软件都很强大。
keroro很强大。200多集了还在不停的演。
东方很强大，天上地下无所不能巫女无敌。
E3很强大，FF13跨了平台一个消息后PS3价格立刻降了，360价格立刻升了。
中国股票很强大，俯X撑来回忽悠钱。
中国青菜很强大，几个月1.5一斤就涨到4块钱一斤了。
奥运很强大。中国的盛世。
所有的一切都很强大。

<天劫online>全部图片资源

Tue, 09 Oct 2007 05:12:43 GMT

<天劫online>是我近期才见到的一个非常赞的游戏，特别是像素图看起来无论是颜色还是设计都是我很喜欢的类型，所以把图片资源解出来，特别向大家推荐一下。版权是空中猛犸的哦。大家看一下就好。

http://www.comicfishing.com/_fish/tj_k750_res.rar

从Jbuilder X到eclipse 3.3....

Wed, 05 Sep 2007 15:48:35 GMT

时代在发展，科技在进步，如今乡间小路都变成了高速公路。偶的IDE在很多很多一群一群一堆一堆的朋友的簇拥下，再加上前一段的新闻的攻略下。。好吧= =我今天把家里的电脑换IDE平台了。。

从Jbuilder X到eclipse 3.3。。各方面其实过渡的感觉都很平稳，晚上专门花费了点时间将eclipse 的颜色，格式，界面调整了一下。差不多算是实现了平稳过渡。而且调成了一些深色调，为了防止眼睛劳累。界面也大体上模仿了JbuilderX以前写程序的界面。也顺手调整了一些以前在Jbuilder没有注意的细节。其它也就没有什么了。整体平台过渡应该算是98%吧。写点东西还算顺手。明天把公司的平台也调整一下好了。。

JbuiderX偶编程一直用的界面。。

eclipse3.3的调整后的界面，以后我将在这个界面下工作。。

周末杂事

Mon, 03 Sep 2007 05:37:20 GMT

自从上周入手入手<JAVA编程思想第四版>第四版到先在已经有一周了。目前进度大概是看了20%左右，大多是上周二到周五看的。
上周五公司活动，去打羽毛球，2个部门的人一共打了7场，我一个人胜了2场>.<，我们技术部以4:3胜市场和产品部，yeah～（虽然实际上最会打羽毛球的2个人打单场去了= =剩下的都是不会打的在比赛）结果市场部的经理请吃饭=v=边吃饭边看刘翔的跑步～又是第一
周末女友学校报到，帮她搬家到广外研究生宿舍。- -3人间，还有空调。现在的学生生活真好啊=_=。事隔一年多没有进过大学城半步，如今大学城环境已经很不错了。我自己的电脑也终于从家里的客厅搬回到卧室了T_T，可喜可贺。昨天在广外，看着那一群一群的学生，不知不觉的感慨自己已经老了。和以前大学时候认识的朋友见面。以前大一大二的人现在都大四了=_=我真的老了啊。。。OTL...都本命年了。我的豆蔻年华回来啊（泪）盈月2香港那次因为某些原因没有去成，所以香港的要在广州处理了。圆通快递还是一如既往的无耻+无赖。打电话放了我2次鸽子；下次改用申通快递好了。
周六偶然知道了halo2最后几关的游戏方法，所以把halo2通关了。9月25日XBOX360版的halo 3发售。以前halo1和halo2都是玩PC的，希望下次能够玩到XB360版的吧。仙剑4之后RPG游戏自然沉寂了一段时间，周末晚上也玩了玩上次在购书中心买到的空之轨迹SC。只玩了一点点。估计今年能打完就不错了=v=。慢慢来吧。

毕竟人生除了工作赚钱，技术学习外，生活也是很重要的=v=好不容易周末好不容易休息，换换脑子出去玩玩后再回来工作才能劳逸结合嘛。
前几天在BBS偶然看到了脚本编译器就是下面这个：
Snake脚本编译器，功能还不错。
http://antigalaxy.spaces.live.com/
没想到作者竟然是摩网的=v=b 难道是我去moabc那里见到过的某人？
这东西和CoCoMo的新版本脚本editor撞车了啊=_,=不过还好。继续潜水观望。。

关于中byte[]与String互相转换时候的中文的处理问题。

Tue, 28 Aug 2007 11:57:58 GMT

今天公司的一个同事问我一个乱码的问题，本来是很小的问题，却让我弄了半个小时都没有弄完。这里严重鄙视一下自己已经生锈的脑袋，最近要转动一下了。其实问题很简单，就是本地把String转化为byte[]然后发送给服务器，然后服务器再把byte[]发给别的客户端，然后别的客户端把byte[] 转化为String。
但是无论发送，接受到的都是乱码，然后查询了发送端的byte[]，服务器端，和接受端的byte[]都没有问题。但是为啥发送后就是乱码呢？然后抛开服务器和接受端的问题。本机String转Byte[] 后再转换回String竟然也乱码。。。这囧坏了我了。因此拿了台测试机回家测试。
结果回家不到15分钟就解决了。。OTL，竟然是我自己疏忽了一个小地方导致的很大的问题。。
现在贴一下独立出来的程序模型。
---------------------------------------
    try {
      TXT = "章鱼烧";
      dx = TXT.getBytes();
      TXT1 = new String(dx);
      TXT2 = new String(dx, "ISO-8859-1");
      TXT3 = new String(dx, "UTF-8");
      TXT4 = new String(dx, "GB2312");
    }
    catch (UnsupportedEncodingException ex) {
    }
打印结果是：

这个就是原来程序的错误，无论用什么编码new出来的String都不是中文。后来注意到最前面的getBytes的编码问题
    try {
      TXT = "章鱼烧";
      dx = TXT.getBytes("UTF-8");//唯一修改的地方
      TXT1 = new String(dx);
      TXT2 = new String(dx, "ISO-8859-1");
      TXT3 = new String(dx, "UTF-8");
      TXT4 = new String(dx, "GB2312");
    }
    catch (UnsupportedEncodingException ex) {
    }
打印结果：

以上在NOKIA 7610上测试通过，也说明了7610的默认encoding是ISO-8859-1，看来关于中文的处理看来要多加注意才行。否则就会犯这种不小心出现的错误。

辛劳+平稳的生活

Tue, 28 Aug 2007 05:26:42 GMT

辛劳+平稳的生活。上周日去一个朋友家玩WII，果真wii要一群人玩才有意思。。。WII上最好玩的果真还是WII sports，和朋友2个人玩高尔夫，保龄球，网游，都很赞～不过也真累。。特别是玩铁锤高达的时候，手都酸透了。结果昨天和今天手臂都酸痛。。囧。。果真我还是适合用鼠标键盘手柄玩游戏啊。WII太消耗体力了。。顺便贴本人的WII形象一个=v=

上周五公司的人一起去唱K，偶不会唱，所以就不停止的吃自助餐，然后唱过后就直接开车去山上了。不幸的是我被分配给要坐一个刚会开车的人的车T V T，路上果真心惊胆战，最后还要开车上山，半高不高的悬崖上，下面就是湖。OTL...心里那个叫祈祷啊。。早知道我去开也会比她开车好点啊,虽说偶也很久没开了，但也不会比她差。OTL。
在山里吃完饭，然后回家的路上坐另外一个人的车= =。在仅仅比车宽不到1米的崎岖山道上那家伙竟然开车开到80公里！然后还说，不是他的车，他自己的福特可以速度再高，...OTL..我心惊胆战啊。总之上次山下次山，偶对开车的理解能力又有了提高。。我还是乖乖回老家的时候练车好了。

来新公司工作了一个月了=v=人也算混熟悉了，也稳定下来了，工作强度中等中有点敢时间，但是工作起来很顺手所以自然也没有什么问题，随手拍照2张留念。

偶的工作证，不厚道的打码。。

在公司里面看到的车。。OTL..囧啊。。

脚本的一些思考

Fri, 24 Aug 2007 02:44:16 GMT

继续昨天的话题，昨天因为那个程序员和那个策划之间对脚本定义的态度不同，所以想弄清楚相关的东西，所以才有下面写的文章：

关于脚本本身的定义：
脚本script是使用一种特定的描述性语言，依据一定的格式编写的可执行文件，又称作宏或批处理文件。脚本通常可以由应用程序临时调用并执行。
------
由上面可以理解到，其实脚本就是可以调用执行的文件。这个可以说是脚本的一个广泛的定义。动态程序一般有两种实现，一是二进制方式，也就是编译成，exe或者其他文件去执行的。另外一种就是脚本方式。通过调用一个文件脚本去解释执行的。通过这点来看昨天那2个人说的都是脚本，但是他们所说的脚本的内容有不同。忽然在网上发现了这样的话：
脚本同我们平时使用的VB、C语言的区别主要是：
1、脚本语法比较简单，比较容易掌握；
2、脚本与应用程序密切相关，所以包括相对应用程序自身的功能；
3、脚本一般不具备通用性，所能处理的问题范围有限。
-------------------
看了上面的解释，也许就清楚了。其实所谓的脚本，本身也就是和VB,C一样的语言，只是简单点局限点而已。而ASP、PHP、CGI、JSP这些都是脚本语言，也就是说，制作网页这些其实是在写脚本，也算编程的～也是写程序的，而非策划的工作咯？这个方面可能越说越麻烦，总之简单地说：写脚本也是在编程！
两个简单的例子，对比LUA和java：
1.打印"hello world"的实现。
LUA实现：
print"hello .world"
JAVA实现:
System.out.print("hello .world");

2.实现计数器：
LUA实现：
function create_a_counter()
    local count = 0
    return function()
        count = count + 1
        return count
    end
end

JAVA实现:
int count=0;
public void create_a_counter(){
count=count+1;
}
----------------
当然如果这样看来.脚本的确也就是编程嘛。这样其实看不出太多脚本的优点来，和编程没有两样。
但是很多可扩展性的游戏制作中，脚本的用途就比较大了，比如说魔兽世界中的用的LUA脚本，暴雪针对自己的游戏专门出了基于LUA的脚本系统，这样就可以让很多人（大多数是程序员）来自己定义界面系统，而不需要看机器内部的代码就OK。不需要编译(有的会用专门的软件简化和转换脚本)，直接就可以运行。因此我的看法就是：脚本就是可以不经过对程序部分再编译就能够运行的寄宿于某种计算机语言的语言。

继续返回到最开始的问题，策划需要的脚本是什么？程序需要的脚本是什么？
说清楚这个问题直接贴一些策划和我的聊天记录就OK
首先是策划的话：
-_- 脚本多复杂？莫非是需要用到程序定义语句的那种？策划不见得要懂程序，这是自己想偷懒的不负责借口啊，所谓脚本，那是简化了格式后交给程序接口解释的一种机制。象这种程度的如果策划能写大可以把程序开除掉节省开支。他为什么对策划的理解这么偏激。随便给策划的工作难度抬高门槛是要不得的。真想提高合作效率就该给别人提供些方便，策划能理解能写的话还要他这程序干啥…就是我，也只能做到提供好工具了才能开始做事。连工具都要我自己解决的话，真不如把程序开掉。=_,= 生化4的工具就是那样的，随改随生效。
可以看一下某日本游戏的脚本：
---------------------------
// 画面白
EF 0 1 1
GW 0
//ウインドウ文字位置設定
WI 0 64 24 28
WI 1 156 32 23
WI 2 156 336 23
WS 1 0
WS 2 0
FI 1 24 0
FI 2 24 296
// 顔ロード顔管理番号0に顔０（シオン）をロード
GF 0 0
// 顔ロード顔管理番号１に顔３（秋葉）をロード
GF 1 3
// 顔ロード顔管理番号２に顔７（志貴）をロード
GF 2 7
// BGロード
GB 42
// BGM
BP 0
// ６０フレームかけてホワイトイン
EF 0 0 60
--------------------------
下面是程序的原话：
网游就是策划要写脚本，本来就是让策划用的，本来策划就要懂程序。 V2.0最重要的是实现了微指令，最终的目标是程序根本不知道跑在自己身上的是什么游戏。我这个是宿主语言寄宿在J2ME上，如果用C++些个解释器,就能跑在C++上。
下面是那个策划的脚本,很长，就贴部分
VARIABLE {
    //misc
    $process = 0;
    $db_select = 0;
    $item_select = 0;
    $sameword = 0; //1: 没什么变化
    $come_from = 0;
    $curscene = 0;
    $menustate = 0;
    $menupause = 0;
    $menucontinue = 0;
    $random = 0;
.....
/** @todo --------场景7--------- */
SCRIPT Scene7_UnLoad {
    UnLoadScript(SCRIPT.Scene7_切屏);
    UnLoadScript(SCRIPT.Scene7_换背面);
    UnLoadScript(SCRIPT.Scene7_楼梯);
    UnLoadScript(SCRIPT.Scene7_楼梯口);
    UnLoadScript(SCRIPT.Scene7_旋转电脑);
    UnLoadScript(SCRIPT.Scene7_增减压电脑);
    UnLoadScript(SCRIPT.Scene7_植物);
}

/** @todo --------场景8 Out--------- */
SCRIPT Out_UnLoad {
    UnLoadScript(SCRIPT.Out_切屏);
    UnLoadScript(SCRIPT.Out_司令塔);
    UnLoadScript(SCRIPT.Out_返回舱);
}
.......
SCRIPT Scene4_修理台 {
    Attach($db_select);
    OpenDialogBox(1, "修理台");
    Detach();

    if ($db_select == 1) { //选择使用
      call(SCRIPT.OpenItemBox);
    }

    if($scene4_repair_att == 0 && $db_select == 0) {
      ShowMessage(2, "专门用来修理电子设备的固定台");
      return;
    }
........
//上面没有东西并且拥有修理器
    if($scene4_repair_att == 0 && $item_repair == 1 && $db_select == 1 && $item_select == 15) {
      UseItem(15);
      LoadMiniGameScene(2);
      LoadGameScene(4, true);
      SetPlayerShow(true);
      call(SCRIPT.Scene4_ChangeActor);
      ShowMessage(2, "物品修理完毕");
      SetValue($scene4_repair_att, 16);
      return;
    }
/** @todo --------植物--------- */
SCRIPT Scene1_植物 {
    Attach($db_select);
    OpenDialogBox(1, "植物");
    Detach();

    if($scene1_grass_att == 0 && $db_select == 0) {
      ShowMessage(2, "植物中有隐藏有东西");
      GetItem(13);
      ShowMessage(3, "数码相机");
      SetValue($scene1_grass_att, 1);
      return;
    }

    if($scene1_grass_att == 1 && $db_select == 0) {
      ShowMessage(2, "一盆植物");
      return;
    }

    if ($db_select == 1 && $item_select != -1) {
      SetValue($sameword, 1);
      call(SCRIPT.SameWord);
      return;
    }
}
}
=====================
两个同为脚本，却代表了2种脚本的使用方式，截然不同啊.一个实现了定义结构简单明了，另外一个实现了定义和简单逻辑。但是复杂度高了非常多。孰优孰劣不好说。。。不过游戏开发者真正需要的是哪种脚本呢？（最后也没有定论，拖出去打。。。。）

程序员和策划之间对于脚本的期望差异。

Thu, 23 Aug 2007 16:53:25 GMT

下午和一个程序设计不错的人还有一个策划分别聊了聊。说到脚本。策划和程序的看法截然不同。
看了那个程序的脚本，功能很强大，差不多相当于手机上的lua了，写一个那个脚本几乎相当于写了同样多的程序了。把脚本给那个策划看，策划却说，如果策划能写这种脚本的话，那要训练这个策划多久，而且如果策划写这种脚本的话，还不如直接写程序了。然后拿出了他正在做的日本游戏的脚本给我看。。的确，脚本简洁明了。但是功能并不强大。有兴趣的我又去查了一下欧美的一些游戏，很多游戏都是用日本游戏的那种脚本方式的，但是也有一些是用LUA这种的，相比来说，日本游戏的那种脚本方式用的人多些。。
可能不是一件大事。但是却让我有了兴趣。也许这个程序写的脚本已经不是基于游戏来说的脚本了，而是基于J2ME这个平台的脚本，也正因为这样。针对的用户群可能并不是策划，而是程序员了。但是程序员的话，又可以直接用J2ME去写，那么这个脚本的意义就是简化程序的劳动了，但是其实，策划要经过程序的手来实现这个游戏世界的话，那么其实流程和原来一样，那么这个脚本是否还具有原先那么多的意义呢？真正使用LUA的我想程序要比策划多的多吧。
因为以前自己写过一个基于脚本的游戏，是类似我说的日式游戏的那种脚本。这段时间打算尝试一下用那个程序员的脚本写点东西。。。亲身体验一下，到底这种脚本的好处在哪里。。
今天关注的自然是GT5P的截图。。。。

>.< 真的。。真的很有感觉的。。其它GT5P的图片可以点击我的相册观看。。
http://www.j2medev.com/blog/user1/21650/cmd.html?uid=21650&do=album

《游戏创造》7月号有偶关于J2ME游戏AI的文章

Sun, 12 Aug 2007 16:02:47 GMT

周五的时候偶然查看邮箱发现自己的邮箱里面有印刷品，拿回来一看是7月的游戏创造。翻了翻，是样刊，里面有偶的文章。呵呵～第一次在《游戏创造》上刊登自己的文章>.<虽然和别人比起来写的并不是多好，而且自己的文章自己觉得都有点古怪。不过还是心理暗爽一下=v=+yeah～

yeah~John Carmack demonstrates ID Tech 5 at WWDC 2007

Wed, 13 Jun 2007 03:36:52 GMT

John Carmack demonstrates ID Tech 5 at WWDC 2007

昨天,ID卡马克在WWDC 2007的演讲和展示,ID Tech 5新引擎的展示.
http://www.youtube.com/watch?v=HvuTtrkVtns

自从Doom3以后,卡马克销声匿迹了很久了...新的技术也一直没有出现在大家面前.cry引擎风头正劲,虚幻3引擎现在也先声夺人,HL2引擎也稳步发展,本以为卡马克已经将成为游戏引擎的历史的时候,终于带着ID Tech 5引擎出现了.
就技术上来说,感觉上就是DOOM3引擎的DX9(或者DX10)版..
引用新闻的话:
----------以下是转贴----
id Software全新的3D引擎和CG渲染技术几乎去掉了所有束缚游戏艺术家们和设计者的障碍，并且提供了独一无二的游戏世界像素级的定制功能，忠实的呈现了极端真实的视觉效果。新引擎还提供了一系列的强大设计工具套件，可以大大的方便和加速游戏制作的进程。id Tech 5将会使游戏拥有广阔的室外场景，同时室内环境的艺术细节也将进化到前所未有的地步。

另据C引擎的制作者卡马克介绍，新引擎id Tech 5除了可以对应Mac系统以外，同样可以完美支持PC、X360以及PS3等多平台的游戏开发工作，可以说是真正符合次世代要求的游戏开发引擎。
------以上是转贴------

从中可以看出,其实新引擎不再过分追求技术攀比的高峰,也不像某些引擎用特效来充门面,新引擎感觉最重要的一点,还是多平台开发,降低开发成本,提高效率. 这点其实正是很多公司投资者所需要的.同样的游戏,即使效果再好,对于投资人来说也不如开发周期减少50%以上的游戏赚.

一个优秀的游戏引擎的效果就是这样,降低游戏开发成本.增加艺术家和设计者的可操作的范围,将游戏的控制权尽量完美的传递给艺术家和设计者.估计以后引擎的争夺除了展现效果方面,也将在下面几个地方竞争了:多平台,简单实用,降低整体成本,减少开发周期.
果真作为游戏制作商,不赚钱是不行的阿...游戏制作商不是慈善机构.降低成本,提高质量.深度探索游戏性.才能生存.

====================

以下是腹黑话:我说老卡阿.家里蹲了这么多年,也不好好工作,就拿了一个DOOM3的DX9版本就想出来忽悠钱?该不会那时候1周写了个手机游戏,赚了100多万刀后,改行赚手机游戏的钱了吧XD.
====================

渔场BBS升级基本上完毕了...虽然美感和原来相比大不足....= =慢慢来好了..我承认我没有设计天份..

而且我的要做的事情多到我都想堕落.前天刚在群里面看到了某国内精英游戏设计师的言论,笑到我肚子痛,昨天则已经到了想吐的境界了(没胃口,吃饭吃几口的吐了).果真精神不好也会身体不好么...难道是我真的要颓废了么...我觉得我还是应该辞职休息一段时间了....

没有干劲,没有激情,没有目标...有呆下去的必要么?..连我自己也被传染了..= =预计下周或者下下周辞职....

blue的网页一拖再拖,就做了个主界面和分页面而已..很多东西都还没有完成..同人物整理拖了3,4天了,东西占领了我的床,我也没有心情整理.TB店的东西也都没整理,A*扩展算法的文章也一直没有时间写.<游戏创造>的AI概述的文章的图1周了还没有给砒霜...

为啥...我会这么多事情这么多麻烦事情..OTL....我要死了..

to Archlich :

blue那边顺利的话就过去..

to char:

搬家后欢迎来玩...

关于手机播放声音的一些实际做法

Tue, 15 May 2007 05:32:41 GMT

关于手机播放声音的一些实际做法.
上次(忘记什么时候了)说过了声音播放的状态转化的问题,这次牵涉一些实际的问题.
首先是声音播放的问题,很多情况下大家都希望2个声音同时播放,(背景音乐和音效),虽然在实际情况上这样做是有可能的,但是其中还是有很多的问题的,一般来说是先停止一个音乐,然后播放另外一个,然后再播放原来的音乐,但是更多人的做法就是只播放音效或者只播放音乐(好吧..我现在就是属于只播放音效的),
针对不同的游戏使用不同的选择,现在大概在手机游戏开发领域大多是这样做的.播放声音有的人是一个一个声明,然后一个一个用的,不过就个人来说,还是推荐大家用player数组, Player[] effect_player,这样的用法,方便适用,虽然有人给我说用Player[]有时候会出现问题,但是实际情况下我还没有碰到过确实是因为创建的是声音数组导致的问题.所以目前我还是用这种方法
public static final byte sound_beat = 0;
   effect_player = new Player[sound_number];
effect_player[sound_beat]=Manager.createPlayer("用于创建声音的数据流","audio/X-wav");
这样的用法是我现在的用法,当然个人推荐是把数据流都打包,这样对于读取速度方面会有一定的提高.
然后就是声音播放的问题,
1.很多手机不支持多个声音同时多个缓冲状态.
也就是说,很多手机不支持多个player同时处于PREFETCHED状态,因此在检测状态的时候尽量避免用PREFETCHED作为判别的标准,建议使用 STARTED状态而避免
PREFETCHED状态做判别.
关于声音播放方面,用的方法也很简单,一下是我暂时的用法
   public void play_effect_sound(int soundNo) {
    try {
      if (enablesound == true) {
        effect_player[soundNo].prefetch();//确认进入prefetch状态,
        effect_player[soundNo].start();//确认播放
      }
    }
    catch (MediaException me) {
System.out.println("effect_player error:"+soundNo);//如果有问题,打印错误的音乐编号
    }
}
虽然其实 effect_player[soundNo].prefetch()这步可以说是多于的,因为调用start的话也会先进入PREFETCHED状态再进入STARTED状态,
但是严格格式来说的话,还是写上好.看每个人的想法了.
2.关于声音同步的问题
关于声音同步的问题,有2个思路,如果是按照顺序播放还没有什么,如果是同时播放的话,就有2种根据游戏需要的解决办法了.1是停止当前正在播放的声音,
然后播放后来的声音,2就是继续播放原来的声音,后来的声音忽略,关于这个问题前几天也问了一下gameloft的神仙桑的解决办法,用的是前者,而我个人习惯上使用后者,只要在调用播放声音的函数上加上
if (effect_player[soundNo].getState() == effect_player[soundNo].STARTED) {
return;//如果声音状态正在播放,返回.
}就OK了.当然如果你播放的声音多于1个的话,也要检测多个player的状态..不过..检测这些不太浪费时间啦.所以一般来说没什么的.
(当然不排除一些比较特别强调音效节拍的游戏),总的来说声音播放就是player数组.不要用PREFETCHED状态检测判断.
针对和动作配合的播放声音,暂时的做法是这样的
public void hero_playBeatSound(int number) {
if (hero.act_frame == number) {//当前动作帧 == 指定动作帧
    sounder.play_sound(Def.sound_beat);//播放beat的声音.
}
}
我个人是用这种办法来确定精确的在某个动作的某一帧来精确的确定播放时间的.针对不少机型这样做是可以同步的(还有一些奇怪的机型暂时就不说了).

[唯一一篇只找回了半篇的文章]关于打包的一些做法

Wed, 18 Apr 2007 18:00:04 GMT

=_=实践证明...我对炎黄博客很无语.....我的东西都是从baidu网页快照上找回来的= =谢谢百度了....唯一一篇只找回了半篇的文章.

------------------------------------------------

上周拖欠的一篇文章,
关于打包的一些做法(j2se写,j2me测试).
--------------------------------
当游戏开发时候不可避免的有一些数据打包和加密,其实现在流行的甚至说所谓的内部的什么加密还有打包工具,其实原理都是很简单的..是不过是在储存的时候动了一点手脚,比如某某国外公司,还有某XXX教授写的OOO加密打包软件.其实都是原理很简单的...(特别是某教授写的加密软件让我差点笑死.可以称为:是男人就20秒破解了....)
OK书归正传,从最基本的原理开始.
所谓的数据打包其原理大多是将很多数据资源文件,以某种格式储存为一个大型个体的文件.从各种复杂的打包方式中独立出最基本的部分其实就是:用数据流读取原始资源文件,然后把这些数据流按照一定的顺序排列到一个新的大型目标资源文件里面.并且生成一定的标记信息(有时候这个标记信息也是储存在目标文件里面的,看情况而定)
一下是一个简单的例子:
目的是进行一个简单的游戏图片(手机PNG图片)资源的打包(J2SE 1.4.2)
===============
首先是获得目标文件夹的里面所有的文件名,并且计算文件中所有的文件的总大小(为了开辟新的一个大数据包来装这些数据):
[code]
static String[] fileName;
static long total_length = 0;
public static void getDirName(String path) {
    File dd = new File(path);
    fileName = dd.list();
    for (int i = 0; i < fileName.length; i++) {
      File ImageFile = new File(path + "\\" + fileName[i]);
      total_length = total_length + ImageFile.length();
      System.out.println(i + ":" + fileName[i] + "," + ImageFile.length());
    }
    System.out.println("total_length:" + total_length);
}
[/code]
统计了总的容量还有获得了文件名之后,就要开始读取相关的资源数据,然后填充到新的空间里面了
[code]
static byte[] imagesPack;
static int new_total_length;
static int mid_length = 0;
static int[] pic_matrix;
public static void save_Res(String path) {
    pic_matrix = new int[fileName.length * 2];
    imagesPack = new byte[ (int) total_length];
    for (int i = 0; i < fileName.length; i++) {
      pic_matrix[i * 2] = mid_length;
      File ImageFile = new File(path + "\\" + fileName[i]);
      try {
        FileInputStream fo = new FileInputStream(ImageFile);
        for (int j = 0; j < fo.available() << 12; j++) {
          imagesPack[mid_length + j] = (byte) fo.read();
        }
      }
      catch (Exception ex) {
        System.out.println("ikani error");
      }
      pic_matrix[i * 2 + 1]
……
2007-4-9 15:56:00

===

=_=如果谁有保存的话记得copy给我一份...我不想再写一遍了..OTL...

[以前写的]关于手机上图层混合的处理方法

Wed, 18 Apr 2007 17:43:55 GMT

Posted: 2007-01-23 14:13

先看效果

[自己的blog转过来的]关于手机上图层混合的处理方法.
本来自己很少在blog上贴出代码.~_~但是本身从事手机游戏开发这个职业.怎么说也是游戏创作的一种.如果在渔场游戏创作区N年不发帖的话,不免觉得过意不去...所以以后看来时不时发一些东西好了..也算对自己的一种努力的催促.

以前关注过我blog的人应该记得我曾经放出过相关的图..
但是因为当时并没有完全理解所谓的光影层的做法,以及光影层的算法.所以当时也只是按照粗劣的想法构造相关的模型测试一下...效果当然和游戏原作差距很大...
昨晚晚上有人和我提起的时候,我不由的认真起来,在花费了一个晚上的时间之后..(准确的说是5个多小时...到凌晨2点多....)终于破解了这个迷惑了很多人的问题...
准确的说...是因为直观画面的关系,导致的一种误解的想法...因为我首先想到的是半透明...选择性半透明.囧..不过没有想到这样的做法和半透明没有一点关系....原理很减单....就是photoshop里面的2个图层之间上层图层使用颜色减淡的效果而已....也正是这个误解导致了我浪费了3~4个小时的时间..而最后一个小时的时间浪费的原因是因为符号问题.因为运算级的问题忘记加括号了....... 写东西也要细心啊...
基本原理其实就一个共识而已: 结果色=基色+（基色*混合色）/（255-混合色）=__=
如果R,G,B超越FF的话,就强制等于FF...然后就OK了=v=

CODE:

//首先要创建一些东西
int w=176, h=208; //需要创建的图像的宽高
int longth = w * h;
int back_Rgb[] = new int[longth];//背景图片
int light_Rgb[] = new int[longth];//光影图片
int dscRgb[] = new int[longth];//最终生成的目标图片.

//然后就是获取图像数组.获得图片backImg,lightImg的相关数组.
try {
backImg.getRGB(back_Rgb, 0, w, 0, 0, w, h);
lightImg.getRGB(light_Rgb, 0, w, 0, 0, w, h);
}
catch (Exception ex) {
ex.printStackTrace();
}
//下面是混合部分
for (int i = 0; i < longth; i++) {
int R1, R2, G1, G2, B1, B2, RR, GG, BB;
//从把颜色从AARRGGBB(0X00000000~0XFFFFFFFF)中分离出R,G,B独立的颜色参数.都是0~255
//分离back图片的数组的颜色.保存为R1,G1,B1

R1 = (back_Rgb[i] - 0xff000000) >> 16;
G1 = ( (back_Rgb[i] - 0xff000000) - (R1 << 16)) >> 8;
B1 = (back_Rgb[i] - 0xff000000) - (R1 << 16) - (G1 << 8);
//分离light图片的数组的颜色.保存为R2,G2,B2

R2 = (light_Rgb[i] - 0xff000000) >> 16;
G2 = ( (light_Rgb[i] - 0xff000000) - (R2 << 16)) >> 8;
B2 = (light_Rgb[i] - 0xff000000) - (R2 << 16) - (G2 << 8);
//这是对2个颜色的混合处理,根据是颜色减淡的公式:a+ab/(255-b),其中a为基色，b为混合色

RR = R1 + (R1 * R2) / (255 - R2);
GG = G1 + (G1 * G2) / (255 - G2);
BB = B1 + (B1 * B2) / (255 - B2);

//如果数值超出范围,就取最高值255

if (RR >= 255) {
RR = 255;
}
if (GG >= 255) {
GG = 255;
}
if (BB >= 255) {
BB = 255;
}
//把颜色从R,G,B独立的颜色参数转化为AARRGGBB的形式.

dscRgb[i] = (RR << 16) + (GG << 8) + BB + 0xff000000;
}

//进行过上面的相关的步骤后,创建新图片...看看你得到的图片是否和我的一样呢~_~

trueImage = Image.createRGBImage(dscRgb, w, h, true);

有时候感觉GAMELOFT东西确实很不错.但是有时候深究起来的话,的确是我们确实会,但是却思路没有达到.的确如他们中的一个策划所说:对于设计者来说，很多NICE效果的实现都是由一个个点子开始，并经由和美术，程序等多方面的摩擦和碰撞才产生出火花的。
顺便说一下,上面的东西稍微加一下修改(比如把上面东西物块化).就连中国GAMELOFT的开发人员都觉得扯的罗马尼亚GAMELOFT的某游戏的效果...(=___=不能再多说了.否则估计会被GAMELOFT公司的人砍吧..=___=涉嫌堕落了几天动画游戏,用老东西充数赔罪的fish...OTL...)

顺便把相关的一些photoshop中的颜色处理方式用程序来运算的方法写出来好了..(网上找的,也是给我写上面代码理论支持的一些公式
注：a为基色，b为混合色
- Darken（变暗）：min(a, b)
- Lighten（变亮）：max(a, b)
- Multiply（正片叠底）：a * b / 255
- Screen（屏幕）： 255 - (255 - a) * (255 - b) / 255
- Overlay（叠加）：a <= 128 ? a * b / 128 : 255 - (255 - a) * (255 - b) / 128
- Hard Light（强光）：HardLight(a, b) = Overlay(b, a)
- Hard Mix（实色混合）：a + b <= 255 ? 0 : 255
- Difference（差值）：|a - b|
- Exclusion（排除）：a + b - a * b / 128
- Pin Light（点光，针状变亮）：b >= 128 ? max(a, (b - 128) * 2 ) : min(a, b * 2 )
- Linear Burn（线性加深）：a + b > 255 ? (a + b) % 256 : 0
- Linear Dodge（线性减淡）：a + b > 255 ? 255 : a + b
- Color Burn（颜色加深）：a-(255-a)*(255-b/)/b
- Color Dodge（颜色减淡）：a+ab/(255-b)

嘛..其实我想让手机实现泛光效果来模拟HDR的..= =不过最近工作实在是太忙..(其实是自己太懒..),等过些日子再说好了=v=b
-----------------------
P.S:如果是C++或者别的话,有直接有从0x000000这种提取R,G,B三个数值的方法..我这里说的只是针对手机这种连接受限制设备,用J2ME的处理方法而已...

[以前资料备份]看来关于旋转等函数要小心的尽量优化的使用了.

Wed, 18 Apr 2007 17:25:56 GMT

关于drawRegion和drawImage

今天对我现在正在制作的东西进行了一个小测试...测试结果如下...:
drawRegion 运行 13716次- -, 占了60%的cpu时间...
同比发现drawImage.绘画42820次,却占用了CPU时间为20%,
也就是说....相当于:
旋转一个图片再绘画是直接绘画一个图片消耗的CPU 的9倍多.....=口=
看来关于旋转等函数要小心的尽量优化的使用了...

-------------------------------
机器缓冲资源.(现在的做法).

自己再开一个缓冲区用于专门从缓冲区copy局部出来以节约资源,暂时有2种想法:
一种是全屏超出范围的缓冲一次,不再缓冲,然后不停的绘制这张buffer.然后移动时候每移动1~2个格子后再缓冲,描绘..如果不移动的话就不再缓冲.这样的话内存会占用比原来整个画面的大一些.(耗内存,省CPU).
令一种是不到全屏范围的缓冲,这样的话内存会比上面小一些,但是要重复描绘一些东西.(耗CPU,省内存).

本来目的就是为了节省CPU,所以晚上先写第一个方法尝试一下.

2007-1-16 14:38:00

[以前写的]关于J2ME MMAPI的Player接口的一些理解.

Wed, 18 Apr 2007 17:02:41 GMT

关于J2ME MMAPI的Player接口的一些理解.

今天完成了本周的任务,下周要进行游戏分析学习,时不时还会总结一些东西,和以前忽视或者没有注意的东西..希望能够提高巩固自己以前的知识.

关于J2ME MMAPI的Player接口的一些理解.

大多时候使用的Player接口的时候,都是先声明Player,然后用Manager来createPlayer,然后通过用Player接口的start和stop来控制.当然这个是最简单的控制.但是其实真正的状态转化比这个还是要复杂那么一点点的.特别是在一些声音有问题的设备,了解状态的转化能够对排除问题和了解机器的BUG有一定的帮助,特别是在移植的时候经常会碰到声音的问题的.

一个player总共有5个状态,可以说player的状态就是这之间互相转化的.
这五个状态分别是:
UNREALIZED(没有实现), REALIZED(实现), PREFETCHED(缓冲读取), STARTED(播放状态), CLOSED(关闭状态).

首先声明一个Player后,这个player的状态首先是UNREALIZED(没有实现)状态,一般情况下这个时候会先用createPlayer创建这个Player,然后使用realize()方法将这个player的状态转化为REALIZED(实现).

这个时候其实已经可以播放了,但是这个时候播放的话,在播放刚启动的时候或多或少会出现的问题就是刚开始的时候会卡一下(读取音乐资源的IO操作的后果),因此这个时候最好能够让Player进入PREFETCHED(缓冲读取)的状态,这样无论在什么时候播放的话,中间的卡的停顿感就会消失.

这样的话,可以说一个Player在播放之前已经准备完毕了.这个时候就能够随时播放了(或者说随时可以进入STARTED(播放状态)了),这时候随时播放任何邪恶的触手的声音都没有问题.-_-特别是一些特殊的游戏对音效和音乐要求的播放时间的精准度比较高的,最好都要PREFETCHED(缓冲读取)的状态比较好.
还有就是所谓的stop的使用,其实是返回PREFETCHED(缓冲读取)的状态,因此并没有所谓的STOPPED的状态(这个名词的确念起来很顺口).一般如果播放完毕后会自动回到PREFETCHED(缓冲读取)的状态.
关于关闭方面其实我想说的是,很多人关闭音乐都要有一个所谓的顺序之类的,其实没有必要,无论处于怎样的状态(除了CLOSED本身),只要运行close()就能够直接返回CLOSED状态的.其他的很多行为本身是不需要的,不过返回了CLOSED状态本身就是相当于这个Player已经关闭了.不能再进行任何别的使用操作了.如果还需要的话,重新创建一个吧.

可能这样说有点笼统,也许划线的话更好理解就是了

UNREALIZED(没有实现)----->REALIZED(实现)----->PREFETCHED(缓冲读取)----->STARTED(播放状态)
realize() prefetch() start()

STARTED(播放状态)----->PREFETCHED(缓冲读取)-----REALIZED(实现)----->UNREALIZED(没有实现)
stop() deallocate()

以上4个状态随时都可以用close()返回到CLOSED状态.

不过......以上只是理想状态的状态转化而已..有些机型还是有一些问题的,之所以想写这个的原因就是可以利用这个原理来从中分析问题的出处,比如上周碰到的一款国外产品的6230I的移植的问题(208*208屏幕的一款机型),在setLoopCount(-1)的情况下,当曲目播放第一遍的时候,状态转化都很正常,当播放第二遍以上的话,即使使用stop()将状态转化为PREFETCHED(缓冲读取)背景也会在播放的.然后就只能针对这样的问题进行修改了.

2007-3-30 14:12:00 by fishfray

这里存放的是自己的知识积累.

Wed, 18 Apr 2007 16:30:24 GMT

和以前的blog一样.这里存放关于一些知识点和自己的感想.虽然以前的很多文章丢失了.但是我相信我以后写出来的东西能够帮助更多的人.