2014年4月27日 星期日

pygame framefork 持續進行中

這個project的進度實在沒辦法進行的很快,畢竟現在我只有每周末可以回家寫,但是每次回到家都想要休息,另外一部份的原因實在是因為我對於設計GUI框架,沒有太多的概念,所以目前也只是按照我個人的想法來包裝,因此隨時都會有改動,最近感覺每次回到家,都要重新看code回想一下自己當初的想法是啥 :) 這樣感覺有點麻煩,所以這篇主要是來記錄一下目前的想法和進度的 :)

目前寫到這樣的結構,其實我已經開始有點混亂了,目前我是寫在 imageCropper裡面,並沒有將這個framework分層,因為目前只是測驗性階段,加上python是動態語言,所以沒有將code分層是不會影響到效率的。

我寫了這個測試,發現我的包裝少了什麼東西,就會回去把包裝修改一下,目前我有很多疑慮,像是

1.寫個物件是處理座標系統的,因為發現了絕對座標和相對座標的問題。
2.寫個物件是來計算每個widget位置的安排,像是考慮到margin padding等問題。
3.widget是不是該包含update這樣的函式,可是如果在每次的gameloop都call update,這樣會不會有效率上的問題,這樣一直改來改去,想來想去,讓我有點不知道所措。
4.需不需要把widget的屬性,另外用json的方式來進行讀取和設置

實在是有太多太多地方需要思考,現階段可能就以先增加其他widget再說吧,像是listbox、scrollbar等,另外我也在想寫遊戲裡的GUI,有必要寫到那麼麻煩嗎? 我一直在思考這些事情,所以project進度也一直沒很大的進展,所以我在想要不要稍微停下來,讀一下別人的open source來擷取一些想法,只是我查了一下pygame gui 的相關open source,大致上只有pgu 感覺比較好一點,可是我又覺得它似乎有點太雜了,再加上似乎沒有在維護了,到最後我找了一個based on pyglet 的game gui,就是這個simplui ,他也是沒在維護了 :( 只是相對我覺得他比較lightweight,所以我決定從這個下手,因為可能比較好讀 :) 不過我沒什麼閱讀open source project的經驗,所以可能會讀比較久一點,才會有相關的心得就是了,而且萬一他用到比較有技巧的東西,那可能就要更久了 :)

目前大概要一段時間才會PO 跟 framework有關的文章了 :)





2014年4月20日 星期日

c++ static_cast, dynamic_cast, const_cast, reinterpret_cast

最近又稍微碰到這類的問題,想說來複習一下也不錯,這邊有不錯的解說 ,可以參考一下,這篇主要是記錄一下這四種type conversion的方法,基本上一扯到conversion,想當然爾,就會關係到C++裡面有的一個很需要注意的東西,那就是implicit conversion和explicit conversion,所以就先來講這兩個東西,就如同字面上的意思一樣,explicit是明顯的意思,因此explicit conversion
大家都應該很熟悉,就像是...

int i(5.2);

這樣藉由 ( ) 這樣的語法轉換型態,就是明顯的轉換,那麼implicit是隱含的,所以什麼是隱含的轉換呢? 其實大家應該都常常寫到,只是不自覺,所以會很恐怖 :) 像是..

double d = 5.2;
int i = d; //相當於 int i = int(d) 或 (int)d

在你initialize的同時,C++會自動幫你轉換型態 :)
或許這樣一看你會覺得不知道恐怖在哪是吧 :p
的確今天的型態如果只是primitive,那你大概是不用怎麼怕,那如果是自己定義的呢??
舉個例子

#include <iostream>
#include <typeinfo>
using namespace std;


class A
{
public:
    A(int a=0)
    :mx(a)
    {
    }

private:
    int mx;
};

void test(A obj)
{
    cout<<typeid(obj).name()<<endl;
}


int main()
{
   test(2);

   return 0;
}


你將會看到,嘿嘿成功執行,你傳入的參數2,其實已經成為classA的copy constructor的參數了,你也可以看到印出來的type的確也是class A,上面只是跟你說一下,型態轉換在C++上面是很恐怖的,常常在很多你想不到的地方,他就發生了,就像這樣,如果哪個一個不小心,就會造成或許不是你預期的結果 :)

哼哼尤其是在stl中,如果你想用到user defined class且有包含指標型態的話,通常最好要定義一下你的copy constructor,因為大概會被call到。關於這邊改天有心情的話,就來用個例子好啦 :)

該來講一下四種cast的方法,在我上面給的那個連結基本上已經不錯的解說了,所以這邊就簡單總結一下而已

static_cast
可以call implict conversoin和explicit conversion
另外還有upcasting和downcasting
只是他不像dynamic_cast會做動態的檢查

dynamic_cast
負責掌控 upcasting 和 downcasting


const_cast
它可以強制加上或拿掉一個變數的const特性,雖然我不知道這樣的實用在哪就是了 :-S

reinterpret_cast
一個很恐怖的東西,它可以強制轉換型態,任意的轉換,所以不要亂用

另外關於這些cast想要更詳細的,可以看看 這篇  :)

2014年4月12日 星期六

試著寫一個小小的framework for pygame

首先就來說說,最近逛著一些論壇,發現越來越多framework跑出來,尤其是關於javascript的,看著那些強大的framework,總覺得自己的程式實力,仍需要很大的努力 :(

有時候看著別人用framework寫出很多不錯的應用程式,我心裡常這麼想著我是否也該要試著玩玩看,像我用python寫程式,python其中的宗旨是do not repeat yourself,這想法的確沒錯,已開發產品來講確實是這樣,因為這樣開發速度才會快,畢竟從0~1是很辛苦的,也很耗時,所以我也碰過一些python的library,像是pygame、pyglet、pillow、pyqt...等,但是問我對他們有沒有完全熟悉,我只能說大概沒有吧,我並沒有把裡面所有個函式都碰過,甚至也沒有將他們記起來,我都是想到需要什麼功能,就去官方文件查查有沒有相關的功能,所以我很常邊查文件邊寫程式。

其實這樣讓我有點擔心,因為要是沒有網路這樣一來我就不是變的不會寫程式了嗎?? 因為沒有文件可以查...可是對於python這語言大概是不太用擔心,因為library本身就幾乎是源代碼,所以可以直接去看源碼,除非他將一些核心用成dll等藏起來,但是對於C++呢? 除非library本身自帶文件那就不用怕了,只看header file你也不會懂那是啥,除非它有寫註解 :P。

在此同時,大量framework充斥的現在,讓我開始擔心起一件事,那就是我們這些後人,或許懂得快速利用哪棵樹來乘涼,但是懂得種樹嗎? 現在已經越來越少人種樹了,因為耗時、耗力,甚至是因為你自己種的樹不見的比其他人好 :(

就以小弟學了演算法來講,光是排序的問題好了,別人的library,可是有顧慮到對於不同的compiler和不同的作業系統甚至是記憶體的情況也考量進去,並分別給予不同的優化,這些種種,不是光隨便看幾天的書就可以寫出來的東西,自己或許真的可以寫出來,但是要花多久時間呢? 但是相對的,用別人的library呢? 花個幾秒的時間,你就可以達到相同效果,的確是何樂而不為呢 :) 這也是為啥懂得用別人的library,也是一件很重要的事 :)

話雖如此我還是覺得身為一個programmer,必須要懂得種樹,要不然programmer還有什麼價值? 只是看看文件,call一下function,說難聽點誰不會啊? 所以我還是選擇一個比較不好走的路,就是每個東西,都玩玩看,不管是底層,還是高階的framework,也因此我決定先來個小小的嘗試,那就是為pygame這個library寫個小小的framework,由於pygame本身並沒有GUI,所以我決定來練練如何自己包裝出一個GUI framework,雖然這並不是多底層的技術,但是我覺得這可以訓練一下,如何讓自己寫出一個大程式且附有重用性,以前我寫過最多行的專案了不起也才快2000行,我想要讓自己有更大的進步,目前我心中也沒有把整個程式結構想出來,一來是因為我查了一下網路,並沒有發現關於設計GUI的程式結構概念,或許有的? 如果有的話,希望好心人可以告訴我一下(留個言),目前的結構是這樣的,我先實現幾個widget,label、button和一個可show image的widget,如下圖,當然我也有包裝了一下,事件處理迴圈,相關code可以看這邊


只是目前我覺得我寫的這些code,可能以後會有很大的改變,畢竟目前我是依照直覺去包裝,往後如果有了整體的想法,就會另外PO一篇來記錄一下 :)