-
Recent Posts
Recent Comments
Archives
- December 2013
- November 2013
- March 2012
- February 2012
- December 2011
- November 2011
- October 2011
- August 2011
- July 2011
- June 2011
- May 2011
- March 2011
- February 2011
- January 2011
- October 2010
- August 2010
- July 2010
- May 2010
- April 2010
- March 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
Categories
Meta
友站連結
Tag Archives: Python
Python使用HGE引擎
大家肯定都知道在Python下面寫2D遊戲有個眾所階知的選擇就是pygame，雖然它簡單好寫，對於簡單的遊戲來說已經足夠，但是他有一個致命的缺點，就是速度太慢了，在pygame的背後是SDL，用純軟體畫圖的函式庫，既然為純軟體繪圖，遇上旋轉、半透明等等需求，更顯得吃力和不切實際，所以該怎麼辦才好呢? 答案是用Haaf’s Game Engine，它是一款用DirectX做為backend的Open source遊戲函式庫，我在先前的文章裡已經有做簡單的介紹，就不再重覆，那這函式庫和Python又有什麼關聯呢? 他是用C++寫的，Python沒辦法用，正因為這樣，我一直一來想幫他寫一個python的binding，我一直想如果Python也能用HGE寫起來一定很開心，我試著找了一下有沒有已經存在這樣的專案，有找到一個，但是居然是在萬惡的GNU授權下的，讓我百思不得其解，那專案的作者到底在想什麼? 想讓大家寫Open source的Game嗎? 我們都知道GNU是大名頂頂的病毒授權，任何程式使用了用GNU的函式庫都會被感染，代表你的主程式一樣得變成GNU的開源授權，我個人非常討厭打著自由名義但是卻有強烈的強迫性質的GNU授權，況且HGE的授權是非常寬鬆的 zlib/libpng License，實在想不透為什麼一個binding可以用超嚴格的GNU，不過那是那作者的自由，我也管不著，在不能接受那惡心的授權，加上我看了一下他的專案似乎好像也沒有很完整的進度，於是我還是決定自己開了一個新的專案 Python HGE 在這樣的情況下，我前些天抽空開了一個新的Open source專案: Python-HGE，把一些最核心的程式碼都用boost.python包裝給Python使用，最核心的部份完成度很高，剩下的需要我在未來有空慢慢補上，License是MIT，如果你問我為什麼選MIT，我想答案應該是商業用途一樣也可以，不像GNU那種假腥腥的自由，還有一個重點就是，我覺得麻省理工這名字聽起來很酷，讓我想起每次在Discovery看到的東西 效能問題 我照著原本HGE的Tutorial7的程式寫了一個Python的版本，這個範例的目的就是在展示HGE的效能，純C++的版本速度當然是很快，而Python的版本FPS掉了不少，一開始讓我覺得有點失望，讓我開始懷疑如果效能掉很多的話，那用Python寫HGE還有價值嗎? 後來仔細思考了一下，對於一般的2D遊戲來說，要像這demo整畫面跑來跑去的圖片加透明效果的情況實在不多，就算有也很難到這樣上千張的圖片，再者我都還沒進行最佳化、跑profile等等，而且雖說FPS掉不少，但是那是和C++數百的FPS比起來，在60以上其實都是可以接受的，加上我測試的這台電腦已經有點年代，對現代的電腦和GUP來說情況只會更好，在如此的考量之下，Python HGE還是有搞頭的 python版的tutorial 7截圖 這個demo可以在這裡下載 目前狀況 目前雖然核心部份已經高度完成，不過我還沒有把編出來的pyd釋放的打算，如果想嘗鮮的話可以直接從那個demo裡面找pyd出來用，又或著自己check out原始碼進行編譯 參與開發 如果有興趣的話，歡迎參與專案的開發，如同我上面所提到的，我用的是boost.python，一款基於C++的python binding函式庫，如果你熟悉boost.python的話當然是最好，就算沒有也沒關系，因為其實大部份工作都是剪下貼上之類的，可以參考我已經寫好的部份，有些函數回傳例如指標之類的東西需要特別處理，除此之外都只是很簡單無腦工作
wxPython自製Control : 用Matplotlib畫圖表的FigurePanel
最近可能會接到一個需要GUI上畫不少圖表的案子，於是就來研究了一下wxPython + matplotlib，前陣子買了wxPython in action，雖然一本1500元大洋讓我心有點淌血，不過這本書真的寫得很棒，讓我對wxPython有更深入的瞭解，如果案子接下來買n本都可以，我個人認為買書來讀是一種投資，所以基本上看上眼的書買起來也不會手軟，接著因為除了畫圖形，也需要用到不少GUI，我把wxPython官方的demo抓下來，裡面每個範例都跑了一次，對於wxPython能做到什麼地步有了更深入的瞭解，越來越覺得wxPython真是酷斃了，很好玩的GUI framework 在這之後，雖然案子還在歸劃的初期，不過我不是很喜歡空等而沒有程式可以寫的感覺，其實在接洽的這段期間就能先完成一些將會用到的東西，像是widget之類的，或寫寫原形來驗證確實可行之類的都很好，所以我就寫了一個用Matplotlib畫圖表的Control : FigurePanel，因為往後在寫GUI都會用到，如果每次都要特地寫來處理這些我會發瘋，當然最好的方法就是包成Control，如此一來所有圖表都可以直接使用，加上可以有統一的行為，例如另存新檔、列印等等，相當方便 什麼是Matplotlib? Matplotlib是一套強大的Python畫圖表用的函式庫，如果不知道他到底可以畫到什麼地步，就可以看他們官網的畫廊，相信看完後就知道它有多強大，幾乎你想得到的圖、想不到的圖，沒看過的圖，他都可以畫，當然，如果裡面沒有你要的圖，或著你要自創圖，當然也可以自己擴增，有了這套函式庫，原本我可能得先花個一個星期還多少時間來建構一套畫圖表的基礎，如今這些時間完全省了下來，這就是使用Open source的好處，沒有這些東西真的不知道要寫到民國幾年 切入正題，我們來看一下FigurePanel的原始碼
WebFaction價目表中文版，再一次推薦WebFaction
介紹WebFaction優秀的主機商，提供使用者完整的自主權，可以執行任何程式，包括自己寫的伺服器等等 Continue reading
開發wxPython的利器 : PyCrust
一直想做的事 最近我在用wxPython開發某些程式，隨著開發的過程中，難免需要一些直接的測試，改動程式碼來進行測式似乎不是很明智的選擇，即使Python是直譯式的語言，每改一次重新啟動整個程式也是一種浪費，而且狀態每次也會重置，於是我開始想，我是否可以寫一個像Half-Life那樣的一個console整合到我的GUI中，如此一來我就可以在開發時直接進行某些測試，對某些特定的模組操作，如此一來開發的效率可以提升，對於程式而言也會更好除錯，但是雖然寫一個console不是什麼太難的事，但也不是什麼太輕鬆的事，為了早點完成程式，於是我就沒有真的去做 直到某本書的出現 : wxPython in action 當有一天我訂的書: wxPython in action終於來了，這本書要1500元，實在是不便宜，但是我認為卻很值得，我在書中發現我以前一直都沒仔細去注意到的東西，PyCrust，在翻過這章節時我驚訝地發現，這不就是我想做的嗎? 一個控制臺，可以讓我操作、觀察、測試我的GUI，而且整合的方法超簡單，只要一行指令 python pywrap.py main.py 在wx.py的package下的pywarp.py會自動找到app並且將PyCrust整合進去，在我程式中執行的畫面就像這樣 在截圖中我利用pycrust將gui的背景換成了紅色，它不止是一款簡單的GUI，因為他是動態載入模組的name space，和一般IDE不同的是，他的自動完成是動態的，一般的IDE只抓得到靜態的成員，但是即然是動態載入又是在執行中，有什麼成員一清二楚，所以基本上自動完成功能感覺非常地強大，但相對的弱點是對於靜態的部份比較麻煩 它除了可以自動整合到現有的wxPython gui程式中，更可以把裡面各個元件分開來獨立使用 所以它可以幹麻? 對我來說，PyCrust將會是像神兵利器般好用的工具，像是開發遊戲之類需要大量的調校，一個console或是動態的機制是免不了的，而console提供了立即且互動式的環境，有了PyCrust，就等於有了現成的console可以使用，在遊戲的開發過程中，開發者可以利用這個console動態地改變各種參數來觀察反應等等，當然開發遊戲只是其中一個應用的例子，即使在一般的GUI中也會是很好用的工具 順帶一提 wxPython in action真的是難得一見的好書，有別於一般的書，它使用問句來當做標題，但是不會因為這樣而零散雜亂，相反的，你可以很正式地看完一次，也可以很快速地掃過一次，當你需要什麼東西時，那些問句可以幫助你很快地找到你需要的東西，豐富的截圖和圖解更讓人不用費心去猜想到底做出來會是什麼樣子，或是想像到底是如何運作，如果要學wxPython，我覺得這本書真的是非常值得推薦，做為工具書，這本也是必備的一本
Python的進步: ctypes
石器時代 在很久很久以前，想要擴充Python要使用API來包裝成Python可用的模組才可以，面對囉唆的一堆C API是一件痛苦的事，接著，進入了石器時代，人們開始使用工具，出現了SWIG、boost::python等，讓擴充Python變成一件更簡單的事情，但是即使是如此，這還是笨重的方法，產生了笨重的二進制檔，笨重的編譯工作，對於只是要將c語言的library擴充給Python使用而言這還不夠好，接著，終於有了進化，ctypes出現了，人們想說，與其做出pyd來給python使用這種多此一舉的事情，東西就在那裡，dll就在那裡，為何不能直接使用呢? ctypes的目的就是讓Python可以直接操做c語言寫的dll，這是一個大躍進，到了python2.5 ctypes還成為了標準的模組之一，這表示新的時代的到來 對ctypes的懷疑 相對於熟悉的事物，面對類似性質但是不同的事物時，總難免有多少疑惑，我在一開始也懷疑這樣能做到什麼地步? 但是在看了它的文件後我瞭解到，大部份dll使用ctypes都可以應用得很好，像是我擔心的callback，ctypes一樣可以提供方法來把python的函數包裝成c語言的callback丟給c語言的dll，運作得很好，其中我最擔心的是多緒的問題，因為有些callback是從其它thread呼叫的，因此如果沒考慮到multi-thread問題的話，callback就廢一半了，但是它一樣也考慮很週到，即使是從不同thread呼叫的python callback，也一樣可以運作得很好 舉個例子 DSPPROC = WINFUNCTYPE(None, HDSP, DWORD, c_void_p, DWORD, c_void_p) 在有了c語言函數的原形建立後，我們就可以使用它來包裝python的函數丟給c語言的dll處理 print BASS_Init(-1, 44100, 0, 0, 0) stream = BASS_StreamCreateFile(False, ‘c:\god know.mp3’, 0, 0, 0) print stream def dspProc(handle, channel, buffer, length, … Continue reading
簡單版本的視覺化tracert
簡單版本的視覺化tracert Continue reading
Python實作tracert
用Python實作tracert
Implement tracert with Python Continue reading
Mapnik整合wxPython
介紹如何整合Mapnik與wxPython Continue reading
別讓危險成為預設的行為，讓危險的行為比安全的行為更麻煩
危險的行為 對於寫程式而言，很多預設的行為都是相當危險的，舉一些最常見的例子SQL Injection、XSS、Buffer overflow，我們可以從這些幾個最常出現被攻擊的類形，都有一個共同的特點，就是它們通常都是因為預設的行為很危險，我們一個一個來看