Hello World!

http://slaner.tistory.com/92

C++과 좀 다르니 확실히 기억해두는것이 좋다

포토샵이나 그림판을 사용하면 할 수 있는 간단한 작업이지만 해당 작업을 일괄적으로 처리하거나 프로그램에서 직접 그린 그림을 바로 합성해야 할 경우가 있기에 해당 기능을 C#코드로 구현한 결과물입니다.

코드 자체는 엄청 간단합니다. 배경이 될 이미지 위에 그대로 타겟 이미지를 그리는것이 모든 작업의 끝입니다. MFC를 학습하였다면 누구든지 쉽게 떠올릴 수 있는 방법이라고 생각합니다.

다만 두 이미지의 DPI가 다를 경우 합성 좌표가 어긋날 수 있기때문에 DPI를 계산해서 환산하는 부분이 코드에 들어가있습니다.

피해자(?)가 생기질 않길 바라며 이 글은 쓴다. 

일단 이 책은 전체적으로 부실한 내용을 가지고 있다는 것을 먼저 이야기하고 넘어가고 싶다. 저자가 원고를 넘길때 검토를 하나도 안 한 모양이다. 아니면 출판사에서 뭘 잘못했던가...

일단 이 책은 만약 지금처럼 GitHub이나 인터넷이 활발하지않은 환경이였다면 불쏘시개로 전락할 수준의 완성도를 가지고있다.

그나마 예제 소스코드를 인터넷에서 받을 수 있으니까 다행인것이다. CD부록도 있긴한데 별로 도움이 안된다. CD를 컴퓨터에 넣는 수고를 할 바에 GitHub이나 페이스북 페이지에 가서 샘플을 받는게 낫다.

기초적인 개념을 익히는데는 좋다고 생각하지만 아무것도 모르는 생초보가 이 책을 보고 따라한다고...? 매우 위험한 생각이다.

맨 처음 책을 보고 시작했을때는 잘 썼다 싶었는데 플레이어 캐릭터에 액션을 집어넣는 부분부터 뭔가 치명적으로 잘못되어간다는것을 느꼈다.

몇몇 부분은 유니티 버전이 올라가면서 변경되었을수도 있겠구나 하면서 넘어간다고 치지만 가장 중요한 스크립트 부분에 문제가 많다.

자잘한 오타부터 시작해서 아예 코드가 빠지거나 잘못된 부분이 많고 한줄만 추가하면 된다는 설명과는 다르게 코드의 일부를 갈아엎어야 하는 부분도 있고

아무 설명 없이 전 챕터에 없던 코드가 생기거나 전 챕터에 있던 코드가 사라지기도 하고 더 이상 사용되지 않는 코드가 사용되거나 사용목적이 잘못된 경우도 있고...

이렇게 작동할 것입니다 라고 서술되어있지만 실제로 조작해보면 그렇게 동작하지 않는 등 정말 문제투성이라고 해도 과언이 아닐 수준이다

유니티 개발에 대한 골격 자체는 잡고 넘어가기는 하며, 코드에 문제가 발생하는 부분들은 직접 디버깅을 하면서 돌다리 두들기듯이 진행할 수는 있지만 지금까지 봐왔던 책들에 비해 완성도가 떨어진다는건 부정할 수 없는 사실이다.

개인적으론 이 책에 4만원 상당의 가치가 있다고는 생각하기 어렵다. 비슷한 가격의, 아직 찾아보지는 않았지만 훨씬 퀄리티가 좋은 책이 이미 있을거라고 확신한다.

정말로, 말 그대로 「나홀로」완성하는 느낌을 받고싶다면 사도 괜찮을지도 모르겠다. 지도가 부실해도 적어도 나침반은 있으니까 오픈월드 게임을 칼 한자루 들고 도보로 여행하는 느낌은 받을 수 있지않을까

var는 다른 언어에서도 쉽게 접할 수 있는 키워드이다.

var의 장점은 string이냐 int냐 등등의 것들을 따질 필요 없이 간단하게 변수를 선언할 수 있다는 점이다.

그렇다면 dynamic은 무엇인가...하면 dynamic도 var와 하는 일은 거의 비슷해보인다. 하지만 dynamic같은 경우에는 좀 더 능동적인 변수라고 말할 수 있다.

이게 무슨 말이냐 하면 var의 경우에는 프로그래머가 직접 지정을 하지 않는다뿐이지 var변수 오른쪽에 위치할 코드로 인해 var의 형태는 확실하게 고정되게 된다.

하지만 dynamic은 실행을 할때도 별도의 검사를 하지 않는다. 즉 좀 더 능동적인 활용이 가능한 변수라고 하겠다.

나같은 경우는 JSON 을 deserialize할때 dynamic의 도움을 많이 받았다. dynamic의 장점은 명확하게 형태가 정해지지 않는 점에 있으므로 들어오는 변수값에 대해 좀 더 능동적인 대처가 가능해진다. 코드의 길이가 줄어드는 효과를 볼 수도 있다. 좀 더 자세한 설명은 MSDN을 참조하도록 하자.

하지만 IDE가 별도로 검사를 해주지 않기때문에 해당 코드에 정말 치명적이고 단순한 문제가 있다고 해도 프로그램이 터질때까지 비주얼 스튜디오는 나에게 이 코드에 문제가 있다고 알려주지 않는다. 못한다고 표현하는 쪽이 더 옳겠지만...

너무 남발하다보면 php로 코딩할때와 비슷한 기분을 느낄 수 있다. php보다야 당연 디버깅하긴 훨씬 편하지만...

하여튼 이 글에서 말하고 싶은 부분은 dynamic이라는것도 있다는걸 알아두면 언젠간 유용하게 쓸 날이 올지도 모른다...?

Newtonsoft.Json를 이용한 코드이다.

Deserialize는 기본적으로 Dictionary를 활용하는 식으로 이용한다.

예를 들어

{

"Test":{

"Kor":{

"Test_0001": "테스트1 입니다",

"Test_0002": "테스트2 입니다",

},

"Eng": {

"Test_0001": "This is Test1",
"Test_0002": "This is Test2",

}

}

}

이런 형식의 JSON이 있다고 하고 여기서 Eng를 추출해보도록 하자

먼저

이렇게 전체 JSON문을 parsing하고 그 이후

이렇게 Eng부분을 별도로 분리하고

이렇게 foreach구문으로 Eng부분을 모두 검색할 수 있다.

특정값을 알고싶다면

이렇게 하면 Eng의 Test_0001의 값을 알아낼 수 있다.

장점...이라고 말하기보기단 내가 WinForm자체를 그리 많이 접해보질 못했기때문에 사실 따질 부분이 없지만 일단 조악하게나마 만져본 경험과 MFC를 만져본 경험에 비추어봐서 몇개 꼽아보자면

가장 큰 장점은 UI를 구성하는데 거추장스럽지않고 깔끔하게 다룰 수 있다는점. 이 이상 할 말이 없을정도로 UI구성이 쉽고 다루기가 편하다. 물론 익숙해지는데 시간이 좀 걸릴수는 있겠지만 그건 뭘 해도 똑같은거고...

또 하나 더 꼽아보자면 안드로이드 어플리케이션이 이런 방식으로 UI를 구성한다는점. 근데 잠깐 건드려보고 말아서 잘은 모르겠지만 확장성이나 난이도는 WPF쪽이 훨씬 좋고 쉽다. 이클립스에선 Grid를 써서 UI를 구성하면서도 뭔가 만들다 만듯한 기분이 계속 들기도하고...

단점이라면 나같은 경우는 주로 MetroRadiance라는 라이브러리와 Livet이라는 라이브러를 써서 WPF 어플리케이션을 만드는데 사실 이렇게 만들어진 라이브러리가 없으면 접근하기가 꽤나 번거롭다...초창기에는 관련 라이브러리가 없으면 만질수도 없을정도. 지금은 MetroRadiance는 없어도 어느정도 만들 수 있지만 Livet은 아직도 필요하다...

물론 WinForm식의 접근도 가능하기야하지만 View와 ViewModel간의 연계라보기단 그 중간형태의 작업같다는 느낌히 강하게 들기때문에...이런식의 접근으로만 할 수 있는 작업도 존재하기때문에 완전히 무시하기도 힘들고

그리고 정말 빈약하다고 말하면 빈약이라는 단어에게 미안할 정도로 국내 자료가 적다...책이 있긴 있는 모양이지만 진짜 그냥 개론만 적어놓은 느낌이고. 사실 해외 포럼에서도 그렇게 인기있는 항목은 아닌지 검색해봐도 뭐 하나 구현하는데 사람마다 구현방법이 다 다르니;; 뭐 이쪽은 정해진 답이 없다 라는게 거의 언제나 정설로 통하는 부분이지만 학습하는 입장에서는 조금 괴롭다...

C#으로 짜여진 간단한 stl파일 변환 프로그램이다.

ASCII형식의 stl파일과 바이너리 형식의 stl파일의 상호 변환이 가능하다.

.Net Framework 4.5.2 기준으로 개발되어있어서 해당 프레임워크의 설치가 필요

STL Converter.zip

정말 간단하다

NuGet 패키지를 사용하면 끝.

프로젝트의 참조에 오른쪽 마우스 클릭->Nuget 패키지 관리에서 opencv를 검색한 후에 OpenCvSharp-AnyCPU를 설치하면 된다.

c++의 함수에서 대소문자가 바뀐것과 약간 사용법이 바뀐것 빼고는 거의 동일하게 구성되어있다.

함수를 쓸때는

Cv2.함수

이런식으로 쓰면 OK. 그 외 대부분의 것들은 OpenCvSharp. 쪽에 들어가있다.

NuGet 패키지 자체는 C++에서도 사용할수 있는것으로 보이지만 예전에 시도했을때는 제대로 사용하지 못했기때문에 C++쪽에서 NuGet 패키지 사용은 어떻게 굴러가는지는 모르겠다...

http://blog.secmem.org/598

일단 WIN32 API를 사용하는것과 방법은 동일.

다만 위 페이지에는 설명이 되어있지않지만 

인자를 받는 함수를 DLL로 작성해서 작동 테스트를 해보기위해 F5를 눌러보면

 PInvoke 함수 '[함수명]'에 대한 호출 결과 스택이 불안정하게 되었습니다. 관리되는 PInvoke 시그니처와 관리되지 않는 대상 시그니처가 일치하지 않기 때문인 것 같습니다. 호출 규칙 및 PInvoke 시그니처의 매개 변수와 관리되지 않는 대상 시그니처가 일치하는지 확인하십시오.

같은 에러가 발생하는 경우가 있다. 작동은 잘 되는것 같지만

이 경우에는 DllImport를

이렇게 수정해주면 에러가 발생하지않는다. 호출방식을 정해주지 않아서 생기는 문제라고한다

(http://blog.daum.net/windria/53)

System.Drawing의 참조가 필요(System.Drawing.Bitmap)

사용예:

/*

비트맵변수 선언 및 불러오기

여기서는 파일 경로로 불러오는 예제가 작성되어있지만 MSDN을 보면 알겠지만 이 방법만 있는것은 아님

https://msdn.microsoft.com/ko-kr/library/system.drawing.bitmap(v=vs.110).aspx

*/

Bitmap big_image = new Bitmap(BigFileLocate);

Bitmap small_image = new Bitmap(SmallFileLocate);

ImageChecker imgChk = new ImageChecker(big_image, small_image);

System.Drawing.Point pt = imgChk.bigContainsSmall();

한번 작업하는것은 상관없지만 이미지를 여러번 새로 불러와서 처리해야할 경우에는 Bitmap이나 Image를 해제해줘야한다. 해제하지않으면 GDI+관련 오류 발생

PS. 이 코드도 정확한 이미지를 찾기 위해서라면 나쁘지는 않지만 OpenCV를 이용하는것이 훨씬 좋다.