'분류 전체보기'에 해당되는 글 389건

Stepmania(http://www.stepmania.com/)는 DDR이나 Pump it up!같은 댄스 시뮬레이션 게임입니다. DDR과 같은 4방향과 Pump it up! 같은 5방향을 모두 지원합니다. 실제로 Stepmania용 스텝도 인터넷에 많이 돌아다니고, 가정용 장판만 있으면 충분히 할 만한 수준입니다.

특히! 무엇보다 좋은 것은 오픈소스라는 것입니다. 누구나 소스를 열람하고 수정할 수 있습니다. 게다가 라이센스도 GPL이 아니라서 상업용으로 써도 무방합니다. 실제로 Stepmania기반 아케이드가 나온 적이 있습니다. 그것도 자그마치 Pump it up! 시리즈 중 하나로 말이지요. (정확히는 Pump it up! Pro 시리즈 입니다.) 이 외에도 상당히 스텝파일 지원폭도 넓어서 4방향 스텝인 DWI와 2000년대에 나온 Kick it up!(Pump it up! 클론 시뮬레이터)의 파일인 KSF도 지원합니다. 물론 지금은 대부분 *.Sm로 만들어지기는 합니다.

그런데 이 Stepmania가 윈도나 맥은 그냥 바이너리를 주지만 리눅스는 그냥 소스만 덜렁 내줍니다. 하다못해 RPM이나 DEB이라도 좀 주지... 그래서 리눅스에서 쓰기 위해서는 컴파일 작업이 꼭 필요합니다. 이번에는 그 짓을 해보도록 하겠습니다.

리눅스는 어디로 갔지? Any라고 써있으면서 소스만 주는 아...

1. 우선 Stepmania홈페이지에서 소스묶음을 다운로드 받습니다. http://www.stepmania.com/download/

여기에 보시면 위의 스크린샷과 같이 Any라 써있는 범용 소스코드(...)를 다운로드 받을 수 있습니다.

이것을 다운로드 받으면 됩니다. Windows도 Mac도 아니니 당연히 그렇지요.

2. 압축을 풀고 컴파일을 위한 패키지를 미리 설치합시다. 

터미널을 열고 다음과 같은 명령어를 넣으면 됩니다.

무진장 많은데 저 라이브러리를 다 쓰기 때문에 다 써먹어야 합니다. xorg-dev만 넣어도 알아서 다 따라온다고 하는데 그냥 넣어버리지요.

3. 위에서 다운로드 받은 덩어리(?)의 압축을 풀어서 해당 폴더에 쳐들어가 봅시다.

이 소스를 컴파일 한 뒤에 Songs 폴더를 포함해서 써먹어야 하는 파일들이 모인 곳이니 중요히 여기자. 문제생기면 또 컴파일하면 된다.

4. autogen.sh 파일을 실행하자. 

잠깐 터미널이 지나가고(터미널에서 실행을 안 해도 파일 변화가 보입니다.) Configure라는 스크립트가 생성됨을 알 수 있습니다.

위와 아래를 비교해보자. 약간의 변화가 느껴지는가?

5. configure를 실행해 봅시다. 이왕이면 터미널로 실행하는 것을 추천 드립니다. 만약 중간에 오류가 생기면 어디서 어떤 라이브러리가 부족한 것인지 알 수 있습니다.

6. 이제 터미널이 들어가야 합니다.

 터미널을 이용해서 해당 소스 트리로 들어갑시다. (cd ~~ 아시지요?)

그 다음 다음과 같은 명령을 내립시다.

(위의 -j뒤의 숫자는 스레드 수입니다. 듀얼코어면 2 쿼드코어면 4를 써주시면 됩니다.

그리고 -f는 동영상 지원용입니다. 만약 최신 소스를 사용하시면 이게 필요없습니다.

7. 이제 컴파일이 다 될 때까지 시간을 보냅시다.

한 번 지켜보자..왜인지 빨려들어갈 것 같은 기분이든다. 괜히 쳐다보지 말고 그냥 다른 짓을 하도록 하자.

8. ~/.stepmania-5.0/Songs 폴더에 내가 하고 싶은 음악들을 몰아넣자.

(그냥 소스트리의 Songs폴더에 넣어도 됩니다.)

특이하게도 폴더트리 구조가 

Songs------Jukebox1-----곡1폴더--곡과 스텝파일

               |                       |--곡2폴더--곡과 스텝파일

               |

               |--Jukebox2------곡3폴더

이러한 형태라서 폴더구조를 이중으로 만드셔야 인식이 됩니다.

9.  ~/stepmania-5.0/Themes 폴더에 내가 쓰고 싶은 테마를 넣자.

(그냥 소스트리의 Themes폴더에 넣어도 됩니다.)

여기는 이중구조 아닙니다. Themes 폴더안에 스킨(테마)하나 폴더 만들어서 그안에 압축풀어 넣으시면 됩니다.

10. 소스트리 루트에 있는 stepmania 파일을 실행하면 끝.

이 제 저것만 실행하면 끝!

11. 메뉴에 추가하거나 /bin에 링크를 만들어 넣는 것은 수동으로 해주시면 됩니다.(네 저 좀 무책임합니다.)

Q: 곡이나 테마파일은 어디서 구하냐구요?

A: 그냥 포럼을 뒤지세요. 상당히 좋은 곡들과 테마들이 넘쳐납니다. 특히 자작스텝의 경우, 개념있는 스텝도 있는 반면 미친듯한 극악의 스텝도 있습니다.

곡 : http://www.stepmania.com/forums/songs/

테마 :http://www.stepmania.com/forums/themes/

Q : 화면이 버벅거려요!

A : OpenGL이 잡히나요? 터미널에서 glxinfo 명령을 내린뒤에 장치가 soft renderer나 softpipe라던가 llvmpipe라던가... 이러면 느립니다. 옵션에서 해상도를 낮추고 이미지 품질을 낮추는 등의 일련의 작업이 필요합니다.

Q : 이거 돈받고 팔아도 되나요?

A : 프로그램은 돈 받고 팔아도 되는데(MIT 라이센스라네요.) 곡이나 테마는 저작권이 걸려있으면 못 팝니다. 물론 전부 자작이라면 가능합니다. 그런데 기본스킨도 저작권 있는것 아시나요?

Q : 발판은 어디서 파나요?

A : 옛날 DDR발판 중고로 구하셔도 되고 그냥 오픈 마켓 뒤지면 나옵니다. 어떤 분은 직접 만들기도 하시더군요. 책받침이나 PE(1T~1.5T정도) 사다가 알루미늄 테이프하고 전선가지고 조이패드나 키보드에 납땜해서 만들기도 합니다.

Q : 층간 소음 어쩌나요?

A : 저한테 묻지 마시고 아랫집하고 직접 이야기 하세요.

Q : 소스 컴파일하는데 너무 오래걸려요. 바이너리를 주세요.

A : 컴파일하는데 요즘 컴퓨터로 2분이면 충분합니다. 제 컴퓨터로 5분이면 컴파일 완료되던데요.

Q : 코나미가 소송 안 거나요? 안다미로는요?

A : 아니 뭘 이런 걸 다 신경쓰세요. 벌써 5.0인데 아직까지 별 소리 없는 것 봐서는 별 문제 없을 겁니다.

Q : 게임이 너무 힘들어요!저 살빠지면 책임지실거에요?

A : 이 사람이 진짜....

최근 Long Live The Queen의 작업 결과물 덕에 갑자기 방문자 수가 늘었습니다. 사실 Long Live The Queen은 처음엔 그냥 심심해서 스팀에서 싸게 팔던 게임을 가지고 이리저리 갖고 놀던 것이 시초였는데, 어느새 이렇게 되었네요. 

다 좋은데... 저 "진 라면" 하고 "현대 카드"는 뭐지? 난 라면에 대해서도 신용카드에 대해서도 쓴 적이 한 번도 없는데?

하지만 약간 씁쓸하기는 합니다. 기껏 열심히 쓴 글은 방문자수가 고작 두 자리수에 그쳤는데 Long Live The Queen 한글 개선 패치를 배포하면서 200명 가까이 늘었습니다. 그것도 검색엔진이 아니라 원 한글패치 제작자 이신 ghap님의 티스토리를 통해서 말이지요.

이 포스팅 전에 Xorg와 Wayland에 대한 글을 올리면서 이 블로그에 대한 정체성이 흔들린다는 토로 글을 시작했었는데, 이것을 보면 안 흔들릴래야 안 흔들릴 수가 없습니다. 아니, 그동안 제가 쓴 글이 그리 영양가가 없었다는 이야기도 되겠네요. 다음 부터는 글을 쓸 때 더 고심을 해봐야 할 것 같습니다. 아니면, 워낙 우분투 사용자 층이 엷다 보니 생긴 해프닝일 수도 있고요. 다시 한번 말씀 드리지만 여긴 우분투/리눅스 관련 블로그 임을 다시 한번 밝혀 드립니다.

Long Live The Queen은 사실 리눅스 지원 게임이라서 소개도 하고, 약간의 삽질을 통해서 안드로이드에서 구동이 가능하다는 것을 보여드리기 위해 올렸던 것입니다. 그러다가, 한글 패치의 존재를 알았고, 이 한글패치를 적용해서 안드로이드 포팅을 하다가 한글이 완벽히 적용이 되지 않았음을 알았고, 이를 해결하고자 삽질을 하게 되었습니다.
오늘도 컴퓨터를 켜자마자 렌파이를 갖고 놀고 있었네요. 그러다 또 Long Live The Queen의 엔진 패치 및 기타 오류 패치를 배포했는데, 개인적으로 이것이 마지막 메이저 배포였으면 좋겠습니다.

정작 하라는 블로그 글은 안 쓰고... 그래서 오늘도 이런 영양가 없는 잡담으로 글을 채우는 중입니다. 내일부터는 다시 제대로 된 포스팅을 해야지요. 여기는 우분투 블로그니까요. (정작 리눅스 민트를 사용하는 중이기는 하지만...)

간만의 포스팅이군요. 한동안 Long Live The Queen 한글패치 관련 작업 및 다른 일 떄문에 글을 전혀 올리지 못했습니다. 이제 원래 블로그 주제에 맞는 글을 다시 올려야지요. 다시 한번 말하지만 여기는 우분투/리눅스민트 사용 및 리눅스에 대한 이야기를 적는 블로그니까요. 기타 삽질 카테고리가 우분투 카테고리보다 늘어나면 블로그명 부터 갈아엎을 겁니다.

이제 서론은 그만두기로 하고, 이번 포스팅 주제를 다시 이야기 하도록 하겠습니다. 이번 포스팅 주제는 지는 해 Xorg와 뜨는 해 Wayland에 대해 써보도록 하겠습니다.(뜬금없이 나타난 해 - Mir는 제대로 공개가 되면 이야기 해봅시다.)

1. Xorg 이것은 무엇일까?

Xorg는 최초의 GUI 시스템인 X윈도우(X11)의 일종입니다. XFree86이 최초의 GUI 구현체였지만 이것이 라이센스가 꼬이면서 사람들은 마지막으로 라이센스가 GPL이었던 버전을 그대로 Fork해서 새로이 만들어내었습니다. 이쪽은 라이센스가 여전히 GPL 혹은 LGPL이었기에 커뮤니티 기반의 리눅스/유닉스 배포판에서 환영을 받았습니다. 물론 대부분의 배포판이 전부 Xorg로 넘어간것도 다 라이센스문제 때문이었지요. 특히 GPL이 꼬여있는 것이 문제였습니다. (이후에 비슷한 일이 OpenOffice.org와 LibreOffice에서 일어납니다.)

그런데 Xorg는 바로 전에 말했듯이 기존의 만들어졌던 XFree86의 후손이기에 소스코드가 XFree86기반이었고, 이 소스는 자그마치 80년대에 만들어진 코드였습니다. 즉, 만들어진지 30년이 된 시스템을 이리저리 때워가며 만든 것입니다. 그런데 2010년대에 들어선 지금에도 대다수 리눅스/유닉스의 GUI는 거의 Xorg 혹은 XFree86입니다. 사실 그동안 많이 쓰이기도 했고 대다수 프로그램들이 이 X11기반으로 돌아가기 때문에 당연하게도 이 Xorg를 이리저리 고쳐서 쓰는 실정입니다. 사실 중간에 격변을 거치기는 했습니다. 문제는 격변이 덩치 불리기로 이루어져서 코드 최적화가 더 이상 불가능할 정도로 안드로메다로 날아가 버렸다는 것이 문제입니다. 그리고, 새로운 그래픽 카드들은 계속 나오고 있고, 이를 지원하기 위한 각종 기술들이 들어가기 시작했고, KMS나 DRI, AIGLX 등의 많은 기능이 추가되게 됩니다. 문제는, 이를 다 쓰기에 Xorg는 너무 낡은 코드를 사용했고, 가벼운 데스크탑을 지향하기에는 조금 무리가 따르게 되었다는 것입니다. 그러던 어느날, Wayland란 녀석이 눈에 띄게 되면서 이 물건이 Xorg의 자리를 노리기 시작합니다.

2. Wayland의 정체

Wayland는 사실 레드햇 개발자가 따로 떨어져나와 시작된 프로젝트였습니다. 꼭 필요했던, 하지만 아무도 시작하지 못했던 그런 프로젝트였지요. 그런데, Wayland 이놈은 대부분 기능을 커널에 넘겨버리는 짓을 합니다. 즉, 커널이 디스플레이의 대부분을 담당하게 하면서, 자신의 몸집을 줄이는 방향을 택한 것이지요. 사실 KMS와 DRI기능이 커널에 들어가면서 이것이 가능하게 되었는데, 지금 사용하는 리눅스 데스크탑은 전부 사용하고 있는 기술입니다. 언제부터 갑자기 xorg.conf 삽질을 하지 않아도 알아서 해상도가 잡히고, 입력 장치들이 알아서 인식되는 등, 한번 Xorg에 큰 변화가 이루어진 적이 있었는데, 이것이 바로 KMS가 있었기에 가능했던 것이지요. 아마도 KMS가 본격적으로 지원된 커널이 2.6.35버전부터 였을 것입니다. 아무튼 Xorg의 코드 사용은 점점 줄어가는데 정작 Xorg는 코드가 너무 방대해서 이 코드들을 줄일 방법이 전혀 없었습니다. 지금도 레거시 지원이라는 명목으로 예전 방식 그대로 설정을 하면 그대로 먹히기는 합니다만, 해상도 설정이나 입력장치 설정 같은 것은 굳이 예전방식으로 할 이유는 없다고 봅니다. KMS방식이 훨씬 빠르기도 하고 가볍기 때문이지요.

 Wayland는 이를 중점으로 삼고 기존의 X11이 사용하지 않거나 사용되지 않게 될 부분을 과감히 쳐내고 필요한 부분 만을 구현해서 만들어냅니다. 이를 통해서 훨씬 작은 시스템이 가능해지고, 가벼운 데스크탑 환경을 만들 수 있게 되었습니다. 실제로 Wayland는 Xorg의 1/10크기 정도라고 하네요.

3. Xorg는 이대로 사라질 것인가?

Xorg도 그렇고 Xfree86도 그렇고, 이 물건들은 자동차로 치면 거의 포니 수준입니다. 그런데 이 포니에 HUD장치를 달고, 내비게이션을 달고, 이것저것 장치를 주렁주렁 달려고 하다 보니, 자동차가 삐걱거리기 일쑤에 지금은 쓰지 않는 쓸데없는 것도 생기게 됩니다. 이미 낡은 자동차에 장치만 잔뜩 달면 기름도 많이 먹겠지요? 참 보는 사람도 답답할 지경입니다.

이런 차에 내비게이션 달고, ABS브레이크를 넣고, 아이팟 시스템을 달고, HID라이트를 달고... 그냥 차를 바꾸는 것이 낫지 않을까? 사진은 현대 포니 출처 - 위키피디아

분명히 지금 사용하는 X11기반 프로그램들도 Wayland로 포팅될 것은 확실해 보입니다. KDE나 Gnome같은 메이저 데스크탑 환경도 Wayland로 포팅중이고 QT5기반의 새로운 Wayland기반 데스크탑 환경도 니왔습니다. (이름은 Hawaii입니다. MAUI프로젝트에서 진행 중입니다. (http://www.maui-project.org/) 그런데 Wayland로 넘어가기 위해 우리는 어떻게 해야 할까요? 사실 우리는 Wayland가 나왔다고 무조건 바꿀 수 있는 상황이 안 됩니다. Wayland만으로는 인터넷조차 하기 버거운 상황이거든요. Firefox가 Wayland기반이 아니라 여전히 X11을 이용하기 때문에 간단한 인터넷도 현재 Wayland만으로는 부족합니다. Firefox나 Chrome도 결국에는 X11기반이 아닌 다른 물건으로 바뀌겠지만, 그것이 Wayland가 될지 아니면 다른 프로젝트의 결과물(Mir같은...)이 될지는 아무도 모릅니다. 그 때쯤이면 Xorg는 추억속의 물건이 될지도 모르겠습니다.

4. Wayland를 지금 써보고 싶다면?

현재 Wayland는 그럭저럭 쓸만한 수준까지 만들어져 있습니다. 그런데 이를 제대로 활용한 배포판이 많지가 않습니다. Debian에 Wayland는 있지만 Debian이 그렇듯이 검증 안 된 패키지는 저장소에 잘 안 들어가게 됩니다. 따라서 Debian은 Wayland를 이용하기 좀 어려운 배포판입니다.(물론  Unstable이나 Sid를 이용하면 되기는 합니다.) Wayland를 써보시겠다면 ArchLinux로 써보시길 추천드립니다. Wayland같이 안정 버전이 없거나, 검증되지 않은 패키지는 빠른 업데이트가 제일 중요한데 Arch같이 빠른 업데이트를 지원하는 배포판은 없기 때문입니다. 게다가 다른 배포판(Debian계열이나 Ubuntu계열이 대표적으로)은 wayland 패키지를 설치했어도 xorg패키지를 설치하지 않으면 GUI설정이 전혀 안되거나 스크립트를 이리저리 뜯어야 하는 문제가 있지만, Arch는 원래 GUI부터 수동이라 Wayland설정을 하기가 더 쉽습니다. 위에서 말한 MAUI프로젝트도 Arch기반인 것도 다 이유가 있는 것이지요. https://wiki.archlinux.org/index.php/wayland 여기의 내용을 그대로 따라하시면 Wayland 기반의 Arch환경을 구축 하실 수 있습니다. 여기에 X호환환경을 만들어주는(사실 Wayland내에 Xorg를 올리는 형태지만) Xwayland를 갖춰주시면 지금도 쓸만한 데스크탑환경이 됩니다.(Xwayland를 이용함으로써 X11기반 프로그램도 쓸 수 있습니다.)

 반대로 Xorg환경내에서 wayland를 이용하고 싶으시다면 기존의 X11기반의 배포판에 wayland를 설치만 해주시면 weston 명령으로 wayland를 창 형태로 돌려보실 수 있습니다.다만, wayland전용의 환경은 많지 않아서 말 그대로 테스트 그 이상의 효과는 못 낼 것 같습니다. 하지만 X11용 그래픽드라이버를 이용하면서 가속도 할 수 있으니, nvidia나 따끈따끈한 신형 AMD GPU 이용자(Catalyst만이 해답인..)라면 이걸로 쓸 수 밖에 없을 것입니다. Wayland는 오로지 오픈소스 드라이버만이 사용 가능하니까요.

5. 잠깐 Xwayland라고요?

위에서 저는 언젠가는 X11기반 프로그램들이 Wayland 기반으로 포팅 될 것이라고 했습니다. 하지만, 사실 Wayland는 X11호환을 위한 라이브러리가 준비 되어있습니다. 제가 Xorg환경내에서 weston명령을 쓰면 새 X11창 내에 Wayland 환경이 뜬다고 했지요? 그걸 반대로 뒤집으면 된다고 생각하면 됩니다. Wayland환경내에 X11환경을 띄우는 것입니다. OSX도 비슷한 짓을 하니까(X11을 내부에서 돌립니다.) X11자체는 크게 패치를 할 것이 없을겁니다. 이 것을 이용하면 Wayland로 포팅이 이루어지지 않은 프로그램도 쉽게 쓸 수 있게됩니다. 예를 들면 지금의 유료프로그램을 들 수 있겠네요. Matlab이라든가, 한글2008같은 프로그램 것 말이지요. 특히 한글은 wayland로 포팅 될 일이 없을 테니 꼭 필요해 보입니다. 그런 프로그램들을 위해 Xwayland가 준비 되었는데, X11이 완전히 사라지게 되면 Wayland내에서도 바로 내 쳐질 것입니다. 어차피 호환을 위해 만들어진 기능이니까요. 하지만 X11이 30년동안 쓰여오면서 그 기반 프로그램을 무시 못하니 Xwayland가 만들어진 것입니다. 30년 동안 쓰인 GUI서버가 언제쯤 사라지게 될지는 알 수 없지만, 그 때까지 부족한 Wayland기반 프로그램들을 대신해줄 물건임에는 틀림 없습니다.

6. Wayland외의 또 다른 경쟁자는?

 과거의 X11을 대체하기 위해 만들어진 프로젝트는 많았습니다. 그나마 뚜렷한 성과를 보인 것은 XGL(OpenGL기반 X11대체 프로젝트)이 있었습니다. 하지만 이도 AIGLX(X11 개선에 초점)에 의해 밀렸고, 지금까지도 X11이 쓰이게 됩니다. 즉, Wayland같이 이렇게 가시적인 성과를 보인 프로젝트는 거의 없었던 것이지요. 딱 하나만 제외하고요. 우분투를 만들어서 배포하는 캐노니컬의 Mir가 현재로써는 유일한 경쟁자로 보입니다. Mir가 어떻게 나올지 어떤 모습을 하게 될지는 캐노니컬이 공개를 하지 않아서 알 수는 없지만, Wayland와 비슷한 형태가 될 것이라고 생각은 듭니다. 어쩌면 XGL vs AIGLX 때처럼 Mir vs Wayland가 될 가능성도 있겠지요. 어떤 프로젝트가 사라지게 될지 아니면 둘 다 살아남아서 서로의 장점을 이끌어낼지는 아무도 모릅니다. 하지만 Mir가 공개된 정보가 많지가 않아서 Wayland와 다르게 알 수가 없습니다. 지금 당장 사용해 볼 수도 없고 알 수도 없어서 아직까지는 Wayland가 대세라고 생각합니다. Mir는 이 Wayland를 뛰어넘어야만 세상에 공개 될 것 같습니다.

리눅스/유닉스는 X11을 통해서 GUI란 놈을 세상에 알렸습니다. 실제로 GUI를 제대로 퍼뜨린 것은 Apple이지만, GUI의 개념을 제대로 만들어 낸 최초의 결과물은 X11이었지요. 이제 그 X11이 역사속으로 사라질 준비를 하고 있습니다. 다만, 역사속으로 사라지려면 좀 시간이 많이 걸릴 것 같네요. 과연 Wayland가 성공적으로 안착을 할 수 있을까요? Xorg는 역사 속으로 사라질 수 있을까요? 리눅스/유닉스의 GUI는 또 어떻게 바뀔까요? 모바일 시대로 넘어가는 이 때의 Wayland가 모바일 시대에 맞춰서 나올 수 있을까요? 10년 뒤의 모습이 정말 궁금합니다.

2016. 3. 23 추가

2016년이 되고보니 Mir도 공개되고 Wayland와 맞붙을 준비가 되었습니다. 아직 Mir가 지원하는 환경이 많지는 않지만 Wayland가 지금까지 걸어온 길에 비해 상당히 순항을 한 것으로 보입니다. 특히 이제는 Unity가 불편한 UI가 아닌 빠릿하고 편리한 UI라는 평가를 받는 지금 Mir가 Wayland에 비해 이득이 더 클 것으로 보입니다. 아쉬운 것은 Wayland가 아직까지도 안정화가 안 되었다는 사실입니다. Mir는 이제 16.04에 탑재 되는 것으로 잠정 결론이 났는데(15.10에서 설치가 가능합니다.)Wayland는 아직까지도 안정화가 되었다는 느낌이 없습니다.

이렇게 가다가는 Wayland를 10년뒤에나 제대로 볼 수 있을지도 잘 모르겠습니다.

http://moordev.tistory.com/20

우선, 링크의 글에서 저는 갖은 삽질을 통해서 안드로이드 버전을 올릴 수 있었습니다. 그런데 이것이 무엇을 의미하는 것인지 이때까지 저는 알지 못했습니다. 갑작스런 한글패치 및 삽질 하기 전에는...

이미 대부분의 기능이 Ghap님 패치에 이식 되었습니다. 몇몇 추가기능(그래픽 가속 기능, 렌파이 번역엔진, 안드로이드 포팅)등을 이용하실 생각이 있으신 분들만 사용해주시면 됩니다.

단순 게임을 즐기기 위해서라면 Ghap님 패치만으로 충분합니다. (몇몇 문장 번역 안 되는 문제는 Ghap님 께서 alpha버전을 통해서 작업하고 계십니다. 필요한 기능이 alpha버전에 들어가 있거든요.)

이 패치는 우선적으로 http://ghap.tistory.com/entry/LONG-LIVE-THE-QUEEN-%ED%95%9C%EA%B8%80-%ED%8C%A8%EC%B9%98-%ED%8C%8C%EC%9D%BC%EC%9E%85%EB%8B%88%EB%8B%A4

여기에 있는 패치 적용이 전제되어야합니다. 즉, Ghap님의 패치를 먼저 하시라구요...

단!!! 우선 Ghap님 패치중에서 options.rpy는 하지 말아주십시오. 엔진 교체시 스팀 연동불가의 원인이 될 수 있습니다. 우선 options.rpy를 뺴고 제 패치를 설치한 후에 구동해 보십시오. 구동이 잘 된다면 그냥 게임을 해주시면 되고 구동이 안 되시면 그 때 options.rpy를 넣어주셔도 늦지 않습니다.

우선 기존의 C:\Program Files\Steam\steamapps\common\LongLiveTheQueen\renpy폴더를 미리 삭제해 주셔야합니다.

안 그러면 엔진충돌 납니다. 혹시 모르니 미리 백업하시는 것도 필수입니다.

리눅스 사용자라면

~/.steam/steam/SteamApps/common/LongLiveTheQueen/renpy 폴더를 미리 삭제해주시면 됩니다.

8월 13일 버전 패치(구글드라이브라 속도가 느립니다. 기다려 주시면 링크가 뜰 것입니다.)

{스팀경로}/LongLiveTheQueen 폴더에 압축을 풀기 전에 LongLiveTheQueen/renpy 폴더를 미리 삭제해 주시기 바랍니다.

Ghap님의 패치와 달리 (스팀경로)/LongLiveTheQueen 폴더에 압축을 풀으셔야 합니다.

윈도우용 (7z압축)

리눅스,OSX용 (tar.gz압축 따로 권한설정 필요없음)

수정사항

1. 로그 관련 오류 수정 - UTF-8인코딩을 기본적으로 쓰도록 함 (기존은 ASCII 인코딩이었음)

2. 저장이나 불러오기 중에 빈 슬롯에 "Empty Slot" 을 "비어있음"이라고 뜨도록 함. 200개 까지는 커버 함

3. 과목을 다 배우거나 한 종류만 50을 배웠을 때 과목 명이 영문으로 뜨므로 임시로 그것을 막기 위해

"당신이 현재 배우는 스킬은 50이 되었습니다. 같은 그룹내의 다른 스킬들이 25 이상이 되기 전엔 해당 스킬을 향상시킬 수 없습니다."

"당신은 이 스킬에 대해 더 배울 것이 없습니다."

이런 식으로 뜨도록 수정. - 한국어를 이용한 꼼수 - strings에 적힌 것과는 별개로 translation.rpy에 하드코딩 했으므로 무조건 이렇게 뜹니다.

4. prettyprint.rpy에 몇몇 함수가 여전히 작동 불능상태이므로 readable_number_small함수를 Override하는 식으로 덮었음. 함수가 작동 안 하는 일은 없을 것입니다.

(주의. Ghap님의 1.6버전의 한글패치 중 /translation/kr/ui/printpretty.rpy 파일이 들어있는 한 해당 스크립트가 우선 오버라이드 됩니다. /translation/kr/ui/printpretty.rpy 및 /translation/kr/ui/printpretty.rpyc 파일의 삭제 부탁드립니다. strings파일도 같이 있는 것으로 봐서 ghap님이 실수 하신 것으로 보입니다.)

5. 세이브파일에는 0주차로 뜨고 게임 내에서는 1주차로 뜨는 것을 수정 하는 패치 제작(제작사와 관계없이 수정 했으므로 무슨 일이 벌어질지 저도 모릅니다. 제작사는 버그가 아니라고 했으므로 안 하셔도 됩니다.)

세이브 주차수 관련 패치

압축을 풀어서 /game 폴더에 넣어주십시오.

6. 제일 중요한 오타 및 실수 수정.

Gambas는 토마토소스에 야채를 썪어서 만든 매콤한 요리입니다. 보통 뷔페등지에 가면 볼 수 있는 음식이지요. 그런데, 갑자기 우분투 블로그에서 왜 요리이야기룰 하냐고요? 사실 Gambas는 이 요리만 있는 것이 아닙니다. Gambas는 리눅스 환경에서 Basic언어로 GUI를 만들어낼 수 있는 막강한 툴의 이름이기도 합니다.

 하지만, 제작자도 이것을 알고 있어서 프로그램 아이콘이 새우입니다. 토마토소스에 볶은 새우요리인데, 정작 아이콘은 파란 새우네요. 약간 유머와 위트를 섞은 것 같네요.

즉, 이 요리이야기가 아니라 이미지 출처 -http://www.piospaella.com/food/item/gambas-al-ajillo/

바로 이 개발도구 이야기 입니다.

우선 gambas 이야기 하기 전에 Visual Basic이야기를 해야 할 것 같습니다. Visual Basic은 Basic언어를 사용하는 RAD(생산성 향상 개발도구 정도라고 생각하시면 편합니다.)입니다. 우선 쉽기로 유명한 Basic언어를 쓰면서 GUI도 상당히 자유롭게 만들 수 있어서 VIsual Basic은 초보 개발자들에게 입문용으로 많이 추천되어져 왔습니다. 다만, 6.0까지만 그랬고 이후에 나온 VB.net같은 물건은 Basic을 쓰기는 쓰는데 워낙 기능이 많아서 입문용으로 C보다 별로인 물건으로 굴러떨어지고 말았습니다. 실제로 지금도 Visual Basic은 2005이후 버전을 쓰거나(그나마도 대부분 교육용으로 나온 2005 Express을 씁니다.)아직도 6.0을 쓰고 있습니다. 6.0이 가볍기도 하지만, 그만큼 VB.net에서 이것저것 기능을 추가하다보니 문법이 방대해진 것도 한 몫 했습니다. 

Visual Basic 6의 모습, 개발자 친화적이라는 Microsoft의 역작중 하나이다. 출처- 위키피디아

하지만 그 특유의 생산성은 여전해서 아직도 간단한 시리얼 통신을 기기 제어, GUI를 구현하는데 많이 쓰이고 있고, 지금도 막강한 영향력을 발휘합니다. 그러다보니 리눅스나 BSD진영에서도 이러한 Visual Basic스러운 물건이 만들어 지는데 이게 바로 Gambas입니다. 그러나 Gambas와 Visual Basic은 서로 호환이 전~혀 안됩니다. 실제로 Gambas홈페이지(http://gambas.sourceforge.net/en)에서도 Visual Basic과의 차이를 들어가며 설명중입니다.

아는 선배의 부탁으로 gambas로 만들고 있는 측정 프로그램, 이걸 만드는데 하루도 채 걸리지 않았다.

하지만 Gambas도 결국 Basic언어를 쓴 하나의 도구이기 때문에 코드 호환성이 어느 정도 확보가 됩니다. 마음만 먹으면 Visual Basic에서 동일하게 컨트롤을 배치하고 Name을 똑같이 배정한 다음 코드를 그대로 복사-붙여넣기 하면 60%정도는 돌아갈 것입니다. 고작 60%?라고 생각하실 수 도 있겠지만 이 정도면 선방한 셈입니다. Basic을 쓰더라도 Visual Basic와 QBasic은 죽어도 호환 안 되는 것을 생각하면 이거라도 감지덕지입니다. VB나 Gambas나 생산성을 위한 도구니까, 본격적으로 만드는 프로그램에는 적합하진 않습니다. 본격적으로 만드실려면 C/C++나 Python같은 언어로 개발하시는 것이 나중에 기능 추가등에 편리합니다. (Visual Basic으로 제대로 만들어서 판매하는 사람도 있기는 합니다. 언어에 한계란 것이 없어서...) 애초에 OS호환성을 따질 생각이었으면 VB나 Gambas보다는 Python + QTCreator or Glade(GUI를 위한)을 쓰는 것을 추천드립니다. 이 쪽이 나중에 기능 추가를 한다거나 호환성을 확보할 때에는 이쪽이 훨씬 더 편리합니다.

하지만 나중을 위해서가 아니라, 그냥 지금 당장 프로그램을 만들어야 하는데 시간이 없다면 Gambas를 쓰는 것이 100배 낫습니다. 윈도라면 Visual Basic으로 하시면 되고요. 하지만 Visual Basic은 가격도 가격이고, 최근 버전은 너무 더럽게 구동이 느려서 저는 그냥 리눅스 환경에서 Gambas를 씁니다. 원한다면 라이브 리눅스에 Gambas런타임하고 새로 짠 프로그램 넣고 주면 그만이니까요. 지금 당장 데이터를 뽑아내야 하는데 가장 생산성이 좋은 Labview는 가격이 상당한데다가 전용 하드웨어가 필요하고, Python은 Glade나 QTCreator와 조합해야 하는데 못 할 것은 없는데, Gambas에 비해 만드는 것이 쉽지는 않습니다. JAVA도 나쁘지는 않지만 GUI 만들기가 제가 이야기한 것 들에 비해 생각보다 어렵습니다.(Swing은 XML로 뽑아내는 GUI가 없는 것으로 알고 있습니다. 만약 Glade처럼 XML로 뽑아내주는 도구가 있다면 트랙백이나 댓글 부탁드립니다.)

Gambas를 이번에 쓰면서 느낀 것이지만, Visual스러운 개발 환경을 갖추면서 오픈소스란 점은 정말 매력적입니다. 원한다면 뚝딱뚝딱 만들어낼 수 있는 점도 상당히 마음에 들고, 기존 Visual Basic사용자들도 별 무리없이 넘어 올 수 있습니다.(몇몇 문법차이는 배우면 되니까 크게 문제는 없습니다.)

장점만 크게 이야기 한 것 같은데 단점도 생각보다는 큽니다. 우선 Visual Basic의 단점은 모두 물려받았습니다. 컨트롤 부족=개발단계 급증가를 의미합니다. 아니, 컨트롤을 개발해야 하는 입장이 된다면 그냥 Basic을 버리고 C/C++만으로 넘어가는 것이 훨씬 좋습니다. 처음부터 C/C++로 개발을 하면 중간에 Basic을 끼워넣어서 두번 거치게 하는 것보다 더 쉽게 처리 가능합니다. 물론 나중을 위해서 컨트롤을 미리 개발할 수도 있겠지만, 만약 비공개 프로젝트라던가, 단순 레포트제출용 데이터라던가 하면, 이 과정은 그냥 '삽질'일 뿐입니다. VB.net은 이를 해결 하기 위해서 오만가지 잡다한 것들을 다 넣어놓았는데, 도리어 Basic하지 못해지면서 사람들에게 외면을 받고 말았습니다. 2005 Express부터는 그 기능을 그대로 가져오면서 필요없는 것들을 가리는 등의 Basic한 면을 돌려놓았다고는 하는데 이미 Basic세상은 C#이 점령해가고 있었습니다.(아아...Basic은 이렇게 몰락해 가는가....) Gambas도 마찬가지로 VB.net수준으로 만든다면 사람들에게 외면 받을 것입니다. 그러다보니 컨트롤이 좀 부족하다는 느낌이 들 때가 있습니다. SDL같은 물건도 지원하는 굉장한 능력은 지녔지만, 저는 SDL기능을 쓴 적이 없네요. 아니, 사실 쓸 일이 없었던 것일지도 모르겠습니다.

또 다른 단점으로는 OS호환성 문제가 있습니다. 즉, 호환성이 문제를 일으킨다는 것인데 우선 Gambas는 BSD와 리눅스에서 GUI Basic을 사용하기 위한 것으로 출발 했기 때문에 윈도는 전혀 지원하지 않습니다. 특히 Xorg에 거의 대부분 의존하고 있기에 Xorg를 사용하지 않는 다른 OS는 절대로 지원이 안 된다고 합니다. OSX도 Xorg가 그나마 설치가 되기 때문에 그럭저럭 쓸 수는 있지만, OSX는 Xorg의 구동이 매우매우매우 답답하게 돌아가기 때문에 별로 추천하지 않는 다고 하네요. 윈도는 Cygwin에서 GUI를 제외하고는 구동이 된다고 합니다. 그런데 GUI 안되면 왜 Gambas로 개발하나요? 그냥 Python으로 만들던가 Bash스크립트 만들어내지.... 구글을 통해서 알아보니 다들 그냥 가상화해서 리눅스 올려 쓰라고 하네요.

OS호환성 말고도 버전별 호환성문제도 있습니다. 하지만 이 버전별 호환성 문제는 JAVA나 Python도 겪고 있는 문제이니 Gambas만의 문제라고 볼 수는 없습니다. 게다가 Python 2.7이 Python3.x 보다많이 쓰이면서 구 버전을 기본을 설치하는 등의 일도 일어나지 않고 있습니다. Gambas2.x보다 Gambas3.x가 훨씬 더 많이 쓰이고 훨씬 더 많이 포럼에 글이 올라옵니다. 그냥 기존 Gambas2프로젝트를 Gambas3로 바꾸는 것이 더욱 이득이 되는 상황이라 이것은 그냥 단점을 상쇄하네요.

리눅스와 BSD에서 Visual Basic같은 도구를 찾으신다면 당연히 Gambas를 설치하세요. 만약 Visual Basic을 쓰셨다면 더욱 금상첨화입니다. 어쩌면 이 새우요리가 여러분의 프로젝트를 빠르게 성장 시킬 동력이 될 수도 있으니까요.

두 IDE의 차이는 성능상으로 큰 차이가 없고, 인터페이스도 사람들마다 반응이 달라서 완벽하게 비교는 저의 특성 상 어려웠습니다. 따라서 단순히 사용에 따른 문제와 그 부분에 대한 이야기가 주류로 쓰여질 것입니다.

안드로이드 앱을 개발하려고 한다면 분명 예전에는 100이면 100 Eclipse + ADT였습니다. 사실 그것밖에 답이 없기도 했고 Eclipse가 워낙 JAVA개발툴로써 제일 좋은 물건이었기 때문에 대부분 이것을 이용했고, JAVA를 이용하는 안드로이드로써는 Eclipse와의 궁합이 가장 중요했지요.

그런데 구글은 Eclipse가 상당히 마음에 안 들었던 모양입니다. 자체적으로 Android Studio란 물건을 내놓았거든요. 사람들 반응은 상당히 괜찮은 물건이라고 합니다. 제가 써본 결과로는 잘 모르겠네요. 다만, 한 가지 기능이 상당히 마음에 들던데, 그 기능은 바로 SDK버전 별로 APK를 빌드 해 주는 기능이었습니다.

Android Studio의 모습. Eclipse와 다른 것은 대체 무엇일까?

Eclipse 시절에는 한번 SDK 최소 버전을 설정하면 SDK버전을 맞추기가 상당히 어려웠습니다. 특히 프로젝트를 API 15로 시작했다면 나중에 구 버전 안드로이드 호환을 위해서 API10으로 낮춘다는 것은 불가능한 일이었습니다. 반대로 신 버전 안드로이드의 추가된 기능을 쓰기위해서 API버전을 올리는 것도 문제가 많았습니다. 컴파일이 안 된다거나 소스가 꼬인다던가 하는 일이 많았지요. 그런데 Android Studio로 만들면 이와 같은 문제가 한번에 해결되더군요. 빌드 할 때 API버전별로 APK를 뽑아내줍니다. 나중의 업데이트를 위한 방법으로 정말 좋은 기능이지요. 새 안드로이드가 나올 때마다 호환성 문제를 매번 겪는 것을 감안하면 정말 눈물 나게 고마운 기능입니다.

그 외에도 많은 개발자들은 Eclipse를 버리고 Android Studio로 넘어갔다는 후문입니다. 하지만 딱 하나 Android Studio를 쓰지 못하는 사람들이 있습니다. 바로 NDK가 지원이 안 되는 문제가 있습니다. NDK는 빠른 구동을 위해서는 필요한 라이브러리이지만 일반적인 어플에서는 필요없는 물건입니다. 특히 자바만 이용한다면 당연히 쓸모 없습니다. 하지만, 게임이라던가 동영상 재생기(MX플레이어 같은 소프트 디코딩 지원 재생기)라면 NDK는 없어서는 안되는 물건이지요. 이 사람들은 어쩔 수 없이 Eclipse를 써야합니다.

하지만 Eclipse를 NDK를 쓰지 않음에도 사용하는 사람들이 있습니다. 이 사람들의 생각은 바로 이것입니다. "구관이 명관이다." 아무래도 이 생각으로 아직도 Eclipse를 사용하는 것 같습니다. 심지어 구글은 아직도 Eclipse의 ADT를 지원해주고 있습니다. 그도 그럴 것이 Android Studio는 아직도 베타 딱지를 못 떼내었습니다. 각종 버그가 출몰 중이라고 하는군요. 저도 실행 중 튕김 증상을 겪었습니다. 아직 베타이니 그러려니 하지만, 진짜 중요한 개발이라면 별로 추천할 만한 상태는 아닌 듯 합니다. 아무리 좋은 기능이 있어도 안정적이지 못하면 그건 쓸모없는 것이니까요. 그냥 개인 개발자라면 그래도 무리없이 쓸 수 있겠지만 수십 수백의 돈이 오가는 프로젝트라면 불안정한 Android Studio보다 기존에 써왔던 Eclipse가 더 믿음직 할 것입니다.

기존 안드로이드 개발용으로 많이 쓰인 Eclipse의 모습. JAVA, C/C++등의 범용이라 안드로이드만의 특화 기능은 플러그인을 이용해야만 한다.

개발의 편의성은 Android Studio가 훨씬 더 우세합니다만, 익숙함은 Eclipse가 더 우세합니다. 당연한 이야기겠지만, Eclipse가 기존에 사용되어지는 바람에 서점의 대부분 책들은 아직도 Eclipse만을 설명하고 있습니다. Android Studio에 대한 책은 아직도 찾지 못했습니다. 거기에 따른 여파로 Android Studio에 대한 한국어 커뮤니티도 Eclipse에 비하면 작은 편 같습니다. 다들, 넘어가야한다는 것은 알고 있지만(구글이 Android Studio를 만든 이상 결국 이 것이 표준 개발툴이 될 것임은 당연해 보입니다.) 그동안 써온 습관과 익숙함 때문에 벗어나기 힘들다고 하는군요. 무엇보다 새로 배워야 한다는 부담감도 꽤 있는 듯 합니다. 같은 JAVA코드를 이용하지만, 인터페이스 자체가 다르다보니 생기는 문제라고 할 수도 있습니다.

지금으로썬 Eclipse가 편하다면 Eclipse를 써야겠지만, 결국 Android Studio가 자리를 잡게 되면 이것을 쓸 수 밖에 없는 날이 올 것입니다. 아니면 구글이 또 다른 IDE를 내놓을 지도 모르고요. IDE를 사용하는 것은 개발자 마음이지만, 사용자들은 새로운 기능이 나오면 이 기능을 이용하려고 합니다. 앱 개발자도 엄연히 말하자면 장사꾼이니까요. 장사꾼은 소비자가 원하는 것을 충족시켜줘야 물건이 팔립니다. 해당 앱의 미래를 위해서 제 생각에는 Eclipse로 개발된 앱을 Android Studio에서 바로 끌고 올 수 있었으면 좋겠습니다. 그런 방법이 있을 지는 잘 모르겠지만요.

Android Studio가 현재는 불안정한 모습도 보이고 있지만 Eclipse를 대체할 것은 확실해 보입니다. 기존 JAVA IDE가 아닌 안드로이드 전용의 IDE인 것도 한몫하고 있고, 그만의 특수기능도 가지고 있습니다. IDE와 통합된 테스트 환경이라는 것이 정말 편리하고 또 생산성도 월등히 향상시킵니다. 구글이 Android Studio의 안정화가 완료했다는 소식이 들려온다면 저도 지금 하는 프로젝트를 Eclipse에서 Android Studio로 옮길 예정입니다. 

과연 Android Studio는 Eclipse를 확실히 밀어내고 독보적인 IDE가 될 수 있을까요? 아니면 그동안 써온 IDE라는 장점을 안고 Eclipse가 계속 안드로이드 개발도구의 1인자가 될까요? 그것은 시간이 알려줄 것입니다.

2015. 10. 26

이 글이 적은지도 약 1년정도 지났군요.

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20150628150257

현재 Eclipse 기반의 ADT는 지원이 종료됩니다. 그냥 Android Studio를 쓰는 것이 제일 낫습니다. 이제 버그도 많이 없어졌고 상당히 편리해졌습니다. NDK지원도 잘된다고 하니(Windows에서는 간간히 문제가 있다고는 하지만...가상머신이나 멀티부트로 우분투 깔면 해결됩니다.) 이제는 Android Studio를 쓰시면 됩니다.

1위는 구글 2위는 다음 3위는....하나코게임즈? 그나저나 장동건을 검색해 들어오신 분은 뭐지?

오늘만 잡담 글을 2개씩 올리네요. 일하기 싫어서 그런 건가... 이제 글이 30개 남짓한 작은 블로그인데 생각보다 재미있는 유입 결과가 올라와서 보여드립니다.

유입경로 4위부터는 그다지 영향도 없고 재미도 없어서 가렸습니다. 1위부터 3위를 보시면 보통의 다른 블로그와 다른 것을 아실 수 있습니다. 바로 네이버를 통한 유입이 전혀 없다는 것인데, 블로그 많이 하신 분들이라면 검색 누락이라고 생각하실 것입니다. 네, 검색 누락 맞습니다. 그런데 사실 저는 네이버가 좋아할만한 글은 하나도 올리지 않았습니다. 네이버가 좋아할 만한 키워드로는 '아이돌'.'연예인','아이폰', '삼성전자','정치권이야기' 이런 것인데요. 저는 네이버가 좋아하지도 않고 사람들이 별로 찾지도 않는 우분투관련 글만 올려대고 있으니 좋아 할 리가 없습니다. 네이버에 검색 요청을 하는 것도 생각했는데 이제 30개 남짓 올라온 블로그에 요청하는 것도 웃기고, 설사 걸린다고 해도 그것이 바로 방문자 증가로 이어질지는 미지수 입니다. 보통 리눅스를 쓰시는 분들은 대개 구글을 이용하시는 경향이 많다보니 저는 구글만 믿고 가야 할 것 같습니다.

3위가 조금 독특한데, 8명뿐이기는 하지만 hanakogames포럼에서 들어오신 분들은 오직 저의 글 중 Long Live The Queen을 안드로이드 포팅하기http://moordev.tistory.com/20 을 위해 손수 들어오신 분들입니다. 어떤 분이 가이드를 알려달라고 해서 링크를 걸었거든요. 대신, 영작은 어려우니 구글번역기를 쓰라고 하면서요.(그 분이 욕 했을지도 모르겠네요. 영어로 실컷 자랑했으면서 정작 가이드는 한국어로 하다니) 실제 그분이 구글번역기를 쓰셨을 지는 잘 모르겠지만, 글 마지막에 포팅 영상을 같이 올렸으니 그것을 보셨을지도 모르곘습니다.(그런데 그것조차도 한글 환경에서 찍은 영상...)

해당 포럼에 가면 아이패드에 포팅(제대로 된 라이브러리도 없는데?)한 분도 있더군요. 굳이 제 글을 보시지 않았을 지도 모르겠습니다. 티스토리에서 유입 국가는 지원을 안 하니 조금은 답답하네요.

구글 검색에 상단에 걸릴만한 방법은 네이버와 다르게 딱 하나밖에 없다고 하네요.

그냥 좋은 글을 잔뜩 쓸 것.

이 블로그를 구글만 믿고 가기로 한 이상 좋은 글을 더 양산하도록 노력해야겠습니다.

저는 그렇게 건실한 것은 아니지만 꽤 오랫동안 운영(?)해 왔던 다음블로그가 있습니다. http://blog.daum.net/moor

하지만 저는 다음 블로그가 약간 제 손으로 못 만지는 곳이 너무 많은 것 같아서 티스토리로 작정하고 옮겨왔지요. 그런데 티스토리는 티스토리대로 문제인 것이 만질 곳이 많아지자, 제가 손을 대기 귀찮아졌다는 것입니다. 기본 스킨 그대로 이용하는 것을 보시면 너무 나도 쉽게 아실 수 있습니다. 아 조금 폰트크기를 키울 필요는 있겠네요. 모바일에서 보니 약간 답답한 면도 보이니까요.

사실 다음블로그에서 글을 써본 결과 이상할 정도로 해외에서 스팸성 트랙백이 자꾸 걸렸습니다. 이유를 알고 보니 다음블로그는 새 글이 올라오면 각종 봇 들이 주르륵 훑고 지나가더군요. 검색엔진 봇도 아니고 처음 보는 괴상한 봇도 나타나던데 그게 원인이 아닌가 싶었습니다. 그 외에도 글을 관리하기 힘들고 제가 그냥 수첩에 끄적이듯이 글을 적다 보니 제대로 된 글은 별로 없었습니다. 그나마 그럭저럭 제대로 쓴 글은 

http://blog.daum.net/moor/37 (이것은 새로 스크린샷 찍고 영상을 찍어서 가져왔습니다.)

http://blog.daum.net/moor/107 (Ren'Py 안드로이드 포팅 글 새로 쓰면서 기존 다음블로그는 비공개 처리)

http://blog.daum.net/moor/102 Cups+Sane 프린트+원격스캔 서버 만들기 정리 후에 가져올 예정.

수많은 글 중에서 쓸 만한 글은 대충 이 정도 뿐.

굉장히 공은 들였지만 그저 일기 형식으로 써서 다른 사람들에게 별로 도움은 안되는 글

http://blog.daum.net/moor/45

http://blog.daum.net/moor/50(내 생각에 거의 삽질이 블록버스터 급인데 현재는 별로 도움 안되는 글)

http://blog.daum.net/moor/106 삽질 하다 포기함. 그냥 다른 물건을 구하는 것이 100배 나음.

난 참 글 쓰는 재주는 없다는 생각이 듭니다. 조금 더 다른 사람을 배려하듯이 써야 하는데 제가 편한대로 글을 쓰다 보니 그 수많은 글 중에서 건질 것이 전혀 없네요. 어쨌건 블로그에 제대로 된 정보성 글을 올리기 위해선 아무런 글도 올라가지 않은 깨끗한 상태의 땅이 필요했습니다. 그러다 티스토리가 눈에 띄인 것이고요. 네이버블로그도 있지만 여긴 다음보다 더 했으면 더 했지 덜 한 곳은 아니라서 그냥 깔끔하게 접었습니다. 티스토리에는 전문성 있는 글들이 자주 올라오는 곳이니, 저도 이 대열에 한 번 끼일 수 있었으면 좋겠습니다.

이상 MoorDev 올림.

한 때 잠깐이나마 마이크로소프트는 Flash의 대항마 격인 웹 플러그인을 발표합니다. 그 이름이 Silverlight입니다. 은빛이라는 한국말로 바꾸면 꽤 예쁜 이름이지만, 이 실버라이트는 결국 Flash라는 거대한 벽을 넘지 못하고 버려진 자식이 되어버립니다. Windows8의 IE지원 대상에서 빼버린 것이지요. 실버라이트를 이용해서 동영상을 서비스해 주는 곳도 일부 있었고(SBS, 다나와 리뷰 등), 일부 사이트에서는 Flash처럼 멀티업로드용으로 쓰기도 했습니다. 그런데 사람들에게서 이미 잊혀진 존재가 되어가다보니 해당 사이트들도 Flash로 바꾸거나 아니면 전혀 다른 방식으로 서비스를 시작했습니다. 이렇게 실버라이트는 사라지는 듯 했습니다.

그런데 이 시점에서도 실버라이트를 버리지 못한 불행한 사이트들이 많이 남아 있습니다. 실버라이트가 마이크로소프트를 통해서도 지원 받지 못하는 마당에 답답한 노릇입니다. 이 사이트들이 정신을 차리고 다른 방법으로 바꾸기 전까지는 우리는 어쩔 수 없이 실버라이트를 써야만 합니다. 사실 실버라이트가 윈도우를 쓰다 보면 자연스레 설치되는 놈이라 자연스럽게 쓰는 것일 수도 있습니다. 그런데 마이크로소프트도 지원을 끊은지 오래인데 아직까지 실버라이트를 고집하는 배짱은 대체 무엇일까요?
(제 생각에는 그냥 똥배짱입니다. 시스템을 바꿀 자금이 부족하거나)

그런데 우분투에서 어떻게 마이크로소프트의 실버라이트를 쓸 수 있을까요? 방법은 두 가지가 있습니다.

1. moonlight라는 실버라이트 호환플러그인을 설치한다.http://www.mono-project.com/Moonlight

2. Pipelight로 실버라이트를 Wine과 조합해서 플러그인을 구동한다.http://pipelight.net

1.경우는 속도는 빠르지만 실버라이트3까지 완벽 지원이며 실버라이트4는 일부 호환입니다. 실버라이트가5까지 나왔다는 사실을 아는 사람은 별로 없는 것 같네요. 적당히 구동은 되지만 저 일부 사이트들 중에서 실버라이트5를 요구하는 (망할)사이트가 있어서 어쩔 수 없이 2.의 방법을 써야 할 것 같습니다.

일단 실버라이트5가 리눅스환경에서 무사히 구동이 된다는 것에서 안심을 해야 할 것 같네요. 참고로 PipeLight는 Windows용 Flash플러그인도 구동지원됩니다. 리눅스용 Flash가 10.x에서 멈춘 지금, 최신플러그인을 요구 할 경우 대용으로 쓸 수 있습니다. 물론 구동 속도는 보장 못합니다. 

Pipelight를 한번 설치해서 Silverlight를 구동해 봅시다. 우선 Pipelight를 설치해야겠지요?

우선 터미널을 열고 다음과 명령을 순차적으로 내립시다.

sudo add-apt-repository ppa:pipelight/stable
sudo apt-get update
sudo apt-get install --install-recommends pipelight-multi
sudo pipelight-plugin --update

첫 번째 명령어는 PPA를 등록하는 명령어 입니다.

두 번째 명령은 새로운 패키지 리스트를 가져오는 명령어 입니다. 즉, 패키지 리스트에 Pipelight를 가져오는 과정입니다.

세 번째 명령은 Pipelight를 설치하는 명령어입니다. --install-recommends 옵션은 같이 추천하는 패키지를 설치하란 것입니다. 이 때 Pipelight 전용 Wine이 설치됩니다. 브라우저 플러그인 전용으로 특화된 Wine입니다.

네 번째 명령어는 플러그인 업데이트 리스트를 받아오는 명령어입니다. 사실 이 순간에도 새로운 플러그인이 지원이 될 가능성이 있습니다. 최근의 Pipelight는 Unity3D Web Player도 지원이 되더군요. 이제는 웹 게임도 우분투에서 3D로 구동할 수 있다니 무서운 세상이군요.

이제 실버라이트를 활성화 해봅시다. 같은 방법으로 Flash도 활성화 가능한데 이것도 터미널을 이용해야 합니다. GUI가 아직 지원이 될 가능성은 없어 보이기 때문에 어쩔 수 없습니다. 터미널과 친해지는 수 밖에 없습니다.

sudo pipelight-plugin --enable silverlight

끝입니다. 이제 Firefox나 Chrome에서 실버라이트를 사용하는 (망할)사이트에 들어가면 잠깐 Wine구동 메시지가 뜨더니 실버라이트가 작동하는 것을 보실 수 있을 겁니다. 만약 해당 사이트가(정말로 망할)OS차별을 한다면 Agent Switcher같은 확장기능을 써서 Windows로 속이시면 간단합니다. (실버라이트는 원래 브라우저 구별은 안 합니다. 단지 Windows에서만 된다는 것이 문제입니다. 그런데 이것 때문에 웹디자이너분들이 Windows외의 OS접근을 막는 경우가 종종 있습니다.)

비슷하게 Flash 11이상 버전을 요구하면

sudo pipelight-plugin --enable flash

이렇게 해주시면 됩니다. Firefox야 문제 없는데 Chrome은 자체 내장 Flash때문에 고생을 한다네요. 어차피 Chrome내장 Flash는 버전이 높으니 굳이 pipelight를 통하지 않아도 됩니다. Firefox를 이용하시는 분들이 이용해 주시면 좋을 것입니다.

http://pipelight.net/cms/installation.html

Pipelight에 우분투 계열 외의 다른 OS나 실버라이트,Flash외의 다른 플러그인을 설치하실 분들은 위의 주소로 가시면 자세히(영어로) 설명되어 있습니다. 

이미 버려진 기술인 실버라이트를 쓰기 위해서 이런 삽질을 해야만 한다니, 정말 짜증이 올라오는군요. 그런데 어쩌겠어요. 해당 사이트를 안 쓸 수도 없는 노릇이고 그렇다고 굳이 윈도를 부팅하기는 더더욱 싫으니 그냥 이렇게라도 써야지요. 역시 오늘도 우분투는 삽질입니다.

저번 포스팅에서는 NDS 에뮬레이터에 대해서 포스팅을 했습니다. 우리나라에 NDS가 들어오던 시절에 또 다른 휴대용 게임기가 있었지요. 바로  PSP입니다. 제가 처음 PSP란 놈을 봤을 때가 아마 2000번대였던 것으로 기억합니다. 1000번대가 나오던 시절에는 제 친구들과 주변인 모두 가난한 학생이었고 굳이 PSP를 사야겠다는 생각이 들 정도로 재미있는 게임은 없었습니다. 즉, 견인차 역할을 해주던 메인 타이틀이 없었던 것이지요. 

그러다가 한국에서 견인차 역할을 해준 대중적(?) 게임이 하나 등장하게 됩니다. 그 물건이 바로 DJMAX Portable입니다. 저번 NDS 에뮬레이터 이야기에서 포켓몬스터가 주류로 나왔다면 이번 PSP에서는 이것이 주류로 나올 것입니다. 몬스터 헌터나 페르소나 시리즈도 PSP의 견인차 역할을 하기는 했지만 제가 Djmax portable나오기 이후의 이야기인데다가 제가 처음 PSP란 놈을 본 것도 다 DJMAX Portable시리즈 때문에 PSP를 사 들고 나타난 놈이 있어서 이 게임을 테스트 게임으로 삼아야 할 것 같습니다.

우선 에뮬레이터 이야기 하기 전에 게임기 이야기를 마저 하자면 PSP도 NDS 마냥 지하철 한 칸에 여러 사람이 들고 있지는 않아도 최소한 지하철을 생각 없이 돌아보면 들고 있던 사람이 보이는 그런 수준으로 꽤 많이 팔린 게임기 입니다. DJMAX Portable 출시 이후로는 학생들도 심심찮게 들고 다니는 모습이 많이 보이더군요. 그 뒤에 판매량이 좋아지고 2000번대와 3000번대 등의 신제품들이 나오면서 PSP도 휴대용 게임기로서의 역할을 충실하게 하게 됩니다. 물론 스마트폰들이 등장하면서 NDS와 함께 보기 힘들어진 같은 운명을 걷게 되기는 합니다. 하지만 역시 NDS와 마찬가지로 게임들 자체는 상당히 재미있는 것들이 많아서 인기 있던 게임기라면 통과의례로 겪는 에뮬레이터들이 만들어지게 됩니다. 그러나 구조가 비교적 간단했던 NDS와는 다르게 PSP는 생각보다는 복잡했던 모양입니다. 애초에 기기 성능도 조금 더 높고 게임 데이터 양도 훨씬 더 많아서 그럴 수 있겠다는 생각도 들지만 각종 홈브류(게임기 제작 업체로 부터 인증받아 정식 판매되는 승인된 게임이나 프로그램이 아닌 개인이 만들어낸 게임과 프로그램)들이 개발되는 것과 비교해서 에뮬레이터 개발은 비교적 늦은 편입니다. 그러다 어느날 한 에뮬레이터가 등장하게 됩니다. 그 이름은 Jpcsp입니다.

Jpcsp의 초기 화면 여느 프로그램 마냥 간단한 화면이다. 그런데 일부 라이브러리가 인식이 안 되서 구동하는데 조금 애먹었다.

PPSSPP 이야기 한다면서 갑자기 왜 Jpcsp 이야기냐고 하시는 분이 있을 것 같아서 말씀드립니다. 사실 PPSSPP가 지금의 호환성과 성능을 갖추게 되기 전까지 PSP에뮬레이터는 이 물건이 전부였습니다. 그리고 이 Jpcsp가 갖고 있던 문제는 PPSSPP가 해결하는 수순으로 갔고요. Jpcsp가 없었다면 지금의 PPSSPP가 나왔을 것이란 생각은 하기가 어려울 수도 있습니다. 그리고 다른 PSP에뮬레이터가 있었기는 했지만 이 물건이 가장 호환성이 좋았습니다. 다른 에뮬레이터는 그저 홈브류 개발 및 테스트용으로 만들어져서 홈브류를 구동하는 수준이었습니다. 하지만 Jpcsp는 본격적으로 정식 판매되는 UMD를 지원한는 에뮬레이터였습니다.

그런데 Jpcsp는 초기 단계라서 그런 것인지 문제가 여기저기서 터져나왔습니다. 이를 해결 하기 위해 정말 많은 사람들이 머리를 싸맸습니다. 지금은 Jpcsp의 태생적으로 해결이 안되는 것도 있고 PPSSPP가 해결한 문제도 있습니다.

첫번째 문제는 오디오코덱 문제입니다. PSP는 소니의 코덱기술을 사용하고 있는데 이것이 저작권 및 특허가 걸려있어서 에뮬레이터 개발에 문제가 되는 것이었습니다. 어느 분들은 에뮬레이터인데 그냥 가져다가 쓰면 안 되냐는 사람도 있을 지도 모르겠지만 에뮬레이터는 불법이 아닙니다. 하지만 특허가 걸린 기술을 가져다가 마음대로 사용하면 그 프로그램 자체가 불법으로 낙인 찍힙니다. 아니면 로열티를 내야 하는데 소니가 에뮬레이터의 로열티를 받으면서 허용해 줄 것 같습니까? 그래서 Jpcsp는 한동안 소리없이 에뮬레이터를 작동시켰어야만 했습니다. 이후의 사운드포지(소니가 만든 프로그램입니다.)의 라이브러리를 이용해서 우회하는 방안을 통해 재생시키는 법을 이용했지만 소리는 나와도 거의 누더기마냥 돌아가는 방식이라 가뜩이나 떨어지는 성능에 성능을 더 떨어뜨리는 방법이었습니다. 게다가 리눅스나 MacOSX는 써먹지도 못하는 방식이었고요. 지금도 오디오 코덱은 해결이 안 된 것으로 알려져 있습니다. 그런데 PPSSPP는 우회 리버스 엔지니어링으로 해결했다고 하네요?

두번째 문제는 자바로 만들어진 것입니다. 자바로 만들어서 여러 OS를 한번에 지원해주지만 문제는 자바이기에 속도가 C나 C++로 만들어진것에 비해 상당히 떨어집니다. 이 문제가 아까의 오디오코덱문제와 합쳐져서 엮이면 극악의 성능으로 바뀝니다. 요즘이야 PC성능이 좋아서 이 마저도 씹을 수 있을 정도지만 기기의 최고 성능으로 끌어내야할 게임이란 소프트웨어가 성능이 떨어진다면 문제가 많은 것이지요. 그래서 사람들은 C나 C++로 개발해달라고 아우성이었지만 Jpcsp가 원래 자바로 만든 에뮬레이터라는 뭔가 상당히 Geek스러운 물건이라 굳이 C로 다시 만들 이유야 없었습니다. 잠시 PCSP라는 C++로 만들어진 물건도 나왔지만 이것은 호환성이 너무 떨어져서 그대로 묻혀버렸습니다.

Jpcsp에 비해 빠르지만 호환성이 너무 떨여저서 묻힌 에뮬레이터 PCSP 이마저도 PPSSPP의 등장으로 2012년 이후 업데이트 중단이다.

세번쨰 문제는 오픈소스가 아니라는 것입니다. JAR파일 형태로 배포하기 때문에 만약 개발자가 때려치면 이 에뮬레이터의 수명은 그대로 끝이 나게 됩니다. 에뮬레이터의 특징 상 누군가가 소스를 받아주지 않으면 그냥 사라지는 것입니다. 위의 PCSP도 소스코드에 대한 이야기는 없는 것으로 보아 오픈소스가 아닌 것으로 보입니다. 오픈소스라면 묻히더라도 나중에 누군가가 다시 발굴해서 써먹을 지도 모를 일이고 다른 프로그램에 일부로써 쓸 수도 있습니다. 하지만 에뮬레이터라면 묻힐 일이 거의 없기도 하지요.

이러한 기존 Jpcsp의 문제를 극복하고 해결한 에뮬레이터가 바로 이번에 주인공인 PPSSPP입니다.

PPSSPP의 타이틀화면 다른 에뮬레이터랑 다르게 화려한 편이다. 그리고 오픈소스라는 것을 강조하기 위해 GPL이라 찍혀있는 것이 선명하다.

이 물건은 앞의 Jpcsp와의 차이가 큰 물건입니다. 앞에서 말했던 성능문제를 C/C++로 개발함으로써 해결했고 오디오코덱을 리버스엔지니어링을 통해서 저작권 및 특허를 회피했으며(이는 처음부터가 그랬던 것은 아니고 업데이트 하면서 해결했습니다.) GPL을 적용해서 배포한 오픈소스 프로그램입니다. 한번에 Jpcsp의 문제를 전부 해결했습니다. 이 에뮬레이터가 나오면서 게임을 즐기기위해 Jpcsp를 돌렸던 사람들은 전부 PPSSPP로 넘어왔다고 합니다.Jpcsp는 게임을 즐기기 보다는 자바로 만들어진 것이라는 그 사실이 워낙 특이하고 재미있어서 나온 것이니 Jpcsp가 묻힐 일은 없지만, 대세가 아무래도 PPSSPP로 넘어갔다는 사실은 확실히 와 닿는 것 같습니다.

그리고 PPSSPP가 Jpcsp뿐만아니라 다른 에뮬레이터와 차이를 보이는 것이 하나 더 있는데 그것이 바로 Android버전의 계획입니다. 다른 에뮬레이터는 안드로이드 버전과 PC버전을 다른 프로젝트로 생각하는데 비해(DeSmuME와 nds4droid, PCSX와 PSX4droid, FinalburnAlpha와 aFBA의 관계와 비슷합니다.)PPSSPP는 안드로이드버전도 같은 프로젝트 내에서 개발합니다. 즉, PPSSPP의 PC버전이 0.9.8이면 안드로이드 버전도 동시에 0.9.8로 업데이트 되는 것입니다. DeSmuME의 업데이트 이후 시간이 지난 후에 nds4droid가 업데이트되는 것과는 차이가 납니다. 덕분에 안드로이드에서 PSP게임을 돌릴 수 있게 됨으로써 지하철에서 보기 힘들어진 PSP는 스마트폰에 의해 또 다시 밀리게 됩니다. 그런데 이미 팔릴만큼 팔렸고 더 이상 소프트웨어도 안 나오는 판국에 밀릴 것도 없기는 하지만 PSP용 게임이 다시금 수요가 생길 지도 모른다는 생각이 드네요.(그것이 거래량에 추가 될지는 미지수이기는 합니다.)

그러나 같은 프로젝트 내에서 같이 업데이트되는 안드로이드와 PC버전은 코드가 약간 다른 것인지 소프트웨어 호환면에서 약간 차이를 보입니다. 일부 게임의 경우 PC버전에서는 구동이 잘 되지만 안드로이드에서 구동이 안 된다는 사람들이 많으며 반대로 안드로이드에서는 구동이 잘 되는데 PC에서 안 된다는 게임도 있습니다. 이것이 Arm과 x86의 차이일지 아니면 코드가 다른 것인지는 조금 살펴봐야 알 것 같지만, (일부의 소스코드가 다른 듯 합니다.안드로이드에서 무사히 구동하게 위해 코드 최적화를 하면서 차이가 생긴 듯 합니다.) 오픈소스이니 잦은 업데이트로 해결 할 수 있을 것이라고 믿습니다.

안드로이드와 PC 모두 잘 돌아가는 대표적인 게임 DJMAX Portable 2

PC에서는 잘 돌아가는 반면 안드로이드에서는 돌아가지 않는 DJMAX Portable 3 같은 시리즈지만 구동면에서도 차이가 있다. 2015.5 지금은 안드로이드에서도 무지하게 잘 된다...

안드로이드 버전에서는 써본 결과 터치 인터페이스가 상당히 불편합니다. 원하는 곳으로 이동이 안 될때가 있고 액션 게임의 경우에는 컨트롤 미스로 게임을 던져 버리고 싶을 때도 있더군요. USB-OTG를 지원하는 스마트폰이라면 그냥 조이패드를 붙여서 개임을 하던가 아니면 알아서 적응을 해서 게임을 하는 수밖에는 없을 듯 합니다. 특히 PSP는 워낙 버튼이 많아서 NDS게임을 스마트폰에서 하는 것에 비해 답답한 면이 많습니다.(NDS게임에는 대개 액션보다는 터치 게임이 많은 것도 한몫 합니다.) 이는 PPSSPP의 잘못이 아니기는 하지만 개인적으로 전용 컨트롤러를 하나 만들고 싶게 하는 수준입니다. 일반 조이패드를 끼우고 지하철에서 할 수는 없는 노릇이니까요.

버튼수가 너무 많아서 터치 인터페이스 자체를 거의 덮을 지경. 컨트롤 미스라도 나면 정말 화가 머리끝까지 난다.

하지만 내 학생시절 부러워 했던 PSP를 지금의 스마프폰에서 굴릴 수 있게 된 점은 상당히 마음에 듭니다. 특히 DJMAX Portable시리즈를 입맛만 다시고 제대로 한 적은 없는데(대신 PC버전인 Trilogy는 열심히 했습니다.)이제야 할 수 있게 되었네요. 누군가 그랬습니다."최고의 게임기는 PC"라고 그랬지요. 이제 한 문장 더 추가되어야겠네요. "최고의 휴대용 게임기는 스마트폰입니다."