Flash務實主義(三)——最短路徑原則(下)


透過現象看本質

首先是個轉場特效問題。

其實我早想到做法了,只是當時還沒實踐。增加混合(BlendMode.ADD)只要關系到光效,泛用性就很高,疊加着畫上去看起來應該就是這個效果。

但是我還是先到群里問了下,然后一幫人就跟我說徑向模糊。還有一幫人說以前搞過,拿我的原圖上了個徑向模糊發給我。但是徑向模糊多慢用過PS都知道,怎么也不可能用在動畫效果里的。這個東西的確有點像徑向模糊,但是像什么就做什么,從表面着手,思考方式就有點單純了。

實際上做法再簡單不過,調整Matrix縮放和旋轉圖形,一點點放大,然后用增加混合模式將原圖疊加着畫上去即可。

var m:Matrix = new Matrix(); 
m.translate(-bmd.width / 2,-bmd.height / 2);
m.scale(scale,scale);
m.rotate(r);
m.translate(bmd.width / 2,bmd.height / 2);
screen.bitmapData.draw(bmd,m,new ColorTransform(1,1,1,0.2),BlendMode.ADD);

增加混合是個很有趣的東西,可以衍生出很多東西,這個以后再說。

短時效果,近似方式可以更大膽

某天看到了個很牛的玩意,一個哥們做了個很酷的模擬水滴從牆面上滴下來的效果,公布了詳細的思路與做法,涉及不少的數學知識(http://jamesli.cn/blog/?p=631)。我們在這只就他這個效果一個很有趣的細節做討論——兩個水滴接近時會自動融合成一個。

水滴本身是一個多個節點的曲線,那么這個融合過程該怎么實現呢?這時候一個沒看作者代碼的人就說話了,而且還畫了圖。總之,他的辦法就是當兩個水滴相交時,先檢測出相交面積,然后找到重疊部分的曲線的點,將這部分點刪除,再將剩下的點平滑連接到一起,這樣兩個水滴就合二為一了。好吧,至少這個沒有要求做曲線相交,但剔除點之后重連接還是要有一定數學知識,到底哪兩個點連接?連接曲線的曲率是多少,怎么才算平滑?連接成一體的新的水滴怎么才能恢復類似圓的形狀?

而作者的代碼很簡單。他的做法僅僅是讓較小的水滴快速移動向大的水滴並漸隱,然后把兩個水滴的面積相加求出新的半徑,小水滴刪除,大水滴直接變大。這個和真實融合的情況相差甚遠,但是由於融合過程很快(現實中確實也很快),如果你不使用變速齒輪,自己也沒有子彈時間似的超級視覺,根本看不出具體融合步驟,也就看不出破綻。

都說圖形編程數學要好,這的確不錯。但實際上除了一些特別惡心的需求,甚至都不需要動用高數的知識。而且如果需要用到高數知識,往往也是光高數知識搞不定的。如果一個問題覺得非得用高中程度之上的知識才能解決的話,有可能就是鑽進了牛角尖。近似方案,足夠了。

算法問題並非都要全部通過公式解決

這是一個實際問題。我曾經自己寫了一個翻頁效果,並用在了項目上。翻頁實際上很難寫,雖然都是解析幾何的知識,但要判斷多種情況,各種翻頁方式的繪制方法是不一樣的。所以最后我只實現了從左上向右下的翻頁,當時足矣。

但是后來美術提要求了,他希望做個從右上向左下翻的動畫(這是一般翻書的習慣),但因為這個是用解析幾何計算出來的,在不同方向上,公式是不同的。而這段代碼里全是已經移項后的方程,根本無法還原,隔得時間也太長,換個方向差不多就要重寫。我頭痛了。

后來我在那無聊,把整個繪制容器翻來翻去,設置scaleX,scaleY,然后看到,翻過來以后,雖然鼠標,圖像全都倒置了,翻頁本身的效果倒是挺正常的,只是翻轉了。垂直翻轉后,由左上向右下就成了由左下向右上,水平翻轉后,則成了從右上向左下。好,我要的效果出來了。

鼠標和貼圖不對?改下就好了,鼠標很好弄,貼圖嘛,繪制的時候先翻轉好就成。

終於不用寫四次同樣的算法了。雖然其他人寫的翻頁可能能用一套公式兼容多個方向的情況,但我的數學水平沒那么好。但就算這樣不也做出來了?條條大路通羅馬,不修改繪制方向,而是改變整個容器的方向,雖然不是標准答案,卻是很理想的應急方案。在這里,它幾乎可以永久使用。

固定動態內容可轉化為動畫

大家小時候都玩過那種投色子在格子上前進的紙上游戲吧。我以前挺熱衷的,還常常自己畫棋盤,各種大小格子跳轉。如果棋盤都是很整齊的直線和折角的話,那自然好說,但如果棋盤本身的線路就是扭來扭去的,或者說本來就是美術亂畫的呢?

首先想到的是做錨點,棋盤就當做背景圖了,旗子都是在這些看不到的點上移動。這里直線移動還是好做的,但是曲線……除非你打算用直線近似代替,否則又要搞什么貝爾法……

但如果你的這部分只是一個小游戲,不關心擴展的話,有一個只有FLASH才能做得到的方案,對於AS2時代的人可能會比較親切,AS3時代進來的人可能根本就見過這種搞法。

咱把棋子移動整個做成一個動畫吧。

有分支就跳轉不同幀繼續播放,棋子走的時候就gotoAndPlay(),移動僅僅是控制播放這個動畫,這樣什么轉彎全都是動畫,做些花哨的動作比如騰躍也都行了。這個的缺點就是只能做固定的行走路線,如果人物可以隨時轉向就有點困難(也不是不能做)。

小游戲有小游戲的搞法,FLASH也正是因為可以支持這些小游戲的搞法才能發展到現在。雖然是老掉牙的東西了,有些時候還是可以用用的。老的東西並不會被完全取代,畢竟它還是有自己的便利之處的。既然用了就能豁然開朗,那么它就是這時候的,最佳選擇。

代碼級簡化

說得挺多了,最后再介紹一些寫法上的簡化方法吧:

  • 正弦震動
  • 實現一個元件的震動,物理方式模擬實現是最傻的,用Tween模擬多次緩動一樣也好不到哪去。而震動指的都是正弦震動,所以我們用Math.sin()處理y軸就可以了。

    你甚至不需要定義一個遞增變量來處理時間,只需要在開始直接t = getTimer()來記錄初始時間,然后像這樣y = Math.sin((getTimer() - t) / T * 2 * Math.PI) * R(getTimer() - t得出的是經過的時間,T是震動周期,然后乘以2π,就是sin函數需要的參數,而再乘以振幅R即可,這都是中學知識)

    停止用setTimeout執行一個函數即可,振幅一樣可以用getTimer() - t作為變量遞減。

  • 九宮格方向
  • 一般人物動畫用的8方向序列幀,需要根據鼠標指示的方向來顯示對應方向的循環序列,平常的做法就是寫上一組九個的IF語句,分別判斷九種情況並設置九種序列幀。這沒有問題,但實際上有更簡單的做法。我們可以認為x軸方向有3種狀態(左,中,右),y軸方向有3種狀態(上,中,下),而這些狀態相互組合形成了結果的9種狀態。如果這三種狀態分別以數字0,1,2表示的話,可以用公式y*3+x直接得出一個狀態值(y是縱向的狀態,x是橫向的狀態),而這個結果則是這樣的:

    0(左上) 1(上) 2(右上)

    3(左) 4(中) 5(右)

    6(左下) 7(下) 8(右下)

    這是一個9宮格,拉成一行就是一個數組,可以將各個方向的序列幀存在這個數組中,然后判斷一次x的狀態值,一次y的狀態值,然后直接用arr[y*3+x]就能取出對應的序列幀,這比寫上一組case或者if都要簡短得多。

  • 顯示對象排序
  • 最后是最標准的顯示對象排序問題,只是單獨排序一個物品並沒什么技巧,從頭到尾循環並比較就對了。但是如果是將一組混亂的數據按大小排列的話,不同排序方法的差異性就會體現出來。

    有的人會用最簡單的冒泡排序,但那個效率很不理想,所以有人就大張旗鼓地表示可以用分治(快速)排序來優化,但是分治排序寫起來比較復雜,不少人都沒背下來(包括我)

    但實際上按時間復雜度來測試,Array.sort方法的結果看上去就很像分治排序。本來就是個系統函數,分治排序又沒有缺點,應該用的就是這個,而且是原生方法速度也很快。但深度排序需要交換層,sort是個函數,其過程無法干預。

    但只要使用參數Array.RETURNINDEXEDARRAY(記得也要用Array.NUMERIC指示按數字排序,否則中途會轉換成字符串不僅錯誤而且慢),最終就會返回一個數組,下標是原位置,值是新位置,然后根據這個數組重新執行一遍setChildIndex就行了,顯示對象序列也就和被排序的數組完成了同步。

順便給份測試結果,畢竟換層有多種方案(setChildIndex, swapChildren, swapChildrenAt),整個排序主要的消耗都在交換層級上,因此換層的方式很影響效率。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com