如果本文对你的开发有所帮助，并且你手头恰好有零钱。

不如打赏我一杯咖啡，鼓励我继续分享优秀的文章。

1、属性的统一访问接口，脚本中就可以通过这个接口来访问属性了；
2、成员函数的统一访问接口，脚本中可以通过这些接口来调用UObject或其派生类的成员函数；
3、串行化的统一接口，实现了一个保存所有对象的UPackage包管理器，从而做到保存到二进制文件、从二进制文件读取，这样做的好处是持久化对象（比如游戏中的材质列表）的载入非常快速，由于是二进制格式，不需要任何字符串数据转换；
4、提供对象的垃圾回收功能；
5、提供编辑器的相应功能，如：对象的“属性”有各种编辑器所需的标记（是否可编辑CPF_Edit等）、对象在编辑器中的渲染DrawThumbnail、对象描述GetThumbnailDesc、对象选择IsSelected、是否更改了包MarkPackageDirty等等；
6、提供一个对象的管理器，这个对象管理器是通过UObject中的一堆静态函数来实现的，如：从管理器中查找一个对象StaticFindObject、分配一个对象StaticAllocateObject、从包中载入一个对象StaticLoadObject、根据类型来遍历管理器中的所有对象FObjectIterator/TObjectIterator、遍历所有选择了的对象TSelectedObjectIterator（编辑器使用）
7、提供配置管理器，通过UObject中的LoadConfig、SaveConfig实现
8、提供类描述信息，描述了这个类从哪个类派生、有什么属性、每个属性的访问方式、有什么函数，从而实现了动态类型判断、脚本属性访问、脚本函数访问、属性串行化等等
9、其他。。。。

简单分析下UObject中的各个成员变量的意义：
Index，用来记录这个UObject在所有UObject列表GObjObjects中的唯一索引
HashNext，用来记录全局UObject Hash表GObjHash中跟这个UObject 的Hash值相同的下一个UObject的指针，用来配合全局Hash表GObjHash通过StaticFindObject函数快速搜索一个指定名称的UObject
StateFrame，脚本相关的咚咚，还没看
_Linker，通过在包文件中载入时的载入器
_LinkerIndex，通过包文件载入时的UPackage包对象在GObjObjects中的唯一索引，相当于Outer->Index
Outer，这个对象所属的包
ObjectFlags，这个对象的一些标记，具体参见EObjectFlags枚举，不同标记来决定这个对象的一些行为，比如是否可以保存、是否可见等等
Name，对象名称，通过一个FName来实现，这个FName可是个好东西哦，字符串比较变成了一个Hash值比较
Class，用来描述这个类，就是以上第1、2、8点说到的。这个Class在调用UObject::StaticClass或派生类的StaticClass静态函数时会一次性初始化，意味着即使创建多少个UObject，但Class只会有一个实例，我们通过这个类，可以使用TFieldIterator的统一方式来遍历这个类的所有属性、函数。

UObject的静态变量，这些静态变量其实就是UObject对象管理器使用的变量，如果用Ogre的设计方法来做，就相当于另外一个class UObjectManager : public Singleton<UObjectManager>，然后在里面把这些静态变量拿到UObjectManager中去。简要分析下静态变量的意义：
GObjInitialized，对象管理器是否已经初始化，全局对象管理器只需要初始化一次就够了；
GObjNoRegister，调用StaticInit时会设置成1；
GObjBeginLoadCount，有多少个对象被BeginLoad了；
GObjRegisterCount，ProcessRegistrants中使用
GImportCount，还没细看哦
GObjHash，通过每个UObject的Name的Hash值取低12位作为索引值保存在GObjHash表中，Hash值的低12位相同的，只记录第一个在GObjHash表中，其他的通过链表方式使用UObject的HashNext来链接起来
GAutoRegister，自动注册的对象列表
GObjRoot，对象树种的顶层对象
GObjObjects，所有对象的列表

先说这么多了，继续学习。

如果本文对你的开发有所帮助，并且你手头恰好有零钱。

不如打赏我一杯咖啡，鼓励我继续分享优秀的文章。

如果本文对你的开发有所帮助，并且你手头恰好有零钱。

不如打赏我一杯咖啡，鼓励我继续分享优秀的文章。

如果本文对你的开发有所帮助，并且你手头恰好有零钱。

不如打赏我一杯咖啡，鼓励我继续分享优秀的文章。

如果本文对你的开发有所帮助，并且你手头恰好有零钱。

不如打赏我一杯咖啡，鼓励我继续分享优秀的文章。

1、创建渲染目标纹理，关键要指定TU_RENDERTARGET参数，在创建这个渲染目标纹理的过程中，Ogre会自动调用  Root::getSingleton().getRenderSystem()->attachRenderTarget把这个纹理添加到Root的渲染目标中，也就是说每帧都会渲染到这个纹理。
TexturePtr texture = TextureManager::getSingleton().createManual( "RttTex",
 ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME, TEX_TYPE_2D,
 512, 512, 0, PF_R8G8B8, TU_RENDERTARGET );

2、获得渲染目标，有了渲染目标，才能给目标指定视口和摄像机
RenderTarget *rttTex = texture->getBuffer()->getRenderTarget();

3、给这个渲染目标指定摄像机，做了这步骤之后，每帧更新时就会把这个摄像机看到的东西渲染到texture中
Viewport *v = rttTex->addViewport( mReflectCam );

4、OK！

如果本文对你的开发有所帮助，并且你手头恰好有零钱。

不如打赏我一杯咖啡，鼓励我继续分享优秀的文章。

  //enumerate partitions
  vector<CorePartition*> partitions;
  mGridPartitionMgr->enumeratePartitions(partitions);

  //iterate through and check distance
  for(vector<CorePartition*>::iterator itr = partitions.begin(); itr != partitions.end(); ++itr)
  {
   float distance = Vector3(getWorldPosition() - (*itr)->getWorldPosition()).length();
   // add by 李锦俊 2007-7-16
   // 不要返回自己作为邻居，会产生bug
   if(distance < loadRadius && *itr != this)
    connected.push_back(*itr);
  }
 }

再给出一个比较严重的bug
GOOFTranslationManipulator.h中的
  // add by 李锦俊 2007-7-12
  // 不要用魔术数，搞到缓存溢出
  SceneNode* mNode[AT_LAST];
  Entity* mEnt[AT_LAST];
  Entity* mConeEnt[AT_LAST];
  CollisionShapePtr mCol[AT_LAST];
  AxisManipulatorHandle* mHandle[AT_LAST];

另外，CorePartition中的setSkyboxMaterial、setGlobalAmbient之类的代码貌似没用。准备弃之。

创建设备
典型地，你将通过标准的Direct3D方法创建设备
HRESULT CreateDevice(
    UINT                  Adapter,
    D3DDEVTYPE            DeviceType,
    HWND                  hFocusWindow,
    DWORD                 BehaviorFlags,
    D3DPRESENT_PARAMETERS *pPresentationParameters,
    IDirect3DDevice9      **ppReturnedDeviceInterface
);
这个方法需要有效的适配器，设备类型(HAL or REF),窗口句柄，行为标志(software/hardware vertex processing 和其它驱动标志)，以及呈现参数(presentation parameters).此外，D3DPRESENT_PARAMETER结构体还拥有大量的成员指定后备缓冲区，多重采样设定，交换效果，窗口模式，深度模版缓冲，刷新率，呈现间隔，以及呈现标志。
为所有这些参数选择有效的设定是具有挑战性的。框架通过DXUTCreateDevice函数简化了这一选择过程。
HRESULT DXUTCreateDevice(
    UINT AdapterOrdinal  = D3DADAPTER_DEFAULT,
    BOOL bWindowed       = TRUE,
    INT nSuggestedWidth  = 640,
    INT nSuggestedHeight = 480,
    LPDXUTCALLBACKISDEVICEACCEPTABLE pCallbackIsDeviceAcceptable     = NULL,
    LPDXUTCALLBACKMODIFYDEVICESETTINGS pCallbackModifyDeviceSettings = NULL
);
最基本的用法是全部使用缺省参数调用：
DXUTCreateDevice();
通过这样的调用框架使用缺省设置创建一个在大多数情况下可用的设备。缺省的设置如下：

选择最佳的设备设置
你可以使用IsDeviceAcceptable回调函数帮助框架为你的应用程序选择最佳的设备设置，就像下面的代码：
bool CALLBACK IsDeviceAcceptable(
D3DCAPS9*     pCaps,
D3DFORMAT     AdapterFormat,
D3DFORMAT     BackBufferFormat,
bool          bWindowed,
void*         pUserContext )
{
    // TODO: return true for acceptable settings and false otherwise.
    return true;
}
这个回调函数的模型基于LPDXUTCALLBACKISDEVICEACCEPTABLE原型(This callback function is modeled on the prototype LPDXUTCALLBACKISDEVICEACCEPTABLE)，框架为每个唯一的以下5个设置的有效组合调用这个函数一次：
D3DDEVTYPE DeviceType;
UINT       AdapterOrdinal;
D3DFORMAT  AdapterFormat;
D3DFORMAT  BackBufferFormat;
bool       Windowed;
注意适配器序号和设备类型没有直接的传入回调函数，而是分别作为D3DCAPS9结构体的成员。
通过这个回调函数，应用程序可以拒绝任何它不支持的或不想要的组合。例如，应用程序可以使用下面的代码拒绝16bits的后备缓冲区格式和所有至少不能支持像素着色器PS_2_0的设备：
bool CALLBACK IsDeviceAcceptable(
    D3DCAPS9*     pCaps,
    D3DFORMAT     AdapterFormat,
    D3DFORMAT     BackBufferFormat,
    bool          bWindowed )
{
    if( pCaps->PixelShaderVersion < D3DPS_VERSION(2,0) )
     return false;
    if( BackBufferFormat == D3DFMT_X1R5G5B5 || BackBufferFormat == D3DFMT_R5G6B5 )
        return false;
    return true;
}

为每个唯一的组合调用回调函数后，框架排列剩下的可用组合，并选择它们当中最好的。排名较高的如下：
D3DDEVTYPE_HAL，获取硬件加速
如果应用程序以全屏模式显示，框架更趋向于使用匹配桌面格式的适配器格式，这样可以在全屏与窗口之间快速切换。例外的是，如果桌面显示模式小于32位，框架更趋向于D3DFMT_X8R8G8B8.
匹配适配器格式的后备缓冲区格式
在选择了这些排名高的组合后，要创建设备，行为标志和呈现参数仍然是需要的。对于这些设置,Direct3D使用上面表中的缺省值。

修改可用的设备设置
应用程序可以通过使用第二个可选的回调函数修改对框架可用的设置，这个函数是ModifyDeviceSettings:
bool CALLBACK ModifyDeviceSettings(
    DXUTDeviceSettings* pDeviceSettings,
    const D3DCAPS9*     pCaps )
{
    // TODO: Include device creation requirements here. 
    // 返回真创建设备返回False保持当前设置
    return true;
}
这个函数是基于原型LPDXUTCALLBACKMODIFYDEVICESETTINGS的。DXUTDeviceSettings结构体被框架定义为：
struct DXUTDeviceSettings
{
    UINT       AdapterOrdinal;
    D3DDEVTYPE DeviceType;
    D3DFORMAT  AdapterFormat;
    DWORD      BehaviorFlags;
    D3DPRESENT_PARAMETERS pp;
};

这个结构体包含了创建设备所需要的所有东西，除了窗口句柄,它被假定为先前创建的窗口的句柄。框架用有效的数据填充这个结构体，然后允许应用程序通过ModifyDeviceSettings回调函数改变设备创建的选择。
在这个回调函数中，应用程序可以在DXUTDeviceSettings结构体中改变行为标志以及呈现参数,乃至结构体中任何其它的东西。如果应用程序在回调函数中什么都不改变，设备会成功的创建。然而，对设备创建设置的任何改变都需要被设备支持，否则可能会导致设备创建失败。
比如，如果应用程序需要一个D3DFMT_D24S8的深度模板缓冲区格式，就必须验证设备是否支持，就像下面的代码：
bool CALLBACK ModifyDeviceSettings(
    DXUTDeviceSettings* pDeviceSettings,
    const D3DCAPS9*     pCaps )
{
    IDirect3D9* pD3D = DXUTGetD3DObject();
    if( SUCCEEDED( pD3D->CheckDeviceFormat(
         pDeviceSettings->AdapterOrdinal,
         pDeviceSettings->DeviceType,
         pDeviceSettings->AdapterFormat,
         D3DUSAGE_DEPTHSTENCIL,
         D3DRTYPE_SURFACE,
         D3DFMT_D24S8 ) ) )
    {
     if( SUCCEEDED( pD3D->CheckDepthStencilMatch(
             pDeviceSettings->AdapterOrdinal,
             pDeviceSettings->DeviceType,
             pDeviceSettings->AdapterFormat,
             pDeviceSettings->pp.BackBufferFormat,
             D3DFMT_D24S8 ) ) )
     {
         pDeviceSettings->pp.AutoDepthStencilFormat = D3DFMT_D24S8;
     }
    }
   
    return true;
}

候选的方案是，回调函数可以使用框架的CD3DEnumeration 对象验证D3DFMT_D24S8是否被支持：
 bool CALLBACK ModifyDeviceSettings(
    DXUTDeviceSettings* pDeviceSettings,
    const D3DCAPS9*     pCaps )
{
    CD3DEnumeration *pEnum = DXUTGetEnumeration();
    CD3DEnumDeviceSettingsCombo *pCombo;
 
    pCombo = pEnum->GetDeviceSettingsCombo( pDeviceSettings );
 
    if( pCombo->depthStencilFormatList.Contains( D3DFMT_D24S8 ) )
        pDeviceSettings->pp.AutoDepthStencilFormat = D3DFMT_D24S8;
       
    return true;
}

应用程序修改了设备的设置后，框架就会用新的设置创建设备。
DirectX April 2005 SDK Update中的更新，ModifyDeviceSettings 回调函数返回了一个bool值。如果应用程序返回true框架继续正常的创建设备。如果返回false框架不改变设备并且保持当前的设备，如果已经有一个存在的话。这允许应用程序能够拒绝框架将设备改变到程序不能使用的请求。例如，在多监视器的缺省配置下，在监视器之间拖动窗口会导致框架改变设备。然而，如果应用程序不能使用其它的设备的话，它应当可以拒绝改变，并继续使用当前的设备。

回降到软件顶点处理
如果你设置一个Direct3D设备到支持像素处理却不支持顶点处理的硬件，你会因此需要改变行为标志。为了确保正确地降到软件顶点处理，谨防你不能拒绝一个基于IsDeviceAcceptable回调函数中顶点着色器版本的设备，并确保行为标志在ModifyDeviceSettings 回调函数中被正确调整。这儿有一个例子演示怎样做这些事情。
bool CALLBACK ModifyDeviceSettings( DXUTDeviceSettings* pDeviceSettings,
                                    const D3DCAPS9* pCaps )
{
    // If device doesn't support HW T&L or doesn't support 1.1 vertex
    // shaders in HW, then switch to SWVP.
    if( (pCaps->DevCaps & D3DDEVCAPS_HWTRANSFORMANDLIGHT) == 0 ||
         pCaps->VertexShaderVersion < D3DVS_VERSION(1,1) )
    {
        pDeviceSettings->BehaviorFlags = D3DCREATE_SOFTWARE_VERTEXPROCESSING;
    }

    else
    {
        pDeviceSettings->BehaviorFlags = D3DCREATE_HARDWARE_VERTEXPROCESSING;
    }
   
    return true;
}

使用你自己的设备
你没有必要依赖于框架来创建Direct3D设备。应用程序自己可以创建设备并将他传递给框架使用。就像应用程序可以覆盖框架的window creation 设置。简单的使用你想要的设置创建一个设备，然后调用 DXUTSetDevice函数让框架在你的设备上渲染。
注意：如果应用程序创建了不依赖于框架的设备，那么应用程序也必须在主循环执行完以后亲自的通过cleanup 释放设备接口。
另请参阅
通过DXUT作更高级的设备选择

下载源代码

前言

　　你可能不希望在发布程序时附带上一个外部的 DLL，因为可能会有些用户在无意中把 DLL 删除了而造成 EXE 不能正确运行，也有可能该 DLL 会被别人拿去使用，也有可能，此 DLL 会成为破解者破解你的程序的突破口。无论出于何种原因，如果你想把一个 DLL 合并到一个 EXE 中的话，本文向你介绍这种方法。

LPVOID sRawDll; // 资源文件在内存中的地址 
HRSRC hRes; 
HMODULE hLibrary; 
HGLOBAL hResourceLoaded; 
char lib_name[MAX_PATH]; 
GetModuleFileName(hInstance, lib_name, MAX_PATH ); // 得到运行程序的名字 
hLibrary = LoadLibrary(lib_name);                  // 就象载入一个 DLL 一样载入运行程序到内存中 

if (NULL != hLibrary) 
{
	// 得到指定的资源文件在内存中的位置 
	hRes = FindResource(hLibrary, MAKEINTRESOURCE(IDR_DATA1), RT_RCDATA); 
	if (NULL != hRes) 
	{
		// 将资源文件载入内存 
		hResourceLoaded = LoadResource(hLibrary, hRes); 
		if (NULL != hResourceLoaded) 
		{
			// 得到资源文件大小 
			SizeofResource(hLibrary, hRes); 

			// 锁定资源以得到它在内存中的地址 
			sRawDll = (LPVOID)LockResource(hResourceLoaded); 
		}
	}
	else return 1; 
	FreeLibrary(hLibrary);
}
else return 1; 

DWORD LoadPbDllFromMemory(LPVOID lpRawDll, LPVOID lpImageDll) 
{
	SYSTEM_INFO sSysInfo; 
	PIMAGE_DOS_HEADER dosHeader; 
	PIMAGE_NT_HEADERS pNTHeader; 
	PIMAGE_SECTION_HEADER section; 
	PIMAGE_IMPORT_DESCRIPTOR pImportDesc; 
	PIMAGE_IMPORT_BY_NAME pOrdinalName; 
	PIMAGE_BASE_RELOCATION baseReloc; 
	PDWORD lpLink; 
	unsigned char Protection[4096]; 
	HINSTANCE hDll; 
	WORD i; 
	DWORD ImagePages,fOldProtect,j,MaxLen,HdrLen,Addr1,Addr2,Pg,Pg1,Pg2; 
	char * sDllName; 

	if(NULL == lpRawDll) return 1 ; 

	dosHeader = (PIMAGE_DOS_HEADER)lpRawDll; 

	// Is this the MZ header? 
	if ((TRUE == IsBadReadPtr(dosHeader,sizeof (IMAGE_DOS_HEADER))) ||
				 (IMAGE_DOS_SIGNATURE != dosHeader->e_magic)) 
		return 2; 

	// Get the PE header. 
	pNTHeader = MakePtr(PIMAGE_NT_HEADERS,dosHeader,dosHeader->e_lfanew); 

	// Is this a real PE image? 
	if((TRUE == IsBadReadPtr(pNTHeader,sizeof ( IMAGE_NT_HEADERS))) || 
				( IMAGE_NT_SIGNATURE != pNTHeader->Signature)) 
		return 3 ; 

	if(( pNTHeader->FileHeader.SizeOfOptionalHeader != 
			sizeof(pNTHeader->OptionalHeader)) || 
		(pNTHeader->OptionalHeader.Magic != IMAGE_NT_OPTIONAL_HDR32_MAGIC)) 
		return 4; 

	if (pNTHeader->FileHeader.NumberOfSections < 1) return 5; 

	section = IMAGE_FIRST_SECTION( pNTHeader ); 
	int HeaderSize = sizeof(IMAGE_SECTION_HEADER); 

	// 节头长度 
	HdrLen = (DWORD)section - (DWORD)dosHeader + 
			HeaderSize * pNTHeader->FileHeader.NumberOfSections; 

	// 找出最大的节的长度,此节一般是代码所在的节(.text 节) 
	MaxLen = HdrLen; 
	int ii=0; 

	for (i = 0;i<(DWORD)pNTHeader->FileHeader.NumberOfSections;i++)// find MaxLen 
	{
		if(MaxLen < section[i].VirtualAddress + section[i].SizeOfRawData) 
		{
			MaxLen = section[i].VirtualAddress + section[i].SizeOfRawData; 
		}
		if(strcmp((const char *)section[i].Name,".rsrc") == 0) ii=i; 
	}

	GetSystemInfo(&sSysInfo);
	ImagePages = MaxLen / sSysInfo.dwPageSize; 
	if (MaxLen % sSysInfo.dwPageSize) ImagePages++; 

	// 分配所需的内存 
	DWORD NeededMemory = ImagePages * sSysInfo.dwPageSize; 
	lpImageDll = VirtualAlloc(NULL, NeededMemory, MEM_COMMIT, PAGE_EXECUTE_READWRITE); 

	if (lpImageDll == NULL) return 6; // 分配内存失败 

	MoveMemory( lpImageDll, lpRawDll, HdrLen ); // 复制节头 

	DWORD OrgAddr = 0; 
	DWORD NewAddr = 0; 
	DWORD Size = 0; 

	// 复制 .text 节数据 
	for (i = 0;i<pNTHeader->FileHeader.NumberOfSections;i++) 
	{
		OrgAddr = (DWORD)lpImageDll + (DWORD)section[i].VirtualAddress; 
		NewAddr = (DWORD)lpRawDll + (DWORD)section[i].PointerToRawData; 
		Size = (DWORD)section[i].SizeOfRawData; 
		MoveMemory((void *)OrgAddr, (void *)NewAddr, Size ); 
	}

	// 把指针指向新的 DLL 映像 
	dosHeader = (PIMAGE_DOS_HEADER) lpImageDll; // Switch to new image 
	pNTHeader = (PIMAGE_NT_HEADERS) ((DWORD)dosHeader + dosHeader->e_lfanew); 
	section = (PIMAGE_SECTION_HEADER) ((DWORD)pNTHeader + sizeof(IMAGE_NT_HEADERS)); 
	pImageBase = (PBYTE)dosHeader; 

	if((ii!=0) && (IsNT()==TRUE)) 
	{
		section[ii].VirtualAddress = section[ii].VirtualAddress + (DWORD)lpRawDll; 
		section[ii].PointerToRawData = section[ii].PointerToRawData + (DWORD)lpRawDll; 
	}

	DWORD importsStartRVA; 

	// Look up where the imports section is (normally in the .idata section) 
	// but not necessarily so. Therefore, grab the RVA from the data dir. 
	importsStartRVA = GetImgDirEntryRVA(pNTHeader,IMAGE_DIRECTORY_ENTRY_IMPORT); 
	if ( !importsStartRVA ) 
	{
		VirtualFree(dosHeader,0, MEM_RELEASE); 
		return 7; 
	}

	pImportDesc = (PIMAGE_IMPORT_DESCRIPTOR) pNTHeader->
		OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress; 

	if(pImportDesc!= 0) 
		pImportDesc = (PIMAGE_IMPORT_DESCRIPTOR) ((DWORD)pImportDesc + (DWORD)dosHeader); 
	else 
	{
		VirtualFree(dosHeader,0, MEM_RELEASE); 
		return 8; 
	}

	while (1) // 处理各入口表中的 DLL 
	{
		// 检查是否遇到了空的 IMAGE_IMPORT_DESCRIPTOR 
		if ((pImportDesc->TimeDateStamp==0 ) && (pImportDesc->Name==0)) break; 

		// 从磁盘载入必须的 Dll, 
		// 注意,载入的 DLL 是合并的 DLL 的入口表中的 DLL, 
		// 不是合并到 EXE 中的 DLL 
		sDllName = (char *) (pImportDesc->Name + (DWORD)pImageBase); 
		hDll = GetModuleHandle(sDllName); 

		if (hDll == 0 ) hDll = LoadLibrary(sDllName); 

		if (hDll == 0 ) 
		{
			MessageBox(NULL, "Can''t find required Dll",
					"Error in LoadPbDllFromMemory()",0); 
			VirtualFree(dosHeader,0, MEM_RELEASE); 
			return 9; 
		}

		DWORD *lpFuncNameRef = (DWORD *) (pImportDesc->OriginalFirstThunk +
								 (DWORD)dosHeader); 
		DWORD *lpFuncAddr = (DWORD *) (pImportDesc->FirstThunk +
								 (DWORD)dosHeader); 

		while( *lpFuncNameRef != 0) 
		{
			pOrdinalName = (PIMAGE_IMPORT_BY_NAME) (*lpFuncNameRef +
						 (DWORD)dosHeader); 
			DWORD pIMAGE_ORDINAL_FLAG = 0x80000000; 

			if (*lpFuncNameRef & pIMAGE_ORDINAL_FLAG) 
				*lpFuncAddr = (DWORD) GetProcAddress(hDll,
					 (const char *)(*lpFuncNameRef & 0xFFFF)); 
			else
				*lpFuncAddr = (DWORD) GetProcAddress(hDll,
						 (const char *)pOrdinalName->Name); 

			if (lpFuncAddr == 0) 
			{
				VirtualFree(dosHeader,0, MEM_RELEASE); 
				return 10;// Can''t GetProcAddress 
			}

			lpFuncAddr++;
			lpFuncNameRef++;
		}
		pImportDesc++;
	}

	DWORD TpOffset; 
	baseReloc = (PIMAGE_BASE_RELOCATION)((DWORD)pNTHeader->
　　　　 OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress); 

	if (baseReloc !=0) 
	{
		baseReloc = (PIMAGE_BASE_RELOCATION) ((DWORD)baseReloc + (DWORD)dosHeader); 
		while(baseReloc->VirtualAddress != 0) 
		{
			PWORD lpTypeOffset = (PWORD) ((DWORD)baseReloc +
					 sizeof(IMAGE_BASE_RELOCATION)); 
			while (lpTypeOffset < (PWORD)((DWORD)baseReloc +
						 (DWORD)baseReloc->SizeOfBlock)) 
			{
				TpOffset = *lpTypeOffset & 0xF000; 
				if(TpOffset == 0x3000) 
				{
					lpLink = (PDWORD) ((DWORD)dosHeader +
　　　　　　　　　　　　　　　　　　　　　　             baseReloc->VirtualAddress +
                                                      (*lpTypeOffset & 0xFFF)); 
					*lpLink = (DWORD)dosHeader + 
                                            (*lpLink) - pNTHeader->OptionalHeader.ImageBase; 
				}
				else
				{
					if (TpOffset != 0) 
					{
						VirtualFree(dosHeader,0, MEM_RELEASE); 
						return 10; 
					}
				}
				lpTypeOffset++;
			}
			baseReloc = (PIMAGE_BASE_RELOCATION)((DWORD)baseReloc + 
				(DWORD)baseReloc->SizeOfBlock); 
		}
	}

	// 取得原始的内存状态 
	memset(Protection,0,4096);
	for (i = 0;i<=pNTHeader->FileHeader.NumberOfSections;i++) 
	{
		if (i == pNTHeader->FileHeader.NumberOfSections) 
		{
			Addr1 = 0; 
			Addr2 = HdrLen; 
			j = 0x60000000; 
		}
		else
		{
			Addr1 = section[i].VirtualAddress; 
			Addr2 = section[i].SizeOfRawData; 
			j = section[i].Characteristics; 
		}
		Addr2 += Addr1 - 1; 

		Pg1 = Addr1 / sSysInfo.dwPageSize; 
		Pg2 = Addr2 / sSysInfo.dwPageSize; 
		for(Pg = Pg1 ;Pg<=Pg2;Pg++) 
		{
			if (j & 0x20000000) Protection[Pg] |= 1; // Execute 
			if (j & 0x40000000) Protection[Pg] |= 2; // Read 
			if (j & 0x80000000) Protection[Pg] |= 4; // Write 
		}
	}

	// 恢复原始的内存状态 
	Addr1 = (DWORD)dosHeader; 
	for (Pg = 0 ;Pg<= ImagePages;Pg++) 
	{
		switch(Protection[Pg])
		{
		case 2: 
			fOldProtect = PAGE_READONLY; 
			break;
		case 3: 
			fOldProtect = PAGE_EXECUTE_READ; 
			break;
		case 6: 
			fOldProtect = PAGE_READWRITE; 
			break;
		default: 
			// Ignore strange combinations
			fOldProtect = PAGE_EXECUTE_READWRITE;  
			break;
		}

		if (fOldProtect !=PAGE_EXECUTE_READWRITE) 
		{
			if (VirtualProtect((void *)Addr1, 
				sSysInfo.dwPageSize, 
				fOldProtect,
				&fOldProtect) == 0) 
			{
				VirtualFree(dosHeader,0, MEM_RELEASE); 
				return 11; 
			}
		}
		Addr1 += sSysInfo.dwPageSize; 
	}

	EntryPoint = (LPENTRYPOINT) ((DWORD)pNTHeader->OptionalHeader.AddressOfEntryPoint +
				 (DWORD)dosHeader); 
	LPVOID lpReserved = 0; 
	EntryPoint((HINSTANCE)dosHeader, DLL_PROCESS_ATTACH, lpReserved); 
	lpImageDll2=lpImageDll;
	return 0; 
}

DWORD GetProcAddressDirectly(PIMAGE_DOS_HEADER dosHeader, char * FuncName)  
{ 
	PIMAGE_NT_HEADERS pNTHeader;  
	PIMAGE_EXPORT_DIRECTORY pExportDir;  
	PWORD lpNameOrdinals;  
	LPDWORD lpFunctions;  
	DWORD * lpName;  
	char * lpExpFuncName;  
	DWORD i;  
	DWORD j;  
	char * lpFuncName;  

	if(dosHeader->e_magic != IMAGE_DOS_SIGNATURE) return 0;  

	pNTHeader = (PIMAGE_NT_HEADERS)((DWORD)dosHeader + dosHeader->e_lfanew);  

	if (pNTHeader->Signature != IMAGE_NT_SIGNATURE) return 0;  

	if ((pNTHeader->FileHeader.SizeOfOptionalHeader != sizeof(pNTHeader->OptionalHeader)) ||  
		(pNTHeader->OptionalHeader.Magic != IMAGE_NT_OPTIONAL_HDR32_MAGIC))  
		return 0;  

	DWORD exportsStartRVA, exportsEndRVA;  
	pImageBase = (PBYTE)dosHeader;  

	// Make pointers to 32 and 64 bit versions of the header.  
	pNTHeader = MakePtr( PIMAGE_NT_HEADERS, dosHeader,dosHeader->e_lfanew );  

	exportsStartRVA = GetImgDirEntryRVA(pNTHeader,IMAGE_DIRECTORY_ENTRY_EXPORT);  
	exportsEndRVA = exportsStartRVA +  
		GetImgDirEntrySize(pNTHeader, IMAGE_DIRECTORY_ENTRY_EXPORT);  

	// Get the IMAGE_SECTION_HEADER that contains the exports. This is  
	// usually the .edata section, but doesn''t have to be.  
	PIMAGE_SECTION_HEADER header;  
	header = GetEnclosingSectionHeader( exportsStartRVA, pNTHeader );  
	if ( !header ) return 0;  

	INT delta;  
	delta = (INT)(header->VirtualAddress - header->PointerToRawData);  
	pExportDir = (PIMAGE_EXPORT_DIRECTORY)GetPtrFromRVA(exportsStartRVA, 
				pNTHeader, pImageBase);  


	pExportDir =(PIMAGE_EXPORT_DIRECTORY) (pNTHeader->
	OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress);  

	if (pExportDir == 0)  
	{ 
		MessageBox(NULL,"Error in GetProcAddressDirectly()",0,0);  
		return 0;  
	} 

	pExportDir =(PIMAGE_EXPORT_DIRECTORY) ((DWORD)pExportDir + (DWORD)dosHeader);  
	lpNameOrdinals =(PWORD)((DWORD)pExportDir->AddressOfNameOrdinals + (DWORD)dosHeader);  
	lpName =(LPDWORD) (pExportDir->AddressOfNames + (DWORD)dosHeader);  
	lpFunctions =(LPDWORD) (pExportDir->AddressOfFunctions + (DWORD)dosHeader);  
	lpFuncName = FuncName;  

	if(HIWORD(lpFuncName)!=0 )  
	{ 
		for( i = 0;i<=pExportDir->NumberOfFunctions - 1;i++)  
		{ 
			DWORD entryPointRVA = *lpFunctions;  

			// Skip over gaps in exported function  
			if ( entryPointRVA == 0 ) continue; 
			for( j = 0;j<=pExportDir->NumberOfNames-1;j++)  
			{ 
				if( lpNameOrdinals[j] == i)  
				{ 
					lpExpFuncName = (char *) (lpName[j] + 
							(DWORD)dosHeader);  
					if(strcmp((char *)lpExpFuncName,(char *)FuncName)==0)  
						return (DWORD) (lpFunctions[i] + 
								(DWORD)dosHeader);  
				} 
			} 
		} 
	} 
	else 
	{ 
		for (i = 0 ;i<=pExportDir->NumberOfFunctions - 1;i++)  
		{ 
			if (lpFuncName == (char *)(pExportDir->Base + i))  
			{ 
				if (lpFunctions[i]) return (unsigned long) (lpFunctions[i] + 
							dosHeader);  
			} 
		} 
	} 
	return 0;  
}

DWORD UnloadPbDllFromMemory(PIMAGE_DOS_HEADER dosHeader) 
{
	PIMAGE_NT_HEADERS pNTHeader; 
	pNTHeader = (PIMAGE_NT_HEADERS)((DWORD)dosHeader + (DWORD)dosHeader->e_lfanew); 
	EntryPoint = (LPENTRYPOINT)(pNTHeader->OptionalHeader.AddressOfEntryPoint +
					 (DWORD)dosHeader); 
	EntryPoint((HINSTANCE)dosHeader, DLL_PROCESS_DETACH, 0); 
	return VirtualFree(dosHeader, 0, MEM_RELEASE); 
}

　　在本文附带的示例代码中，合并了一个名为 hardware.dll 的动态连接库，该动态连接库是一个获取系统硬件信息的库文件，其中包括了以下函数:

   getmac 		取得网卡 MAC 
   VolumeNumber 	取得硬盘卷标 
   changeres            改变屏幕分辩率 
   IsDiskInDrive        检查软驱中是否插有盘 
   DPGetDefaultPrinter  取得默认的打印机名 
   DPSetDefaultPrinter  设置默认的打印机 
   getserial            取得硬盘的出厂序列号 
   getmetric            取得显示分辩率 
   PrintStringDirect    直接向打印机发送一个串 
   vfpbeep              让 PC 喇叭发声 
   getcpuid             取得 CPU ID 
   getbios              取得主板 BIOS ID 

题外话
　　另外，其它一些本文未提及的非主要的函数，请自行参见源代码中的注释。
再，本文涉及 PE 文件格式方面的知识，它们已经超出了本文的范围，具体信息可参见 MSDM 中的:

特别感谢卢春明（Aming）在我编写本文时所作的一些技术方面的建议和指导

如果本文对你的开发有所帮助，并且你手头恰好有零钱。

不如打赏我一杯咖啡，鼓励我继续分享优秀的文章。

摘要

本文简要介绍了在DirectX 9 SDK中提供的Effect Framework支持，以及DirectX FX文件结构和Microsoft Hight Level Shading Language的基本知识。本文假定读者对DirectX Graphics有一定了解，并正在学习DirectX Effect Framework。希望能够与各位读者共同探讨、切磋。

简介

Effect的起源

在计算机3维场景中，物体表面的材质代表了其光学特性。最简单的材质可以表现为Diffuse颜色，Specular颜色，Emissive颜色等信息的集合；而为了表现物体表面的细节，可以 在材质中加入一张纹理——这些就构成了最基本的材质信息。在以前的Direct3D程序中，这些信息可以直接传送给设备，由设备自动根据它们来计算物体表面的光学效果。但是， 仅仅有这些基本的材质信息，已经不足以满足游戏制作者的要求和游戏玩家的要求了——他们希望场景中的材质更加复杂，具有更多的细节，更加逼真。

在Direct3D中，除了材质的概念，还存在一个渲染状态（Render State）的概念。在Direct3D Device中存在很多的渲染状态，它们可以在Direct3D进行渲染时控制渲染的流程和效 果，从而实现某些带有特效的材质。程序员可以通过IDirect3DDevice*::SetRenderState()方法来设置这些状态。所有的渲染状态都是一些特定的数值。对状态的设置可以通过硬 编码完成，即在程序中调用SetRenderState()方法，将设置什么样的状态“写死”在程序里，但是这样做的缺点就是太不灵活了——如果想要实现一种新的渲染状态，就需要修改 程序代码。所以更好的一种方法是将为了实现某一种特效材质的一些渲染状态值记录到一个“效果文件”中，通过在程序运行时读取该文件，从中分析出这些值，并将它们作为参 数调用SetRenderState()。这样，要想实现一种新的特效，只需修改“效果文件”而不用更改代码。

Direct3D SDK是通过Effect Framework来支持这种机制的。而前面所述的“效果文件”在Direct3D中是以*.fx文件存在的。在fx文件中保存了为实现某一特效的渲染状态，包括状态名 称和它们的对应值。所以在9.0以前版本的DirectX中就已经有Effect Framework和FX文件了，早期的Effect Framework仅仅是为了实现对渲染状态进行控制。 但是随着计算机显示硬件技术的发展，图形处理单元（GPU）正在重复CPU所走过的路——新一代的GPU已经具有了可编程特性，程序员可以通过对GPU编写一段程序来控制其渲染的 输出效果。这种程序一般称为Shader程序。目前的Shader程序分成两种，Vertex Shader和Pixel Shader。Vertex Shader主要用于对3维网格模型的每一个顶点进行处理，而Pixel Shader主要用于对要绘制到屏幕上的每一个象素进行处理。通过Shader，程序员可以制作出相当丰富的实时渲染效果。

同CPU一样，对GPU编程也是借助一定的编程语言来进行的。 在DirectX 8中，对GPU的编程是通过一种类似于汇编的语言进行的。而在DirectX 9中，使用了一种类似于C语言的高级语言——Microsoft High Level Shading Language (HLSL) 。

无论使用什么语言对GPU编程，都需要把编译好的Shader程序输送到显卡去。Direct3D Device可以通过SetVertexShader()和SetPixelShader()来向显卡输送Shader程序。然而，由 于Shader和材质具有十分紧密的关系——一般来说，一个Shader就是为了实现一种特殊的材质——最好是能够将Shader程序与材质进行整合。 所以，在DirectX 8和DirectX 9中，原来的Effect Framework发生了扩充——在原来的基础上加入了对Shader程序的支持。程序员可以把Vertex Shader和Pixel Shader程序以函数 的方式直接书写在FX文件中。

 .FX文件

FX文件中的内容大致可以分成几部分：

• 预编译标志
• 变量表
• 结构定义
• 函数
• Technique

预编译标志：预编译标志包括

• #define
• #elif
• #else
• #endif
• #error
• #if
• #ifdef
• #ifndef
• #include
• #line
• #pragma
• #undef

其中最常用到的是#include和#define，同C语言中的意义很相似：用#include可以在一个FX文件中引入另外一个或多个文件。#define可以定义FX文件中的宏替换。例如：

#include带来的好处和C中也是一样的－您可以在一个头文件中定义一些公有变量、函数等，在其他文件中引用它们－就不用写很多遍了。例如：

文件public.fh:

//定义一个名为VS_OUTPUT的结构。关于结构体定义，下文中会有介绍

//定义一个名为CaculateWorldPosition的函数。关于函数定义，下文中会有介绍

这样，当我们在另外一个文件中include这个头文件时，上面所有的定义都可以直接使用了。

文件client.fx:

Ogre的Manager真是多啊,就象个官僚公司,干事的没几个,一堆的Manager,个个丫还都是Singleton.说自己是Singleton却又public构造函数,让人来new它.在第1次被new的时候,偷偷地将this赋给静态成员ms_Singleton,第2次new它就要assert喊冤了,当然这都是叫Singleton的模板基类的那个构造函数干的(典型的小人行径,见不得光).Manager一多,本来不复杂的事,也变得复杂了.

1.LogManager
a.全局单体LogManager组合Log指针Map集合,控制有多个Log对象,1个Log对象表达对一个Log文件的输入(老一套).
b.同时LogManager维护1个当前默认主事的Log对象mDefaultLog,以展现Log对象功能而隐藏自己实际是个Manager的身份(邀功自赏,其心可诛).
c.维护一个监控者接口LogListener列表,以履行作为一个Manager受外部监督的职责(实为推清责任).

2.DynLibManager
a.全局单体DynLibManager组合DynLib*指针Map集合,控制多个DynLib对象,1个Dynlib表达对动态库的装载和卸载(典型的官僚主义,人浮于事,这点屁事都要有Manager).

3.ResourceGroupManager
  a.全局单体ResourceGroupManager组合ResourceManager指针Map?Manager的Manager,靠,好大的官)
  b.一上任就安插了个亲信Manager,建立个叫General的ResourceManager.

4.SceneManagerEnumerator
  a.连它都是系统单体,一个迭代器,小人得志啊,不说了,它可管着一堆SceneManager,惹不起.
  b.一开始就安排了什么事都作不了的SceneManager(基类)作默认SceneManager,大事小事都是它,室内室外一手包.

5.一堆中层干部,一堆的MaterialManager,MeshManager,ParticleSystemManager,SkeletonManager......,都是Singleton,有的还是ResourceManager的门生,一开始都干了2件事.
a.定名分:向ResourceGroupManager注册说自己是某方面的Manager,_registerResourceManager.
b.要资源:向ResourceGroupManager要求控制对某种脚本的解析_registerScriptLoader(就是瓜分资源).
c.有个OverlayManager,ArchiveManager最牛,手下还有几个工厂给它干活,无非是自己作不了,又推给下级.

6.一堆插件外劳,开始加载,这些外劳到系统中来当然要注册.

7.透明实体mTransparentObjects按z序排序,不透明实体按material分组.

8.我一开始认为Materail是个很聪明的概念,后来才发现上当受骗了,它管理了mTechniques数组,而Techniche管理了mPasses数组(Multipass render),最后实质的内容在Pass类中,Pass类表达了一个渲染的环境.由于这个官僚系统实在太官僚,所以按对象每次渲染是不可接受的(跨部门合作太多,相互扯皮),渲染状态切换频繁,效率极低,透明渲染z序混乱.所以需要按Materail分组和z轴分序,而RenderSystem的最重要方法接受RenderOperation参数.

9.Pass和RenderOperation是两位最能干的劳动人民,都是受人管制的对象,整个系统的灵魂和核心,Pass封装了最重要的渲染状态(即进行glDrawXXX时管线所处的状态,着色系统),RenderOperation封装了带纹理几何渲染操作(glDrawElements几何系统),两者构成一个完整的渲染.即,先,调用SceneManager的setPass(在其中其仍将调用RenderSystem以设置管线状态),再,调用RenderSystem的_render.

10.SceneManager的虚方法_findVisibleObjects是场景管理的核心,由它将Renderable分组,分透明和不透明分送入不同的渲染队列,Renderable组合RenderOperation和Pass(但出头的都是Materail),然后SceneManager对之排序,整理,送入RenderSystem渲染.

11.SceneManager的_renderScene是基本渲染核心,它完成若干任务
   a.帧动画驱动_applySceneAnimations
   b.场景图更新_updateSceneGraph
   c.渲染队列更新,_findVisibleObjects更新主场景,_queueOverlaysForRendering更新上层主界面,_queueSkiesForRendering更新天空盒,最后_renderVisibleObjects.

12.渲染队列RenderQueue,维护std::map<RenderQueueGroupID, RenderQueueGroup*>对象,以表达其内部的多个方面(世界,前景,背景)的渲染分队列.RenderQueueGroup再往下分std::map<ushort, RenderPriorityGroup*, std::less<ushort> >,以表达其(如前景)内部按ushort优先级维护渲染分队列.RenderPriorityGroup维护一个mTransparentPasses,若干个SolidRenderablePassMap.

图像使用2次方是很讨厌的问题,不在技术难度上,而在技术妥协上.实际上要求美工作出2次方纹理,并且整张图的空间利用率要高,是很难的.
当有些策划丢过来奇奇怪怪的尺寸的图像,我都要吐血,当知道2n次方限制后,他们把图像尺寸扩大一下,再丢给我空余大量空白的2n次方纹理,再吐血.

玻璃渣资源里标准的2n次方人物纹理,图像挤的满满的,每个身体部位纹理还是一个矩形,利用率之高不得不令人佩服,然而这对美工要求是极高的.
1024*768的图像是要拆成4*3的256*256图像的,而不是一整大张纹理,因为768不是2的n次方,更不要扩大为1024*1024,加大25%的内存.
还有Wow里Loading界面的图像都压成512*512,因为Loading图像模糊一点不要紧,很简单却都是很重要的细节.
所以当Wow运行在我Geforce2的显卡上时,我觉的很cool.

Nvidia的驱动程序也很讨厌,实际Geforce6显卡才支持non power of two texture,Geforce 5200级的显卡,在硬件能力上不足以支持NPOT,但是最新的驱动程序使用了软件模式进行模拟支持,而软件模拟根本毫无实用价值,渲染变得超级缓慢,因为驱动程序每次纹理渲染都会很聪明地把非2次方尺寸图像自动Scale到2次方尺寸,对于一个800*600的图像,驱动程序在这个步骤就吃光了CPU.
所以总有些人喊着为什么OpenGL没有软件渲染支持,DX很体贴都有(实际上DX也没有,比如那个所谓的8层纹理),而我认为如果软件渲染能解决问题,那要硬件作什么!不能解决问题的方案我们支持它作什么!

// OpenGL动态执行2n次方图像限制
inline int next_p2(int a)
{
 int rval=1;
 while(rval<a) rval<<=1;
 return rval;
}

int nWidthPowerOfTwo = next_p2(tex.nWidth);
int nHeightPowerOfTwo = next_p2(tex.nHeight);

if(tex.nWidth == nWidthPowerOfTwo  &&  tex.nHeight == nHeightPowerOfTwo)
{ 
 glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, nWidthPowerOfTwo, nHeightPowerOfTwo, 0, ilGetInteger(IL_IMAGE_FORMAT), GL_UNSIGNED_BYTE, ilGetData());
 tex.fScaleX = tex.fScaleY = 1.0f;
} 
else
{ 
 glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, nWidthPowerOfTwo, nHeightPowerOfTwo, 0, ilGetInteger(IL_IMAGE_FORMAT), GL_UNSIGNED_BYTE, NULL);
 glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, tex.nWidth, tex.nHeight, ilGetInteger(IL_IMAGE_FORMAT), GL_UNSIGNED_BYTE, ilGetData());
 tex.fScaleX = (float)tex.nWidth / (float)nWidthPowerOfTwo;
 tex.fScaleY = (float)tex.nHeight/ (float)nHeightPowerOfTwo;
}

然而对这个问题,正确的解决方案是事先规划,强制执行,be clever.