2015年9月10日 星期四

[懷舊] jmcce 1.5 (3) - jmcce 1.6 α

還沒有 release jmcce 1.5 就直接跳 jmcce 1.6 了。因為實在太興奮, 所以急著 po 出這個訊息, 這還是一個火力展示的版本, 連堪用都稱不上, 要達到某個實用性還需要不少時間, 我相信這個版本的實用性會大增, 為什麼呢? 因為我終於加入我想要的功能了。

讓 jmcce 支援 freetype2 和真正的 utf8 encoding。



上述影片會 cat 出 b 檔案的內容, 有簡體中文、繁體中文、日文, 呼 ... 總算出來了, 心中的興奮到現在還不能忘。

之前支援 utf8 是轉成 big5 再由原本的 code 秀出, 實在太蠢了, 不過要徹底改造 jmcce 完全支援 utf8 可不是只有編碼的困難, 還得把底層的字型系統換掉, 因為其原本的字型是用 big5 去查詢該字型的 bitmap, 所以無法支援 utf8, 之前我只能用 utf8 轉 big5 來支援 utf8。

那該怎麼辦呢? 我使用了 freetype2 並搭配 unifont.pcf.gz 這個字型, unifont.pcf.gz 剛好是 8x16, 16x16 的字型, 剛好可以套在 jmcce 640X480 的環境上, 我可以先避免計算字型大小、位置等問題。而且他是 unicode 字型, 用這一個就可以秀出簡體中文、繁體中文、日文, 不需要去切換不同字型, 程式寫起來比較簡單。

再來是 unicode 編碼問題, 使用 freetype2 需要能將 utf8 轉 ucs-4, 我為這問題苦思許久, 還用上 qt qstring (為了使用 qstring 要 link qt, 怎麼都覺得不划算), 好在 c++11 的即時到來解了我這問題。c++11 提供了 utf8 轉 ucs-4 的程式庫, 不過 gcc 得用 g++-5 才支援, clang 則需要在安裝 libc++, 而又好在 g++-5 的到來, 我省了些麻煩。

改寫 hztty_write() [console.c], 換掉其中的 draw_hanzi_char(), draw_ascii_char() 搭配 freetype2, 總算有了目前的成果。

unifont.pcf.gz 是 bitmap 字型, 所以沒有 anti-alias, 字型沒那麼美觀, 不過這是巨大的一小步, 能完成他, 我覺得很有成就感。

不過閒暇時間不多, 要能完成到可以使用, 可能要花上一段很久的時間, 現在問題還蠻多了, 而且 linux framebuffer 我實在不熟, 老是畫錯 pixel 的位置, 雖然有 virtulbox 可以方便 debug, 但還是得花上不少時間。

其實 fbterm 已經做得很好了, 也有輸入法可用, 在穩定度實用性都勝過 jmcce 不少, 字型支援也比較好, 顯示速度也贏 jmcce 不少 (以 linux framebuffer 顯示來比較), 我在想我有必要把時間花在 jmcce 上嗎? 也罷! 就讓 jmcce 先停留在 1.6 α 好了。

需要改善的部份:
畫字的速度要和 fbterm 一樣快
使用 framebuffer 畫字的錯誤
對於任意解析度都可以正常秀字

fbterm
apt-get install arphic* fbterm fbterm-ucimf

arphic* 會把 fbterm 需要的中文字型裝起來。

ref:
使用fbterm等组件实现Linux终端下中文文本的显示和输入

20150909 補充:
我終於知道為什麼 fbterm 的秀字可以那麼快了, 這個問題困擾我很久, 我瘋狂的比對 fbterm 和我的 render 程式碼, 改寫了一些, 但還是沒有 fbterm 的速度快。

它有一個 cache 可以 cache 住從 freetype2 找到的字型 [Font::Glyph *Font::getGlyph(u32 unicode) ], 這樣就不用再去呼叫 freetype2 api 再找一次, 不過這不是最根本的問題, 因為我從程式碼早已經知道, 也做了測試, 確定不是這個因素。

我之前參考了 fbterm, 做了以下的改進:
  • 將 bitmap 的回圈數降低, 找出 bit 為 1 的資料 [Font::Glyph *Font::getGlyph(u32 unicode)]
  • 使用了一個 u32 而不是 u8 來設定 rgba 顏色, 只要 assign 一次, 而不是分成 3 次 (void Screen::draw##bits(u32 x, u32 y, u32 w, u8 fc, u8 bc, u8 *pixmap) )
  • 移除背景顏色, 只畫前景 pixel

而這些改進完全沒有改進秀字的速度。

另外一個因素是字型檔案本身, 我的程式使用 unifont.pcf.gz 來秀字, fbterm 用了bsmi00lp.ttf, 看來是 freetype2 api 用 ttf 時可以更快的找到 glyph, 我只換了這個字型, 秀字就飛快的加速了。

疑惑解除了真是開心, 我還以為有什麼特別的祕密呢。

沒有留言:

張貼留言

使用 google 的 reCAPTCHA 驗證碼, 總算可以輕鬆留言了。

我實在受不了 spam 了, 又不想讓大家的眼睛花掉, 只好放棄匿名留言。這是沒辦法中的辦法了。留言的朋友需要有 google 帳號。