down link :  NormalMapGenerator

http://goo.gl/bdQfP

올려짐: 2004-09-16 06:33    주제: 높이맵이 문제네요....

lachesis님의 조언대로 NormalMapGenerator라는 노말맵 생성 프로그램의 소스를 분석해 노말맵 생성프로그램을 구현 해보았습니다.(코드량 정말 쪼끔)  그런데 문제는 그 소벨필터링은 일반적인 칼라이미지가 아닌 높이맵을 읽어서 노말맵을 생성한다는 것입니다. 일단은 GPG2의 부록 CD에 있는 높이맵을 가지고 테스트 해봤습니다. 물론 제대로 노말맵이 생성됩니다.  그런데 이 높이맵을 어떻게 칼라맵에서 뽑아 낼지가 관건입니다.  일단은 높이맵이 그레이스케일 이미지라고 해서 픽셀의 RGB값을 더해서(R+G+B) 3으로 나누어 다시 RGB에 똑같은 값으로 저장해 보았습니다.  RED = (R+G+B)/3;  GREEN = (R+G+B)/3;  BLUE = (R+G+B)/3;  하지만 부록 CD에 있는 높이맵 처럼 나오지가 않습니다. ㅡㅡ  이 높이맵을 생성할 수 있는 방법을 알고싶네요.........................  그전에 GPG2 CD의 RadeonDot3Bump3DLight폴더에 있는 FieldstoneBump파일이 높이맵이 맡는지 물어보고 싶네요... 높이맵 같은데 파일 이름끝에 Bump라고 붙어 있어서... ㅡㅡ voidpeople님께서 지금 하고있으신 작업은 대부분 ATI개발자에 자료가 꽤 있습니다.  노말맵생성에 대해서도 역시 NormalMapGenerator라는 툴을 제공하고있는데  소스도 같이 배포하고 있구요, 소스파일은 고작 하나뿐인데 300줄 밖에 되지않습니다.  TGA형태의 height map을 읽어서 normal map으로 바꿔주는데,  질문하신 sobel filter를 적용하는 부분도 나와있구요.  그리고 또 찾아보시면 NormalMapper라는 툴도 소스와 함께 제공하는데,  보통 Doom 3나 FarCry 등에서 쓰는 하이폴리곤에서 노말맵을  추출하는 polybump 형태의 툴도 있습니다.

DXViewer.exe

예전버전인듯..

http://www.nvidia.co.kr/geforce-experience/

드라이버를 최신 상태로 유지하고 게임을 최적화할 수 있는 가장 쉬운 방법

3d max 폴더중 plugins 폴더에 .dle 파일을 복사해 넣으면 된다

PandaDirectXMaxExporter_x64_6.2011.72.0.zip

PandaDirectXMaxExporter_x86_5.2010.67.0.zip

http://www.andytather.co.uk/Panda/directxmax_downloads.aspx

http://goo.gl/9yU00

http://kblog.popekim.com/2012/10/kgc-2012_12.html

2012년 10월 12일 금요일

http://www.gpgstudy.com/forum/viewtopic.php?topic=8829

엔진 속도를 올려볼려고, 파티클의 빌보드 한개당 DrawPrimitive하던것을 
긴 버텍스 버퍼에 월드 좌표로 때려밖은후에 렌더링 하려고 고치는 중입니다. 

DrawPrimitive횟수도 많이 줄이고요, SetRenderState, SetTexture횟수도 줄이도록 정렬하고있습니다. 

그런데.. 버텍스 버퍼가 크다보니 락/언락만 해도 프레임이 10%로 내려가더군요.. 
엄청난 속도 저하이죠..^^ 정확히 이야기하면 락/언락 하고 그버퍼의 폴리곤 1개만 찍어도 그러더군요.. 
안찍으면 락/언락해도 전혀 안내려가고요... 

버텍스 버퍼를 D3DPOOL_MANAGED로 만들어서 DrawPrimitive하는순간 시스템메모리에있는 복사본을 
VGA로 넘기나 봅니다. 
그래서 D3DPOOL_DEFAULT로 생성했더니 속도저하가 없더군요..다만 디바이스 리셋시 삭제/복구만 잘해주면 
될듯 싶습니다.. 그게 귀찮아서 이제껏 D3DPOOL_MANAGED만 사용했었거든요.. 

지오메트리랑, 스킨모두 D3DPOOL_MANAGED로 사용하고있거든요.. 
지오메트리야 정점 버퍼 자체는 변하지 않아서 첨 생성해서 만든다음 그냥 사용하고 
스킨은 Tick()마다 락/언락을 하거든요.. 

궁금한점 
1. 락/언락을 하지 않는 버퍼는 D3DPOOL_MANAGED와 D3DPOOL_DEFAULT가 성능이 같나요? 
2. 락/언락을 하는 D3DPOOL_MANAGED버퍼는 DrawPrimitiveUP하고 성능이 같나요? 
3. 모두 D3DPOOL_DEFAULT로 바꾼다면 비디오메모리가 모자랄경우 D3DPOOL_MANAGED에 비해 단점이 있나요? 혹은 디바이스 리셋시 삭제/복구말고, 락할때 옵션이라던지 다른 관리들이 필요한지 궁금하네요..

SDK 도움말에 설명이 나와있긴하지만.. 그래도 꽤 많은 분들이 헷갈려하시는거 같습니다. 

D3DPOOL_MANAGED 는 풀이 시스템메모리에 백업되고 필요시에 비디오메모리로 로드됩니다. 한번 로드된 풀은 해제되거나 아니면 메모리의 부족으로 강제로 내려갈때까진 메모리상에서 유효합니다. 
시스템메모리에 백업되어있기때문에 디바이스 리셋시에도 별다른 조치를 할 필요가 없습니다. 

D3DPOOL_DEFAULT 는 풀이 비디오메모리에 바로 생성되고 메모리가 부족하면 풀을 만들때 오류를 뱉어냅니다. 따로 백업되어있지않기때문에 디바이스 리셋시에 더이상 유효하지 않게 됩니다. 

D3DPOOL_MANAGED 는 시스템메모리에 백업되어있기때문에 'Read' 하는것에는 별다른 문제가 없습니다. 다만 'Write' 는 하게될때마다 메모리에서 내렸다가 다시 로드되어야되기때문에 무리가 따릅니다. (레퍼런스상에서도 D3DPOOL_MANAGED 로 생성된 버텍스버퍼나 인덱스버퍼는 런타임상에서 업데이트하는걸 성능상에 문제로 추천하고 있지 않습니다. 같은 이유로 렌더타겟같은것들은 D3DPOOL_MANAGED 로 만들수가 없습니다.) 

D3DPOOL_DEFAULT 는 따로 시스템메모리에 백업이 없기때문에 'Read' 에 무리가 있습니다. 다만 'Write' 하는것에는 D3DPOOL_MANAGED 로 만들어진것보단 적합해서 각종 다이나믹 버텍스버퍼/인덱스버퍼 등에 쓰이게 됩니다. 

다이나믹 버텍스버퍼나 인덱스버퍼를 쓸때 자주 쓰이는 옵션인 D3DLOCK_DISCARD 와D3DLOCK_NOOVERWRITE 는 CPU 와 GPU 의 병목현상을 막기위한 플래그들입니다. 
D3DLOCK_DISCARD 는 현재 드라이버가 잡고있는 풀은 그대로 내버려두고 같은 크기의 새로운 풀을 잡아서 거기에 업데이트를 할수 있게합니다. 그리고 잡고있던 풀이 다 쓰여지고 나면 그 풀을 해제되고 새롭게 만들어졌던 풀이 쓰이게 되는거죠. 드라이버가 다 그릴때까지 멈춰있을수없으니 이런식으로 쓰게 됩니다. 
D3DLOCK_NOOVERWRITE 는 현재드라이버가 잡고있는 풀을 업데이트하지 않겠다고 명시적으로 말하는거가 되겠네요. 렌퍼런스에서는 저 두개의 옵션중에 한가지는 꼭 Lock 할때 써주는것을 추천하고 있습니다. (두개같이 쓰는건 비추하고 있습니다.) 

이런저런 이유로 보통 다이나믹 버텍스버퍼나 인덱스버퍼를 쓸때는 조금 큰 하나의 풀을 잡아놓고 거기에 조금씩 알맞는 플래그로 업데이트해가며 렌더링하는게 여러가지면에서 좋은거 같습니다. 

unsigned int uOffset = 0; 
Loop { 
unsigned int uVertexSize = ...; 
if(uOffset+uVertexSize > uVertexBufferSize) { 
uOffset = 0; 
} 
unsigned long dwLockFlag = D3DLOCK_DISCARD; 
if(uOffset > 0) dwLockFlag = D3DLOCK_NOOVERWRITE; 
pVertexBuffer->Lock(uOffset, uVertexSize, ..., dwLockFlag); 
... 
pVertexBuffer->Unlock(); 
DrawPrimitive(...); 
uOffset += uVertexSize; 
} 

1. 
D3DPOOL_MANAGED 나 D3DPOOL_DEFAULT 나 업데이트를 하지 않는다는 조건에서는 성능은 같습니다. (다만 D3DPOOL_MANAGED 로 생성된 많은양의 풀들이 한꺼번에 비디오메모리로 로드되는 순간에는 버벅임같은것을 느낄수는 있습니다.) 
2. 
D3DPOOL_MANAGED 로 생성된 풀을 런타임상에서 계속 Lock/Unlock 하는건 DrawPrimitiveUP 보다 더 느릴수도 있습니다. 
3. 
모두 D3DPOOL_DEFAULT 로 바꾼다면 비디오메모리가 부족하면 아예 풀생성 자체가 안됩니다. 용도에 따라 꼭 D3DPOOL_MANAGED 가 되어야되는경우도 있습니다. (텍스쳐같은걸 Lock/Unlock 등을 통해서 읽어야되는경우) 레퍼런스상에서는 특별한 경우를 제외하곤 D3DPOOL_MANAGED 를 쓰라고 하고 있습니다.

http://tadis.tistory.com/category/Direct%20X:

다이렉트3D는 정해진 기본형(primitive)을 이용해서 그리는 함수를 4가지를 제공한다.

1. 인덱스 버퍼(vertex buffer)를 이용하지 않고 기본형을 그리는 함수

  1) DrawPrimitive(): Drawprimitive 함수는 데이터 입력스트림의 현재 집합으로부터 지정된 형식의 '인덱스 되지 않은 기본형들을 렌더링' 한다. 이 경우 유일한 '데이터 스트림은 SetStreamSource함수에 의해 선언'된 것이다. (버텍스 버퍼를 이용한다.)

  - Syntax-

   HRESULT

   : 성공하면 D3D_OK를 리턴한다. 실패하면 D3DERR_INVALIDCALL을 리턴한다.

 2) DrawPrimitiveUp(): DrawprimitiveUp 함수는 사용자 메모리 포인터에 의해 지정된 타입의 기본형정보를 렌더링 한다. (버텍스 버퍼를 이용하지 않는다.)

  - Syntax-

   HRESULT

   : 성공하면 D3D_OK를 리턴한다. 실패하면 D3DERR_INVALIDCALL을 리턴한다.

아래 번역한 것은 CEGUI 튜토리얼을 번역한 것입니다

원래 용도는 혼자만 볼것이였습니다, 얼추 번역한다음 소스에 넣었지만 결국엔 유니코드지원이 안되기때문에 빼버리게 된부분입니다만

그냥 지워버리긴 좀 아깝고 혹여나 필요한 분이 있을지도 모른다는 생각에 올려놓습니다

번역은 얼추 번역한것이라 약간 매끄럽진 않을 수도 있습니다

중간 중간 보이는 소스는 개인 프로젝트에 적용하기위해 테스트했던 코드 조각들입니다

번역사이트는 http://www.cegui.org.uk/docs 에서 튜토리얼 부분 입니다

 =================== CEGUI 파일 구성 부분 =================

//@brief CEGUI 를 활용한 GUI 클래스

//@ 아래내용은 http://www.cegui.org.uk/docs 일부 내용을 이해하기 쉽도록 번역한것,  나중에 잊어먹을 경우를 위해서.. [sjh]

//@ 

//CEGUI 는 XML 기반이다

//notice 확장자가 꼭 .xml 이 아니고 의미에 맞는 확장자가 붙는다 ,for example .imageset for an Imageset and .font for a Font 

//또한 이름짖는 규칙은 없다

//1) Imageset : Imageset은 몇몇 소스윤곽에 대해서 지정된 지역들의 모음들이다, 이미지파일 또는 텍스쳐와 같은...

//  imageset 은 scheme의 부분으로서 로드되어지는 한 Imageset을 지정한다

//2) Font : CEGUI 안에서 사용하기위한 폰트를 정의한다, 이것은 두가지 타입이 있다

//  Font는 scheme의 부분으로서 로드되어지는 한 Font를 지정한다

// 1. FreeTypeFont : 표준폰트 .ttf 폰트에 기반되어지는 폰트, 이것은 속성에서 Type="FreeType" 으로 쓰일 수 있고 .font   XML 안에서 사용된다

// 2. PixmapFont : 이 폰트의 타입은  [폰트 glyphs]에대한 이미지들을 정의한 Imageset으로 정의되어진다

// 그리고 비트맵된 폰트로서의 생각되어진 최상이다, .font XML 파일 속성에서  Type="Pixmap" 으로 쓸 수 있다

//3) LookNFeel :  LookNFeel은 CEGUI의 skinning system의 주요한부분으로부터 보관한다

//   WidgetLook과 그 자식에 대한것들을 담고있다

//   LookNFeel은 scheme의 부분으로서 로드되어지는 한 LookNFeel파일을 지정한다

//   

//4) Scheme : Scheme 파일은 다른 데이터 파일들과 리소스들과 함께 그룹화하는 넓은 의미이다 그리고 그것들의

//  상호작용의 몇몇을 정의는 그리고 싱글포인터로부터 CEGUI의 windows와 widgets 를위해서 

//  'skin' 으로 간주되어지는것을 로드하는 의미이다

//  

//5) Layout :  레이아웃파일은 window 레이아웃의 XML표현을 포함한다. 각 집합된 'Window' 속성은 만들어질수있는 

//   window 또는 widget을 정의한다,

//   'Property'요소들은 바랬던 세팅과 각각 정의되어지는 window를 위한 property 값들을 정의한다

//   

//6) Config : CEGUI의 config파일지원은 모든 system default들,  로드되어지는 initial resource들을 지정하는것을 당신에게 허ㅎ ㅓ락한다.

//  뿐만아니라 초기화와 실행하기위한 종료 스크립트파일들(ScriptModule을 사용할때)

// , Renderer와 System오브젝트들을 만들수있는것을 넘어 C++코드의 쓰여지는 라인없이도...

//

 ===================  초기화 부분 ===================

using namespace CEGUI;

//@brief CEGUI 를 활용한 GUI 클래스

//@ 아래내용은 http://www.cegui.org.uk/docs  내용을(전체는 아니지만 중요 부분을 번역한것[SJH], 나중을 위해..

//----------------==========-----------------[ CEGUI의 기본적인 리소스 로딩 sjh]----------------==========-----------------

//CEGUI 의 기본적인 bootstrapSystem() 을 수동으로 만들어주는 구문은 

//http://www.cegui.org.uk/docs/current/rendering_tutorial.html   에서 The Hard Way: Manual object creation. 이하의 구문을

// 따라하면 된다, Call the function to render the GUI 이것 전까지

//리소스 그룹 생성

CEGUI_TRY{

//[ CEGUI 렌더링을 얻기위한 가이드 ] http://www.cegui.org.uk/docs/current/rendering_tutorial.html

//1. 오브젝트로 기반된 CEGUI::Renderer의 인스턴스를 생성한다

//2. CEGUI::System 오브젝트를 생성한다(오브젝트 : 위에서 생성되어진 renderer에서 파싱한것)

//3. 각 프레임,  렌더링을 수행하기위한 CEGUI::System::renderGUI 함수를 호출한다.

// bootstrapSystem 함수는 아래3개를 생성한다, 인자는 CEGUI의 렌더링연산을 위해서 사용되어질 디바이스를 넘긴다

// * 리턴값 : 생성되어졌던  CEGUI::Direct3D9Renderer 오브젝트에 레퍼런스 

//- CEGUI::Direct3D9Renderer

//- CEGUI::DefaultResourceProvider

//- CEGUI::System

//CEGUI 의 기본적인 모든걸 자동적으로 만들어주는 명령문

Direct3D9Renderer& tempRenderer = Direct3D9Renderer::bootstrapSystem( _pD3dDevice );

//initializeManually();

//[ ResourceProviders로 리소스 로딩에 대한 가이드] http://www.cegui.org.uk/docs/current/resprov_tutorial.html

//

// 우리는 당신이 리소스 그룹들과 

// CEGUI와 함께 제공되는 datafiles(C:\sjhPhysics\datafiles\.) 디렉토리안에 data file들을 접근하는 

// 그것들의(리소스 그룹들의) 대상 디렉토리들의 초기화를 수행할 방법, 

// 그리고 우리가 모든 리소스 타입들에 대해 사용되기 위해서 defaultgroups를 할당하는 방법을  보여줄것이다

// 흔히있는 것으로서 핵심 CEGUI::System 오브젝트를 초기화한 후에, 우리는 리소스 그룹들의 한 set과

// 그것들의 타겟 디렉토리들의 한 set을 그때 지정한다.

// ( 타겟 디렉토리들 : 이것은 워킹 디렉토리가 CEGUI 패키지와 함께 'bin' 다렉토리가 될것을  맡는다.)

// DefaultResourceProvider에 대해 필요되는 dirs 를 초기화한다

CEGUI::DefaultResourceProvider* rp = static_cast<CEGUI::DefaultResourceProvider*>

(CEGUI::System::getSingleton().getResourceProvider());

rp->setResourceGroupDirectory("schemes", "../CEGUI/datafiles/schemes/"); //schemes

rp->setResourceGroupDirectory("imagesets", "../CEGUI/datafiles/imagesets/"); //imagesets

rp->setResourceGroupDirectory("fonts", "../CEGUI/datafiles/fonts/"); //font

rp->setResourceGroupDirectory("layouts", "../CEGUI/datafiles/layouts/"); //layouts

rp->setResourceGroupDirectory("looknfeels", "../CEGUI/datafiles/looknfeel/"); //looknfeel

rp->setResourceGroupDirectory("lua_scripts", "../CEGUI/datafiles/lua_scripts/"); //lua_scripts

// 만약 당신이 Xerces를 사용하는 중이고 schemas 위치(locatin)를 지정해야한다면

// 이것은 오직 실제로 필요가 되어진다.

rp->setResourceGroupDirectory("schemas", "../datafiles/xml_schemas/"); //xml_schemas

// 지금 완료되었다, 

// 우리는 그것들(리소스 그룹들)의 대상 디렉토리들 set과 함께 정의되는 리소스 그룹들의 한 멋진 set을 가지고있다.

// 끝으로, 그것들(리소스 그룹들)의 디렉토리들을 사용하는 system을 얻기위해서, 

// 우리는 사용되어지는 default resource groups를 설정한다

//유효성 스키마( validation schemas)를 위한 설치기본그룹 (setup default group)

CEGUI::XMLParser* parser = CEGUI::System::getSingleton().getXMLParser();

if (parser->isPropertyPresent("SchemaDefaultResourceGroup"))

parser->setProperty("SchemaDefaultResourceGroup", "schemas");

// 사용어지는 default resource groups을 설정한다

CEGUI::Scheme::setDefaultResourceGroup("schemes"); //schemes 를 default 그룹으로 설정

CEGUI::Imageset::setDefaultResourceGroup("imagesets"); //imagesets 을 default 그룹으로 설정

CEGUI::Font::setDefaultResourceGroup("fonts"); // fonts 를 default 그룹으로 설정

CEGUI::WindowManager::setDefaultResourceGroup("layouts"); //layouts를 default 그룹으로 설정

CEGUI::WidgetLookManager::setDefaultResourceGroup("looknfeels"); //looknfeels 를 default 그룹으로 설정

CEGUI::ScriptModule::setDefaultResourceGroup("lua_scripts"); //lua_scripts를 default 그룹으로 설정

// 아래 내용을 정리해보면 schema는 어떤 .xsd 파일

// schme는 .xsd 파일안에 있는 내용들의 그룹지어지는 묶음을들을 각각 scheme라고 칭하는 듯

//[ 데이터 파일과 Defaults 초기화에 대한 가이드 ] http://www.cegui.org.uk/docs/current/datafile_tutorial.html

//[소개]

// CEGUI는 다양한 다른 data 파일들을 사용하고

// (적어도 처음에)정확하게 모든 이 파일들이 있는것으로서 몇몇의 혼란과 그것들이 서로 관계되는 방법이 있다.

// 게다가, 당신들이 CEGUI을 사용하는 당신의 다수의 응용프로그램을 위해서 대부분 분명히 

// 설정 할( 설정하기위해서 기술적으로 필요없는 반면에 ) 몇몇의 system 전체 default들이 있다.

// 이 튜토리얼은 당신이 CEGUI와 함께 사용되는 기본 default 옵션들을 설정하는것과 데이터와 함께 더 쉬울 수 있도록

// 명령에 대한 이 주제들에 대한 소개로서 제공될것이다.

//[Font, Imagest, LookNFeel,Scheme, XSD?   그것은 모두 XML 이다]

//

//스크립트 언어 파일들과 로드할수있는 모듈들(.dll/.so files, 등등), 그래픽컬 이미지의 예외와 함께 

// CEGUI를 가지고 사용되어지는 모든 데이터 파일들은 XML기반이다.

// 이것은 당신이 실행 할(.xsd schema 파일들) 첫번째의 가능성있는 방해물로 우리를 실제로 이끈다.

// 

//  스키마 유효성(Schema Validation )

// 비록 Expat 기반 XML 파서 모듈이 XML 데이터 파일들을 파싱하는 것을 위해 지금 default 선택이되었다고 할지라도,

// 이전에 오랬동안 default는 (그리고 여전히 이 저자가 선택을 선호한다) 아파치 소프트웨어 재단(http://xerces.apache.org/xerces-c)

// 으로부터 Xerces-c++ 라이브러리에 대해 기반된 파서이다.

// 이 특별한 파서를 사용하는것의 이점은 그것이 스키마 유효성(schema validation)을 제공하는 것이다.

// 특별한 경험이 없는 사람들을 위해서, 스키마 유효성(schema validation)은 새로온 XML data가 

// 그것이(XML data) 잘 구성되어있고 그것이(XML data) 필요되어지는 정보를 포함한다는것을 보장하기 위해서

// 확인할 수 있는 방법이다.

// 작동하기위한 이 유효성(validation)을 위해서, 몇몇의 추가적인 파일들이 필요되어진다

// 

// ( schema 파일 : schema 파일들로서 알려진 놀랄것도 없이 

//   아래에 설명되어진 CEGUI's 자신의 scheme 파일들에 혼란되지 않기위한 파일들이다 )

//   

// schema 파일들은 XML 입증에 사용된다 왜냐하면 CEGUI는 CEGUI 범위에  datafiles/xml_schema/ 디렉토리안서

// 발견 되어질수 있기때문에, 그리고 .xsd 파일 확장자를 가진다.

//   

// 당신이 현재는 알아야하는 중요한 것은 XML 파서를 기반으로 한 Xerces-C++ 을 사용하는 중일때, 이 .xsd 파일들이

// ResourceProvider system에서 반드시 이용가능하다는 것이다.

// 

// 이것은  schema 파일들을 포함하고있는 디렉토리에서 리소스 그룹들을 세팅하는 것에의해 그리고  

// schema 파일들을 로딩하는 중일때 CEGUI::XercesParser에 의해 사용되는 default 로서 그 그룹을 세팅하는것에

// 대게 가장 잘맞게 달성되어지진다.

// 

// ( schema 파일들 :   The Beginners Guide to resource loading with ResourceProviders

// [http://www.cegui.org.uk/docs/current/resprov_tutorial.html] 이  안에서 

// 이것이(스키마 파일) 다뤄지고있는것을 수행하기위한 세부사항  )

//[데이터 파일]

// 이전에 언급된 것으로서, CEGUI에 대다수의 데이터 파일은 XML기반이다. 

// 일반적 '.xml' 파일 확장자를 사용하는 것 보다, 데이터 파일은 파일들이 실제로 나타내는 것에따라 보통  지정된다

// 예를들어, Imageset을 위한 .imageset과 Font를 위한 .font

// (그렇지만, 이 이름짓는 system의 필요조건은 없다 - 당신은 당신이 좋아하는 어떠한 방법을 이름짓는것은 자유다)

// 목적 각 파일 타입의 매우 간략한 개요를 이제 따른다.

// 

// [Imageset]

// Imageset은 몇몇의 소스외면에 이름지어진 지역들의 모음이다, image파일 또는 texture 와 같은..

// CEGUI 전문용어안에서, 각각의 이 명명된 지역들은 Image 이며 CEGUI에 의해 사용 되어지는 사진의 기본 레벨이다.

// 소스 image파일 또는 텍스쳐 컨텐츠를 수정하는것에 의해서, 또는 Imageset 파일을 가지고 정의되는 지역들의 범위들을

// 수정하는것에 의해서 , 당신은 CEGUI에 의해 그려지는 것의 표현을 쉽게 변화시킨다.

// 

// Imageset 파일들의 완벽한 설명을 위해서, Imageset XML 파일들을 보아라. ( Imageset XML files [http://www.cegui.org.uk/docs/current/xml_imageset.html] )

// 

// [Font]

// 놀랄것도 없이, Font 파일은 CEGUI안에서 사용을위한 폰트를 정의한다.

// 정의되어질 수 있는 폰트는 존재하는 두가지 타입들에 있다  :

// 

// FreeTypeFont) : 이것은 표준 폰트 파일에 기반되어진 폰트이다( true-type '.ttf' font 와 같이 ).

// FreeTypeFont은 .font XML 파일안에서 속성 Type="FreeType"을 통해서 지정된다.

// Imageset 파일들의 완전한 설명을 위해서, Imageset XML files를 보아라

//   (Imageset XML files [http://www.cegui.org.uk/docs/current/xml_imageset.html] )

//

// PixmapFont) : 폰트의 이 타입은 폰트 문자를 위해서 Image들을 정의하는 Imageset에 기반되는 폰트이다,

//  그리고 비트맵된 폰트로서 생각되어지는 최상이다.

//  PixmapFont는 .font XML 파일안에서 속성 Type="Pixamp"을 통해서 지정된다.

// 폰트 파일의 완전한 설명을 위해서, Font XML 파일들을 보아라. 

//   (Font XML files. [http://www.cegui.org.uk/docs/current/xml_font.html] )

// 

// LookNFeel) : LookNFeel은 중요한 대부분의 CEGUI의 skinning system에서 보관한다. 

// 각각은 하나 또는 system 다수 이미지와 자식 widget 구성요소들, 그것들의 위치들, 

// 추가적은 속성 값, 등등에 설명된 더 많은 WidgetLook 정의들을 포함할 것이다.

// 이 WidgetLook 설명은 CEGUI안에 window들과  widget들로서 결국 나타나지는 것으로 system 내부의 요소들을

// 반드시 구체화한다.,

// 폰트 파일들의 완전한 설명을 위해서, Font XML files를 보아라 

// ( Font XML files [http://www.cegui.org.uk/docs/current/xml_font.html] )

// Scheme) :  Scheme 파일은 다른 데이터 파일들과 리소스들과 함께 그룹짓기위한 큰 수단이다.

//         그리고 그것들의 상호작용의 몇몇을 정의하기위해서, 

//         그리고 CEGUI의 window들과 widget들을 위해서 'skin' 으로 간주되어질 것들을 로딩하기위해서 싱글 포인터로부터.

//         Schme는 하나 또는 더 많은 아래것들을 포함할 수 있다.

//         1) Imageset은 scheme의 부분으로서 로드되어지는 Imageset 파일을 지정한다

//         2) Font는 scheme의 부분으로서 로드되어지는 Font 파일을 지정한다

//         3) LookNFeel은 scheme의 부분으로서 로드되어지는 LookNFeel 파일을 지정한다

//         4) WidowSet은 로드할 수있는 모듈의 이름을 지정한다,  widget 이름들의 set은 당신이 system을 등록하려는

//           모듈을(로드할 수있는 모듈의 이름을) 포함한다.

//           ( 비록 어떤 이름들이 열거되지 않더라도, 모듈에서 모든 이용가능한 타입들이 등록되어진다, system 에 )

//           이것은 CEGUI에 추가된 핵심 widget 타입을 더하는것의 편리한 방법이다.

//           ( 특별하게 비록 이 모듈이 타사에의해서 제공되어졌다 할지라도 )

//         5) WindowRendererSet은 로드할 수있는 모듈의 이름을 지정한다, 

//            그리고 window renderer의 set은 당신이 system을 등록하기 바라는 그 모듈(로드할 수있는 모듈의 이름) 내부를 포함한다

//            ( 비록 어떤 이름들이 열거되지 않더라도, 모듈에서 모든 이용가능한 타입들이 등록되어진다, system 에 )

//            'Window Renderer'는 몇몇 기본 window 타입(들)을 위해서 렌더링을 제어할 수있는 오브젝트이다.

//            CEGUI에 의해서 공급되어진 모든 window renderer 오브젝트들은 'Falagard' skinning system의 

//            활용에 의해서 렌더링을 수행한다 (비록 이것이 엄밀한 요구사항이 아닐지라도.. )

//                (Falagard는 웹에서 찾아보니 : CEGUI에서 사용하는 Falagard시스템. 즉 UI커스터마이징을 가능하게 해주는 시스템 

//                          이라 함 , 이 사람이 http://historyis.tistory.com/47 이것에 대한 설명서를 한글화 하여 파일 링크 걸어놓음)

//           6) WindowAlias는 대체 가능한 이름들에 의해서 window/widget 타입에 참조되는 방법을 제공한다.

//               또한 그리고 그것(WindowAlias)은 또 다른 widget 타입을 가지고 이미 등록되어진 Widget 타입을 'hide'  하는데에

//               사용되어질 수있다. ( 그래서 그 다른 widget타입이 대신에 사용되어진다. )

//           7) FalagarMapping은 구체적인 window/widget타입, window renderer타입 그리고 widget look 정의를 링크하는 것에

//               의해서 새로운 사용하기 편리한 window타입을 만든다.

//               

//               scheme파일들의 완벽한 설명을위해서, Scheme XML files를 보아라 [Scheme XML files: http://www.cegui.org.uk/docs/current/xml_scheme.html ]

//

//

// Layout) : layout 파일은 window layout의 XML 설명을 포함한다. 각 끼워넣어진 'Window' 요소는 window 또는 만들어지는 widget을 정의한다,

//               'Property' 요소들은 각 정의되어진 window를 위해서 바랬던 세팅들과 속성 값들을 정의한다.

//     ( layout 파일들의 완벽한 설명을 위해서, Layout XML files을 보아라 [Layout XML files : http://www.cegui.org.uk/docs/current/xml_layout.html ]  )

//  

// Config ) : CEGUI의 config 파일은 모든 system defaults, 로드되어지는 초기 리소스들, 뿐만 아니라 

// Renderer와 System 오브젝트들을 만드는 그것을 넘어 C++코드의 한 줄 쓰는것 없이

// 실행하기( ScriptModule를 사용하는 중일때 ) 위한 초기화와 종료 스크립트 파일들을 지정하는것을 

// 당신에게 ㅎ ㅓ 락한다 

// ( config 파일의 완벽한 설명을 위해서, CEGUI Configuration XML files를 보아라 

//  [CEGUI Configuration XML files : http://www.cegui.org.uk/docs/current/xml_config.html ] )

// [ 기본 파일들을 로딩하는 것 ]

// 

// 것들(일,동작)을 설치하기 위해서 그리고 몇몇 파일들에서 당신이 로드해야만하는 것을 실행하는것.

// 필요되어지는 파일들의 전형적인 set은

// 1) Imageset

// 2) Font

// 3) LookNFeel

// 4) Scheme

// 이다.

//Scheme 파일에 대하여 유용한(당신이 위 설명으로부터 지금까지 쭉 수집되어왔을 것으로 )

// 것은 당신을 위해서 다른 파일들을 자동적으로 로딩할 수 있는것이다.

// 이 튜토리얼의 목적을 위해서, 우리는 scheme 파일들과 font 파일들 로드할 것이다.

// (그것(로드할)은  scheme가 우리를 위해서 Imageset과 LookNFeel을 자동적으로 로드한다는 것을 맡는다 )

// scheme와 font 파일들은 수행되어진다.

// 이와같이 :

// TaharezLook scheme 파일을 생성한다/로드한다

// 이 자동로드 TaharezLook looknfeel와 imageset file들

CEGUI::SchemeManager::getSingleton().create( "TaharezLook.scheme" );

// 폰트를 생성/로드한다

// 로드되어지는 첫번째 폰트는 자동적으로 default 폰트이다, 하지만

// scheme는 이미 로드되어지는 폰트를 가졌을 수있다는것에 주의해야한다,

// 그래서 이미 default set이 존재할것이다,

//  만약 우리가 확실하게 default이기 위해서 "Commonweath-10"폰트를 원한다면, 우리는 명시적으로 나중에

//  default를 설정해야만한다.

//CEGUI::FontManager::getSingleton().create( "DejaVuSans-10.font" );

//위의 코드는(그리고 CEGUI 샘들을안에) 리소스 그릅 위치들과 default 그룹들이 

//[ResourceProviders로 리소스 로딩에 대한 가이드] 에서 설명되어진것으로서 모두 지금까지 쭉

// 설정되어왔다는 것을 가정한다.

//----------------==========-----------------[System defaults 초기화 sjh]----------------==========-----------------

//당신은 System을 위한 몇몇의 default 옵션들을 지정해야한다

//이것은 system은  font와 마우스커서가 이용할수있는 것으로 항상 가지고 있는것을 보증한다

//window 또는widget이 자신의것의 선호가 없음을 지정할때..

//FontManager 는 system default로서  첫번째로 로드되어지는 font 를 자동적으로 세팅한다.

//만약 이것이 당신이 필요로하는 default font가 아니라면, 또는 만약 당신이 이전 font들이 로드되어졌다는것을 보증할수 없다면

// 당신은 명시적으로 default를 지정해야한다, 이 코드로

//System::getSingleton().setDefaultFont( "DejaVuSans-10" );

//또 하나의 당신이 일반적으로 설정 할수있는 오브젝트는 마우스 커서이다

// 이것은 당신이 그것의 커서를 설정하지않은 어떠한 요소의 위로 마우스를 움직일때 마우스커서는 사라지지않는다는것을 보증한다

// 설정하기위한 default 마우스 커서를위한 코드는 아래와 같고

// 이것은 scheme에의해 로드되어지는 TaharezLook imageset을 사용한다

System::getSingleton().setDefaultMouseCursor( "TaharezLook", "MouseArrow" );

//마지막으로, 만약 당신이 툴 팁들을 사용하길 생각한다면

//당신은 당신이 그것의 목적을위해서 사용되는것을 원하는 widget 타입 기반의 ToolTip의 이름을 지정해야한다

// window 단위당 기준에 대해 이것을 설정하는것은 실제로 가능하다

// 비록 이것이 일반적으로 필요되어지지 않고 이 서문의 튜토리얼의 범위를 넘어서는 것일지라도

// default tool tip window 타입을 설정하는 코드는 이것과 같다

System::getSingleton().setDefaultTooltip( "TaharezLook/Tooltip" ); //문서에는 setDefaultToolTip 이라고 되어있지만 T 가 CEGUI::SYSTEM 에서찾아보니 소문자이다

//여기까지가 가장 기본적인 초기화이고 CEGUI 을 초기화하는 최소한의 작업이다

 ===================  =================== ================[ 생성 부분 ]===================  ===================  ===================

using namespace CEGUI;

//CEGUI 창 생성

CEGUI_TRY{

//http://www.cegui.org.uk/docs/current/window_tutorial.html

// The Beginners Guide to Creating a CEGUI Window

//이부분을 더중요한 부분이라 하니 번역해 놓는다.. 역시 나중에 시간이 지나 까먹었을때를 대비해서 [sjh]

// * brief : [모든 widget은 window이다]

// * 이것은 CEGUI로 작동할때 반드시 완전히이해되어져야하는 가장 중심의 개념이다(열라 강조한다...;;)

// * system에있는 모든 widget은 동일한 Window 기반 클래스로부터 상속되어진다.   [ http://www.cegui.org.uk/docs/current/window_tutorial.html 여기의 내용을 중요부분을 번역해놓는다, 다음 문장 번역을 위해 써놓음]

// * 그래서 나는(튜토리얼쓴사람) window를 언급할때는 언제든지, 이 튜토리얼의 목적들을 위해서,

// * 동일한 아이디어들은 push button 또는 스크롤바 widget으로 그냥 쉽게 적용되어질 수있다는 설명을 덧붙인다. (튜토리얼이 비기너 튜토리얼이라 이런 글을 써놓은듯..)

// * 

// * brief [많은 설정들은 상속되어진다]

// * CEGUI안에서 window들을 위해서 유용한 많은 설정들과 속성들은 window 계층구조아래로 전달되어진다.

// * 예를들어, 그때 default에 의해서, 만약 당신이 0.5로 특정한 window 에 대해 알파 투명도를 설정한다면 모든 window와 widgets은

// * window가 더 높은 값들에서 적용되어진 변화들에의해  또한 영향을받을것으로 붙여진다.

// * 예를들어, 비록 자식 window에대해 실질적으로 설정된것(마지막 값들)을 바뀌지않게 유지하고 그리고/또는 

// * 사용되어진 설정들은 현재 window로 상속된 계층구조안에서 모든 window들로부터 설정되는 값들의 몇몇의 조합들은 

// * 일반적일지라도..

// * 

// * 

// * 이것은 window 제거와 같은것들로 또한 적용한다; 예를들어, default에 의해서, window는 붙여진 자식 window들과 widges들을

// * 제거할 것이다 window가 파괴되어질때....

// * 이 방식의 주요 이점은 당신이 알파, visility, enabled/disabled 상태 와같은 것들을 위해서  

// * root window 설정들로 변화들을 만든것에의해 전체 GUI에 쉽게 영향을 줄수있다는 것이다

// *  그리고 root window를 간단하게 파괴하는것에 의해서 전체의 GUI layout을 쉽게 제거할수있다.

// *  

// *  default 상속된 동작들은 제어가 주어진 더 좋은것이 필요로 되어지는 또는

// *  관리 기술들이 향상된 일부가 사용되어지는 window 단위당에 대해 오버라이딩 되어질 수있다.

//brief [ window들을 생성한다]

// 동작하게하는 이것(window생성 하는것)의 두가지 방법이 있다, C++ 코드와 XML layout 파일들을 통해서...

// 각 접근은 아래에 논의되어진다

//

// brief [ C++ 코드를 통해 GUI 생성 ]

//  CEGUI에 있는 모든 window들은 WindowManager 싱글톤 오브젝트에 의해 생성되어진다

//  당신은 WindowManager::getSingleton 함수를 통해서 이 오브젝트들로 접근할수 있다.

WindowManager& wmgr = WindowManager::getSingleton();

//대게, 당신은 당신의 GUI 안에 'root' window로서 DefaultWindow(또는 그것의 이전 이름 DefaultGUISheet 을 사용하기위해서 ) 로서 

//알려진 것들을 사용할 것이다

// 이것은 필요하지않다, 하지만 CEGUI를 위해서 사용법의 받아들여지는 패턴이다.

// 그리고 당신이 더 많은 top-level window들을 더하는것을 시작하자마자 그것들(windows)을  배치하는것을 돕는다.

// 

// 본격적으로 시작하기위해서, 

// 그래서 우리는 GUI를 위해서 root 'GUI Sheet'로서 그것(DefaultWindow)을 설정함으로서 DefaultWindow를 생성할 수 있다

Window* myRoot = wmgr.createWindow( "DefaultWindow", "root" );

System::getSingleton().setGUISheet( myRoot ); //setGUISheet 는 Set the active GUI sheet (root) window. 

//WindowManager::createWindow함수는 그것의 파라미터들로서 두개의 스트링들을 취한다

//이 예제안에서 "DefaultWindow" 첫번째 파라미터는 system에게 type 또는당신이 생성하기 바라는

//window의 클래스를 말해준다.

// 일반적으로,  비록 일부일지라 하더라도, 당신이 이용할수있는것을 가지는 window는 

// 당신이 당신의 scheme 파일, DefaultWindow와 같은것을 로드했을때 등록되어지게되는 그것들이(window)

// global 타입들이고 항상 이용가능하다

// 

// 이 예제에서 "root" 두번째 파라미터는 window로 할당되어질 유일한 이름이다

// 이 이름은 나중에 WindowManager로부터 window에대한 포인터를 검색하는 것으로 사용되어질수있다

// 명칭된 당신의 root window "root" 는 필요하지 않지만 일반적인 문법인것을 주의해야한다

// 

// System::setGUISheet함수는 GUI의 root로서 주어진 window를 지정하는 것으로 사용되어진다.

// 이것은 어떤 현재 sheet/root window를 대체할 것이다

// 비록 이전 window계층구조가 실질적으로 소멸되어지지 않는다는것을 주의한다 할지라도(그것은

// 디스플레이로부터 단지 분리되는 것이다  ) 

// 당신은 System::setGUISheet 함수를 하용하는 그것들(window들) 사이에서 간단하게 flipping 에 의해서

// GUI 'pages' 사이에 쉽게 전환할 수있다

// 

// 지금 당신은 당신의 첫번째 윈도우를 지금까지 쭉 만들어왔고 그것을 GUI system으로 붙였다.

// 그리고 system은 그것이 GUI를 그릴때 GUI의 root 로서 이 window를 사용할것이다.

// 하지만 만약 당신이 이 코드를 사용하는 간단한 프로그램을 컴파일을 했다면, 당신은 어떤것도 아직 볼수없다 ;뭣때문이지? <- 내가쓴말 아님 

// 당신의 응용프로그램에 어떤문제는 없다,

// 위에 만들었던 DefaultWindow는 단지 전적으로 눈에 보이지않는다!

// 이것은 root window로서 완벽하게 적합작 DefaultWindow를 만드는 것이다; 그것은 다른 window와 widges들이 붙여질 수 있는

// 빈 도화지로서 제공한다

// 지금 그것들을 해보자...

// 

//여기에 frame window를 만들것이다;

// 이것은 당신의 테스트탑위의 window들에 유사한 방법으로 작동하는 window이다, 이 것은 title bar를 가지며 이동되어질 수있고, 사이즈가조절될 수있다.

FrameWindow* fWnd = static_cast<FrameWindow*>( wmgr.createWindow( "TaharezLook/FrameWindow", "testWindow" ));

//여기서 우리가 "TaharezLook/FramwWindow"  window를 만드는 중이다. 이것의 이름은 system도처에 보여지는 또다른 규칙을 사용한다

// window 타입은 widget set의 이름에 의해서 앞에 붙여진다

// (만약 당신이 WindowsLook scheme를 로드할경우, 당신은 대신에 "WidndowsLook/FramwWindow" 를 생성할수있다 )

// 우리는 우리의 새로운 window에게 "testWindow"의 간단한 테스트 이름을 부여했다

// 기억해야하는 한가지 마지막인것은 캐스트의 사용이다, 이것(캐스트)은 WindowManage::createWindow 함수가 Window 타입을 항상 리턴하기 때문에

// 필요되어진다

// 

// 많은 다른 이 경우에서 기본 window 포인터는 충분할것이다, 

// 하지만 당신이 하위클래스들에 도입된 함수를 접근 하기를 원할 때가있다

// 그래서 보여지게되는것으로서의 캐스트 사용은 CEGUI를 사용하는 중일때 공통이다.

// 우리의 새로운 window로 유용한 어떤것을 할수있는 system을 위해서, 우리는 몇가지 추가적인 단계들을 수행해야한다

// 

// 1) 첫번째,  우리는 위에 설정한 root window로 window를 붙여야한다

myRoot->addChildWindow( fWnd );

//지금 우리는 초기 위치를 설정할수있고 우리의 window를 위한 사이즈를 설정할WindowManager

//CEGUI는 동일한 시간에서 상대적(scale)과 절대적(offset) 구성요소들의 사용을 활성화하는 '통합된' 좌표system을 사용한다

//이것은 당신이 볼것인 각 좌표들이 두 부분을 가지고있는 이유이다.

// 이 개념의 약간 확장되어진 소개를 위해서Falagard skinning system for CEGUI [http://www.cegui.org.uk/docs/current/fal_man.html] 의 부분인

// The Unified Co-ordinate System[http://www.cegui.org.uk/docs/current/fal_intro.html#fal_unifiedsystem]

// 을 보세요. (음......;; 귀차니즘이... )

// 

// 예제로 돌아가서

// 부모의 top-left로부터 거리의 1/4의 위치

fWnd->setPosition( UVector2( UDim( 0.25f, 0 ), UDim( 0.25f, 0 ) ) );

//부모의 절반 사이즈인 크기를 설정한다

fWnd->setSize( UVector2( UDim( 0.5f, 0 ), UDim( 0.5f, 0 ) ) ); //(그럼 1 이 부모의 full 사이즈라는 거네(0.~1.) )

//끝으로, 우리는 framw window의 타이틀바의 설명을 설정한다.

fWnd->setText( "Hello World!" );

//그리고 그것이 전부다!  (ㅋㅋㅋ)

//응용프로그램안에서 컴파일되어질때, 당신이 디스플레이의 중간에 간단한 frame window를 지금 볼것이다.

//[XML layouts]

// 위의 모든것은 아주 훌룡하다, 하지만 하나의 주요한 결점이있다;

// 당신이 GUI layout을 조정하는것을 바라는 어떤 시간에, 당신은 당신의 코드를 수정해야하고 

// 재컴파일을 해야한다. (This will get  old pretty quick), 그래서 당신이 정말로 원하는 것은

// 외부적으로 당신의 GUI layout을 지정할수있는것이다, 그리고 당신의 코드는 파일을 

// 통해 layout을 로드한다.    이것은 CEGUI layout XML 파일들의 목적이다.

// 

// system은 XML layout파일들을 지원한다, 그것은 WindowManager::loadWindowLayout 함수를 통해서 로드되어질수있다.

// 이 함수는 당신을 위한 모든 window들을 만든다 그리고 로드되는 계층구조의 root window에 포인터를 리턴한다

// 그것은 GUI의 root 로서 할당된것으로서 이상적이다!

// 

// 그래서, 모든것의 첫번째로 우리는 layout 파일을 필요로한다, 다음의 XML은 text 파일로서 저장되었다,

// 우리가 위에서 논의했던 코드에  layout 파일에 대응하는 것이다.

// <?xml version="1.0" ?>

// <GUILayout>

// <Window Type="DefaultWindow" Name="root">

// <Window Type="TaharezLook/FrameWindow" Name="testWindow">

// <Property Name="UnifiedPosition" Value="{ {0.25, 0}, {0.25, 0} }" />

// <Property Name="UnifiedSize" Value="{ {0.5, 0}, {0.5, 0} }" />

// <Property Name="Text" Value="Hello World!" />

// </Window>

// </Window>

// </GUILayout>

// Window 요소들은 WindowManager::createWindow 함수들에 확실한 매핑을 보여준다

// -그것들은 이전에 논의되었던 파라미터들에 정확하게 일치하는 타입과 이름을 가진다.

// Window 구성요소들의 내포된것은 다른것으로 어떤 window들을 붙이기위해서 사용되어진다

// 당신이 layout 파일안에서 하나의 'root' level window를 단지 가질것이라는 것에 주의해야한다

// 그것은 당신이 그 밖의 window들과 widget들이 위치되는 캔버스(도화지같은 공간)로서 사용되어지는 

// DefaultWindow를 대게 볼수있는것이 또 하나의 이유이다.

//속성 요소들은 정의되어지는중인 Window에 대한 속성들을 설정하기 위해서 사용되어진다.

// 각 window/widget 클래스를 위해서 이용할수있는 많은 속성들이 있다, 그리고 각 클래스는 

// 그것의(window)의 부모 클래스로부터 모든 속성들이 또한 상속된다.

// 이용가능한 하드코딩된 속성들과 그것들의 value string formats에대한 문서에 대해서 API reference안에

// Properties namespace들을 보시오. 

// 'Falagard' skin들은 그것들 자신의 속성들을 만들 수 있는 때문에, 당신이 사용하는 중인 window들은

// 이전 링크(이 'soft' 속성들에 대한)에서 열거되는 것보다 더 많은 속성들을 포함할 가능성이 있다.

// 당신은 기록문서가 당신이 사용중인 skin과 함게 제공되어지는 어느것이든지 참고해야한다

// 예를들어, CEGUI Wiki를 보시오 : 

// TaharezLook Properties http://www.cegui.org.uk/wiki/index.php/SetProperty

// WindowsLook Properties http://www.cegui.org.uk/wiki/index.php/SetProperty_(WindowsLook)

// 

// 만약 "test.layout" 로 불리는 파일로서 저장했다면, 당신은 이  layout을 로드할 수 있고 다음과 같이 

// GUI root 로서 그것을 설정할 수 있다.

// 

// Window* myRoot = WindowManager::getSingleton().loadWindowLayout( "test.layout" );

// System::getSingleton().setGUISheet( myRoot );

//최종결과는 예상보다 일찍 C++ 코드에서 수행되었던 것으로서 정확하게 동일하다.

// 지금 우리는 수정할 수 있는것을 기대하고 상수편집과 application 코드의 재컴파일에 대해 필요없이

// GUI layout을 향상시킨다.

//[결론]

//여기서 우리는 기본 window 생성을 수행하는 방법, 간단한 window 계층구조를 만드는 방법,

//, 그리고 몇몇의 window 세팅들을 수정하는 방법을 지금까지 쭉 보아왔다

// 당신은 이것이 C++코드와 외부의 XML layout 파일 둘다 사용해서 얻게되어질수있는 방법을 지금까지 쭉 보아왔다

// 양쪽의 방법들을 사용해서 이용가능한 많이 향상된 기능성들이 있다.

// 비록 그런 기능성들은 이 소개의 튜토리얼의 범위를 넘어서 있을지라도

}CEGUI_CATCH(Exception e){

std::cout<<"CEGUI:생성 : "<<e.what()<<std::endl<<std::endl;

return false;

}

return true;

}

 ===================  종료  ===================

종료하면서 해제하는 부분은 따로 번역할 것은 없으며

최근엔

CEGUI::Direct3D9Renderer::destroySystem();

CEGUI::System::destroy(); //모든 실글톤의 객체들을 제거됨

을 하거나 CEGUI 버전에 따라 싱글톤 포인터를 얻어와 해당 포인터를 직접 해제해주거나 해야 하는 방식 입니다

p.s CEGUI나 기타 게임에 관한 공유하실 분 있으면 언제든 환영합니다~

http://www.cyworld.com/romejune/

이 블로그에서 용책과 해골책의 소스를 거진 올려놓음 음;;;; 그래도 되나? ㅋ

http://blog.naver.com/clous02?Redirect=Log&logNo=110023903727

1) 파티클의 버텍스 버퍼이용 방법

* 버텍스 버퍼정의(최대한의 일정한 사이즈로)

* 파티클의 속성을 다룰 구조체를 정의

   * 구조체 리스트에 이벤트나 최대 숫자의 개수를 정하고 소멸시 하나를 생성하는 방법으로 생성

* 속성에 존재하는 베텍스 데이터 자료를 버텍스 버퍼로 동적인 복사

* 파티클에 관련된 RenderState를 설정

* 렌더링한다.

2) 작동방식

* FVF의 지정: D3DFVF_XYZ | D3DFVF_PSIZE

* Particle 속성을 위한 구조체

: 동적인 버텍스 생성과 소멸 – List

* 위치 한계의 최대 사이즈 결정

* 버텍스 버퍼 마련

* 파티클을 생성(총알은 속도 일정 위치 변경)

* 버텍스 버퍼에 이동

* 파티클의 생성 – 변경 – 소멸 – 생성의 과정

* 렌더링 : DrawPrimitive(D3DPT_POINTLIST)

3) 파티클 구현 방법

* Particle

  - Bilboard이용 파티클 구현(사각형)

  - D3DPT_POINTLIST : 하나의 픽셀로 렌더링된다

  - Point Sprite(점하나로 가능)

• Texture 적용이 가능 – Blending으로 알파 연산

• 크기 변경 가능

• 하나의 포인트로 사용가능

• 성능향상과 메모리 이익

4) 파티클의 종류

* 일정한 사이즈로 반복 되는 현상

  - 눈 비등

        - 박스속에 거두고 충돌처리로 사망을 시키면서 사망이 하나라도 벌어지면 자동으로 생성

           한다

 - 파티클정보를 담고 있는 리스트에서 erase시키고 push_back한다

* 이벤트가 발생하면 생성되는 스타일

 - 버텍스 버퍼는 가능한 총알의 최대 사이즈를 지정

 - 속성리스트를 만들고 렌더링해야할 만큼  버텍스 버퍼에 지정하고 렌더링한다

 - 이벤트 발생시 생성

 - 카메라의 위치에서 카메라의 방향으로 발사

 - 일정한 위치를 전진하면 소멸

 - 생성 – 변경 – 소멸의 단계

* 두가지 방식다

 - 위치의 속성은 계속하여 변화함으로 일정한 사이즈로 만들어 놓은 버텍스 버퍼에

위치값을 계속하여 갱신한다

5) 파티클에서 주의할 점

* 파티클 사이즈 조정시 주의할 점

  - 렌더스테이트의 사이즈 조정은 모두 DWORD

  - 이벤트에 의하여 파티클이 증가할 경우 조정하지 않으면 버텍스 버퍼의 한계를 초가하는 경우가 발생

  - 눈이 한 개만 출력될 때는 인덱스 증가가 벌어지지 않기 때문

6) Point Sprite 렌더 상태

 * D3DRS_POINTSPRITEENABE : default – false

  - true : 지정된 전체 텍스트를 포인트 스프라이트에 텍스쳐 매핑

  - false : 포인트 스프라이트의 텍스쳐 좌표를 이용하여 지정

 * D3DRS_POINTSCALEENABLE : default – false

  - true : 포인트 크기를 뷰스페이스 단위로 해석(카메라와의 거리값에 따라 변화)

  - false : 스크린 스페이스 단위로 해석 – 사이즈를 3으로 주면 3x3 사이즈로 그려진다

 * D3DRS_POINTSIZE

  - 포인트 스프라이트 크기 지정

  - Device->SetRenderState(D3DRS_POINTSIZE, FtoDw(2.5f));

    DWORD FtoDw(float f)

{

  return *((DWORD*)&f);

}

 * D3DRS_POINTSIZE_MIN : 0.2

 * D3DRS_POINTSIZE_MAX : 5.0

 * 거리에 따라 포인트 스프라이드의 크기가 변화하는 방법을 제어

 * D3DRS_POINTSIZE_A

 * D3DRS_POINTSIZE_B

 * D3DRS_POINTSIZE_C

CommitChanges 

Remarks

If the application changes any effect state using any of the ID3DXEffect::Setx methods inside of an ID3DXEffect::BeginPass/ID3DXEffect::EndPass matching pair, the application must call ID3DXEffect::CommitChanges before any DrawxPrimitive call to propagate state changes to the device before rendering. If no state changes occur within a ID3DXEffect::BeginPass and ID3DXEffect::EndPass matching pair, it is not necessary to call ID3DXEffect::CommitChanges.

This is slightly different for any shared parameters in a cloned effect. When a technique is active on a cloned effect (that is, when ID3DXEffect::Begin has been called but and ID3DXEffect::End has not been called), ID3DXEffect::CommitChanges updates parameters that are not shared as expected. To update a shared parameter (only for a cloned effect whose technique is active), call ID3DXEffect::End to deactivate the technique and ID3DXEffect::Begin to reactivate the technique before calling ID3DXEffect::CommitChanges.

    // Using current technique

    // Begin           starts active technique

    // BeginPass       begins a pass

    // CommitChanges   updates changes to any set calls in the pass. This should be called before any DrawPrimitive call to d3d

    // EndPass         ends a pass

    // End             ends active technique

이건  에 대한 d3dx9effect.h 에 있는 설명 에 있다