這個是 同事 給我的外國得相關的資料
http://www.flashxpress.net/ressources-flash/dopez-votre-framerate-avec-les-classes-animatedbitmap-et-animatedbitmapdata/
http://www.bytearray.org/?p=117
基本上這種做法 叫 香蕉片 ( Banana Slice)
因為香蕉片的 原始碼 我沒找到(所以下面講的香蕉片都是指第一個網址)
不過基本理念(作法)應該和我的做法是一樣的
利用 draw 去繪製 MC 成 bitmapdata
用來取代一些複雜而且多特效(濾鏡.遮罩 大小改變..等等) 的 MC
相關的應該不用介紹了~~ 不過還是簡單的複習一下
先講我看過 第一個網址的東西後 我的是如何改良
香蕉片板
1. 是分成兩段 一段是將MC 產生對應影格數的 bitmapdata
2. 在利用另外一組去將它顯示到場景上
他的做法和我的做法在某種程度上 不謀而合
都會把定時呼叫的東西 拆出來 可以另外的設定
在經過了這樣久之後 再次看到類似作法的人
終於有不孤單的感覺...
不過我發現他有一些繪圖是在做白工!
不過也許是因為他預先一格內畫好全部的關係
所以必須再多繪一次元件上的濾鏡
就我自己的測試 但是不管是程式加的 還是原本元件上有的
只要用 draw 畫下來 基本上都包含了該元件的濾鏡效果
不會有效果的目前發現的有
blendMode
角度 大小
除了 blendMode 相關的處理 都可以參考第一個的 CODE
不過我自己是很猶豫一點!因為是對應 MC 上的角度 和 scale 的屬性!
說不定有一些操作還是會用到
這樣會被 這個 吃掉 可能會造成一些問題!!
我自己得會將原本的 MC 留著 (因為要留著一直去 draw)
所以一些屬性改變的問題 還是會找到原本的 MC 上!
但是香蕉片版卻不會!! 這一點使用上要小心
blendMode 在FLASH 提供的函數就能解決
但問題是 你要將一個 bitmapdata分成超多小區塊~~去處理~
而且大小 形狀 等等的都必須 設定的精準一點才可能
所以這部分是說真的十分得麻煩
目前我沒有好的處理方式! 而且香蕉片的也不處理這一塊
所以我就....先跳過
再來說說效能的部分
我的版本每回合去 draw 大約 800 * 600 左右的大小的 bitmapdata 在 FPS 是 24
CPU 都是在 14~20 左右
但是使用香蕉片的方式 大約是 5~7 左右的 CPU 消耗!!
這樣關鍵的差距 就是在每一格都畫 和 是用已經存好的bitmapdata 間的差距
因為他的 CPU 消耗真得很省 所以我也弄了一個 我的 香蕉片 以下我都簡稱我的香蕉片
唯一作的改良是 原本一格將全部的 MC 畫出 bitmapdata 的部分
改成 每一格都畫 直到全部影格都畫好為止 就會跳去 純粹使用 bitmapdata
而且 整個是 static 的!!! 共用一個主體 一個計時器 !!!
好講幾個關鍵的重點!!
1. 存 bitmapdata 的部分 記得使用 clone 小小的卡了一下
2. 存幾張 bitmapdata 的部分 最好可以手動設定!! 不要自動抓 MC 的影格長度
3. 不要將全部的圖片合成一張 這樣會浪費相當多的 記憶體.....
分開來會比較好一點 不過這個也是要看情況
先就第三點 說一下
本來我有一個設定 可以把在一起的 MC 一起畫
本來每格畫 這個事情就很簡單 也沒問題
但是變成要使用預先畫好的 bitmapdata 時 變成要計算 一起畫的影格的最小公倍數!!
而且存圖區域變成 兩個區域的聯集區域
這一塊一整個麻煩~ 以我遇到的情況 100格對 170格....
原始MC板 記憶體約 36mb
使用香蕉片板 約 19x
使用我的香蕉片板 瞬間突破 270 我就果斷停止了
所以還是分開存會比較省 這個是我最近使用上遇到的情況
我又把那個一起畫的功能拿掉了......
話說這個功能多災多難 我前前後後 大概拿掉了三四次了
2012年8月29日 星期三
2012年7月19日 星期四
[AS3] 處理 重繪區域比顯示區域大的一些方法 II
基本上是上一篇的延續 !
應該有很多人都做過 閃電 的那種動畫!
假設 閃電的動畫的內容是不一樣的 但是閃電的動作是一樣的 ?
如何動態的操作 可以避免掉一些顯示的問題!
如下圖 :
如果像圖這樣 會出現 使一開始要出現的圖樣 是第一格的圖樣 !
我想解法很多種~
我以前會把 第一格空下來
然後聽 add 事件 有就直接換 影格
這樣可以避免一開始瞬間的錯誤
假設 這個使用上一篇 處理 重繪區域比顯示區域大 的方法
以這個案例來說 使用上一篇的方法 會使效能變差 和 消耗的記憶體增加
基本上是一點用都沒有 !
我純粹只是想測這種方法的能不能解這個問題 !
下面是 這個的範例 CODE 和 各種 計時器 間 會出現的差異 !
範例如下!
警告 這個範例會不斷閃爍
如果有某些疾病的人請不要打開...
DEMO
===============================================================
題外話
其實 我的計時器 和 上一篇的 繪圖的這種
嚴格講 應該分成兩種體系
一種是 static 的
一種是 CODE 這種的
一個程式中 會需要到兩種嗎 ?
本來我用靜態版的弄了範例~~
結果我沒辦法同時做出 四種 都同時的擺在一起
所以最後又改成現在的這種版本....
也許某些情況會需要 使用到兩種不同的計時器
不過是否真的需要全局統一 ?
還有本來看到最近新出的 worker
最一開始想把它當成 另外一種計時器 去跑的~
或者 能把它整合進 計時器 中!
只要 開某種計時器 那把這個記時器相關的運算都由某個 worker 去執行
或者說 把整個系列的運算獨立出來 總之這邊還在嘗試~
感覺上不是沒希望! 不過 我可能要把整個 計時器 都大改寫
利用事件的方式 似乎是不可能的~~
應該有很多人都做過 閃電 的那種動畫!
假設 閃電的動畫的內容是不一樣的 但是閃電的動作是一樣的 ?
如何動態的操作 可以避免掉一些顯示的問題!
如下圖 :
如果像圖這樣 會出現 使一開始要出現的圖樣 是第一格的圖樣 !
我想解法很多種~
我以前會把 第一格空下來
然後聽 add 事件 有就直接換 影格
這樣可以避免一開始瞬間的錯誤
假設 這個使用上一篇 處理 重繪區域比顯示區域大 的方法
以這個案例來說 使用上一篇的方法 會使效能變差 和 消耗的記憶體增加
基本上是一點用都沒有 !
我純粹只是想測這種方法的能不能解這個問題 !
下面是 這個的範例 CODE 和 各種 計時器 間 會出現的差異 !
範例如下!
警告 這個範例會不斷閃爍
如果有某些疾病的人請不要打開...
DEMO
===============================================================
題外話
其實 我的計時器 和 上一篇的 繪圖的這種
嚴格講 應該分成兩種體系
一種是 static 的
一種是 CODE 這種的
一個程式中 會需要到兩種嗎 ?
本來我用靜態版的弄了範例~~
結果我沒辦法同時做出 四種 都同時的擺在一起
所以最後又改成現在的這種版本....
也許某些情況會需要 使用到兩種不同的計時器
不過是否真的需要全局統一 ?
還有本來看到最近新出的 worker
最一開始想把它當成 另外一種計時器 去跑的~
或者 能把它整合進 計時器 中!
只要 開某種計時器 那把這個記時器相關的運算都由某個 worker 去執行
或者說 把整個系列的運算獨立出來 總之這邊還在嘗試~
感覺上不是沒希望! 不過 我可能要把整個 計時器 都大改寫
利用事件的方式 似乎是不可能的~~
2012年7月10日 星期二
[AS3] 處理 重繪區域比顯示區域大的一些方法
我想有處理過一些閃光字的人一定會發現這個問題
就是閃光字明明很小但是他的重繪範圍比較大
想看這個比較好的效果的可以到 閃光字 這看
如果有 DEBUG版的 player 的話可以開啟 重繪範圍看看
我來介紹一下我知道解決這個問題的幾個方法!
1.
從結構面去解決
只要有作移動補間動畫是在 遮罩的圖層上的
不是被遮圖層上 如下圖
那最簡單的解法
就是 把整個遮罩物件(遮罩 和 被遮的物件 一整組設成 快取點陣圖)
如下圖
那這樣他的補間動畫就會是
不過有得時候
因為某些複雜的表現
沒辦法把 補間動畫作在 遮罩區
那下一種程式面的方法就可以解決
2.
使用 mc.scrollRect 屬性
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/DisplayObject.html#scrollRect
不過在我的測試下 好像是沒用的....
也許這個也有一些 我不知道的限制....
但是在另外的測試 下是有用的
效果會和你 限制的區域一樣大!
不過這邊我沒去深究! 就把它當成是一種解法
我有測到一個限制~
就是這個物件 要設 快取成點陣圖 後才有用
以我這個範例來說 也是設了就有用了
沒設 就會和這個圖一樣
不過可能 還有一些其他的因素 例如 player 的版本 等等的
總之...我覺得第三個方法 我比較喜歡 所以我也沒深究了
3.
最後這個是一個簡單的想法
利用 顯示物件沒有貼在場景上
但是依然存在 而且可以被繪圖這一點!
然後 重繪的區域就會是你繪圖的區域
下面是這個簡單的想法的 CODE
有興趣的可以看一下
package
{
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.display.MovieClip;
import flash.display.Sprite;
import flash.events.Event;
import flash.geom.Rectangle;
import ui.logo;
public class MovieClipToBitmapDemo extends Sprite
{
private var _mc:MovieClip;
private var _bmd:BitmapData;
private var _bm:Bitmap;
private var _rect:Rectangle;
public function MovieClipToBitmapDemo()
{
_mc = new logo();
this.addEventListener(Event.ENTER_FRAME, onEnterFrameFun);
_rect = new Rectangle(0,0,109,78);
_bmd = new BitmapData(109, 78, true, 0);
_bm = new Bitmap();
_bm.smoothing = true;
this.addChild(_bm);
draw();
}
private function onEnterFrameFun(e:Event):void
{
draw();
}
private function draw():void
{
_bmd.fillRect(_rect, 0);
_bmd.draw(_mc,null,null,null,_rect,true);
_bm.bitmapData = _bmd;
}
}
}
希望可以幫到一些人
然後再補充一點
就是如果這個被重繪的圖
裡面有很複雜
而且 有多重的濾鏡 遮罩 互相影響!
那重繪這個動作
可以幫你節省一些效能
但是 記憶體就會略多了 !
2012年7月9日 星期一
[AS3][迷宮]簡單的迷宮建立 2
這篇是上一篇的延續~~
上一篇是產生 迷宮的路徑!
這一篇是 迷宮的貼圖
基本的想法是~
把 迷宮的生成 和 貼圖 的部分切開!
這樣以後要換
貼圖得方式 (像下面的講的 兩種圖源)
作法 (連在一起的路是否貼成房間? 房間是 否有出入口? 是否是 1:1 的貼圖方式? )
產生的大小~(一次貼出整個 迷宮大小? 還是按照指定的座標只貼周圍大小)
等等
都比較方便!
先來講解一下!
貼圖的基本
一個基本的 平面迷宮!
以路來看一格內 牆的形狀 只有 16種!
如下圖
處理的方式有好幾種!
最簡單的方法利用處理圖的方式 去做一張專用的!
不過這個方式太麻煩(對我來說)
因為我的用法是使用 bitmapdata 的資料去貼!
基本上 5~12 還有 0 15 可以簡單的按照圖的大小就抓到資料
可以利用這些資料去產生缺少的那部分
以1 的做法就 5 的一半 貼 8的一半
13 是 9 一半 貼 11的一半
其他的也都是類似的作法 一半貼一半!
(不過以上都是 來源圖的處理方式)
然後基本的 0~15 十六種的圖就齊了
才進我的貼圖程式!
基本上我上一篇生出的 迷宮結果
會有下面這一些的資訊
(x=0, y=0),(x=1, y=0),(x=1, y=1),(x=0, y=1),(x=0, y=2),(x=1, y=2),(x=2, y=2),(x=2, y=3),(x=2, y=4),(x=1, y=4),(x=1, y=3),(x=0, y=3),(x=0, y=4),(x=0, y=5),(x=1, y=5),(x=2, y=5),(x=3, y=5),(x=3, y=4),(x=4, y=4),(x=5, y=4),(x=5, y=3),(x=6, y=3),(x=7, y=3),(x=7, y=2),(x=6, y=2),(x=5, y=2),(x=5, y=1),(x=5, y=0),(x=4, y=0),(x=3, y=0),(x=3, y=1),(x=2, y=1)
一共 9條路
我的 way 的矩陣 第 1 組是 通路! 也就是從起點到 終點的路!
簡單的講就是 way[0][0] 是起點!
way[0][way[0].length-1] 這一點就是終點!
這張圖是處理這個的結果圖
因為只有這樣的資訊!
事實上是無法一次就貼出地圖的!
必須再貼圖的時候再掃一次全部的路
因為在迷宮生成的時候做
也沒辦法免除這一次的掃描!
所以我就合併在這邊做
讓生成迷宮時要處理的事簡化 (結果這一篇就超複雜 orz)
講一下這邊的邏輯
首先把路的矩陣拿出來!
如果有上一點
把現在這一點和上一點連接的牆打掉.
如果沒有上一點!
找上一條路 和這個 點連接的 牆 打掉
如果沒有上一條路
找附近接鄰的點 把牆打掉
按照這個邏輯 就可以把全部的路 都用 0 ~ 15 的地圖資訊 都生出來~~
下面是按照上面例子的第一條路的一小段作的圖
1.
一開始的 0,0 因為沒有上一條路 也沒附近接鄰的點
所以 就會記成 0
2.
第二個點 (1,0) ,按規則 上一個點 (0,0) 所以打開兩個點中的牆
第一個點(0,0)記作 2
第二個點(1,0)記作 4
3.
第三個點 (1,1), 上一個點 (1,0) 所以打開中間的圖
第二個點(1,0)記作 7
第三個點(1,1)記作 1
4.
第四個點 (0,1) 上一個點 (1,1) 所以在打開中間的牆
第三個點(1,1)記作 8
第四個點(0,1)記作 2
5.
因為這邊太繁瑣~所以我就一次把這條路作完!
6.
下一條路!
(x=3, y=2) 因為沒有上一點!
所以上一條路! 找到點 (2,2), (3,1)
恩 就看各人寫法 是先找到先用! 還是隨機選一點!
我是隨機選一點 看他生成的圖 來解釋 是使用 (2,2) 這一個!
所以
把 (2,2) 記作 10
把 (3,2) 記作 4
好了比較有代表性的部分 作完 剩下的就是依照一樣的方法~
就會生出貼圖所需的資訊了
圖如下
把全部的路 作完!
那就可以按照順序去貼圖了!!
然後我來講一下! 其實上面都是 我以前的做法!
這次重寫的時候 覺得這樣不確定性 太高!!
還要多花一次工 去掃上一條路!
所以打算修改
最先就是直接 拉到生成迷宮的裡面
因為有一些路 會改變 所以不能直接放在生成!!
不然交互影響後 在改變會有問題
簡單的講就是 生的時候 就把牆打掉
但是我卻沒辦法補回來
不然就是在放棄時 要多一堆迴圈去補回來
這段我沒實作 因為光想就覺得麻煩
必須要路生出來之後 確定後 再做上這一段!
所以拉進去 的效率 和 在這邊的效率
或是說迴圈的次數 其實是一樣的!
並不如我所想可以少好幾圈 ( 這應該就是當初會把這段放這邊的原因)
後來就又改回原來的方式! 也就是上面講的
不過 我後來有一個以記憶體換的方式~
就是 路第一個點 是上一條路的進入點!
以上面的例子來說! 第二條路的矩陣會變成下面這樣
(x=2,y=2),(x=3, y=2),(x=4, y=2),(x=4, y=1)
這樣
就不會有 沒有上一點的情況!
但是 記的從 第二個點 開始!
因為第一個點是上一條路的點
光這一點 就可以省下 一次迴圈 好幾次判斷!
上一篇有講到可以把路貼成房間!
因為房間的部份我也是在上面那一段作掉
但是這段的CODE 可能被我不小心當成註解拿掉了
先定義一下房間
就是 除了出口 或 入口外
都是 中間是可以通行 沒有牆的路
從現在的點往前找 連續點
所以U 字型 中間的 點是不可能被當成房間的!
如圖
2, 3 , 6, 7
1, 2, 7, 8
1,2,3,6,7,8
這三個組合是不可能是 房間!
因為點沒有連在一起!
如果可以組成 設定大小的房間的話
就檢查 附近是否有 路的開頭(檢查所有路的第一格)
如果沒有就設定成房間!
因為這個做法~不確定性太高
所以有了下面這一段
在最一開始生成路之前!
先產生對應得房間
這樣在生成主要道路的時候
還會自己避過房間
然後利用上一篇 連接兩點的函式
把有開口的房間 (房間 出口或入口)
和路的隨機一格連接起來
最後要把房間的格子補進去
講一下這邊的重點!
最後才補房間這點
因為房間不在路上!!
所以他不會被當成 生出路的點!
因為我的方式都是從路生路
所以房間的附近都不會是路的開頭
但是 在 地圖上 這些點 都不是 牆 所以會被避開!
又因為是一起補 所以都是連在一起!
剛好符合之前的定義 ! (其實是精心策畫的剛好 orz)
貼房間地形的圖這部分~
其實方法很笨
但也是為了讓人自己設計的房間可以完整的貼上去~
所以這部分 讓人可以自己設定 貼圖的編號 事件等等
不過這邊的貼圖也是 符合 0 ~ 15 的那個規則
是形狀要符合 0~15的規則 但是裡面的花樣可以不同
總結一下
這一篇產生的是貼圖的二維矩陣!
基本上 路的部分都是 0~15 這 16種
混進房間後 因為房間的特殊貼圖 才有 16以上的數字
還會有一個矩陣是放 單格事件
等這個矩陣進來之後
整合 控制
整合 事件的處理
才會是 真正可以玩的地圖
所以總共會有
1. 上一篇的 路的矩陣
2. 這一篇產生的 貼圖的矩陣 (沒有房間的話是從 0~15 有的話會有 16以上的號碼)
3. 還有一個是 對應位置 的 事件矩陣 (理論上是三維 因為一格 可以發生的事件也是 一個矩陣)
好像還有一段我忘了講 就 不是 1:1 貼圖的這段
主要是作再傳入的貼圖矩陣這邊
以 1 號 U 字型的這種
當然可以以一格 用 一半貼一半的方式去處理掉
但是也可以是
0, 15, 0
0, 15, 0
0, 0, 0
這樣 九格 貼成一格的方式!
然後這一篇理論上會有三種
輸出的畫面
第一種
就是一次生成全部的地圖
像上一篇的 DEMO 一樣
大部分的用途都是用來生成小地圖
第二種
就是經過一點優化
只生成所在點周圍固定格數的地圖!
第三種
我自己是在
http://wonderfl.net/c/dxgc
http://wonderfl.net/c/lpY3
這裡看到這種! 超炫
所以第三種的部分 我應該是在學習這種版本
不過還沒有完成
但是CODE混進上面的那段中了
然後在這次看CODE中我又改了幾個地方
本來我以為我把 房間的部分完全從 上面那段拆掉了
所以把本來註解掉的房間那段全刪了
後來這篇寫到一半才發現原來沒有
原來註解掉的部分只是為了簡單化問題
好處理第三種狀況 不過發現的時候已經太晚了
然後這次寫BLOG一邊寫
又一邊優化一些地方
簡單的講 不管是 哪一種輸出的方式
都會有 兩個二維矩陣 和 整個地圖是一樣大
還會有一個和地圖一樣大的二維矩陣 是放該位置 會發生的 事件矩陣
因為一個位置 可能會有多種事件
這次我把整個貼事件的部分 大改(順便在一次回憶一下 順便為下一篇作準備)
不再是 查詢和地圖一樣大的二維矩陣
而是拿出 從貼圖矩陣中 對應圖形的 事件矩陣
記錄發生和改變 ! 這樣維護的矩陣會小很多
其實只要像上一篇一樣 拆出來重做一次~
就可以 DEMO了 不過這部分 好像越改離我越遠
又有一些我覺得很有趣 的東東
這篇想結束 結束不了 我也覺得很糟糕....
總之先這樣結束 orz
CODE的部分 我改好再貼上來
上一篇是產生 迷宮的路徑!
這一篇是 迷宮的貼圖
基本的想法是~
把 迷宮的生成 和 貼圖 的部分切開!
這樣以後要換
貼圖得方式 (像下面的講的 兩種圖源)
作法 (連在一起的路是否貼成房間? 房間是 否有出入口? 是否是 1:1 的貼圖方式? )
產生的大小~(一次貼出整個 迷宮大小? 還是按照指定的座標只貼周圍大小)
等等
都比較方便!
先來講解一下!
貼圖的基本
一個基本的 平面迷宮!
以路來看一格內 牆的形狀 只有 16種!
如下圖
最下面的是 一般 RPG 製作大師的素材圖!
基本上包含了 5~12 還有 0 15
但是缺了 1 2 3 4 和 13 14這幾種類型!
因為我和 RPG 製作大師的 貼圖方式不同~
所以我不會用到 四點的那種圖(一組圖的最右上 不過有時要貼柱子時 好像還是會用到...)
但是要變成我可以使用的圖要經過處理處理的方式有好幾種!
最簡單的方法利用處理圖的方式 去做一張專用的!
不過這個方式太麻煩(對我來說)
因為我的用法是使用 bitmapdata 的資料去貼!
基本上 5~12 還有 0 15 可以簡單的按照圖的大小就抓到資料
可以利用這些資料去產生缺少的那部分
以1 的做法就 5 的一半 貼 8的一半
13 是 9 一半 貼 11的一半
其他的也都是類似的作法 一半貼一半!
(不過以上都是 來源圖的處理方式)
然後基本的 0~15 十六種的圖就齊了
才進我的貼圖程式!
基本上我上一篇生出的 迷宮結果
會有下面這一些的資訊
(x=0, y=0),(x=1, y=0),(x=1, y=1),(x=0, y=1),(x=0, y=2),(x=1, y=2),(x=2, y=2),(x=2, y=3),(x=2, y=4),(x=1, y=4),(x=1, y=3),(x=0, y=3),(x=0, y=4),(x=0, y=5),(x=1, y=5),(x=2, y=5),(x=3, y=5),(x=3, y=4),(x=4, y=4),(x=5, y=4),(x=5, y=3),(x=6, y=3),(x=7, y=3),(x=7, y=2),(x=6, y=2),(x=5, y=2),(x=5, y=1),(x=5, y=0),(x=4, y=0),(x=3, y=0),(x=3, y=1),(x=2, y=1)
(x=3, y=2),(x=4, y=2),(x=4, y=1)
(x=1, y=6),(x=1, y=7),(x=2, y=7),(x=2, y=6),(x=3, y=6),(x=4, y=6),(x=5, y=6),(x=5, y=5),(x=6, y=5),(x=6, y=6),(x=7, y=6),(x=7, y=7),(x=6, y=7),(x=5, y=7),(x=4, y=7),(x=3, y=7)
(x=2, y=0)
(x=6, y=1),(x=6, y=0),(x=7, y=0),(x=7, y=1)
(x=4, y=5)
(x=3, y=3),(x=4, y=3)
(x=0, y=6),(x=0, y=7)
(x=6, y=4),(x=7, y=4),(x=7, y=5)
一共 9條路
我的 way 的矩陣 第 1 組是 通路! 也就是從起點到 終點的路!
簡單的講就是 way[0][0] 是起點!
way[0][way[0].length-1] 這一點就是終點!
這張圖是處理這個的結果圖
因為只有這樣的資訊!
事實上是無法一次就貼出地圖的!
必須再貼圖的時候再掃一次全部的路
因為在迷宮生成的時候做
也沒辦法免除這一次的掃描!
所以我就合併在這邊做
讓生成迷宮時要處理的事簡化 (結果這一篇就超複雜 orz)
講一下這邊的邏輯
首先把路的矩陣拿出來!
如果有上一點
把現在這一點和上一點連接的牆打掉.
如果沒有上一點!
找上一條路 和這個 點連接的 牆 打掉
如果沒有上一條路
找附近接鄰的點 把牆打掉
按照這個邏輯 就可以把全部的路 都用 0 ~ 15 的地圖資訊 都生出來~~
下面是按照上面例子的第一條路的一小段作的圖
1.
一開始的 0,0 因為沒有上一條路 也沒附近接鄰的點
所以 就會記成 0
2.
第二個點 (1,0) ,按規則 上一個點 (0,0) 所以打開兩個點中的牆
第一個點(0,0)記作 2
第二個點(1,0)記作 4
3.
第三個點 (1,1), 上一個點 (1,0) 所以打開中間的圖
第二個點(1,0)記作 7
第三個點(1,1)記作 1
4.
第四個點 (0,1) 上一個點 (1,1) 所以在打開中間的牆
第三個點(1,1)記作 8
第四個點(0,1)記作 2
5.
因為這邊太繁瑣~所以我就一次把這條路作完!
6.
下一條路!
(x=3, y=2) 因為沒有上一點!
所以上一條路! 找到點 (2,2), (3,1)
恩 就看各人寫法 是先找到先用! 還是隨機選一點!
我是隨機選一點 看他生成的圖 來解釋 是使用 (2,2) 這一個!
所以
把 (2,2) 記作 10
把 (3,2) 記作 4
好了比較有代表性的部分 作完 剩下的就是依照一樣的方法~
就會生出貼圖所需的資訊了
圖如下
把全部的路 作完!
那就可以按照順序去貼圖了!!
然後我來講一下! 其實上面都是 我以前的做法!
這次重寫的時候 覺得這樣不確定性 太高!!
還要多花一次工 去掃上一條路!
所以打算修改
最先就是直接 拉到生成迷宮的裡面
因為有一些路 會改變 所以不能直接放在生成!!
不然交互影響後 在改變會有問題
簡單的講就是 生的時候 就把牆打掉
但是我卻沒辦法補回來
不然就是在放棄時 要多一堆迴圈去補回來
這段我沒實作 因為光想就覺得麻煩
必須要路生出來之後 確定後 再做上這一段!
所以拉進去 的效率 和 在這邊的效率
或是說迴圈的次數 其實是一樣的!
並不如我所想可以少好幾圈 ( 這應該就是當初會把這段放這邊的原因)
後來就又改回原來的方式! 也就是上面講的
不過 我後來有一個以記憶體換的方式~
就是 路第一個點 是上一條路的進入點!
以上面的例子來說! 第二條路的矩陣會變成下面這樣
(x=2,y=2),(x=3, y=2),(x=4, y=2),(x=4, y=1)
這樣
就不會有 沒有上一點的情況!
但是 記的從 第二個點 開始!
因為第一個點是上一條路的點
光這一點 就可以省下 一次迴圈 好幾次判斷!
上一篇有講到可以把路貼成房間!
因為房間的部份我也是在上面那一段作掉
但是這段的CODE 可能被我不小心當成註解拿掉了
先定義一下房間
就是 除了出口 或 入口外
都是 中間是可以通行 沒有牆的路
從現在的點往前找 連續點
所以U 字型 中間的 點是不可能被當成房間的!
如圖
2, 3 , 6, 7
1, 2, 7, 8
1,2,3,6,7,8
這三個組合是不可能是 房間!
因為點沒有連在一起!
如果可以組成 設定大小的房間的話
就檢查 附近是否有 路的開頭(檢查所有路的第一格)
如果沒有就設定成房間!
因為這個做法~不確定性太高
所以有了下面這一段
在最一開始生成路之前!
先產生對應得房間
這樣在生成主要道路的時候
還會自己避過房間
然後利用上一篇 連接兩點的函式
把有開口的房間 (房間 出口或入口)
和路的隨機一格連接起來
最後要把房間的格子補進去
講一下這邊的重點!
最後才補房間這點
因為房間不在路上!!
所以他不會被當成 生出路的點!
因為我的方式都是從路生路
所以房間的附近都不會是路的開頭
但是 在 地圖上 這些點 都不是 牆 所以會被避開!
又因為是一起補 所以都是連在一起!
剛好符合之前的定義 ! (其實是精心策畫的剛好 orz)
貼房間地形的圖這部分~
其實方法很笨
但也是為了讓人自己設計的房間可以完整的貼上去~
所以這部分 讓人可以自己設定 貼圖的編號 事件等等
不過這邊的貼圖也是 符合 0 ~ 15 的那個規則
是形狀要符合 0~15的規則 但是裡面的花樣可以不同
總結一下
這一篇產生的是貼圖的二維矩陣!
基本上 路的部分都是 0~15 這 16種
混進房間後 因為房間的特殊貼圖 才有 16以上的數字
還會有一個矩陣是放 單格事件
等這個矩陣進來之後
整合 控制
整合 事件的處理
才會是 真正可以玩的地圖
所以總共會有
1. 上一篇的 路的矩陣
2. 這一篇產生的 貼圖的矩陣 (沒有房間的話是從 0~15 有的話會有 16以上的號碼)
3. 還有一個是 對應位置 的 事件矩陣 (理論上是三維 因為一格 可以發生的事件也是 一個矩陣)
好像還有一段我忘了講 就 不是 1:1 貼圖的這段
主要是作再傳入的貼圖矩陣這邊
以 1 號 U 字型的這種
當然可以以一格 用 一半貼一半的方式去處理掉
但是也可以是
0, 15, 0
0, 15, 0
0, 0, 0
這樣 九格 貼成一格的方式!
然後這一篇理論上會有三種
輸出的畫面
第一種
就是一次生成全部的地圖
像上一篇的 DEMO 一樣
大部分的用途都是用來生成小地圖
第二種
就是經過一點優化
只生成所在點周圍固定格數的地圖!
第三種
我自己是在
http://wonderfl.net/c/dxgc
http://wonderfl.net/c/lpY3
這裡看到這種! 超炫
所以第三種的部分 我應該是在學習這種版本
不過還沒有完成
但是CODE混進上面的那段中了
然後在這次看CODE中我又改了幾個地方
本來我以為我把 房間的部分完全從 上面那段拆掉了
所以把本來註解掉的房間那段全刪了
後來這篇寫到一半才發現原來沒有
原來註解掉的部分只是為了簡單化問題
好處理第三種狀況 不過發現的時候已經太晚了
然後這次寫BLOG一邊寫
又一邊優化一些地方
簡單的講 不管是 哪一種輸出的方式
都會有 兩個二維矩陣 和 整個地圖是一樣大
還會有一個和地圖一樣大的二維矩陣 是放該位置 會發生的 事件矩陣
因為一個位置 可能會有多種事件
這次我把整個貼事件的部分 大改(順便在一次回憶一下 順便為下一篇作準備)
不再是 查詢和地圖一樣大的二維矩陣
而是拿出 從貼圖矩陣中 對應圖形的 事件矩陣
記錄發生和改變 ! 這樣維護的矩陣會小很多
其實只要像上一篇一樣 拆出來重做一次~
就可以 DEMO了 不過這部分 好像越改離我越遠
又有一些我覺得很有趣 的東東
這篇想結束 結束不了 我也覺得很糟糕....
總之先這樣結束 orz
CODE的部分 我改好再貼上來
2012年7月3日 星期二
[AS3][Box2D] 一個簡單的範例
這是一個很有趣的遊戲!
有趣的BOX2D的遊戲!
以後再來專篇介紹他~
下面是一個類似功能的一些簡單範例
簡單的範例
基本的操作 就是上下左右 四個方向鍵
上是加速
下是減速
前後 是轉角度
每台車有自己的速度上限 轉角度的速度 加速的速度 等等 的個別屬性
都有自己的 AI 轉向 讓自己不倒地的部分 加速的邏輯
下方的曲面地圖會隨機的 產生
右上方會有一個簡單的 小地圖
還可以看到其他車 目前所在的位置~~
不過真正的遊戲要判斷 四腳朝天 就會結束
到終點也會結束
但這個範例沒弄...
話說 BLOG 是不是這樣寫比較簡單.
有趣的BOX2D的遊戲!
以後再來專篇介紹他~
下面是一個類似功能的一些簡單範例
簡單的範例
基本的操作 就是上下左右 四個方向鍵
上是加速
下是減速
前後 是轉角度
每台車有自己的速度上限 轉角度的速度 加速的速度 等等 的個別屬性
都有自己的 AI 轉向 讓自己不倒地的部分 加速的邏輯
下方的曲面地圖會隨機的 產生
右上方會有一個簡單的 小地圖
還可以看到其他車 目前所在的位置~~
不過真正的遊戲要判斷 四腳朝天 就會結束
到終點也會結束
但這個範例沒弄...
話說 BLOG 是不是這樣寫比較簡單.
2012年6月28日 星期四
[AS3][Sound]Sound相關的一些測試
其實是之前遇到的一個問題~~
就是 sound 輪播得時候 會有小中斷的感覺!
這個問題有兩個層面!
第一個
就是 sound 檔本身的處理的問題
Ticore大大寫的這篇 解決 Mp3 循環音效停頓的問題
可以解決這個問題
第二個
就是使用 sound.play()
然後聽他的 complete 的事件
然後再一次的使用 sound.play() 去播放
通常這樣的都是為了準確的了解這個聲音是否 結束了沒有!
我自己的聲音播放的類別也是這樣做~
不過聽說使用 sound.play(0, 次數)
卻不會有 斷音的問題
所以我就寫了測試程式測試~
//
//
用上面的程式測試! 會發現有下面的 trace
//
soCompChannel lp : 0 rp: 0
soLoopChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
//
就是 sound 輪播得時候 會有小中斷的感覺!
這個問題有兩個層面!
第一個
就是 sound 檔本身的處理的問題
Ticore大大寫的這篇 解決 Mp3 循環音效停頓的問題
可以解決這個問題
第二個
就是使用 sound.play()
然後聽他的 complete 的事件
然後再一次的使用 sound.play() 去播放
通常這樣的都是為了準確的了解這個聲音是否 結束了沒有!
我自己的聲音播放的類別也是這樣做~
不過聽說使用 sound.play(0, 次數)
卻不會有 斷音的問題
所以我就寫了測試程式測試~
//
package demo
{
import flash.display.Sprite;
import flash.events.Event;
import flash.events.ProgressEvent;
import flash.media.Sound;
import flash.media.SoundChannel;
import flash.net.URLRequest;
import ui.sound;
public class soundDemo extends Sprite
{
private var soComp:Sound;
private var soCompChannel:SoundChannel;
//
private var soLoop:Sound;
private var soLoopChannel:SoundChannel;
public function soundDemo()
{
super();
soComp = new sound();
soCompChannel = soComp.play();
soCompChannel.addEventListener(Event.SOUND_COMPLETE, onSoundCompleteFun);
soLoop = new sound();
soLoopChannel = soLoop.play(0, int.MAX_VALUE);
soLoopChannel.addEventListener(Event.SOUND_COMPLETE, onSoundCompleteFun);
this.addEventListener(Event.ENTER_FRAME, onEnterFrameFun);
}
private function onSoundCompleteFun(e:Event):void
{
soCompChannel.removeEventListener(Event.SOUND_COMPLETE, onSoundCompleteFun);
soCompChannel = soComp.play();
soCompChannel.addEventListener(Event.SOUND_COMPLETE, onSoundCompleteFun);
}
//
private function onEnterFrameFun(e:Event):void
{
var flag:Boolean = false;
if(soCompChannel.leftPeak == 0) flag = true;
if(soCompChannel.rightPeak == 0) flag = true;
if(flag) trace('soCompChannel lp : ' + soCompChannel.leftPeak + ' rp: ' + soCompChannel.rightPeak);
//
flag = false;
if(soLoopChannel.leftPeak == 0) flag = true;
if(soLoopChannel.rightPeak == 0) flag = true;
if(flag) trace('soLoopChannel lp : ' + soLoopChannel.leftPeak + ' rp: ' + soLoopChannel.rightPeak);
}
}
}
//
用上面的程式測試! 會發現有下面的 trace
//
soCompChannel lp : 0 rp: 0
soLoopChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
soCompChannel lp : 0 rp: 0
//
就程式面的角度看!
是代表聽 事件 重播的機制會讓 channel 有一個影格左右的沒有聲音!
因為我自己試聽不出來一個影格的差異 !
所以我是這樣去看到底有沒有斷音!
總之結論是使用 原生 sound.play 去 LOOP
會比聽事件 去 loop 順
所以我是這樣去看到底有沒有斷音!
總之結論是使用 原生 sound.play 去 LOOP
會比聽事件 去 loop 順
上面的測試環境
聲音是使用 SWC 鑲進去的
如果是使用
soComp = new Sound(new URLRequest('../asset/sound.mp3'));
的方式 測試也是一樣 ! (以我手邊第一次處理的 MP3)
不過~我後來有處理另外一個WAV
用SWC 的方式 是只有開始會有 0
但是使用 new URLRequest 的方式~
卻是和聽事件的一樣! 會中斷!
所以還是要看 Sound 檔
用SWC 的方式 是只有開始會有 0
但是使用 new URLRequest 的方式~
卻是和聽事件的一樣! 會中斷!
所以還是要看 Sound 檔
2012年6月24日 星期日
[雜談] Indie Game 觀後感
恩~今天去看了
獨立製作遊戲
http://igdshare.org/
雖然不是現在才發現~
不過在一次的確定了~
其實大家的想法都一樣~~
開發中的不確定感~
自己的經歷~
自己的喜好~
自己的過往~
發表 展示的感覺~
展示時出現 BUG..的心情...
大家的反應~
能不能了解我設計的目的~
巴拉~巴拉~巴拉的~~
有時候一改在改~
一改在改~
其實真正做才是最難的地方~
可以~勇敢~認真的放手一搏~~
創意其實大家都有的~
但是能真正生出來的有多少?
我自己的個性應該是不敢走鋼索的那種人巴...
今天看到的這些人
對我來說才是真正的勇者
其實還有更多想講的~
但是怎麼說~
還是介紹一下影片巴~~
今天的影片基本上~
是介紹獨立開發遊戲的
最重要的是下面這三款~
雖然一開始我把 FEZ 搞錯了~
搞成日本的那款~
理論上以獨立開發來說不應該搞錯的 orz
FEZ
一個在 2D世界的小人
突然發現世界是 3D 的! 所以開始探索~很有趣 很好玩~
很多很有趣的地方~~
然後他的技術 也蠻簡單實現的~
但是創意卻很難!
這個作者蠻有趣的~其實每一個都蠻有趣的~
不過以某種程度來說~我覺得他是最慘的一位
Super Meat Boy
這兩位開發者~怎麼說~
對遊戲得執著真的很厲害~~
寫到要打胰島素才能在寫~
然而以某種程度來說~
他們的成就也是驚人的~
特別是 他和異塵餘生 同檔期
但是在評價上比他高~~
而且還是自己會想買的遊戲 XD
那來講講遊戲~~
一款很有趣的動作遊戲!
一款創意 搞笑~和風格都很獨特的遊戲!
Braid
一個有趣的世界!
有愛情 有故事!
很多的創意的遊戲
利用 時間倒流 來達成 或是進行 解謎等等的遊戲~
關於這個作者給我的感覺就是像CSI的葛瑞修~
他做出了一個超棒的遊戲~
但是他卻因為一些評論 讓他非常沮喪~~
話說以我自己來講~
我應該也是會讓他很沮喪的那種人巴 orz
因為我應該是以解決問題為目的~
而不深究為什麼這樣的人
上面這幾款都是 有賺大錢的遊戲~
也很特殊的遊戲!
基本上 可以看出一個模式!
主角 本身都不會 在強化
而且都是 各有特別得地方!
重點以動作為導向
(雖然個人為人 FEZ 是以探索為導向)
接下來講講我最近的一些 獨立開發的遊戲巴? (應該巴~對我來說不是大公司作的 都算)
雖然說都不是算是很高知名度的作品 (不過換個角度看 應該算 知名度也蠻高的 orz)
大雄無理系列!
基本上 看影片巴!
http://www.youtube.com/watch?v=F_22X_mRr1E&feature=channel&list=UL
這個應該分成兩個一個是原版的
ドラえもんのび太 的 生化危機
這個就改編得很大~類型很多~
RPG 探索 SLG 等等等
生化危機 是其中之一
作者基本上都是掛名 aaa
再來就是
對這個作品進行二次改造後的無理版! (據了解有許多版本 也是一堆人都有作的)
基本上是讓 aaa 的版本 對人物的個性 等等的作修正~
修正到比較符合正常的哆啦ㄟ夢的人物個性~
後面延續的版本
不過就是 按照生化危機的劇情趣改編 延續~
還對一代的系統進行改造~
多了很多很有趣的東西~
多主角~換武器~躲子彈~劇情分支~多結局~真結局. 巴拉巴拉~
簡單的講 生化危機有的~大部分的他都有做了~
超神的
むなしい努力
網址 下載網址
http://freegame.on.arena.ne.jp/simulation/game_1554.html
基本上是一款 自行開發的 RTS + SLG 的遊戲~
因為我先看到的是這個~所以~和他類似的另外一款~
我就不介紹了~~
基本上 想像成 全場景的
聖魔戰記 就對了!
或者說 是 龍之力量!
事實上我看到的時候 是想到 吳氏工房的 波斯戰記系列~
和他的一些後續 的作品~(不是波斯 或 黑暗天使系列的)
簡單 大膽 的戰鬥系統!
多樣的招換 招式 劇情的分歧 選擇~
該有的我覺得都有了 !
其實 也是可以當 緋王傳 看也是一樣~
以魔王軍來說 純用招換戰 也不是不能統一世界!
不過 緋王傳的一些策略 和 特別的設計 這款就沒了
想當年 一定要凹贏盜賊拿寶物的部分~
這遊戲真的就感受不到了
剩下一些在
http://www.kongregate.com/ 的我就以後再寫...
這邊的好玩的遊戲好多阿~~
很多款我都 忍不住的全破了 orz
================================================
FEZ:
http://www.youtube.com/watch?v=CWUU0vvWLRo
Super Meat Boy
http://www.youtube.com/watch?v=CQ_PtD3LwpE&feature=related
Braid
http://www.youtube.com/watch?feature=player_embedded&v=uqtSKkyJgFM#!
訂閱:
文章
(
Atom
)










