首先決定暫時(shí)不考慮DX9/OGL了，我不可能在不了解一個(gè)庫(kù)的時(shí)候就給它留好接口。耽誤我挺多時(shí)間了，雖然有重大收獲……
今天的成就是把Shader啟動(dòng)起來(lái)了，做了一個(gè)花的三角形。
不管怎么說(shuō)，拋棄Framework不談，本周完成界面顯示還是沒(méi)什么大問(wèn)題的。剩下的時(shí)間我還是去讀讀ConfigSystem（DXSDK里一個(gè)很囧的小球Sample）的整體結(jié)構(gòu)，還有讀讀DXUT的代碼了。
如果順利的話，我也決定采用DXUT開發(fā)，因?yàn)槲覜](méi)有必要在對(duì)整體流程已經(jīng)了解的情況下，對(duì)每個(gè)細(xì)節(jié)了如指掌。我的關(guān)注點(diǎn)還是：資源管理、框架、Shader。不能偏離了學(xué)習(xí)DX的目的。

沒(méi)弄明白怎么粘圖，那就不管了，反正一個(gè)破三角形也沒(méi)什么好看的……
隨便改了改代碼，用RenderMonkey時(shí)寫的一些vs和ps的東西還記得。
另外Dx10的用于輸出的一些Semantics的名字改了：

Direct3D 10 Semantic	Direct3D 9 Equivalent Semantic
SV_Depth	DEPTH
SV_Position	POSITION
SV_Target	COLOR

不管怎么說(shuō)總是麻煩了一點(diǎn)。討厭的是RenderMonkey在我的電腦上沒(méi)裝起來(lái)，不能方便的編輯shader然后輸出fx了。明天還是研究下如何輸出編譯的錯(cuò)誤信息。好歹編不過(guò)要能告訴我是哪行編不過(guò)才行……

現(xiàn)在的Shader代碼：（就隨便搞了下，顯示出一個(gè)暗紅色的怪東西：）
struct VS_OUTPUT
{
 float4 Pos : SV_POSITION;
 float4 Color: COLOR0;
};

VS_OUTPUT VS( float4 Pos : POSITION )
{
 VS_OUTPUT Output;
 Output.Pos = Pos;
 Output.Color = float4( 0.3f, Pos.y, Pos.x, 1.0f );
    return Output;
}

struct PS_OUTPUT
{
    float4 RGBColor : SV_Target;  // Pixel color   
};

PS_OUTPUT PS( float4 Pos : SV_POSITION,
    float4 Color: COLOR0 )
{
 PS_OUTPUT Output;
    Output.RGBColor = Color;
    return Output;
}

technique10 R0
{
    pass P0
    {
        SetVertexShader( CompileShader( vs_4_0, VS() ) );
        SetGeometryShader( NULL );
        SetPixelShader( CompileShader( ps_4_0, PS() ) );
    }
}

主要是把Tutorial2里的fx拿出來(lái)，把兩個(gè)輸出從單純的float4變成了一個(gè)結(jié)構(gòu)體，然后給VS的輸出增加了一個(gè)Color，最后再把坐標(biāo)的一部分當(dāng)作顏色輸出了出去。

我究竟是不太能接受這種不規(guī)則的學(xué)習(xí)方式，而且太心急太有壓力太怕完不成，只能退而求其次。我想如果用glut寫完還有剩余的時(shí)間，我會(huì)把它轉(zhuǎn)到win API。而且我相信FamilyBlock的邏輯并不難，我有信心快速完成它。

好吧，今晚有重大突破，那就是：窗口顯示出來(lái)老！v ~。~b
就是DXSDK里那個(gè)藍(lán)藍(lán)的窗口，不過(guò)我為了搭建Frame，繞了好多彎，剛剛才終于顯示出來(lái)。
目前完成了GraphicsDevice類的創(chuàng)建了，我正在考慮怎樣設(shè)計(jì)通用的點(diǎn)列表、材質(zhì)等等接口，得尋人咨詢下OpenGL的關(guān)于點(diǎn)列表的接口。如果大家都是自定義結(jié)構(gòu)體+參數(shù)那就沒(méi)什么好說(shuō)的老，把點(diǎn)列表做成一個(gè)點(diǎn)容器那么復(fù)雜似乎也沒(méi)有必要。唉，做到再說(shuō)吧！

目前的主函數(shù)代碼：

int _tmain(int argc, _TCHAR* argv[])
{
 InitFramework();
 CComPtr<IGraphicsLibrary> pGL;
 if (FAILED(GetDefaultFrameworkLibrary(&pGL)))
 {
  wprintf(L"No default graphics library found.\n");
  ATLASSERT(false);
  return 1;
 }
 CComBSTR bsGLName;
 if (SUCCEEDED(pGL->GetLibraryName(&bsGLName)))
 {
  wprintf(L"Default graphics library is: %s\n", (BSTR)bsGLName);
 }

 pGL->EnumAdapters();

 CComPtr<IGraphicsDevice> pGraphicsDevice;
 if (FAILED(pGL->CreateGraphicsDevice(FALSE, 640, 480, L"Only a test", &pGraphicsDevice)))
 {
  ATLASSERT(false);
  return 1;
 }

 FrameworkSimpleMainLoop(pGraphicsDevice);
 return 0;
}

最后的FrameworkSimpleMainLoop就是近似傳說(shuō)中的glutMainLoop啦，不過(guò)為了避免全局變量，我把pGraphicsDevice給傳進(jìn)去了……
然后想想貌似這里沒(méi)什么避免全局變量的必要（或者整個(gè)類，然后用靜態(tài)變量算了）。現(xiàn)在的話，如果想在MainLoop內(nèi)更換GraphicsDevice，原來(lái)的Device的引用計(jì)數(shù)也釋放不掉了。
然后覺(jué)得一開始的注冊(cè)可用庫(kù)之類的流程也要改，目前那個(gè)全局map也會(huì)把所有的DLL都保留著，沒(méi)有釋放掉。
最好的辦法是，全局map里只保留創(chuàng)建函數(shù)，在獲取Library。主程序可以Enum每個(gè)可用類（按接口），傳遞GUID進(jìn)去，獲得一個(gè)接口，也可以選擇創(chuàng)建默認(rèn)類，然后獲得一個(gè)接口。在InitFramework的時(shí)候，每個(gè)DLL只嘗試性連接，如果連接成功，可以立刻釋放。等到對(duì)應(yīng)的類被創(chuàng)建的時(shí)候再去重新連接。
另外在ToggleDevice的方面還沒(méi)什么好的想法。或者干脆維護(hù)一個(gè)Device列表？列表內(nèi)的被Render。這也是需要改進(jìn)的。

      今天把瑪麗醫(yī)生的界面規(guī)劃了一下，規(guī)劃的是那么的美好。中午吃完飯連寢室都沒(méi)來(lái)得及回就趕來(lái)實(shí)驗(yàn)室寫代碼，但是萬(wàn)惡的XYLayout讓我寒心了。
      以前只是聽說(shuō)過(guò)XYLayout，但還是沒(méi)有用過(guò)。今天規(guī)劃界面的時(shí)候我想到了XYLayout，自己幻想XYLayout挺好的，對(duì)每個(gè)組建都固定一個(gè)位置，這樣做界面太好了。可是回來(lái)之后寫了代碼居然發(fā)現(xiàn)JDK里面竟然無(wú)法編譯，當(dāng)時(shí)那個(gè)心情啊。后來(lái)想想，還是先寫功能吧，屏幕上就先出來(lái)一個(gè)16*8的格子加上菜單，另外的界面就等等再說(shuō)吧。      摘要:   閱讀全文 暈死了都，為什么<gl\gl.h>前面一定要加#include <windows.h>……………………崩潰的link error
不就是一個(gè)小小的ReadBMP24函數(shù)，我想里面就用了個(gè)GLubyte類型，沒(méi)用啥別的，go to definition一下，定義在gl\gl.h里，就把頭文件從glut換成了gl，于是出現(xiàn)了崩潰的link error。上帝啊，不帶這么折磨新手的。
抓狂中……

今天早上意圖創(chuàng)建Device和SwapChain。這沒(méi)什么問(wèn)題，但是我意圖通過(guò)模板演繹和宏來(lái)簡(jiǎn)化對(duì)動(dòng)態(tài)鏈接的DLL中函數(shù)的調(diào)用時(shí)，我寫的模板和宏不能正常工作。
我寫的函數(shù)和宏如下：
template <typename FuncType>
FuncType __forceinline GetModuleFunc(HMODULE hModule, LPCSTR lpProcName, FuncType /*pFunc*/)
{
 return reinterpret_cast<FuncType>(GetProcAddress(hModule, lpProcName));
}

#define CallModuleFunc(Module, ProcName, Args) (GetModuleFunc(Module, #ProcName, ProcName))?((GetModuleFunc(Module, #ProcName, ProcName)) Args) : E_FAIL

思路是通過(guò)函數(shù)的聲明演繹出函數(shù)類型，進(jìn)行強(qiáng)轉(zhuǎn)然后調(diào)用。

失敗原因是盡管沒(méi)有直接調(diào)用pFunc，但pFunc依然作為參數(shù)被引用了，因?yàn)槭莿?dòng)態(tài)鏈接的DLL，沒(méi)有引用對(duì)應(yīng)的lib，所以鏈接時(shí)提示找不到符號(hào)的錯(cuò)誤信息。

想知道有沒(méi)有什么其他的辦法只通過(guò)函數(shù)聲明而不通過(guò)引用來(lái)獲得類型以實(shí)現(xiàn)對(duì)動(dòng)態(tài)鏈接的DLL中的函數(shù)的調(diào)用？vs2005還不支持typeof關(guān)鍵字，暫時(shí)沒(méi)有想到什么好辦法。

調(diào)用方代碼大致如下：以CreateDXGIFactory（Direct10里的一個(gè)函數(shù)） 舉例：
HRESULT ret = CallModuleFunc(m_hDXGIModule, CreateDXGIFactory, (__uuidof(IDXGIFactory), (void **)&pDXGIFactory) );
 if (FAILED(ret))
 {
  ATLASSERT(0);
  return E_FAIL;
 }

后記：
在偉大的叛叛的指導(dǎo)下，用boost搞定了這個(gè)問(wèn)題。
一個(gè)test程序如下：
 BOOST_TYPEOF(Direct3DCreate9) *pDirect3DCreate9 = NULL;
 HMODULE hdx = LoadLibrary(_T("d3d9.dll"));

 pDirect3DCreate9 = reinterpret_cast<BOOST_TYPEOF(Direct3DCreate9) *>(GetProcAddress(hdx, "Direct3DCreate9"));
 if (pDirect3DCreate9 == NULL)
 {
  ATLASSERT(0);
 }
 else
 {
  IDirect3D9 * pD3D = pDirect3DCreate9(D3D_SDK_VERSION);
  if (pD3D == NULL)
  {
   ATLASSERT(0);
  }
 }

按照這個(gè)思路已經(jīng)可以寫出通用的宏了。
template <typename FuncType>
FuncType __forceinline GetModuleFunc(HMODULE hModule, LPCSTR lpProcName)
{
 FuncType fun = reinterpret_cast<FuncType>(GetProcAddress(hModule, lpProcName));
 return fun;
}

#define CallModuleFunc(Module, ProcName, Args) (GetModuleFunc<BOOST_TYPEOF(ProcName) *>(Module, #ProcName))?((GetModuleFunc<BOOST_TYPEOF(ProcName) *>(Module, #ProcName)) Args) : E_FAIL

可惜的是boost::typeof的代碼我完全看不懂……學(xué)習(xí)C++的路漫漫其修遠(yuǎn)兮……

唉，我每天的業(yè)余時(shí)間都是被劈成兩半的，每一半只有兩個(gè)小時(shí)。
今天晚間的成果是：成功的用動(dòng)態(tài)鏈接調(diào)用了DX10的函數(shù)，鏈接失敗的情況程序也可以通過(guò)返回值給予一定的提示。
通過(guò)這種方法拿到了IDXGIFactory接口，然后列舉了下我的顯卡和顯示輸出，還有在B8G8R8A8顯示模式下的所有可用分辨率和刷新率（PS: 我現(xiàn)在是單顯卡輸出兩個(gè)顯示器的。）

運(yùn)行結(jié)果：
Default graphics library is: Direct3D 10 Library
Adapter NVIDIA GeForce 8600M GT    :
        VendorId: 4318, DeviceId: 1031, SubSysId: 16321043, Revision: 161
        DedicatedVideoMemory: 241M, DedicatedSystemMemory: 0M, SharedSystemMemor
y: 767M
Outputs:
        \\.\DISPLAY1: 1024 * 768
        Available display mode for B8G8R8A8_UNORM:
                640*480 Refresh rate: 60Hz
                640*480 Refresh rate: 70Hz
                640*480 Refresh rate: 72Hz
                640*480 Refresh rate: 75Hz
                800*600 Refresh rate: 56Hz
                800*600 Refresh rate: 60Hz
                800*600 Refresh rate: 70Hz
                800*600 Refresh rate: 72Hz
                800*600 Refresh rate: 75Hz
                1024*768 Refresh rate: 60Hz
                1024*768 Refresh rate: 70Hz
                1024*768 Refresh rate: 72Hz
                1024*768 Refresh rate: 75Hz
        \\.\DISPLAY2: 1280 * 800
        Available display mode for B8G8R8A8_UNORM:
                640*480 Refresh rate: 60Hz
                640*480 Refresh rate: 60Hz
                800*600 Refresh rate: 60Hz
                800*600 Refresh rate: 60Hz
                1024*768 Refresh rate: 60Hz
                1024*768 Refresh rate: 60Hz
                1280*800 Refresh rate: 60Hz

目前依然是連窗口和圖形界面都沒(méi)有的-___,-
慢慢來(lái)，因?yàn)檫@些基礎(chǔ)的東西也是很重要的。
另外，列舉顯示卡和顯示器的代碼暫時(shí)沒(méi)有返回給上層，主要是編碼一個(gè)枚舉類型還是挺耗時(shí)間的。暫時(shí)用硬編碼解決。
 

格子里的故事簡(jiǎn)介

 

分內(nèi)核和外在兩部分來(lái)說(shuō)。先說(shuō)內(nèi)核的東西，也就是游戲的技術(shù)實(shí)現(xiàn)目標(biāo)。

基于傳統(tǒng)的俄羅斯方塊游戲，在其基礎(chǔ)上設(shè)置游戲障礙及我們的游戲要求也就是過(guò)關(guān)條件。這個(gè)游戲的過(guò)關(guān)條件就是在我們指定的區(qū)域用同一種顏色填滿，而且指定的區(qū)域外必須是其他顏色的色塊，或背景或另外一種顏色。圖示說(shuō)明：

采用俄羅斯方塊的經(jīng)典7元素，再配上顏色極為14種元素。目標(biāo)填充區(qū)域需要全被同色格子占據(jù)，并且不能有同色突出，如圖反應(yīng)的兩種情況。大致就是這個(gè)意思。

 

 

 

 

 

下面說(shuō)外在部分，初步設(shè)想把它設(shè)計(jì)為一棟大樓里發(fā)生的事情。背景是晚上的某棟大樓，M*N個(gè)格子構(gòu)成一關(guān)，在外在表現(xiàn)為M*N個(gè)房間構(gòu)成一個(gè)樓層段。過(guò)關(guān)鏡頭向上走，也就是移向更上的一個(gè)樓層段。最開始的時(shí)候背景只有目標(biāo)填充區(qū)域有微微光亮，周圍的房間偏黑，然后14種元素以望遠(yuǎn)鏡的鏡片形式下落，穩(wěn)定后它對(duì)應(yīng)的房間里就會(huì)變得更亮，如果這個(gè)房間屬于目標(biāo)填充區(qū)域，那么房間被點(diǎn)亮，我們可以透過(guò)鏡片看到里面發(fā)生的一個(gè)gif的故事，如果不屬于目標(biāo)填充區(qū)域，那么會(huì)顯示一個(gè)拉上窗簾的gif。游戲過(guò)關(guān)之后鏡頭移動(dòng)到更上層的一個(gè)樓層段，重復(fù)。但是每個(gè)樓層段每個(gè)目標(biāo)填充區(qū)域所包含的房間里的gif是不一樣的，也正是由這些不同來(lái)反映各個(gè)階層或者說(shuō)生活中的各個(gè)層次的人們的生存形態(tài)。格子里的故事這個(gè)題目也取自這里，同時(shí)想要表達(dá)的還有一種我們一直被禁錮的意思，活著的時(shí)候是在大大的盒子里，死后實(shí)在小小的盒子里。當(dāng)然這些都不要告訴玩家~~，你也可以不這么認(rèn)為。但這些確實(shí)是我想到的。而且我覺(jué)得游戲永遠(yuǎn)不只有一個(gè)目的，它畢竟是一種表達(dá)手段。哦，扯遠(yuǎn)了。下面跟上游戲進(jìn)度和工作分配。

 

11.12——11.16 第一階段游戲功能實(shí)現(xiàn)，包括基本俄羅斯方塊功能實(shí)現(xiàn)

11.17          成果進(jìn)度匯報(bào)討論

11.17——11.23 第二階段游戲功能實(shí)現(xiàn)，包括特定區(qū)域顏色判定

11.24           成果進(jìn)度匯報(bào)討論

11.25——11.30 第三階段游戲功能實(shí)現(xiàn)，包括選關(guān)、存檔功能實(shí)現(xiàn)

12.1             成果進(jìn)度匯報(bào)討論

12.1——12.7    后期測(cè)試優(yōu)化，包括圖片和聲音導(dǎo)入

12.8             發(fā)布。

 

以上責(zé)任人：PureMilk、糖糖、朱波

Gif圖片制作：肖赤赤