其他

開始做一些工具，研究了一下XNA和winform結合的問題，研究了幾個實現以後Winform就熟悉了，然後發現網上的實現都不好。於是我做了一個改動圖形部分最少的實現。因為XNA預設範本已經有一個Game.Run.在windows

如果想要提高更好的服務,我們的遊戲容量會很大如果完全通過MarketPlace來更新,一次小小的升級,對使用者來說都是災難性的流量損失.如果拋棄了content架構，那麼我們可以設計如下的模式，來為使用者提供下載服務 遊戲資料來源遊戲資源存放在ftp伺服器或者http下載伺服器上，程式的更新走marketplace，你想寫出1M的程式都非常非常難，使用者對於程式的下載和更新將是非常迅速的。而遊戲資源部分，不使用content架構，而是自訂格式儲存，那麼，遊戲資源的更新，是完全可以做到按需下載的。

建立繪製用字型，輸出32點陣。使用字型輸出字串使用效果，後面的部分無視，那是用輪廓資訊簡單建模繪製的。 粗版雅黑 普通雅黑微軟雅黑也被我們征服了1.0版本

pure c#是一件有趣的事情DLR也是一件有趣的事情，但顯然不夠有趣。我想要一個更可靠的指令碼系統強型別，可以編譯期檢查排錯可以跟蹤執行很遺憾，沒有發現有合適的開源項目可用 於是，我自己來弄一個。首先基本設計了位元組碼執行引擎的指令設計了8條指令，因為想要極致簡潔，並且可以快速實現，這張圖裡用了7條NOOPSETMATHLOGICIFGOOUTEXIT 當然還有最重要的第8條

TM2T入手了，重裝的windows7 32bit 中文系統。Tx2Z TM2T 對比圖 顯卡驅動弄死我了。HP的這幫傻蛋，官網上驅動都整不對，32bit下載下來還是64bit的。Intel和ATI的聯合蠢蛋，顯卡支援切換是好事兒，為啥驅動整那麼複雜。windows 自動更新還會更一個會黑屏的驅動下來，折磨了我3個鐘頭。最後拿HP dv3

利用後處理的深度測試的優質的描邊，五個旋轉的茶壺。現在先寫出了一個描邊的後處理，以及情境繪製時每個茶壺都要使用的特殊的shader。目前是手寫的，先完成功能。然後對這個部分進行封裝，實現一個自動的驅動過程和Shader組合過程。然後任何效果的實現都不再依賴於代碼的修改，當然這是很長期的一個事情，目前先實現一個優雅的卡通渲染就行了。整個情境的效果資訊都可以配置在一個XML中。從卡通渲染到實感繪製，任意增刪一個效果，一切皆可動態完成。目前的XNA還沒有支援出MRT，由於windows phone 7

讀取微軟雅黑遭遇問題英文字模正確，中文Cmap映射就不對。cmap表有可能在微軟雅黑有多國語言的映射關係，我在cmap映射階段沒有過濾語言，這是一個漏洞。曲線看起來有些狀況，可能在微軟雅黑裡有用擴充的三次曲線。不過在ttf主要格式已經對我們敞開大門的情況下，這些bug只是一些小狀況。再說，這年頭誰放在遊戲裡的字型自己不編輯一下。編輯的時候就可以把這些已知的問題解決掉。這個中文解決方案只是我個人在製作，現在實在是抽不出手來解決這些小狀況。還是先拿老牌的黑體 楷體

是一個地形系統和多點觸摸的地圖編輯器，那將是非常舒服的，和滑鼠完全不同的操作體驗。關於地形，唉。。。windows phone 7

如果你以前的博文有看，你會看到這裡有了很大的不同，一個新的Render2Texture類，可以直接產生一段data寫進貼圖裡。然後就把這個貼圖繪製出來，就是那一堆猛。關鍵的流程已打通，至於怎麼對字模進行緩衝，或者你願意用一個灰階圖緩衝，我看到已經有很多XNA的開發人員幹過了。甚至過幾天我會直接去借用他們的代碼。那些都是應用程式層的代碼，我借來做做sample。我解決的是底層的問題，目前只是用了一個非常簡單的畫法把輪廓線花了出來。接下去要支援筆刷設定，支援填充，支援反走樣。這套字型系統就可以有一點

不知道有多少人考慮過深度利用SVN來工作，甚至利用SVN來當某些商務服務器使用。我昨天晚上開始重新拾起這個塵封已久的想法，一身冷汗，睡眠不足。遂做了一天的實驗，翻閱了大量svn的文檔，甚至閱讀了svn和tsvn的一些代碼。無果，最後終於瞭解了一點東西，我們最常用的svn協議是 基於webdav修改而來的。而webdav是在http1.1的基礎上擴充而來的。對tsvn進行了抓包分析，終於跑通了第一條通訊。僅將最後測試可用的關鍵代碼放這，用visual svn

已經可用的一個版本精靈配置精靈配置，先將精靈分類，指定每種分類分為多少個方向和動畫，mirror表示是有對應的鏡像關係，可以自動產生由spriteconfig.xml決定，編輯器不能修改 精靈列表儲存在

  其實比左邊那個小一半完成了一個掃描線填充演算法。發現這個演算法主要有兩個缺陷。一是像素精度的，所以當邊線太小時無能為力。還和字型有關。連邊線一起填充也許是個辦法。二是一次只能填充一個多邊形具體點說就是一條曲線。三是出現曲線內的曲線時，Fill方法是無能的，出現無法判別哪裡不該fill的情況。處理不了鏤空當然分析曲線，是可以確定的，計算太多，這並不是c#擅長的工作。對於三也可以分曲線逐個處理，遇到前面曲線處理過的顏色就反色。當然也有好的地方

有同學說silverlight裡面透明有問題，我看了一下，確實有問題，但是很容易解決的問題。弄了個100隻章魚的例子。CLGC和CLGF for silverlight 已經實用化了。做高效能2D小遊戲可以滿足。重寫了圖片載入器，不受silverlight噁心的線程制約，支援png jpeg格式。文字還是採用ttf方案，完全拋棄平台差異性。 CLGF在IOS的調試暫停，那天Novell

1。在pc上調試比模擬器愉快的多，也可以更容易的發布小樣給別人看。需同時保持pc和wp7的兩份代碼，隨時保持相容性，可以用copy project來簡單完成。我就是有相當一段時間沒有保持代碼相容性，結果前些天移植wp7的時候要重構一些代碼。PC端用的是dotnet framework 4 client profile，當然也可以不帶 client profilewp7端用的是 dotnet framework compact 3.5曾幾何時WM端的應用在pc上可以直接執行調試，現在已經行不通了，

寫了多年c++，搞3d渲染。前端時間搞clgc（c#） 跨平台2D開發庫終於，這個月開始關注HTML5，終於退化到寫javascript了，別說挺好玩的。javascript的語言設計過於簡潔了，規模上去挺難控制的，要想各種各樣的招數javascript的語言設計過於簡潔了，規模上去挺難控制的，要想各種各樣的招數 代碼寫成這樣以後，代碼出點問題就非常麻煩了，尤其是格式問題，我非常依賴粒度非常小的單元測試，我找到了一個叫做zhutzpah 的單元測試工具，有點bug，但總算解決了很多問題。

XNA4的Content帶來的無奈與限制就不提了，重要的是和3.1相比改變了不少，看了一下3.1的骨骼動畫的例子，在4上面，才疏學淺的看不出個名堂。Effect檔案，我已經想辦法翻牆了，繞過了Content.貼圖由於SetData介面用的輕車熟路，本來產生了一種VeryEasy的錯覺，今天具體看了一下介面，才發現除了SetData之外，沒有任何可以利用的東西。從SourceForge上找到了一個PNG處理的開源項目，在此鳴謝一下。Windows上編譯很順利，注意不能直接使用，一定要建一個XNA

 測試頁面，需要silverlight5 betahttps://crazylights.googlecode.com/svn/clge_publish/s5testTestPage.html我最關注的部分，是silverlight5中的xna，我已經使用silverlight5實現了一個spritebatchsilverlight5

http://crazylights.sourceforge.net/gametest.htmhtml5 大家瞅瞅 自從上次開始擺弄javascript，一部留神就深了。 javascript一定要批判，一定得批判，批判促進進步。   首先是完全不卡死介面的方式，非同步控制載入，簡單的說就是loading。

正確含曲線（2010.5.8日淩晨三點取得此進展）不含曲線。（2010.5.5日淩晨四點取得此進展）黑體的字型沒有一個用曲線的。突然想到了微軟雅黑，不含曲線產生也快些，下次用微軟雅黑看看。做了很多測試，主要是納悶在truetype曲線格式的描述上，資料太少了，做過的那些同志都是一筆帶過，沒有人詳細解析一下，truetype那一長串不再曲線上的點應該做何解釋。我現在是對於一串的，就按照二階貝塞爾的要求，按照 012 234 456 這樣的順序來繪製曲線。得空還得去研讀一下freetype的原始碼，

技術說起來很簡單，我是受到了DeltaEngine和Blader的啟發過程中看了Blader、XNATouch這些開源方案，終於完成了這樣一個圖形核心。無論是deltaengine還是XNATouch，都在無限跳票中，我已經比他們走的更遠。 架構設計上分為兩個部分：一個是CLGC，負責繪圖、檔案讀取。CLGC封裝了基本的數學庫、貼圖操作，字型操作、SpriteBatch，TTF解析，jpg解析，png解析。隔離了不同平台檔案存取方法的差異。底層實現主要是基於XNA和OpenTK中的OGL和OGL