Home > Tags > C++

C++

要做 Visual Studio 樣子的使用者介面? 用 DockPanel Suite 吧!

雖然引擎連1%完成度也沒有,今天開始做遊戲的編輯工具,或者應該說是做工具的原型,一切都當作是實驗吧。

DockPanel Suite 的 Sample Screenshot
(這是 DockPanel Suite 的 Sample,不是 Visual Studio 啊! )

之前已決定採用開源的 DockPanel Suite。它是一個 C# 開源的 .Net 程序庫,基本上做到 Visual Studio.Net 的視窗 docking 功能,包括 tabbed window、split window、float window、docking indicator、auto-hide、讀寫 XML 設定檔等等。我是看到 Cg Composer 的 DLL 才知道有這個 .Net 程序庫,後來也找不到更好的選擇。

Continue reading

關於表頭檔的 inline function

閱讀了猴子靈藥《表頭檔要不要?拿速度來換!》後,發覺所言甚是,表頭檔的問題許多時會被忽略。現在寫的代碼,除了考慮執行效率,也應該要考慮編譯效率。

關於在標頭檔寫 inline function 而增加編譯時間,本人有一點看法,就在此和大家分享。

首先,我們知道

Inline function 的目的是增加執行效率,但一般在 debug 版本是不會被展開的,只有在 Release mode 才會用到。

那麼,在編譯 debug 版本中使用 inline function 只會增加編譯的時間。基於這一點,我現時的”引擎” (不知何時才能算是真正的引擎,可以去除引號)的代碼 layout 就使用 macro 去解決這個問題。所有類別的代碼 layout 分為 3 個檔案: header (.h), inline (.inl) 和 implementation (.cpp)。例如:

Continue reading

使用 Custom Build Tool 執行 SWIG

今晚完成了近期的第三個目標,加入 Script Module 的 Binding (其實只是一個叫 Runtime 的類別),利用 C# 去執行之前的 Lua 的程序 (test1.lua)。

今早 Edwin 的回應啟發了一些想法,所以著手更改 SWIG 在 Visual Studio 的編譯方法。

現在採用了Visual Studio 的 Custom Build Rule。由於 Lua 和 C# 需要不同的規則,所以要兩個 file extensions,我設定 Lua 的 Swig Interface 檔案為 .li,C# 則是 .ci。

Lua

swig
 -c++
 -lua
 -o $(OutDir)/$(InputName)Lua.cxx
 "$(InputPath)"

C#

swig
 -c++
 -csharp
 -o $(OutDir)/$(InputName)Cs.cxx
 -outdir $(OutDir)
 -namespace Mil.$(InputName)
 -dllimport $(TargetName)
 "$(InputPath)"

生成的檔案會放置於 Debug 或 Release 的輸出目錄,解決之前兩個 configuration 會互相影響的問題。

兩個規則分別生成 $(OutDir)/$(InputName)Lua.cxx 和 $(OutDir)/$(InputName)Cs.cxx,這些檔案需要加入 Project 裡。但因為一個項目不應該同時加入 Debug 和 Release 版的這些檔案,我想到的方法是寫一個 .cpp 去 #include 這些檔案,例如:

// MathCs.cpp
#include "stdafx.h"
#include "MathCs.cxx"

之後再把 Project 的 Include path 加入 “$(OutDir)”,那麼,就可以正確地編譯現時 Configuration 的 Swig 生成檔案。

後來再試驗檔案的 Additional Dependencies 屬性,設定單一檔案仍然不成功。之後我把 .li 和 .ci 裡 include 的檔案改名為 .lii 和 .cii,希望只要可設置 dependencies 為 *.lii 和 *.cii 就可以了,但都不成功。或許可以用 Pre-Build Event 去檢查這些檔案,如比輸出檔案新就 touch 那個 .li 或 .ci。不過未嘗試。

最後,還有一個問題是 C# 的 Proxy 需要編譯多個由 SWIG 生成 .cs 檔案。我找了一回才發現 C# 沒有 #include、也似乎沒有機制可以編譯 *.cs 等多個檔案。最後暫時用 C++ Project 的 Post-Build Event 把適當 Configuration 的檔案拷貝到 C# 的項目裡,再人手加入這些檔案。

copy $(OutDir)\*.cs ..\MilCs

實作簡單的材質

進度有點緩慢,今天才完成了 3月6日定下的第一個目標。

使用 blinn_bump_reflect.fx 的渲染

今天的學習進度:

  1. 設定 Matrices 及修正相關函式: 現時設定為 column-major。改正相關函式花了很多時間。
  2. 修改 ChamferBox: 由於 ChamferBox 只負責生成一個 Geometry 物件,所以把 constructor 改為一個 function。原本想嘗試做一個 non-member function,但是 SWIG 部份有問題,花了一兩個小時也找不到解決辦法,所以現在改為一個 static member function。
  3. 實作 Material: 使用 HLSL fx 檔案在建構一個 Material (在 Direct3D9 上而已,之後再考慮跨平台的設計)。利用 FX Composer 的 Blinn.fx 測試渲染。
  4. 加入 Texture: 因為 blinn.fx 需要 diffuse texture,又實作了一個 Texture 類別,和 Material 相似,也是從 constructor 讀入一個影像檔案。
  5. 測試 blinn_bump_reflect.fx: 因為這個 Effect 需要 Tangent 和 Binormal,所以實作了
    void GeometryBuilder::ComputeTangentSpace(int texcoordIndex)

    函式從三角形網格計算這些向量,當中參考了這個網站的實作

  6. 加入 CubeTexture: blinn_bump_reflect.fx 需要環境貼圖,因此加入這個類別。並重構 Texture,使 Texture 和 CubeTexture 繼函自 TextureBase。

Continue reading

開始實作圖像引擎

昨晚只是寫 Blog 已經花了幾小時。不過這也是值得的,因為我可以從寫的過程中把思路弄清楚一點。今晚終於開始編程。

詳細的設計留待一兩天才說吧,今天基本上只寫了一些數學部分、Direct3D9 的起動、一個叫 Geometry 的類別和一個 Chamfer Box。但全部都通過編譯但未進行測試。

我希望在這幾天內實現以下的產出 (deliverables):

  1. 在 C# 創建的視窗中渲染一個旋轉 Chamfer Box,只有直線光源。
  2. 用 C++ 和 Lua 寫同一個和 (1) 相同的程序。
  3. 用 C# 創建的視窗中運行 (2) 中的 Lua 的程序。
  4. 在 cygwin 上執行 (2),使用 gcc 和 OpenGL。

過了這一步,就可以加入輸入和嘗試做一些遊戲性相關的實驗。有時間的話,也想找一部 PSP 用開源的 SDK 試試移植。

混合語言的遊戲開發系統架構

用甚麼程式語言來做軟件是一個大問題,思考了一個周末,現時想做一個混合語言的遊戲開發系統架構。暫時只考慮三種程式語言: C++、C# 及 Lua。以下首先分析這三種語言的特性,之後再提出一個系統架構科案。

Continue reading

試驗SWIG (一) C++ 連接C#和Lua

今晚初次嘗試使用 SWIG (Simple Wrapper Interface Generator)。SWIG 是一個能為 C/C++ 程式生成各種 Script 語言 Wrapper 的工具。簡單地說,就是有了一個 C++ 程式,用 SWIG 來連結這個程式和 Script,使腳本語言可以呼叫 C++ 的函數及類別等等。

SWIG 支持大部份 C++ 的功能,甚至 template 也能支持。同時可以生成十數種腳本語言的 wrapper,包括我正在考慮使用的 Lua、Python 和 C# 等。

跟據我的目標,先做一個 3D Vector 的測試。以下是一部份C++代碼 (Vector3.h):

Continue reading

Home > Tags > C++

Search
Feeds
Meta

Return to page top