雜物聚集地

cocos2d將大張SpriteFrame縮小後消除鋸齒的作法

Sun, 04 Dec 2011 16:58:11 GMT

#cocos2d-x

研究後沒有使用
紀錄一下

如果有一張大圖想要縮小使用
當縮小的比例很小時
即使對該圖的texture 呼叫 setAntiAliasTexParameters()
也會有鋸齒的感覺

如果不另外用小圖的話
可以使用mipmap去處理
主要對目標texture作兩步驟處理

呼叫generateMipmap()
呼叫setTexParameters()

ccTexParams.minFilter = GL_LINEAR_MIPMAP_LINEAR
ccTexParams.magFilter = GL_LINEAR or GL_LINEAR_MIPMAP_LINEAR

基本上原圖為NPOT才可以用
使用後就不會有明顯的鋸齒感覺
感覺上會比較滑順

但應該會加重記憶體的使用
故不使用

ref :
https://www.cocos2d-iphone.org/forum/topic/2735
https://zh.wikipedia.org/wiki/Mipmap

Lua預編譯

Sun, 04 Dec 2011 16:29:19 GMT

Lua預編譯主要好處：加載更快，與保護source code免於被用戶修改(另外還有檔案更小)。

方法：

安裝luaforwindows

https://code.google.com/p/luaforwindows/ 2. 安裝後設定系統Path 加上lua安裝路徑
預設應該是 C:\Program Files\Lua\5.1 3. 開cmd, 輸入luac 測試一下可不可以執行 4. 可以的話可開始使用, 使用方法如下：
luac -o [預編譯後檔案路徑] [要預編譯檔案路徑] (可將多個檔案預編成單一檔案)

以下是lua學習參考資料
https://linux.die.net/man/1/luac
https://blog.chinaunix.net/space.php?uid=380521&do=blog&id=2412459
https://timothyqiu.com/2011/lua-note-02-table-traversal-using-c-api/

JNIEnv錯誤使用紀錄

Tue, 19 Jul 2011 17:00:38 GMT

#jni

最近專案有需要從cocos2d-x接Open Feint的功能
所以必須要從c++ call Java code
不過犯了一個極大的錯誤

一開始activity在啟動時呼叫一個function
記錄該方法傳入的JNIEnv的指標
做為C call Java code時使用
在成就上傳時常常會死當
後來剛好ndk r6出來後就用ndk-stack來除錯
發現是JNIEnv指標出問題

後來再查資料才知道JNIEnv指標與Thread有關
像我這樣的作法是會有問題的
穩當的作法是存JavaVM指標

JNI_OnLoad
JNI_CreateJavaVM

再以JavaVM取JNIEnv

AttachCurrentThread
GetEnv

C, C++, Objective C, Java, C# 差異比對

Mon, 09 May 2011 17:12:31 GMT

#link

C Style Languages: C, C++, Objective C, Java, C#
該網站將一些類型相似的語言做比對
十分完整
對有其中一種語言基礎的人很有幫助

Object composition(物件複合) & Class inheritance(類別繼承)

Mon, 04 May 2009 17:05:16 GMT

首先，類別繼承不同於介面繼承(Interface Inheritance)。
類別繼承重於共享程式碼與內部佈局機制，介面繼承重於可替換性。

假設現在有A,B兩個class
class A中有method work()
現在要讓B使用A的work()
有以下兩種方法：

B extends A ,呼叫繼承來的work()方法
給B一個欄位為class A，並在class B 中給予一個方法去呼叫該欄位的work()

方法1為類別繼承，方法2為物件複合，在物件導向中這兩種方法是最常見的再利用(reuse)技術。
在方法2中，使用了稱為delegation(委託)的技術，簡單來講就是把自己該做的事交給別人去做，這樣的方法讓物件複合擁有與繼承一樣強而有力。

比較：
物件複合可在執行期動態指涉(Reference)其他物件 [1]P.19
類別繼承破壞封裝性

在一些書中提到了能用物件複合就不要用類別繼承的觀念
多用物件複合技術，少用類別繼承。(Favor object composition over class inheritance.)[1]原P.20中p.23
條款14：優先考慮複合(Composition)，然後才是繼承(inheritance) [2]中P.71

但這只是一個原則，繼承的功能強大，但由於他破壞了封裝性，所以只有當子類別確實是父類別的subtype時才適合使用繼承。如果，父類別與子類別處於不同package或副類別本身並不設計為繼承用(抽象類別為繼承用)，還是建議使用複合。[2]中P.76
使用delegation過頭可能適得其反，在[3]的第三章提到一種程式碼的壞味道：中間轉手人(Middle Man)，就是由於使用delegation過頭而產生。

最後，在重構(Refactoring)技術方面有兩個相關。

Replace Inheritance with Delegation：有時我們將一個B類別繼承A類別想要使用它的操作，但是有時候會發現我繼承A類別後也繼承了一對不需要的東西，或發現繼承後根本不適用時使用。[3]中p.352
Replace Delegation with Inheritance：當你發現你使用了你委託對象的所有函式，則可以考慮繼承他(仍有限制)。[3]中p.355

參考資料
[1]GoF, Design Patterns
[2]J. Bloch, Effective Java Programming Language Guide
[3]M. Fowler, Refactoring: Improving The Design of Existing Code
[4]J. Kerievsky, Refactoring to Patterns

…