http://slaner.tistory.com/92

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

C#에서는 유용하게 잘 써먹었던 Singleton이였지만 개인 프로젝트를 C++로 진행한 적이 없었기 때문에 C++에서는 사용할 일이 없어 지금까지 외면해왔지만 

업무상으로 C++에서 코드를 작성해야 하는데 해당 프로젝트에 Singleton을 쓰면 좋을 것 같아서 검색하던 도중 좋은 글을 찾았다.

http://vallista.tistory.com/entry/1-Singleton-Pattern-in-C

일단 매우 기초적으로 구성할 수 있는 Singleton부터 Tamplete을 이용한 Singleton까지 다양한 Singleton들이 존재하고 

개인적으로는 Tamplete을 이용한것이 가장 깔끔한것 같다. 일단 포인터와 메모리 관리가 가장 편하고 한번 만들어두면 다른 곳에서도 활용할 수 있으니...

http://gamasotworld.blogspot.kr/2013/12/programming_29.html

위 글은 싱글톤 사용 이유와 단점에 대해 서술되어있으니 한번 읽어보고 내가 진행하는 프로젝트에 꼭 싱글톤이 필요한지에 대해 생각해보는것도 좋을 듯 싶다.

취미가 본업보다 빡세게 굴러가는 시점에서 이미 여러가지를 포기한 상태나 다름없긴하지만 하튼 특정 기능들의 구현을 위해 ajax라는걸 손대보게 되었다.

일단 백과사전이든 강의에든 이것저것 쓰여있기는 하지만 웹개발에 익숙하지도 않고 관심도 없었기때문에 이해하는데 꽤나 많은 시간을 소요했다. 읽는것보단 예제를 직접 시연해보는게 빠르다는것도 오랜만에 다시 느꼈고...

처음에는 그냥 자바스크립트인가 했지만 약간은 떨어져있는...뭐라고 설명해야 되는지 딱히 감이 잡히질 않는데 그냥 이해한걸 간단하게 한줄로 설명해보면 

웹 페이지를 실시간으로 변경하는데 사용되는 것. 다만 서버를 사용한다

자바스크립트는 철저하게 Client기반. 즉 브라우저를 기초로 해서 굴러가는 언어라고 생각했었지만 이런식으로도 통신이 가능하구나 라는것을 알게 된 기회가 되었...지만 뭐 실제로 내가 이걸 이곳저곳에 막 쓰고 그러진 않겠지

1회성 긴급 땜빵용 습득이 되어서 체계적으로 배울 기회가 없어지는것 같기도 하고

내가 윈폼 기반 프로그램으로 돈을 벌어먹고사는가라면야 계속 이어가야겠지만

취미로 하는 프로젝트에서 에너지를 그렇게 막 쏟을 필요가 없을 것 같다는 생각도 들어서 어떻게든 프로젝트를 WPF쪽으로 전환시키려다가 방법을 찾음

무려 WinForm용 컨트롤을 불러와서 사용할수있는 기능이 있었던것이다...

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

이제 CefSharp기반 프로젝트를 굳이 Winform에서 진행할 필요가 없어졌다

일단 윈폼은 MFC의 후계자같은 느낌이 강해서 UI구성에도 애를 먹었는데

역시 UI구성은 WPF쪽이 압도적으로 편하고 깔끔하게 구성할 수 있는것같다

이거 완전 MFC아닌가 할 생각이 들정도의 기시감, 그리고 UI구성의 불편함

일부 작업이 자동화 되었다 뿐이지 사실상 MFC구성할때랑 큰 차이가 없는 구성. 심지어 일부 컨트롤은 따로 MSDN을 볼 필요가 없을정도로 사용방법이 비슷하고

사실 WPF도 기본적으로는 View와 Viewmodel이라는 구조를 가지고있고 유사점도 있긴하지만 Winform은 그냥 새련된 MFC라는 인상이 픽팍...

디버깅하기엔 더 좋은거같긴하지만 만지면 만질수록 WPF로 회귀하고 싶은 마음만....

그랑블루 도우미 개선 작업을 모두 WPF로 작업하려고 하였으나...

사실 원래 버전도 생긴게 그렇게 생겼다 뿐이지 WPF로 작업한 물건이였고 개선버전에서 UI가 대폭 변경된 이유는 여러 이유때문에 제외시켰던 일부 UI들을 꺼내서 다시 적용시킨것에 지나지 않지만...

그랑블루 도우미라는것을 맨 처음에 프로토타입으로 구상했었을때는 예전에 작업했던 제독업무도 바빠!(칸코레 뷰어) 처럼 내장 브라우저에서만 프록시가 돌고 화면 우측에 정보를 띄워주는 그런 구조였지만 

IE에서는 그랑블루가 정상적으로 돌지 않는다+Chromium기반 브라우저를 WPF에서 돌릴수가 없다 

등의 이유들로 reject된 컨샙...

결국 시스템 프록시를 통해서 웹 브라우저의 동작을 캡처하고 분석하는 방향으로 프로젝트가 진행되었지만 이 방식은 프로그램이 필연적으로 시스템 옵션을 건드리는 부분이 있고, chrome자체에 통신을 캡처하는 어플리케이션이 깔려있는(ex: 미꾸라지 VPN, ZenMate VPN등) 경우에는 해당 어플리케이션이 활성화 상태가 아니더라도 웹 탐색을 캡처해낼 수 없다는 문제 때문에 불편사항이 많았고 그에 따른 기타 유언비어들까지...

하여튼 이번에는 우연찮게 CefSharp이라는 Cef를 wrapping한 라이브러리가 있다는 사실을 알게 되었고 예전에 봤던 크롬 브라우저 자체를 어플리케이션에 올리는 방식이 아니라 아예 크로미움을 내장할 수 있는 그런 라이브러리인데 여기서 발생한 첫번째 문제는 Cef는 기본적으로 ffmpeg를 지원하지 않고 무조건 빌드할때 옵션을 줘서 같이 빌드하도록 만들어야 한다는 점이고

두번째 문제는 같은 라이브러리를 사용하지만 Winform에서는 Chrome보다 좋은 퍼포먼스를 보여주지만 WPF에서는 Microsoft Edge보다 나쁜 퍼포먼스를 보여준다는 것이다.

사실 지금까지 작업했던 모듈들은 다 WPF로 작업을 했었고 소환석 이미지 만들어주는 프로그램에 기존 기능을 이식할때도 거의 코드 복붙만으로도 이식이 가능했지만 이 경우에는 사실상 Document부분(이라고 지칭하겠다. WinForm에선 좀 다르게 부를수도 있을것같지만)만 그대로 가져오는것이 가능하고 나머지 UI부분은 아예 처음부터 다시 짜야한다는 점

통신 캡처용 라이브러리와 메인 Winform사이의 커뮤니케이션이야 어짜피 같은 C#으로 짜는거니까 그대로 들고온다고 하지만 역시 가장 문제가 되는 부분은 UI다. 

Winform을 얼마 안 만져봐서 잘은 모르지만 벌써부터 UI구성에 엄청나게 애를 먹고있고 기존에 구현했던걸 그대로 구현하려니까 앞길이 막막하다. 가장 좋은 해결법은 WPF에서도 Winform만큼의 퍼포먼스가 나오면 되는건데 이건 뭐 아무리봐도...

다른 대안인 ChromiumFX나 CefGlue라는것도 있지만 이걸 다시 빌드할 생각을 하면 현기증이 날 뿐이고....일단 해결책이 안나오면 그쪽도 생각해봐야겠지만

필요사항

.NET Framework 4.6을 설치할 수 있는 OS가 필요합니다. MacOS와 Linux는 지원하지않습니다.

최소사양: 윈도우 비스타 서비스팩2, 윈도우 7 서비스팩1 이상

.NET Framework 4.6 

※WIndows 10 이상 버전에서는 설치할 필요가 없습니다. WIndows 7에서는 설치해야 할 수도 있습니다.

해당 프레임워크가 설치되어있지 않으면 프로그램이 실행되지 않습니다.

VS 2015 재배포 패키지(x86) 

※브라우저를 구동하는데 필요합니다. 실행은 되는데 브라우저가 보이지 않는다면 해당 패키지의 x86(32비트)버전을 설치하시기 바랍니다.

그랑블루 판타지라는 게임 자체의 최적화상태가 매우 좋지 않기때문에 컴퓨터 사양의 영향을 많이 받을 수 있습니다.

프로그램 설명

테스트용 버전입니다. Windows 7 x86(32비트) 이상의 운영체제가 필요합니다

내부 구조는 많이 다르지만 프로그램의 컨샙은 칸코레 뷰어(https://github.com/Grabacr07/KanColleViewer)와 거의 흡사합니다. 게임이 크롬에 최적화되어있는 관계로 C# 기본 브라우저를 사용하지 않고 Cef를 사용합니다. 

C# 바인딩 라이브러리로는 CefSharp를 사용합니다.

Cef라이브러리를 사용하기 위해 Visual Studio c++ 2015재배포 패키지(x86)가 필요합니다.

내장 프록시 라이브러리가 추가되어있기때문에 방화벽 설정이 필요합니다.

기초기능은 최신버전 그랑블루 도우미와 동일합니다.

FAQ

01. 화면이 이상하게 출력되는 경우 대처법

일부 컴퓨터 환경(High DPI)설정에서는 브라우저가 깜박거리거나 축소되어 보일 수 있습니다.

위와 같이 설정하여 이 현상을 발생하지 않도록 할 수 있습니다. 단 높은 DPI환경에서 윈도우가 해당 DPI에 맞게 사이즈가 변경이 되지 않으므로 UI가 잘 안보일 수도 있습니다.

뭐 언어마다 장단점이 있고 어떤게 더 우월하다 하고 싸움붙이는건 

엄마가 좋아 아빠가 좋아 수준의 질 낮은 행위라고는 생각하지만 일단 장단점을 알아야 나중에 사용할때 도움이 되지않겠는가? 

일단 속도면에서는 아직까지는 메모리나 포인터를 직접 관리하는 C++이 우월한 편이다. 하지만 개발 난이도는 넘사벽급으로 C# 이 쉽고 적응하기 좋다.

하지만 C++로는 가능한게 C# 단독으로는 불가능한 경우가 꽤 있는 편이다.

예전에 참가했던 Github 프로젝트에서 Flash Object위에 한글 자막을 띄워줄 수 없느냐 라는 문의가 들어왔을때 한창 MFC와 C++을 배우고 있던 시기라 그냥 DC를 얻어와서 화면상에 그려버리면 제아무리 Flash Object라고해도 그 위에 그릴 수 있지않을까 했지만 애초에 C#에서는 사용자가 DC를 직접 컨트롤 할 수 없게 되어있었다. 

뭐 C#에도 Image나 Bitmap같은 클래스가 존재해서 예전에 C++에서 하던 보편적인 작업들은 가능하지만(엄밀히 말하면 해당 클래스들 하부에는 DC를 컨트롤하는 부분들이 있을것이다) 좀 더 하드웨어를 직접적으로 컨트롤 하는 그런 작업들은 마이크로소프트에서 막아둔것이다. 

포인터도 사용은 가능하지만 Visual Studio한테 나 여기서 여기까지 이 영역 안에서만 포인터 직접 쓴다! 하고 고지를 날리면서 작업해야하고.

사실 개인적으로는 둘 중 하나만 파는게 아니고 둘 다 알아야 한다고 생각한다. 예를 들어서 C#에 있는 클래스중에 List<T>라는 클래스가 있는데 이 클래스는 간단히 말해서 동적배열이다. 하지만 C++에서 사용하는것과 달리 선언하는것과 정리하는 작업(애초에 정리가 필요없는 경우가 대부분이다)이 정말 쉽고 동적과 정적으로의 전환이 매우 간단하다. (ToList와 ToArray 한방이면....) 하지만 내부적으로는 C++에서의 동적배열과 거의 유사하기때문에 (아마 기본적인 구조는 linked list일것이다) 포인터나 Linked list를 아예 모른다면 특정 경우에서는 엄청 해맬 수 있다.

결국 C#도 기초를 보면 C++이고 OpenCV같은것들은 C#코드가 따로 있는게 아니고 C++의 라이브러리를 wrapping해서 사용하고 있는 상황이고 말이다.

여하튼 개인적으로 사용할때는 C#을 매우 엄청 많이 즐겨쓰는 편이다. 만약 프로그래밍을 배운다면 C++로 시작하는것보다는 C#으로 학습을 시작해서 기초적인 흐름을 잡고 그 이후에 C++을 배우는것도 나쁘지 않을것이라고 본다. 물론 경우에 따라 다르고 상황에 따라 다르긴 하겠지만...파이선도 쉽고 강력하다고 하지만 개인적으로는 C#쪽이 개발 결과물도 우리가 평소에 보던것과 가깝고 일단 개발환경을 구축하는 난이도가 다르다고 생각한다.

하지만 C#으로 입문해서 거기에 머물러 있는것은 좋지않다고 생각한다. 

필자는 C#으로 먼저 프로그래밍을 배우고 이후에 C++하고 MFC를 배웠는데 C++하고 MFC를 배우면서 불편함도 엄청나게 느꼈지만 아마 C++을 배우지 않았으면 지금보다 개발능력이 현저하게 떨어지는 수준이였을것이다. 지금도 개발능력이 높다고는 못하지만....일단 뭐든 배워서 남주는건 없는것같다. 특히 이 분야는 아는 만큼 보이는것도 많고 느끼는 점들도 많아지는것 같고

경고: 해당 한글화 어플리케이션을 사용해서 발생하는 모든 문제에 대해서는 글 작성자는 일절 책임을 지지 않습니다.

Dropbox: 링크

일부 설정 및 메시지만 한글화 되어있습니다. 압축을 풀면 apk파일이 들어있습니다

테스트는 PHANTOM 4 PRO에서만 진행하였으므로 다른 기종에서의 한글 적용 여부는 확인이 불가능합니다

Unity와 연동시킬때마다 비주얼 스튜디오에서 "알 수 없는 오류입니다" 오류창이 발생하는 오류가 있었는데 이 문제를 해결하는 법에 대해서 써보도록 하겠다.

해결방법은 여러가지가 있지만 가장 보편화된 해결법은

%localappdata%\Microsoft\VisualStudio\15.0_4388abd4 (2017의 경우에는 15.0 뒤에 문자가 추가로 붙어있을 수 있음)

해당 경로에서 현재 사용하는 비주얼 스튜디오의 버전에 해당하는 폴더 안에 들어가보면 privateregistry.bin라는 파일이 존재한다.

일단 이 privateregistry.bin파일을 제거하면 해결된다는 답변이 많았지만 나의 경우에는 이 문제가 반복해서 발생했고 지울때마다 실행은 됬지만 비주얼 스튜디오가 재설정 되었기때문에 번거로워져서 해결법을 좀 더 찾아보았다.

그래서 찾은 해결법

1. 먼저 Visual Studio와 관련된 모든 프로세스를 종료

2. 위에서 언급한 privateregistry.bin파일을 지운다.

3. Visual Studio를 관리자 권한으로 실행

관리자 권한으로 정상 실행을 확인한 뒤부터는 관리자 권한이 아닌 보통 권한으로 실행해도 문제가 없다. 

파일 참조 권한이 막혀서 문제가 발생하는 경우가 종종 있는것같다. 나같은 경우에는 관리자 권한으로 Visual Studio를 실행하여 privateregistry.bin파일을 재생성한 뒤부터는 해당 문제가 발생하지 않았다.

며칠동안 열심히 만지고 있지만 확실히 예전에 비해 메리트가 많이 줄었다. 자유도야 늘어나기야 했지만 아직도 답답한 부분이 많고

그 중 가장 답답한 부분은 Xcode가 맥 전용이라 iOS앱 개발을 시도해보려고 해도 일단 맥이 필요하다는점이...유니티 iOS개발도 결국 빌드는 Xcode에서 한다는거같고

Xamarin도 있다지만 안드로이드 스튜디오를 쓰고 느낀거지만 역시 범용보다는 전용이...

일단 Sky Compass의 애니메이션 채크인 기능은 GPS정보를 무조건적으로 필요로 합니다. 해당 지역에서 현재 애니메이션을 상영하는 시간인지 알 필요가 있기 때문입니다.

다만 Ameba TV상영시간인 토요일 24:00에는 별도의 GPS정보를 채크하지 않는것으로 알려져있습니다. 이는 인터넷 TV의 특성상 별도로 위치제한을 걸어두지 않은것으로 보입니다.

하지만 그 이외의 몇몇 방송시간대에는 방송지역에 맞춰 GPS정보를 시뮬레이팅해줘야합니다.

일단 아메바 TV바로 다음 시간대인 MBS방송을 예로 들어보자면 MBS는 간사이 광역권 방송이므로 GPS 위치를 간사이지방으로 설정해줘야합니다. 이 경우 가장 무난하게 오사카나 교토 등을 선택하면 되겠습니다. 그 외의 방송국도 특별히 방송권역이 정해져있는 경우에는 해당 방송국 권역에 맞춰 GPS를 설정해줘야합니다.

GPS 시뮬레이팅 어플리케이션은 종류가 많지만 이 글에서는 필자는 Lockito를 사용하고 있습니다.

일단 필수사항은 아니지만 Lockito를 사용하는 경우 핸드폰의 GPS설정을 GPS센서만 사용하는 기기전용 모드(참고: https://support.google.com/nexus/answer/3467281?hl=ko)로 변경할것을 추천합니다.

포스터 채크인의 경우도 GPS 시뮬레이팅을 이용하여 진행하면 깔끔

여기서 쓰는 STL은 Standard Template Library가 아니라 STereoLithography 파일에 대한내용.

일단 STL 파일 구조가 단순한 관계로 바이너리 형태든 ASCII형태든 뷰어 자체를 만드는건 쉽지만

OpenGL로 처음부터 구현하는건 시간도 시간이고 퀄리티도 그렇고 노력도 들어가므로

굳이 만든다고 한다면 VTK를 사용하는 편이 압도적으로 편하고 시간도 적게 걸리고 완성도도 높게 나옴

사실 어떤 목적이든 정말 특수한 경우가 아닌 이상은 직접 만드는것보다 이미 릴리즈 된 프로그램들을 사용하는것이 가장 편하고 좋겠지만...

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

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

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

1. 연동 비밀번호 설정

먼저 데이터 연동 버튼을 누르고

데이터 연동하기를 누른다음

아래쪽 버튼을 누르고

설정하기를 누른다음

비밀번호를 설정하면 됩니다. 비밀번호는 8자리 이상 16자 이하의 영어 대소문자와 숫자를 모두 섞어서 만들어야합니다. 

2. 설정한 연동 비밀번호를 통한 ID연동

여기서 위쪽 버튼을 눌러서

ID와 비밀번호를 입력하면 됩니다. ID는 프로필이나 타이틀 화면에서 확인할 수 있는 9자리 숫자입니다.

이 데이터 연동은 타이틀 화면에서도 데이터 연동 버튼을 통해서도 가능합니다.

해당 연동법은 iOS와 안드로이드, PC버전 모든 환경에서 사용이 가능하므로 이전보다 계정이전하는 불편함이 줄어들었지만

일반적인 매치나 프랜드 등록 등을 통해서도 완전히 공개되는 유저 ID와 유저가 개인적으로 설정하는 패스워드 한쌍으로만 인증이 진행되기때문에 비밀번호의 보안에 주의가 요구됩니다.

분명 스캐치업 내부에서는 재질(머티리얼, 텍스쳐)가 정상적으로 보이지만 랜더링 해보면 오브젝트에 재질이 입혀지지않고 회색으로 표시되는 경우가 있다.

윈도우 계정의 이름이 한글이기 때문에 V-Ray가 텍스쳐 캐시 폴더를 정상적으로 찾아가지 못하기 때문에 생기는 문제이다.

만약 자신의 윈도우 계정명이 한글(C:\Users 폴더에서 확인가능)이라면 제어판에서 새로운 계정을 생성하여 새로 세팅을 하는편이 좋다.

그렇다고 윈도우 계정의 폴더명을 바꿔버리면 대참사가 벌어지니 하지 말도록 하자. 가능은 하지만 계정 이름을 영문으로 새로 만드는게 시간적으로 이득일것이다.

그리고 제어판에서 바꿀 수 있는 이름은 외부에 보이는 이름뿐이라 문제 해결에 도움이 되지않는다. 무조건 계정을 영어로 새로 만드는것을 추천한다.

이것 외에도 여러가지 이유에 따라서 윈도우 계정명은 한글이 아닌 영어로 만드는것이 좋다. 오래된 프로그램들은 한글을 인식하지 못하기때문에 설치에 이상이 발생하거나 정상적으로 실행되지 않는 경우가 많다. 대표적 예로 C++ 재배포 패키지 구버전들이 그렇다. 일반적인 방법으로는 설치가 불가능하고 커맨드 프롬프트를 이용하여 설치를 해줘야한다.

계정명이 영어인데도 문제가 발생하고있다면 위쪽 표시줄에 있는 확장 메뉴에서 V-Ray로 들어가면 디버깅모드에서 머티리얼 관련 캐시 및 연결 등을 초기화 할 수 있는 메뉴가 있다. 아마 이 부분으로 해결이 되지않을까 싶다.

일단 모든 조건을 갖춘 완벽한 도구는 있을 수가 없다고 생각하기때문에 단점 위주로 서술...

개인적으로 가장 선호하는 Visual Studio만 해도 가벼운 개발이나 웹개발 쪽에선 확실한 장점이 없고 저사양 컴퓨터에서 돌리기엔 무리가 따른다.

Eclipse의 경우에는 별도로 손을 대서 작업해줘야 하는 부분이 꽤 있어서 썩 좋아하지는 않는다. 기본적인 부분만 사용한다면 문제가 없는 편이지만 가끔 코드를 받아서 보면 특정 플러그인이 필요하다던가 하는 부분도 있으니까 이런 부분은 확실히 번거롭다.

Android Studio는 안드로이드 개발을 위해 개조된 툴인만큼 전반적으로 만족하지만 역시 약간 무거운 편이고...그냥 안드로이드 개발환경 자체에 맘에 안드는 부분들이 있어서 싫은 부분들도 있지만 그런건 이 부분에선 논외고

Unity는 뭐 그냥 편하다...아직 고차원적인걸 만들어보질못해서 고질병이라는 최적화 수준이 낮다는 부분은 아직 체감을 해보지못했다. 하지만 툴 자체의 완성도가 낮다고 느껴질때가 가끔 있다.

Unreal Engine은 퀄리티 자체는 확실히 좋고 맨 처음에 접했던 이미지와는 달리 의외로 유니티보다 빠르게 느껴진다. 툴 자체의 완성도는 이쪽이 훨씬 높지않을까 하고 생각된다. 단점은 나중가면 거기서 거기일거같은 부분들이긴하지만 확실히 유니티에 비해 익숙해지기는 어렵다. 

코딩이야 유니티는 C#기반이고 언리얼은 C++이니까 언리얼쪽이 더 어려울거라고 생각되지만 이거도 좀 더 해봐야 알것이고...

EditPlus는 가볍고 편한 툴이긴하지만 기능추가나 커스터마이징같은 부분이 자유롭지 못한 편이고 확실히 요즘 새로 나오는 툴들에 비해 세련되지 못하다.

AcroEdit는 무료 라이선스에 메모리에 대해서도 훨씬 너그럽지만 뭔가 손에 맞질않는다. 아마 UI가 익숙해지지않는게 가장 큰 이유일거같기도 하다.

Visual Code는 일단 무겁다. 그리고 확장의 개수가 적다. 텍스트 에디터인 주제에 꽤 무겁기때문에 자주 쓰게되질않는다.

Atom은 Visual Code와 근간은 같지만 일단 좀 더 빠르다. 확장의 개수는 많지만 Visual Code도 그렇고 Atom도 그렇고 둘 다 알파벳 문화권 이외의 인코딩들에게 너그럽지 못하다

Sublime Text는 일단 에디트 플러스에 맞먹을 정도로 빠르지만 UI가 직관적이질 못한 느낌을 받는다. 언급한 텍스트 에디터들중 CLI환경에 가장 가까운 느낌을 준다. 사실 개발을 하기 시작하면 대부분의 작업은 단축키로 해결하지만 역시 맨 처음 접할때는 GUI쪽이 훨씬 이해하기도 좋고 간편하니까.

일단 이런 난잡한 환경을 싫어하는 사람들도 있겠지만 나같은 경우는 지금 위에 언급한 도구들에 한해선 다 사용하고있다. 물론 사용빈도가 같지는 않고 자주 사용하는 툴이 있고 자주 사용 안하는 툴이 있지만 저걸로는 안되던데 이걸로는 될까 하는 생각이 들때마다 비교해가면서 그때마다 꺼내쓰고있다.

위에 언급한 것들 말고도 세세한 장단점도 있긴하지만 다 적으려면 시간도 걸리고, 특히 이런 글은 개인적으로 느끼는 점이 강하게 어필되기때문에

어떤 툴이 사람들에게 자주 언급된다면 속는 샘 치더라도 한번쯤은 만져보고 직접 평가하는게 가장 좋다고 생각한다.

저번에는 아마 AcroEdit에 대해 이야기했던거 같은데 이번에는 Sublime Text다.

AcroEdit도 나쁜 에디터는 아니지만 손에 딱히 익질 않아서 쓰는둥 마는둥 왔다갔다 하던 시기에 Sublime Text를 추천받았다.

일단 가장 먼저 느낀점은 가벼움이였고 두번째로는 다양한 부가기능이였다. 솔직히 쓴지 얼마 안된 입장에서는 이 다양한 부가기능에 대해선 크게 쓸 말이 없다. 가장 유용하게 썼던 기능은 여러줄, 혹은 여러 칸을 동시에 편집하는 기능이였지만 그 외의 기능은 아직 접할 기회가 없었다.

플러그인을 인스톨 하는쪽은 Atom이나 Visual Code보다 직관적이지 않다. 

그리고 사실상 제한은 없지만 유료라는것도 약간의 장애물이 될 수도 있다고 생각한다.

하지만 Sublime Text가 기본적으로 제공하는 기능들에 익숙해지고, 그 기능들을 확실하게 써먹을 수 있는 환경에서 개발을 한다면 좋은 선택이 되리라고 생각한다.

일단 현재 해보고 있는 작업에서는 스레드를 추가한 후 해당 스레드로 무한 반복문을 돌려 화면을 지속적으로 캡처하면서 캡처한 화면을 매번 OpenCV 이미지 분석 메소드로 넘긴 후에 결과를 받아오는 식으로 하고있지만 OpenCV의 작업 처리 시간이 생각보다 긴 탓에 현재 개발환경에서 화면 한장을 분석하는데 약 0.9초의 시간을 소모하고있다.

이 경우에는 마우스 커서가 실시간으로 움직이고있는 이미지를 트래킹하는건 조금 무리가 있다고 생각한다. 멈춰있는 이미지의 좌표를 정확히 추적하는데는 이정도만 되어도 충분하다고는 생각하지만...

스레드를 다른방식으로 쓴다던가 아니면 OpenCV에 실시간으로 영상을 트래킹할수있는 기능이 있으면 해당 기능을 사용해서 반응속도를 좀 더 올릴 수도 있다고 생각이 되긴한다.

실제로 OpenCV를 이용한 AR 트래킹은 거의 실시간으로 오브젝트를 추적하는것이 가능하므로 실시간으로 움직이는 이미지를 추적할 방법은 있을거라고 생각되긴하지만...이후는 나중에

뭐 DPI가 무엇인가 하는 등의 기초적인 이야기는 안 하고 넘어가기로 하겠습니다

일단 여기서 이야기할 DPI는 윈도우의 DPI에 대한것.

화면을 캡처해서 캡처한 화면을 인식하는 등의 작업이나 캡처한 화면을 바로 저장해주는 캡처 기능들을 만들 때 그 특정 화면의 윈도우 크기를 알아낼 필요가 있는데

자신의 윈도우 크기를 알아내는건 쉽지만 다른 프로세스의 윈도우 크기를 알아내는건 그것보단 조금 복잡하기때문에 이 부분에 대한 설명도 넘어가기로 하고....

왜 여기서 DPI이야기가 나오느냐 하면 DPI에 따라 이미지를 crop할때 쓰이는 값에 가져온 창 크기값을 바로 적용시킬 수는 없다는 이야기이다.

너무 정직하게 '윈도우의 크기를 뽑아냈으니 그대로 집어넣으면 되겠지' 하고 값을 집어넣으면 예상했던것과는 다른 결과물이 나온다 라는 말을 하고 싶은것이다.

보통 윈도우는 96DPI에 설정이 맞추어져있지만 간혹 다르게 설정되어있는 컴퓨터들이 있다. 주로 노트북에서 설정이 되어있는 것 같고 그 외에는 해상도가 지나치게 높으면 설정을 하는것으로 보인다. 이 경우에는 96DPI에서 캡처하던것처럼 스크린을 캡처하게 되면 이상한 영역이 캡처되게된다.

DPI가 다르기때문에 달라진 배수만큼 원래 Point값을 변조해서 사용하면 문제가 해결되는것을 보고 어느정도 이해는 했지만 좀 더 깔끔한 해결법이나 다른 방법이 있으리라고 생각해본다.

지저분하게 잡설을 늘어놓았지만 결국 하고싶은 말은 스크린을 캡처하는 기능을 프로그램에 넣는다고 하면 컴퓨터의 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의 값을 알아낼 수 있다.

일단 안드로이드 스튜디오에 내장된 기능으로 굉장히 쉽게 푸쉬 기능을 구축할 수 있다.

Tools->Firebase 를 눌러 Notifications으로 들어가 시키는대로 따라하면 기초적인 준비는 완료된다.

알림은 Firebase 콘솔에서 Notifications을 선택하여 쉽게 전송할 수 있다.

여기서 메시지를 입력하고 사용자 세그먼트에서 앱을 선택해서 전송해도 좋고 주제를 선택해도 좋다. 주제는 별도로 생성하는 파트는 없고 토픽을 구독하려는 어플리케이션이 있으면 해당 토픽을 자동적으로 생성하는 모양이다. 적용되는데는 시간이 꽤 걸리므로 인내가 필요한듯 싶다.

하지만 Firebase 콘솔에서는 어플리케이션이 켜져있을때 한정으로만 메시지 전송이 가능하기때문에 백그라운드에서도 작동하게 만드려면 API를 사용해야한다.

필자는 가장 익숙한 C#을 사용하였지만 Node.js를 사용하는 사람도 있고, 아마 php로도 되지않을까싶다.

관련 문서: https://firebase.google.com/docs/cloud-messaging/http-server-ref

WebClient클래스를 사용하여 POST형식으로 보내려고 하였으나 Header를 설정하는 부분에서 문제가 발생하여 HttpWebRequest를 사용하였다.

여기서 ContentType과 Authorization는 필수적으로 들어가야한다. Authorization해더가 없는 경우에는 인증 에러가 뜨기 때문에...

서버 키는 Firebase 콘솔에서 프로젝트 설정->클라우드 메시징에 들어가 확인할 수 있다.

해당 기능을 사용하면 푸쉬서버가 없어도 원하는 푸쉬 알림을 보낼 수 있지만 특정 변화에 자동적으로 반응하는 기능을 구현하고싶다면 서버가 필요하지않을까...

결국 문제를 해결하긴했는데 그냥 가장 좋은건 중복id를 사용안하는게 아닐까싶다 ㅎ.........

이 id가 자동으로 추가되는 시스템에서 장점을 하나도 느낄 수가 없다

그냥 xml보다 액티비티를 먼저 읽어들이는건지 아니면 그냥 이름순으로 읽어들이는지는 모르겠지만...아마 이름순으로 읽어들이는쪽이 아닐까 생각된다.

@+id와 @id의 차이도 잘 알아야 하는데 +가 붙은쪽이 새로 선언하는 쪽인데

그러니까 이 멍청한놈은 위쪽 문서에 @id가 있고 아래쪽 문서에 @+id가 있으면 이걸 똑똑하게 처리를 못 한다는것이다.

단순하게 순서대로 문서를 순회하면서 수작업으로 +가 없는곳에 +를 붙여주고 +가 이미 앞에서 붙었으면 +를 빼주는 작업으로 문제를 해결하였다.

비주얼 스튜디오 MFC ID관리도 하다가 가끔 뻑나면 짜증나고 그랬는데 이 부분에서만큼은 MFC가 훠어어어어얼씬 편하고 좋다고 느꼈다...