디스어셈블링 및 실제 메모리를 디버깅하면서 데이터와 객체를 할당시 어떤 구조로 메모리에 올라가는지와

C#에서 클래스를 할당하면, 힙이 어떻게 동작하는지를 보자

쉽게 보기 위해서 예제는 x86(32bit)로 컴파일되었고 이를 기준으로 설명합니다.

예제로 사용할 모습은 이와 같다.

아무 클래스나 하나 만들고 그 안에 문자열 하나와 int 하나를 선언, 구조체 역시 메모리를 살펴보기 쉽게 int형 두개로 선언했다.

먼저 Case1 메소드를 디버깅해보자

Watch창에서 살펴보면 현재 testObject의 상태를 알 수 있고, '&testObject'로 testObject의 실제 메모리 주소를 볼 수 있다.

C# 문법에서는 직접적인 포인터를 사용하려면 unsafe 옵션을 이용해서 사용 할수 있으나, 이는 그리 권장하는 바가 아니며 간접적으로 포인터를 사용할수 있는데 이는 IntPtr을 이용하는 방법이다.

IntPtr의 경우엔 이후에 더 자세히 다룰 예정이다.

해당 메모리 주소로 가서 직접 살펴보면, 0x02eeb6b8 이라는 메모리 주소을 담고 있다.

이것으로 testObject 자체는 특정 주소를 담고 있는 포인터라는 것을 알 수 있다.

포인터가 가르키는 주소로 가서 살표보면 다음과 같다.

하일라이트된 두 영역이 클래스의 맴버변수들을 담고 있는 위치이다.

SomethingClass는 처음 1개의 string 변수와 두번째 int 값을 하나 가지고 있는데, 처음 앞 4바이트가 string이고 두번째 0값으로만 채워져 있는 4바이트 영역이 int값의 메모리 공간이다.

실제로 이렇게 맴버변수 int fisrt의 값을 1212라고 바꾸면, 메모리상에서 어떤 변화가 생기는지 보자

두번째 하이라이트되어 있던 공간의 값이 0000 04bc의 값으로 바뀌었고, 10진수 1212의 16진수 값은 4bc이므로 정확하게 찾은 메모리 위치가 맞는 것을 확인 할 수 있다.

그렇다면 첫번째 하이라이트였던 string 영역의 값을 분석해보면, 문자열의 저장은 해당 문자열이 존재하는 영역의 주소값을 가지고 있다.

즉 첫번재 하이라이트 4바이트 값은 포인터이다.

해당 포인터를 따라가면 이와 같은데, 하이라이트 해둔 부분이 문자열의 총 길이를 나타낸다.

그리고 그 뒤에가 문자열들이 들어 있다.

문자열들을 보기 편하게 2바이트 소팅을 해서보면 처음 값이 4e로 이는 아스키코드로 대문자 'N'에 해당한다 그 뒤로 i c e가 순차적으로 들어 있다.

간단하게 객체 하나가 할당될때 어떤 일들이 메모리상에서 일어나는지 살펴보았다.

다음 포스팅부턴 IntPtr에 대해서 자세하게 쓸려고 한다.

원래 IntPtr을 설명하기 위해서, 이 글을 썼다.

가비지 컬렉터로부터 가변 힙을 할당 받아, 이를 포인터에 넣어 사용하거나 또는 이미 생성한 객체를 포인터로 받아 조작하는 것들을 앞으로 쓸 예정이다.

StackOverflow에 매우 좋은 답변으로 달려 있는 내용인데, C#에서 Reflection을 이용해서 구조체(Struct)의 맴버 변수를 Set(Get)하려고 하면 제대로 작동되지 않는다.

접근할 수 없는 이유는 Struct는 ValueType으로 Stack에 할당되어 있기에 Reflection 연산으로 접근 할 수 없기 때문이다.

이를 의도된 Boxing을 통해서 Heap영역으로 옮긴 후 Reflection을 사용하는 방법이다.

물론 이때 다시 맴버 변수 접근으로 값을 가져오려면 Unboxing을 해야한다.

생각보다 퍼포먼스 손해가 많아 보이니, 꼭 필요한 경우나 어쩔수 없는 최후의(?) 상황에서 사용을 하자

이해를 돕기 위한 예시 코드는 아래와 같다

* 코드가 제대로 안나오면 F5(새로고침)해보세요

* 의사코드이므로 컴파일 안될 수 있습니다.

* Ref.https://stackoverflow.com/questions/6608368/why-doesnt-reflection-set-a-property-in-a-struct

백수로 맞이한 생일, 그리고 향그러운(?) 봄 바람을 만끽하며 어느 덧 백수의 끝이 보이긴 합니다. 언제까지 놀면서 돈만 까먹을 순 없으니 ㅠ_ㅠ

오늘의 포스팅은 요즘 많은 사람들이 꽤 궁금해 하고 또 충분한 needs가 있는 "프로그래밍 공부, 대체 어떻게 해야 돼?" 입니다. ㅎㅎㅎ 멋대로 정해본 제목..

아무 뼈대 없이 걍 생각나는대로 글을 쓰므로 두서가 없고 내용이 빠지는 게 종종 있을 수 있습니당.

먼저 오늘의 주가 되는 독자들은 전혀 프로그래밍 지식이 없는 사람들을 대상으로 해봅시다.

태어나서 처음 "프로그래밍 언어"를 접하게 돼면, 일단 가장 먼저 이런 생각이 들지요. "왓더 ㅈㅇㄹ#$!!# 이 외계어는 뭔가?"

정말로 처음 느낌은 뭔가 굉장히 낯설게 느껴집니다. 그럴 수 밖에 없지요. 그게 정상입니다. 만일 여러분들이 처음 프로그래밍 언어를 보고도 평안한 마음이라든가 득도의 햇살을 느낀다면 스스로가 정상이 아님을 인지 하시면 됩니다.

그런데 한 가지 팁을 알려드리자면, 낯설을 뿐이지 어렵진 않아요. 정말로~

스스로 세뇌를 해보세요

자 이제 본격적인 이야기를 해보자면 (음?) 보통의 게임 프로그래머가 돼기 위해서 공부하는 첫 번째 프로그래밍 언어는 C/C++ 입니다. 사실 C와 C++은 서로 다른 언어이긴 한데, 예를 들어 설명하자면 C++은 C의 확장팩 입니당. 스타 오리지널과 확팩이 있듯이요. 그렇게 이해 하면 쉽죠 ㅎㅎㅎ

그래서 게임 프로그래머 목표이신 분들이면 모두 C/C++을 배웁시다!!! 배워서 남주는거 없으니 한살이라도 어릴 때 하나라도 더 배웁시다. :D

진짜 문제는 이제부터 나오는데, 대체 이놈에 C/C++(이하 걍 C++) 은 생긴 것부터 맘에 안드는데, 처음 접하시는 분들은 이게 뭔지도 모르죠. "플밍 언어?? 먹는거임?"

먹는 거는 아닌건 확실함

사실 그래서 쌩판 아무것도 모르는 상황에서 시작 하실 때 가장 좋은 건,

1:1 과외가 짱이겠죠?

음...이건 논외로 치고 어쨌든 학원이든 대학이든 정규 커리큘럼을 우수한 성적으로 이수 하는 방법이 가장 좋습니다.

사실상 아무 지식 없는 '무' 상태에서 프로그래밍을 독학으로 공부 한다는 건 대단히 어렵긴 합니다.

결국 좋은 스승을 만들어야 합니다. :D (돈을 쳐 바르든...납치를 하든)

대략적으로 초반에 배워야 할 것들만 정리해 보면

- C/C++

- 자료구조

- 알고리즘

- Win32API

정도가 있겠군요. C/C++은 언어고 나머지는 이상한 것들입니다. 뭐 지금 당장은 너무 자세히 알려 하지 맙시다.

언어를 해결하는 부분에 초점을 맞춰야 하니까요.

C++ 언어의 기본 문법은 쉽습니다. (진짜임 ㅎ_ㅎ)

실제로 제가 C언어를 첨본게 (C++말고) 중학교 3학년때 였는데 책 한권 사서 독학으로 기본적인 것들은 했어요. 이런 건 쉬워요. 안되면 걍 외워버리는 방법도 있으나 제가 프로그래밍을 좋아하는 이유 중 하나는

아무것도 외울게 없다.

그러합니다. 한 개도 안외워도 됩니다. 이해만 하면 됩니다. 그럼 됩니다.

다시 앞 이야기로 돌아가서, 프로그래밍 언어가 뭔지에 대한 설명은 이곳에서 블라블라 하기엔 어렵구요. 제 포스팅의 주제는 어디까지나 공부 방법에 있으니까 ( 근데 아직까지 제대로 안쓴거 같은데 )

간략하게 이야기 하자면 프로그램은 (소프트웨어) 프로그래밍 언어로 만들어집니다. 끗

프로그래밍 공부의 가장 첫 번째는 언어의 공부입니다.

어떻게하면 언어를 이해 할 수 있는지, 그리고 한국말 처럼 유창하게(?) 쓸 수 있는지 이게 핵심이지요.

제가 드리는 팁은, 먼저 독학은 쉽지 않습니다. 아예 아무것도 모르는 상태에서 독학 한다는 건 어렵죠 (물론 가능한 사람들도 있어요) 그래서 가급적이면 학원이나 대학등을 이용해서 배경 지식을 습득하는 게 좋습니다.

훌륭한 멘토가 있는 것도 좋구요. 평이하죠 이 방법은?

두번째로는 걍 부딧치는 방법이 있죠. 제가 좋아하는 방법인데요 일단 부딧쳐 보세요. 대학? 학원? 그런거 걍 먹어버리세요. 초반에는 많이 해봐야 늡니다. 저는 개인적으로 초반에 코딩의 양이 중요하다고 생각해요.

이해 하지 못해도 무작정 예제들을 따라서 코딩 하고 컴파일 해보고, 결과를 확인해보고 디버깅 해보고.. 이런 과정들을 하면서 언어의 문법도 제법 잡히고 점차 프로그래밍이라는게 어떤건지 감도 잡혀갑니다.

근데 언어를 쌩판 처음 접하면 이 방법은 무용지물이겠죠. 먹는 건줄 알고 있는 상태니까 혀를 갖다 대고 있을테닝ㅎ_ㅎ

이건 먹는 건강??

이런 분들을 위해 행동강령을 짚어 보자면 일단 책을 삽시다. C++ 책을

그런데 최근 나오는 입문 서적들 중 어떤 것들이 있는지 전혀 몰라서, 딱 "이걸 보세요!!" 라고 할 순 없구요. 다만 이러이러한 책인지 살펴봅시다. (어페가 좀 있는뎅.. 잘 모르니 좋은 책을 찾는 것도 쉽진 않으니 @_@)

예제 중심의 책인지 봅시다. 책에서 특정 소스들을 중심으로 설명하고 연습 해 볼수 있는 식으로 진행이 되는지 봅시다. 뭔가 문제를 풀거나 하는건 아니에요. 책을 폈는데 퀴즈가 들어 있다면 내려 놓고 딴거 봅시다.

챕터1 (목차1) 부분을 읽어봅시다. 이 사람이 하는 말이 한글말인지 외계어인지 읽어보고 생각해봅시다. 알아들수 있는지?? 못 알아먹겠으면 내려 놓고 딴거 봅시다.

이 부분은, 같은 걸 설명할 때에도 쉽게 풀어서 잘 설명을 할 수 도 있으나 귀찮으니 걍 어렵게(?) 막 설명 할 수도 있어요. 특히 쌩판 모르는 상황에서 처음부터 배경지식이 필요한 말들이 나와버리면, 뇌에서 파업해버립니다.

앞 부분을 읽어보면서 저자가 어떤식으로 설명과 풀이를 하는지 봅시다. 설마 챕터1에다가 어려운 내용을 적어두진 않았을 겁니다. 만약 챕터1부터 포인터가 나온다면....내려 놓고 딴거 봅시다.

이렇게 어려운 검증을 통해 얻은 책을 이제 봐야합니다. 많은 사람들이 책을 사놓고 안봅니다!!!! (저도 그러함...)

돈 주고 산다고 그 지식이 내 머리 속에 복사 되지 않으니 읽어야 비로써 돈 값을 합니다.

뭔가 병맛 같은 외계어로 쏼라 거려도 읽어봅시다.

책을 읽는 방법은 여러가지 있는데, 여러번의 속독 후 정독 / 정독 후 속독 / 정독..정독..정독..

가장 좋은 방법이야 3번 정독하는 게 좋지요. 다만 1번도 끝까지 보기 힘든데 3번이라니 ㅎ_ㅎ 저도 지금껀 살면서 3번 읽은 책이 있기나 한가?? 싶네요

어쨌든 많이 봐야 합니다. 똑같은거 자꾸 봐야해요. 우리 모두의 엄마들 말씀인 "반복 학습" 입니다.

본인이 스스로 생각했을 때 "아 난 ㅈㄴ 천재니까" 그러면 밑에 A, 그게 아니면 "난 낫 놓고 ㄱ 자도 모르는 ㅄ 이야" 하면 B 를 봅시다.

A. 처음부터 책에서 시키는대로 하나씩 해보면서 진도를 끝까지 나갑니다. 중요한건 완독!!! 끝까지 다 가서 책의 마지막장 까지 읽는게 중요! ( 천천히 정독 )

B.일단 한글만 읽어보자.

B 그룹의 경우엔 제 말을 믿고 책을 걍 끝까지 읽어봐요. "이건 교양서적이다~" 생각하고 걍 끝까지 갑시다.

아, 참고로 너무 두꺼운 책을 사면 안돼요. 입문 서적은 그냥 얇은거 사세요. 우리들은 두꺼운거 사봐야 반도 못 봅니당. 걍 얇은 책이 짱짱임

B그룹 여러분들은 걱정 하실 필요 없어요. 사람인 이상 책을 끝까지 읽을 수 있고, 끝까지 일단 읽고 봅시다. ㅎ_ㅎ

그 후엔 A그룹 처럼 하시면 됩니당.

낮부터 열심시 쓰다가 중간에 끊어 쓰다보니 오늘은 여기서 이만 줄입시당.

언젠가 블로그에다가 C/C++ 기초부터 강의형식으로 만들어 보고 싶네요. 긍데 제가 게을러서 >_<

ps. ToolFramework 2편도 써야 하는뎅 ㅎ_ㅎ 요즘 디아에 푹 빠져있다보니 ㅌㅌㅌ

최근 백수라 집에서 놀다보니, 여행을 가고 싶지만 여러여건상 이것도 쉽진 않군요( 언제나 갈 예정임 ㅋ)

뭐 여하튼!!

집에서 쉬다보니  컨디션도 꽤 좋아졌고 해서 예전에 KGC2011에서 강연했던 주제를 제대로 정리하고자 하는 시간을 갖으려 합니다. ㅎㅎ 오늘이 그 첫번째 시간이군요. 이게 총 몇개로 이루어질지는 모르겠지만 해보는데까지 해봅시다. 먼저 앞으로의 계획을 대략적으로 정리하자면 아래와 같습니다.

- 엔진과 툴의 이종간 연동을 위한 구조 설계( DLL Interop을 이용 C/S모델로 설계해서 C++과 C#을 적절히 사용 )

- WPF(C#) 에서 Navtive DirectX Rendering 하기 (엔진의 Rendering 기능을 연결해서 WPF 컨트롤러에 붙이는 거 )

- 툴 자체를 Plug-In 구조로 설계해서 각각의 기능을 독립적으로 묶고 관리 하며 무한한 기능확장(?) 구조 설계

- TCP/IP를 이용, 원격지에 있는 툴 조종 및 행동 반영

아.... 그냥 막 생각하려니까 좀 이상하군요 ㅎㅎ 조금 더 부연 설명을 하자면 별것들 아닌데

첫번째는 KGC2011에서 강연 했던 주요 내용이구요.

두번째도 강연에서 잠깐 나왔던 건데, 그때 당시에는 자세히 다루지 않았죠. (간단함..hWndHost를 이용하는 거)

세번째는 언젠가 설계했던 건데 당장은 잘 기억 안나므로 제대로 정리 할 수 있을까? 싶은 의문이 듬

네번째는 KGC 강연때 마지막에 "이러 이렇게 하면 이런게 된다!" 라고 말했던 걸 만들어서 정리해볼려고 함.

막상 이렇게 조금이라도 정리해보니 대단한 여정이 될꺼 같네요(?) 끝까지 갈 수 있을런지......ㅡ_ㅡ

먼저 왜 이러한 주제를 택했고 어디서 어떻게 시작이 되었는가를 잠깐 살펴보자면, 이거 한장으로 모든 설명이 끝날 것 같다.

현재에도 많은 게임 엔진을 C++로 만들고, 이 추세는 앞으로 꽤 지속 될꺼라 생각합니다. 다만 C++의 툴 생산성은 꽤나 좋지 못하다고 생각하는데, 그나마 대안이 될만한게 WPF이지 않을까 싶습니다. ㅎ

윈폼도 써보고 MFC도 써봤지만 (MFC는 오래전에 ㅎㅎ ) UI 구성부터 시작해서 제대로 View와 모델을 구분하지는 못한것 같고 가장 크게 다가오는 것은 UI  구성이 꽤나 어렵지요.

WPF는 기존 MVC나 MVP와는 좀 다른 MVVM 패턴이라는데 ( http://msdn.microsoft.com/ko-kr/magazine/dd419663.aspx / WPF의 MVVM 패턴 )

저도 MVVM이니 MVC 잘 모릅니다. ㅎㅎ 다만 핵심적인 것은 View 코드와 비즈니스로직 코드를 완전히 분리한다 라고 이해 하시면 될 것 같습니다. View코드라 하면 UI를 구성 짓는 코드이고, 비즈니스 코드는 실질적 기능 구현에 쓰이는 코드 입니다

자..자세한건 링크를... 저는 몇번 봐도 계속 까먹어서 ㅎㅎㅎ

Anyway 원래 주제로 돌아가서 C#으로 툴을 만드는 것 까지는 좋은데, 문젠 C++로 만들어져 있는 게임 엔진 기능을 쓰기가 참 애매합니다. 전통적인 방법 중 하나로 C++/CLI 가 있는데요. CLI 은 Common Language In.... 머시기인데요. C++과 C#의 "중간계" 정도로 보시면 됩니다. ㅎㅎ 물론 이 C++/CLI를 사용해서 연동을 해도 되구요 C/S 모델도 사용 할 수 있습니다. 다만 개인적으로 모호한 "중간계"를 사용하고 싶지 않네요. C++/CLI에서 가장 난해한 부분은 Native 메모리들을 Managed 영역으로 맞춰주는 작업인데 이게 햇갈리는 부분이 좀 있네요. 물론 인터페이스를 단순화 한다면 이러한 부분도 해결은 되겠죠.

또 개인적으로 C++/CLI은 거의 사용을 안해봐서 잘 모릅니다.

그래서 깔끔하게 순수 C Dll을 택했고, Dll Interop을 통해서 C#에서 함수들을 사용합니다.

간단하게 이 구조의 모습은 다음과 같습니다

밑에 화살표는 무시하고, 툴 <-> DLL( Engine DLL ) 요런 모습입니다.

이게 현재 Version 0.1의 ToolFramwork 솔루션 모습입니다. 이건 앞으로 연재를 해가면서 계속 발전 할겁니다. ㅎㅎ RenderingTool 프로젝트는 사실상 빈 깡통이구요. 각 설명을 하자면

- ClientLauncher : Client런처 입니다  exe이고 엔진을 lib 또는 dll로 링크 하고 있습니다. WinMain을 가지고 있고, 현재로썬 딱히 하는게 없어요. 엔진 초기화 해서 돌리는 게 전부 입니다. 실제로 게임 로직이 들어가진 않아요.

- FrameWork : 아주 옛날에 만들어 둔건데 ㅋㅋ 제 블로그 뒤지면 스샷도 나오죠(...) 이건 원래 두개로 쪼갤려고 했는데 (game 로직 / engine ) 너무 귀찮으니... 그냥 게임 엔진이라고 생각하시면 됩니다. ㅎㅎ 아 이게 언젠가 DirectX 11으로 간단한 렌더러로 바꿀 생각이에요. ㅋ 물론 언제 그런 날이 올진 모르겠군요. 일단 예제 샘플로 쓰기에 좋음

- ToolInterface : 실제로 위에 그림에서 "DLL" 기능이고 툴의 기능적 로직들( 게임 엔진을 사용해야 하는 기능들 )이 이곳에 모두 들어갑니다. 그리고 중요한 Dll 통신용 인터페이스들을 Export 하고 있죠. 물론 그외에 다른 함수는 일절 Export 하지 않습니다. 오직 통신에 쓰이는 인터페이스 몇개만 Export 합니다.

- RenderingTool : 앤 아직 깡통...

이렇게 보니까 매우 심플하죠? 아닌가요 ㅋ 실질적으로 빌드해서 나오는 것은 ToolInterface.dll / Framework.dll / RendringTool.exe 이 3개 입니다. ClientLauncher는 그냥 디버깅용(?)으로 넣어둔 거라 큰 의미는 없고 소스 배포 할 때에도 빼 버릴까 생각 중입니다. ㅎㅎ 괜히 혼란만 가중 시킬꺼 같아서...

이제 우리가 살펴봐야 할 것은 ToolInterface 부분이며, 가장 먼저 Export 하는 부분을 봅시당

ToolInterface의 파일 뷰

// DllExport.h

#pragma once

#define DLL_EXPORT __declspec(dllexport)

extern "C"
{
	// 툴 인터페이스 초기화
	DLL_EXPORT void* InitalizeWindow( ::HINSTANCE applicationInstance, ::HWND hWndParent, int screenWidth, int screenHeight, const char* pAssetPath );

	// 툴 인터페이스 해제
	DLL_EXPORT void Start();
	DLL_EXPORT void Stop();

	DLL_EXPORT bool Send( const char* pCommand, void* pData, unsigned int dataSize );
	DLL_EXPORT bool SendOutput( const char* pCommand, void* pData, unsigned int dataSize, void*& pOutputData, unsigned int& outputDataSize );
	
}

딱 정확히 5개의 함수만 익스포트 시킵니다. ㅎㅎ 저걸로 모든 툴의 기능을 다 만들 수 있고 나중에 더 재미난 기능들도 가능하죠. 그리고 이것들은 한번만 만들어두면 앞으로 거의 왠만해선 고칠 일이 없습니다.

여기서 짚고 넘어가야 할 부분은 Send 와 SendOutput 인데요. 사실 이 함수들은 ToolInterface.dll -> WPF(C#) 으로 데이터를 보내는 함수가 아닌, 반대로 WPF(C#) -> ToolInterface.dll 함수들 입니다.

이는 WPF 입장에서 봤을 때 Send이기 때문에 이렇게 이름 지은 거구요. ToolInterface.dll 입장에서 봤을 때는 Recv나 Get 정도의 의미입니당. 실제로 저 안에서 하는 일도 데이터를 받아와서 해당 Command로 넘겨주고 기능들을 처리 하는 일입니다.

아, 오늘은 여기까지 써야겠네요. 시간이 너무 늦어서 ㅎㅎ 나머진 내일...