《OpenGL 3 & DirectX 11: The War Is Over》:繪圖 API 終戰之日?

OpenGL Logo

(圖片來源:www.cnblogs.com)

原文出處:OpenGL 3 & DirectX 11: The War Is Over

現今在 DirectXOpenGL 皆已相當普及的年代裡,我們似乎也逐漸淡忘了兩者從前的那段江湖恩怨。在著名硬體網站 Tom’s Hardware 的這篇專欄文章裡,作者帶領我們重新回顧這場「繪圖 API 戰爭」中的起伏轉折,以及 OpenGL 3 與 DirectX 11 的未來展望,是篇值得仔細閱讀的好文章。

「DirectX 最殺!很強很邪惡的微軟帝國萬歲!」
「想跨平台嗎?OpenGL 才是唯一的光明道路!」
「我是初學者,應該要選擇 DirectX 或 OpenGL?」
「我想做出一款超棒超好玩的遊戲,要用 DirectX 還是 OpenGL 比較好?」

身為遊戲程式設計者,如果你有定期瀏覽國外各大程式論壇的習慣,應該會對以上這些問題感到非常親切、熟悉,而且可能還會有些反感吧?在遊戲程式設計相關領域的討論區裡,最常見的萬年討論串非「DirectX 與 OpenGL 的比較」莫屬。DirectX 與 OpenGL 雙方各有死忠的支持者陣營,只要在網路上裡提出類似以上敘述的問題,往往會引來雙方擁護者激烈的對抗與辯論;如果又不小心觸動了某些資深程式設計者的「逆鱗」,就更加會戰到天荒地老無以復加。

在過去的短短幾年之內,我們親身經歷了消費性 3D 顯示卡市場的爆炸性成長。從以前只有硬派玩家會花大錢購買的「3D 加速卡」,到現在幾乎已成為標準配備的「3D 顯示卡」,電腦繪圖硬體不僅成功地打入了一般消費者的市場中,其性能也獲得革命性的突破,目前 GPU 的電晶體數量甚至已經超越了 CPU。時至今日,DirectX 與 OpenGL 在電腦繪圖與遊戲業界中的地位,究竟是處於分庭抗禮的情勢,或者已經分出了勝負?且讓我細說從頭。

Continue reading

《Measuring Responsiveness in Video Games》:測量與分析遊戲的回應性

stopwatch原文出處:Measuring Responsiveness in Video Games

本文接續前篇文章「《Programming Responsiveness》:遊戲程式設計中的回應性」的遊戲回應性 (Responsiveness) 以及遊戲回應延遲 (Response Lag) 議題,進一步提出能夠實際測量反應時間的方法,同時對各款遊戲作品的回應性表現進行測試與分析。

(圖片來源:http://www.geardiary.com/)

在前文中,提到了遊戲開發者易於忽略的遊戲回應性問題,但是並沒有提出實際的測量方法;如果我們只使用人眼去觀察遊戲是否產生延遲情形,是相當主觀而且不準確的測量方法。身為遊戲開發者,我們需要更加精確的方法以及更為客觀的數據,才能夠證明遊戲的回應性緊密或者遲緩。在 PC 平台的遊戲上,通常比較少對於 FPS(遊戲每秒畫格)做出限制,強制鎖在 30 FPS 或者 60 FPS 的數值;但是在 Console 的平台上,遊戲需要從 30 FPS 或 60 FPS 中做出選擇。如果能夠取得客觀的延遲時間數據,遊戲開發者就能夠更明智地在兩個數值之間做出抉擇,進一步強化遊戲畫面以及遊戲操控性的表現。

想要測量遊戲中的延遲時間並不困難,只需要準備一台具備攝影功能的數位相機,對準遊戲中的電視螢幕與操縱手把進行錄影。作者使用的是便宜且常見的 Canon Powershot SD800IS 相機(我不清楚這台相機的價格算不算是便宜 XD);將相機設定調整至「運動模式」或「快速畫格取樣率模式」,然後把取樣數調整至「60 FPS」後,使用腳架置放於電視螢幕前面;如圖所示,使相機能夠清楚地拍攝到電視螢幕畫面以及手上的遊戲手把,就可以開始拍攝遊戲中的各種操縱動作與結果反應。拍攝完畢後,可以使用 QuickTime 或其他播放軟體,以鍵盤的方向鍵每次移動一個畫格播放,計算出由按下按鈕到畫面呈現結果所花費的畫格數,也就是遊戲中的回應延遲時間。

Continue reading

《Programming Responsiveness》:遊戲程式設計中的回應性

armored-core原文出處:Programming Responsiveness

在玩遊戲的經驗裡,你是否覺得有些遊戲玩起來不太順暢,但又說不上來是什麼原因;明明是單機的遊戲,卻覺得操作反應有些 Lag;狙擊槍的準星明明抖個不停,竟然也可以命中敵人。這篇文章裡,作者對於遊戲的「回應性」(Responsiveness) 這個鮮少有人提及的議題,做出了詳細的觀察與探究,非常值得遊戲程式設計者與遊戲企畫設計者閱讀參考。

(圖片來源:http://games.mattsarrel.com/)

如果以軟體領域的角度來檢視,遊戲軟體與其他軟體最大的不同之處,或許就是在於遊戲對「即時反應」(Realtime Response) 的嚴格要求。在一些節奏比較快速的遊戲中,如第一人稱射擊、賽車競速或音樂節奏類型遊戲等等,甚至不能夠承擔超過零點幾秒的延遲誤差。那怕只是一點點的延遲反應而已,都會破壞玩家對於遊戲的投入感;更甚者,也可能就此在玩家心中埋下難以逆轉的負面印象。

Response lag is the delay between the player triggering an event and the player receiving feedback (usually visual) that the event has occurred.

「回應延遲」(Response Lag) 的定義,是指從玩家觸發事件,直到玩家得到回饋反應的延遲期間。觸發事件,是指玩家藉由搖桿、手把、鍵盤或滑鼠等輸入裝置,觸發遊戲系統中的行為動作;而回饋反應,則通常是指遊戲中的視覺面呈現。如果在「觸發事件」與「得到回饋」兩者之間的延遲期間過於冗長,將會造成玩家認為遊戲反應遲鈍、動作慢吞吞或是操縱不順暢等等負面觀感。

Continue reading

《Top 10 Traits of a Rockstar Software Engineer》:明星程式設計師必備的十項特質

原文出處:Top 10 Traits of a Rockstar Software Engineer

這是一篇很有意思的短文。文中條列出不多不少、總共十項優秀軟體工程師所應具備的特質,並且很微妙地將軟體工程師比喻成搖滾明星。你是公司的主管嗎?按照這些特質尋找人才就對了!你是在學的學生嗎?按照這十項特質的方向努力學習就沒錯了!

在這十個特質中,我認為最關鍵、同時也是寫得最為貼切的莫過於第一點:Loves to Code


1. 真心喜愛程式 (Loves to Code)

程式設計,是一種發自於內心、不求回報的付出 (Labor of Love)。如同任何的職業一樣,唯有具備滿滿的熱情,才能完成真正偉大的事情。一般人的誤解,常認為撰寫程式是一種機械化,或者純然科學化的行為。事實上,最棒的軟體工程師是工匠 (Craftman),能夠將能量、巧思以及創造力注入每一行的程式碼當中。優秀的工程師,知道程式碼區塊何時被琢磨至完美的程度,也知道在大型的系統中,這些區塊何時會如同謎題般巧妙地拼湊組合起來。熱愛撰寫程式的工程師所獲得的喜悅感,就像是作曲家完成一首交響樂所感受到的狂喜;而也正是這種興奮感以及成就感,使優秀的程式設計者們真心熱愛程式設計。

Continue reading