首先決定暫時不考慮DX9/OGL了,我不可能在不了解一個庫的時候就給它留好接口。耽誤我挺多時間了,雖然有重大收獲……
今天的成就是把Shader啟動起來了,做了一個花的三角形。
不管怎么說,拋棄Framework不談,本周完成界面顯示還是沒什么大問題的。剩下的時間我還是去讀讀ConfigSystem(DXSDK里一個很囧的小球Sample)的整體結構,還有讀讀DXUT的代碼了。
如果順利的話,我也決定采用DXUT開發,因為我沒有必要在對整體流程已經了解的情況下,對每個細節了如指掌。我的關注點還是:資源管理、框架、Shader。不能偏離了學習DX的目的。
沒弄明白怎么粘圖,那就不管了,反正一個破三角形也沒什么好看的……
隨便改了改代碼,用RenderMonkey時寫的一些vs和ps的東西還記得。
另外Dx10的用于輸出的一些Semantics的名字改了:
Direct3D 10 Semantic |
Direct3D 9 Equivalent Semantic |
SV_Depth |
DEPTH |
SV_Position |
POSITION |
SV_Target |
COLOR |
不管怎么說總是麻煩了一點。討厭的是RenderMonkey在我的電腦上沒裝起來,不能方便的編輯shader然后輸出fx了。明天還是研究下如何輸出編譯的錯誤信息。好歹編不過要能告訴我是哪行編不過才行……
現在的Shader代碼:(就隨便搞了下,顯示出一個暗紅色的怪東西:)
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拿出來,把兩個輸出從單純的float4變成了一個結構體,然后給VS的輸出增加了一個Color,最后再把坐標的一部分當作顏色輸出了出去。
posted @
2008-11-14 00:30 正牌的天地之靈和他的徒兒們肖赫_王婷婷_王冠_鄭燚_孫婷 閱讀(281) |
評論 (0) |
編輯 收藏






posted @
2008-11-13 21:32 正牌的天地之靈和他的徒兒們肖赫_王婷婷_王冠_鄭燚_孫婷 閱讀(111) |
評論 (0) |
編輯 收藏
我究竟是不太能接受這種不規則的學習方式,而且太心急太有壓力太怕完不成,只能退而求其次。我想如果用glut寫完還有剩余的時間,我會把它轉到win API。而且我相信FamilyBlock的邏輯并不難,我有信心快速完成它。
posted @
2008-11-13 21:15 正牌的天地之靈和他的徒兒們肖赫_王婷婷_王冠_鄭燚_孫婷 閱讀(125) |
評論 (0) |
編輯 收藏
好吧,今晚有重大突破,那就是:窗口顯示出來老!v ~。~b
就是DXSDK里那個藍藍的窗口,不過我為了搭建Frame,繞了好多彎,剛剛才終于顯示出來。
目前完成了GraphicsDevice類的創建了,我正在考慮怎樣設計通用的點列表、材質等等接口,得尋人咨詢下OpenGL的關于點列表的接口。如果大家都是自定義結構體+參數那就沒什么好說的老,把點列表做成一個點容器那么復雜似乎也沒有必要。唉,做到再說吧!
目前的主函數代碼:
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就是近似傳說中的glutMainLoop啦,不過為了避免全局變量,我把pGraphicsDevice給傳進去了……
然后想想貌似這里沒什么避免全局變量的必要(或者整個類,然后用靜態變量算了)。現在的話,如果想在MainLoop內更換GraphicsDevice,原來的Device的引用計數也釋放不掉了。
然后覺得一開始的注冊可用庫之類的流程也要改,目前那個全局map也會把所有的DLL都保留著,沒有釋放掉。
最好的辦法是,全局map里只保留創建函數,在獲取Library。主程序可以Enum每個可用類(按接口),傳遞GUID進去,獲得一個接口,也可以選擇創建默認類,然后獲得一個接口。在InitFramework的時候,每個DLL只嘗試性連接,如果連接成功,可以立刻釋放。等到對應的類被創建的時候再去重新連接。
另外在ToggleDevice的方面還沒什么好的想法。或者干脆維護一個Device列表?列表內的被Render。這也是需要改進的。
posted @
2008-11-12 22:59 正牌的天地之靈和他的徒兒們肖赫_王婷婷_王冠_鄭燚_孫婷 閱讀(144) |
評論 (0) |
編輯 收藏
今天把瑪麗醫生的界面規劃了一下,規劃的是那么的美好。中午吃完飯連寢室都沒來得及回就趕來實驗室寫代碼,但是萬惡的XYLayout讓我寒心了。
以前只是聽說過XYLayout,但還是沒有用過。今天規劃界面的時候我想到了XYLayout,自己幻想XYLayout挺好的,對每個組建都固定一個位置,這樣做界面太好了。可是回來之后寫了代碼居然發現JDK里面竟然無法編譯,當時那個心情啊。后來想想,還是先寫功能吧,屏幕上就先出來一個16*8的格子加上菜單,另外的界面就等等再說吧。
posted @
2008-11-12 22:04 正牌的天地之靈和他的徒兒們肖赫_王婷婷_王冠_鄭燚_孫婷 閱讀(233) |
評論 (0) |
編輯 收藏
摘要:
閱讀全文
posted @
2008-11-12 19:40 正牌的天地之靈和他的徒兒們肖赫_王婷婷_王冠_鄭燚_孫婷 閱讀(260) |
評論 (2) |
編輯 收藏
暈死了都,為什么<gl\gl.h>前面一定要加#include <windows.h>……………………崩潰的link error
不就是一個小小的ReadBMP24函數,我想里面就用了個GLubyte類型,沒用啥別的,go to definition一下,定義在gl\gl.h里,就把頭文件從glut換成了gl,于是出現了崩潰的link error。上帝啊,不帶這么折磨新手的。
抓狂中……
posted @
2008-11-12 11:07 正牌的天地之靈和他的徒兒們肖赫_王婷婷_王冠_鄭燚_孫婷 閱讀(286) |
評論 (0) |
編輯 收藏
今天早上意圖創建Device和SwapChain。這沒什么問題,但是我意圖通過模板演繹和宏來簡化對動態鏈接的DLL中函數的調用時,我寫的模板和宏不能正常工作。
我寫的函數和宏如下:
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
思路是通過函數的聲明演繹出函數類型,進行強轉然后調用。
失敗原因是盡管沒有直接調用pFunc,但pFunc依然作為參數被引用了,因為是動態鏈接的DLL,沒有引用對應的lib,所以鏈接時提示找不到符號的錯誤信息。
想知道有沒有什么其他的辦法只通過函數聲明而不通過引用來獲得類型以實現對動態鏈接的DLL中的函數的調用?vs2005還不支持typeof關鍵字,暫時沒有想到什么好辦法。
調用方代碼大致如下:以CreateDXGIFactory(Direct10里的一個函數) 舉例:
HRESULT ret = CallModuleFunc(m_hDXGIModule, CreateDXGIFactory, (__uuidof(IDXGIFactory), (void **)&pDXGIFactory) );
if (FAILED(ret))
{
ATLASSERT(0);
return E_FAIL;
}
后記:
在偉大的叛叛的指導下,用boost搞定了這個問題。
一個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);
}
}
按照這個思路已經可以寫出通用的宏了。
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的代碼我完全看不懂……學習C++的路漫漫其修遠兮……
posted @
2008-11-12 09:11 正牌的天地之靈和他的徒兒們肖赫_王婷婷_王冠_鄭燚_孫婷 閱讀(429) |
評論 (1) |
編輯 收藏
唉,我每天的業余時間都是被劈成兩半的,每一半只有兩個小時。
今天晚間的成果是:成功的用動態鏈接調用了DX10的函數,鏈接失敗的情況程序也可以通過返回值給予一定的提示。
通過這種方法拿到了IDXGIFactory接口,然后列舉了下我的顯卡和顯示輸出,還有在B8G8R8A8顯示模式下的所有可用分辨率和刷新率(PS: 我現在是單顯卡輸出兩個顯示器的。)
運行結果:
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
目前依然是連窗口和圖形界面都沒有的-___,-
慢慢來,因為這些基礎的東西也是很重要的。
另外,列舉顯示卡和顯示器的代碼暫時沒有返回給上層,主要是編碼一個枚舉類型還是挺耗時間的。暫時用硬編碼解決。
posted @
2008-11-12 00:51 正牌的天地之靈和他的徒兒們肖赫_王婷婷_王冠_鄭燚_孫婷 閱讀(313) |
評論 (0) |
編輯 收藏
格子里的故事簡介
分內核和外在兩部分來說。先說內核的東西,也就是游戲的技術實現目標。
基于傳統的俄羅斯方塊游戲,在其基礎上設置游戲障礙及我們的游戲要求也就是過關條件。這個游戲的過關條件就是在我們指定的區域用同一種顏色填滿,而且指定的區域外必須是其他顏色的色塊,或背景或另外一種顏色。圖示說明:
采用俄羅斯方塊的經典7元素,再配上顏色極為14種元素。目標填充區域需要全被同色格子占據,并且不能有同色突出,如圖反應的兩種情況。大致就是這個意思。

下面說外在部分,初步設想把它設計為一棟大樓里發生的事情。背景是晚上的某棟大樓,M*N個格子構成一關,在外在表現為M*N個房間構成一個樓層段。過關鏡頭向上走,也就是移向更上的一個樓層段。最開始的時候背景只有目標填充區域有微微光亮,周圍的房間偏黑,然后14種元素以望遠鏡的鏡片形式下落,穩定后它對應的房間里就會變得更亮,如果這個房間屬于目標填充區域,那么房間被點亮,我們可以透過鏡片看到里面發生的一個gif的故事,如果不屬于目標填充區域,那么會顯示一個拉上窗簾的gif。游戲過關之后鏡頭移動到更上層的一個樓層段,重復。但是每個樓層段每個目標填充區域所包含的房間里的gif是不一樣的,也正是由這些不同來反映各個階層或者說生活中的各個層次的人們的生存形態。格子里的故事這個題目也取自這里,同時想要表達的還有一種我們一直被禁錮的意思,活著的時候是在大大的盒子里,死后實在小小的盒子里。當然這些都不要告訴玩家~~,你也可以不這么認為。但這些確實是我想到的。而且我覺得游戲永遠不只有一個目的,它畢竟是一種表達手段。哦,扯遠了。下面跟上游戲進度和工作分配。
11.12——11.16 第一階段游戲功能實現,包括基本俄羅斯方塊功能實現
11.17 成果進度匯報討論
11.17——11.23 第二階段游戲功能實現,包括特定區域顏色判定
11.24 成果進度匯報討論
11.25——11.30 第三階段游戲功能實現,包括選關、存檔功能實現
12.1 成果進度匯報討論
12.1——12.7 后期測試優化,包括圖片和聲音導入
12.8 發布。
以上責任人:PureMilk、糖糖、朱波
Gif圖片制作:肖赤赤
posted @
2008-11-11 21:47 正牌的天地之靈和他的徒兒們肖赫_王婷婷_王冠_鄭燚_孫婷 閱讀(137) |
評論 (0) |
編輯 收藏