블로그 이미지
Every unexpected event is a path to learning for you. blueasa

카테고리

분류 전체보기 (2794)
Unity3D (852)
Programming (478)
Server (33)
Unreal (4)
Gamebryo (56)
Tip & Tech (185)
협업 (11)
3DS Max (3)
Game (12)
Utility (68)
Etc (98)
Link (32)
Portfolio (19)
Subject (90)
iOS,OSX (55)
Android (14)
Linux (5)
잉여 프로젝트 (2)
게임이야기 (3)
Memories (20)
Interest (38)
Thinking (38)
한글 (30)
PaperCraft (5)
Animation (408)
Wallpaper (2)
재테크 (18)
Exercise (3)
나만의 맛집 (3)
냥이 (10)
육아 (16)
Total
Today
Yesterday



오늘은 닷넷 소스를 볼수 있는 리플렉터를 소개합니다.

http://www.red-gate.com/products/reflector/

.Net Reflector는 닷넷 어셈블리를 살펴보거나 분석할 수 있는 도구 입니다.

이 도구는 무료인데다가 설치를 할 필요조차 없는 구조입니다.

압축파일을 다운 받은 후 압축을 풀기만 하면 바로 사용할 수 있습니다.

사용법은 다음과 같습니다.

TextBox의 소스를 알아보고 싶은 경우를 살펴보겠습니다.

우선 다음과 같은 소스를 만들어 보겠습니다. 아래는 TextBox만 생성하는 소스입니다.

namespace WpfApplication3
{
using System.Windows;
using System.Windows.Controls;

/// <summary>
/// Interaction logic for Window1.xaml
/// </summary>
public partial class Window1 : Window
{
/// <summary>
/// Initializes a new instance of the <see cref="Window1"/> class.
/// </summary>
public Window1()
{
InitializeComponent();

var textBox = new TextBox();
}
}
}

아래는 File -> Open에서 실행파일을 선택한 화면이다.

var textBox 가 TextBox textBox로 변경되어 나타나는 것을 알 수 있다.


Disassembler에 있는 TextBox를 클릭하면 TextBox의 내용도 살 펴 볼 수 있다.

반응형
Posted by blueasa
, |


VS2008에 있는 Output Window를 사용하여 디버깅을 할 수도 있지만 실제 바이너리 파일 운영하면서 디버깅을 해야 하는 경우에는 Output Window를 사용할 수가 없다.

이럴때 사용하면 편한 툴이 DebugView for Windows이다.

아래 사이트에서 다운 받을 수 있다.

http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx

DebugView for Windows 는 sysinternal에서 제공되는 다양한 툴들 중 가장 많이 사용되는 툴이다.

아래와 같이 프로그램이 실행되는 순간에 Debug.WriteLine을 사용한 경우에 대한 예이다.

namespace WpfApplication2
{
using System.Diagnostics;
using System.Windows;

/// <summary>
/// Interaction logic for Window1.xaml
/// </summary>
public partial class Window1
{
/// <summary>
/// Initializes a new instance of the <see cref="Window1"/> class.
/// </summary>
public Window1()
{
InitializeComponent();
Debug.WriteLine("DbgView Test");
}
}
}

반응형
Posted by blueasa
, |

NiImageConverter::SetPlatformSpecificSubdirectory 란 함수를 이용해보세요.
반응형

'Gamebryo > Effect' 카테고리의 다른 글

Effect 애니메이션 초기화 방법  (0) 2011.09.21
[펌] 체인라이트닝 이펙트 만들기  (1) 2011.06.11
[펌] 이펙트 에니메이션 방법  (1) 2011.05.20
강의자료 - 파티클 예제  (0) 2011.03.22
Setup about Effect Dumy…  (0) 2011.03.21
Posted by blueasa
, |
저 같은 경우 예전에 이벤트 발생 했을 때 특정 노드만 애니메이션 해야 하는 기능이 있었는데요 도움이 될지 모르겠네요.
NiTimeController* pkControl = spStrongBoxDoor->GetControllers();
pkControl->SetAnimType(NiTimeController::APP_INIT);
float fAccTime = TimeMgr::GetInst()->GetAccumTime();
NiTimeController::StartAnimations(spStrongBoxDoor, fAccTime);
spStrongBoxDoor->Update(fAccTime);
NiTimeController::StopAnimations(spStrongBoxDoor);

애니메이션 시킬 노드를 초기화 하고 전체 애니 시간을 설정해 준 후 업데이트 한 다음에 멈춰 버립니다.
그 다음에 이벤트 발생 했을때 NiTimeController::StartAnimations(spStrongBoxDoor);
이렇게 호출 해서 사용 했습니다. 위와 같이 사용 하면 딱 한 루푸만 작동하고 멈췄습니다.


출처 : http://cafe.naver.com/dxgameprogramming/1661 의 리플 중 [딸기하나]님 리플..
반응형
Posted by blueasa
, |

Debug에서는 최적화를 설정하면 안된다.

1. 속성 -> 구성 속성 -> 일반에서 옵션 설정
- 전체 최적화 최적화: 링크 타임 코드 생성 사용

2. 속성 -> 구성 속성 -> C/C++ -> 최적화에서 옵션 설정
- 최적화: 속도 최대화
- 인라인 함수 확장: 적합한 것 모두 확장
- 내장 함수 사용: 예
- 크기 또는 속도: 코드 속도 우선
- 프레임 포인터 생략: 예
- 파이버 안전 최적화 사용: 아니오
- 전체 최적화 최적화: 링크 타임 코드 생성 사용

3. 속성 -> 구성 속성 -> 링커 -> 최적화에서 옵션 설정
- 링크 타임 코드 생성: 링크 타임 코드 생성 사용
- 참조: 참조하지 않는 데이터 제거
- COMDAT 정리 사용: 중복 COMDAT 제거

최적화옵션으로 release하면 이전버젼 포팅시 오류발생소지가 있으므로 끄자

반응형
Posted by blueasa
, |

겜브리오의 Frame Render Sytstem 에서는 랜더클릭별로 알파프로세스를 지정해 줄 수 있다.

구조를 설명하자면.. 각 Mesh들은 랜더클릭의 랜더링 함수가 호출될때 클릭별로 설정된 CullingProcess에 의하여 보여지는 영역들에 대한 메쉬들의 집합을 구한다. 이 RenderObject들의 리스트(NiVisibleArray)를 가지고 랜더링을 하게되는데 이것은 SceneGraph상의 순서(생성순, 노드어태치순)으로 일괄적으로 랜더링되며 AssetViewer나 NiApplication에서는 NiAlphaSortProcessor를 사용한다. 이것을 연결하지 않을시 디폴트로된 기본 솔트프로세스가 연결되어지는데 이건 그냥 순서대로 그리는것이다.

NiAlphaSortProcessor를 보면 NiBackToFrontSortProcessor를 상속하게 되는데 위에 불투명한랜더링객체(알파가 없는, NiSortedAdjustNOde가 적용된)를 우선적으로 그리고, 알파가 있는 랜더링 객체를 기본적으로 Mesh의 피봇중심(BoundCenter)과 카메라와의 거리(ZBuffer)을 이용하여 뒤에서부터 앞으로 정렬하여 나온 NiVisibleArray의 내용을 그린다.

하지만 위와같은 랜더링시 문제점도 있어서

1) 알파텍스쳐가 쓰인 큰오브젝트(폭포, 스카이박스)의 경우 폭포의 피봇중심과 그 폭포앞의 오브젝트들(폭포앞물튐파티클등)이 서로 카메라의 위치에 따라 혹은 폭포와 스카이박스피봇와의 거리차등..의 문제로 인해서 앞뒤판정이 실제와 차이나게 생길수있고

2) 알파를 적용한 빌보드와 파티클이 같이 나오는 경우 파티클이 뒤에서 빌보드를 통과한다거나 앞에서 뒤로 빌보드를 통과 하거나 혹은 빌보드와 근접시.. 카메라의 위치에 따라 잘못판단되는 경우가 생길수있다.
예) 두장의 알파빌보드를 근접하여 놓았을경우 카메라 방향에 따라 앞뒤면이 잘못 나올수있다.

3) NiSortAdjustNode를 썼을 경우에도 불투명 오브젝트로 처리하게 되니 만약 NiSortAdJustNode 뒤에 불투명한 오브젝트가 있고 그것이 나중에 랜더링 된다면 이 NiSortAdjustNode를 쓴 알파오브젝트에는 실제로 뒤에 오브젝트가 나오지 않게 될 것이다.
예) NiSortAdjustNode를 쓴 폭포뒤에 불투명한 동굴이 있다고 쳤을때 실제로 어태치된 순서가 동굴이
나중에 어태치 되어있다면 동굴은 폭포수에 그려지지 않을 것이다.

위와 같은 문제를 해결하기 위해선 디자이너들이 알파에 대한 정렬 프로세스를 확실히 이해 한 상태에서 작업을 해야 한다는것이다.

파티클이나 빌보드의 경우 겹쳐저도 상관없는 경우 ZTest만 하고 ZWrite는 하지 않게 하여 (Zmode10), 테스트를 하여 투명우산 앞에 그릴지 뒤에 그릴지를 판단하고 그려질땐 Zbuffer를 쓰지 않아 같은 파티클의 경우 섞이게 만들고. 넓은 반투명 빌보드의 겹침현상은 기본적으로 두개의 오브젝트의 피봇중심이 가까워서 일어나는 현상임으로 이런경우는 실제피봇중심만 거리를 두게끔 처리함으로서 해결할수 있을 것이다. 이렇게 되어도 카메라의 거리에 따라 문제가 생길수 있는 부분은 존재하는데 확실히 랜더링 순서를 알고있는 메쉬집합체의 경우 깊이를 쓰는 부분에서 순서대로 깊이를 판단해서 NiVisibleArray에 넣어 주어 랜더링 하는 방법이 있는데

나의 경우에는 디자이너와 협의하여 순서를 확실히 아는 오브젝의 경우 Aset_이라는 이름으로 판단하였다.

아래는 사용중인 CustomAlphaSortProcessor 의 핵심 부분이다.


void NiCustomAlphaSortProcessor::PreRenderProcessList(const NiVisibleArray* pkInput, NiVisibleArray& kOutput, void* pvExtraData)
{
if (!pkInput) return;

NiRenderer* pkRenderer = NiRenderer::GetRenderer();
NIASSERT(pkRenderer);

NiPoint3 kWorldLoc, kWorldDir, kWorldUp, kWorldRight;
NiFrustum kFrustum;
NiRect<float> kViewport;
pkRenderer->GetCameraData(kWorldLoc, kWorldDir, kWorldUp, kWorldRight,
kFrustum, kViewport);

const unsigned int uiInputCount = pkInput->GetCount();

if (m_uiAllocatedDepths < uiInputCount)
{
NiFree(m_pfDepths);
m_pfDepths = NiAlloc(float, uiInputCount);
m_uiAllocatedDepths = uiInputCount;
}


NiSortedObjectList kItems0;

unsigned int uiDepthIndex = 0;

bool bSet = false;
float f;
for (unsigned int ui = 0; ui < uiInputCount; ui++)
{
NiRenderObject& kMesh = pkInput->GetAt(ui);

// NiSortAdjustNode인 경우
if( !kMesh.GetSortObject() ) // NiSortAdjustNode는 알파로 처리하되.. 알파보다는 먼저 랜더링 되게 변경.
{
kItems0.AddTail(&kMesh);
}
else if (IsTransparent( kMesh ) )
{
NiNode * pkParent = kMesh.GetParent();
NiFixedString name = kMesh.GetName();
if( name.Contains("Aset_") || ( pkParent && pkParent->GetName().Contains("Aset_") ) )
{
kOutput.Add(kMesh);

if( bSet == false )
{
f = ComputeDepth(kMesh, kWorldDir);
m_pfDepths[uiDepthIndex++] = f;
}
else
{
f = f-0.1f;
m_pfDepths[uiDepthIndex++] = f;
}

bSet = true;
}
else
{
bSet = false;
kOutput.Add(kMesh);
m_pfDepths[uiDepthIndex++] = ComputeDepth(kMesh, kWorldDir);
}


}
else
{
// 불투명한 오브젝트는 바로그린다. (NoSort 포함);
NiAVObject* pkAVObj = &kMesh;
if (NiIsKindOf(NiRenderObject, pkAVObj))
{
// FOutputLOG( (char *)(const char *) kMesh.GetName() );
kMesh.RenderImmediate(pkRenderer);
}

}

}

// NiSortAdjustNode는 불투명랜더링이 끝나면 이것도 바로 랜더링
while (kItems0.GetSize())
{
NiRenderObject* pkGeom = kItems0.RemoveHead();
pkGeom->RenderImmediate(pkRenderer);
}

//

SortObjectsByDepth(kOutput, 0, kOutput.GetCount() - 1);

/* // 로그를 남겨보자..
FOutputLOG("====알파만 걸러서 순서가 어뜨케 되나..=====================");
for(int i = 0; i<kOutput.GetCount(); i++)
{
NiRenderObject& kMesh = kOutput.GetAt(i);
FOutputLOG((char*)(const char*)kMesh.GetName());
}
*/


}

반응형

'Gamebryo > Lecture' 카테고리의 다른 글

Mesh의 생성 ( Particle, 검궤적 등 )  (0) 2011.11.08
게임브리오 2D Line관련  (0) 2011.10.30
무기잔상효과  (0) 2011.02.08
캐릭터 기울기 연산  (0) 2011.02.08
Gamebryo 셋팅  (1) 2011.01.06
Posted by blueasa
, |

Libci.lib에 대한 Link 에러 문제이군요.

VS .NET 2003으로 오면서 2002까지 지원하던 '구 버전의 iostream Library'를 더이상 'CRT'에 포함하지 않게 되었습니다.

'구 버전의 iostream Library'가 무엇인고 하니 바로 아래에 나와있는 것들입니다.

LIBCI.lib : Single-thread, Static Link /ML
LIBCIMT.lib : Multithreaded, static link /MT
MSVCIRT.lib : Multithreaded, dynamic link /MD

이것들이 이제 더이상 존재하지 않습니다. C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib 경로를 살펴보면 없지요.

'새 버전의 iostream Library'는 다음과 같습니다.

LIBC.lib : Single-threaded, static link /ML
LIBCMT.lib : Multithreaded, static link /MT
MSVCRT.lib : Multithreaded, dynamic link /MD

딱 보니까 이름 짓는 규칙을 아시겠지요? 'i'자가 붙은 게 바로 구형 iostream이고 MS에서 사장시키기로 작정한 것 같습니다. (각 lib의 디버그 버전에는 파일명에 'd'자가 하나씩 더 붙지요.)

원래는 LIBC.lib와 그의 형제들에 구 버전의 iostream이 탑재되어 있었는데, VC++ 4.1 이후부터 iostream을 바꾸고, 기존 것을 계속 쓰고자 하는 사용자를 위해 'i'자를 붙인 Library를 따로 만들어 분리시켜버린 것 같습니다.

말썽을 일으키고 있는 프로젝트와 '인터넷에서 구한 소스' 등이 말썽을 일으키는 것은, 해당 프로젝트에서 구 버전의 iostream을 사용하도록 'Default Library'를 명시적으로 지정하였기 때문이 아닌가 싶네요.

이 문제를 피할려면, 기존 프로젝트의 Default Library를 무시하도록 링커 옵션에서 '모든 기본 라이브러리 무시'를 선택하시거나 '특정 라이브러리 무시' 선택하시기 바랍니다. 이렇게 하면 /NODEFAULTLIB 링커 옵션이 추가됩니다.

이 내용들은 MSDN에 보다 상세하게 나와있습니다.

반응형
Posted by blueasa
, |

LIBCMT.lib(invarg.obj) : error LNK2005: __invoke_watson already defined in MSVCRTD.lib(MSVCR80D.dll)

닷넷 2005에서 .lib를 사용할 때..

디버그용과 릴리즈용을 구분지어줘야 한다.

즉, 프로그램을 디버그 모드인 프로그램에서, 릴리즈 모드로 컴파일 된 lib를 인클루드 할 경우

LIBCMT.lib(invarg.obj) : error LNK2005: __invoke_watson already defined in MSVCRTD.lib(MSVCR80D.dll) 와 같은 링크 에러가 발생한다.

Multi-threaded (/MT) : 릴리즈용

Multi-threaded Debug (/MTd) : 디버그용

DLL도 마찬가지.

반응형
Posted by blueasa
, |

녹화, 만화, 압축류의 3대 종결자(반디캠, 꿀뷰, 반디집)로 불리는 반디소프트에서


반디집의 정식버전을 냈습니다



주요 특징으로는 세계 유일 모든 압축 확장자 완벽 지원외에도..


  • 분할 압축 기능이 뛰어납니다.
  • MFC와 같은 무거운 라이브러리를 사용하지 않아 프로그램이 작고 빠르고 가볍습니다.
  • 64bit OS를 네이티브로 지원합니다.
  • 유니코드를 정말 '잘' 지원 합니다.
  • 반디집은 무료(無料)입니다.
  • ALZ, EGG 포맷도 지원합니다.
  • 쓰기 편합니다.



64비트 기본 지원이라서 윈7에서도 작동이 잘된다고 하고 유니코드 지원으로 파일명이 깨지는


일어파일도 문제없이 풀린다고 합니다


저도 미루다가 방금전부터 사용중인데 정말 마음에 들어서 알집을 삭제해버렸습니다


최근 이스트 소프트가 네이트온 사건부터해서 좀 말이 많아서 슬슬 갈아타는 중입니다


알집은 반디집으로 알씨는 편집이 편해서 그냥 두긴했지만


이미지뷰어로는 구글의 피카사를 쓰기 시작했습니다 (압도적으로 빠릅니다 강력추천-_-b)


아무튼...



 


기존 알집 사용자분들이 익숙해져서 갈아타기 고민되셨을 부분같은데..


오른쪽 클릭 메뉴에 바로 풀기, 폴더명으로 풀기 기능이나


압축파일 미리보기(스샷에서는 기능 꺼놓은 상태입니다)


무려 새폴더만들기 기능도 있습니다!!



물론 위의 모든 오른쪽 클릭 메뉴는 설정에서 변경 가능합니다


아이콘이 마음에 안들면 환경설정에서 역시 변경 가능합니다



지원가능 확장자수가 정말 많습니다


특히나 그동안 쉽사리 다른 압축프로그램으로 갈아탈수 없게 했던 알집 고유 압축 확장자인


EGG와 ALZ도 지원한다는 점과


알집에서 제대로 지원이 안되던 7Z도 완벽하게 호환되는점이 좋습니다


겸사겸사 갈아타시면 좋을것 같습니다


.

.

.


설치파일은 ↗에서 받을수도 있고 아래의 홈페이지 링크에서 받으셔도 됩니다


반디집 홈페이지

http://apps.bandisoft.com/bandizip/

반응형
Posted by blueasa
, |
어젠가 그젠가 MSDN 보다가 재미난 문서를 발견했습니다. 안전한 DllMain을 작성하는 방법에 관한 글인데, 이 곳에서 다운로드 받아서 보실 수 있습니다. DLL의 로딩 과정과 로더 락에 관한 설명을 곁들여서 왜 그런 일들이 문제를 일으키는지 자세히 설명해 준답니다. 심심하지 않으신 분들도 꼭 챙겨보세요. ㅋ~ 

아래는 문서 내용 중에 괜찮은 부분 같아서 퍼온 겁니다. 의외로 저런 작업들을 하는 코드를 만나는 경우가 많습니다. 대부분 문제가 발생하지 않더라도 어디선간 문제가 발생하고 있다는 것을 의미하는 거겠죠. 좀 더 자세한 시나리오와 함께 문제를 설명해줬으면 했는데 그런 부분이 없는 것이 약간 아쉽더군요.

경고!!! 
DllMain에서 다음 작업들은 절대로 하지 말 것.

  1. LoadLibrary, LoadLibraryEx 호출. 데드락이나 크래시를 유발한다.
  2. 다른 스레드와 동기화. 데드락을 유발한다.
  3. 로더 락을 획득하려는 코드가 가지고 있는 동기화 오브젝트를 획득하려는 시도. 데드락을 유발한다.
  4. CoInitializeEx를 사용한 COM 스레드 초기화. 특정 조건이 충족될 경우 이 함수는 LoadLibraryEx를 호출한다.
  5. 레지스트리 함수들. 이 함수들은 advapi32.dll에 구현되어 있다. advapi32.dll이 초기화 되지 않았다면 크래시가 발생할 수 있다.
  6. CreateProcess 호출. 프로세스 생성은 다른 DLL을 로드할 수 있다.
  7. ExitThread 호출. DLL 디태치(detach) 과정 중에 스레드를 종료하면 로더 락을 다시 획득하도록 만들 수 있다. 이는 데드락이나 크래시가 유발된다.
  8. CreateThread 호출. 동기화만 하지 않는다면 스레드 생성은 괜찮을 수 있다. 하지만 위험하다.
  9. 네임드 파이프나 네임드 오브젝트 생성 (2000만 해당한다). 윈도우 2000에서 네임드 오브젝트 생성은 터미널 서비스 DLL에서 구현되어 있다. 해당 DLL이 초기화되어 있지 않다면 크래시.
  10. CRT에 포함된 메모리 관리 함수들. CRT DLL이 초기화되어 있지 않다면 크래시.
  11. user32.dll이나 gdi32.dll에 포함된 함수 호출. 일부 함수들은 다른 DLL을 로드하고, 이 사실은 크래시가 발생할 수 있다는 것을 의미한다.
  12. 관리된 코드 사용.
* 가장 아름다운 DllMain은 존재하지 않는 것이다 (비어 있는 함수 바디).
** 그래도 먼가 하고 싶다면 kernel32.dll에 포함된 함수 중에 위에서 언급되지 않은 것들만 쓰도록 한다. kernel32.dll이 초기화는 운영체제가 보장해 준다. 
*** 글로벌 오브젝트에 대한 초기화 코드 또한 DllMain 과정에 포함된다. 따라서 글로벌 오브젝트의 생성자 내지는 초기화 함수 부분에 위에서 언급한 내용이 있어서는 안된다.
**** 초기화를 하지 말란 소린가? 아니다. 지연시키라는 말이다.

요 근래엔 정말 컴터 책은 한 권도 안 읽은 것 같네요. 참신한 책 있으면 추천 좀 해주세용. 《실용주의 프로그래머》나 《The Art Of Unix Programming》을 보면서 흘렸던 눈물이 그립군요. 그나마 제프리 아저씨의 신간이 있었지만, 그마저도 사실 전 전판에 비해서 큰 차이를 보기는 힘들었던 것 같습니당.

출처 : http://www.jiniya.net/tt/788
반응형
Posted by blueasa
, |