삽질하는플머

유니티 테스트 1 - 위치댐퍼

여가생활/Unity,Mono&.Net
유니티에 익숙해져볼 요량으로, 델파이로 만들었던 가감속 댐퍼 객체를 C#으로 바꿔 이식해보았다. 
이번 3.5 버전부터 프리뷰로 들어간 플래시 출력을 한 번 걸어봤는데... 아주 아주 잘 되는군. 
가끔씩 튀는 경우도 있기는 한데... 초벌변환한 코드가 그렇지 뭐. 몇 번 손보면 안정화될 듯. 



유니티는 뭔가 눈으로 보면서 확인하며 코딩하는데 익숙한 내게, 귀찮은 3D 코딩을 털어버리고 알맹이에만 집중할 수 있는 환경을 제공한다. 
오래 전 도스에서 윈도로 넘어가던 시절, 윈도 하나 띄우려고 주절주절 읊어주어야 하는 API 목록에 질려 비베를 깔짝이다가 델파이를 만났을 때의 감동이 느껴진다.  게다가 처음 써 본 C#은 델파이와 마치 형제처럼 닮아있다. 

아직 익숙치 않지만 조금씩 친해지는 느낌이 좋다. 손에 익으면 정말 쓰기 편한 물건이 될 듯 하다. 
 

Unity 3D 설치. MonoDevelop 와의 첫 만남.

여가생활/Unity,Mono&.Net
Unity 3D 는 알게 모르게 어느새 대세가 되어있는 무시하기 힘든 멋진 물건. 
4월 8일까지 iOS, 안드로이드 빌드가 가능한 Basic 버전을 무료로 배포하는 통 큰 행사덕에 일단 다운받아 깔아보았다.
말로만 듣던 MonoDevelop 도 한번쯤 써보고 싶었고...

유니티와 함께 설치된 MonoDevelop 는 유니티용으로 필요한 것만 추린 물건이라 많은 부분이 비어있다.
윈도나 하나 띄워볼까 싶어 GTK 프로젝트를 생성하니 에러만 빠바방~  심지어는 디버거도 없다.  

일단 GTK# 부터 설치해보자. 
http://monodevelop.com/Download 

여기서 윈도 아이콘을 눌러주면  "GTK# for .NET 2.12.10" 을 내려받을 수 있는 링크가 나타난다. 




설치한 후 생성된 .NET 바이너리를 실행시키려면 GTK# 이 설치된 디렉토리에 PATH가 걸려있어야 한다. 
바로 적용되지 않으니 시스템->등록정보에서 환경변수를 한 번 확인해주거나 귀찮으면 그냥 재부팅 하자.

이제 MonoDevelop 에서 GTK# 프로젝트를 생성하고 GUI Designer 를 사용할 수 있다. 








유니티용 MonoDevelop는 유니티용으로 이런저런 설정이 추가된 물건이라 그런지 디버거도 빠져있다. 
어차피 유니티용이고 스크립트 작업시 디버거로 유니티 자체를 실행시키도록 되어있으니 빼버린 듯 하다. 
뭐 정 필요하면 독립적인 MonoDevelop을 내려받아 쓰면 될 일이고... 어차피 C#을 다른 곳에 쓸 일은 없으니 일단 패스. 
다만 일반적인 어플을 만들때와 달리 유니티에서 띄우면 Run 메뉴가 비활성화되고 Debug 메뉴만 살아있는 게 신기하군. 
유니티 프로젝트를 불러왔을 때 Reference 에 UnityEngine.dll 이 포함되어있는 것과 관련이 있는 듯. 



실제로 그런지 파보자. Hello World를 출력해주는 빈 콘솔 프로젝트를 시작하고 컴파일. 이 시점에서 Run 메뉴는 아직 살아있다. 




솔루션 브라우저에서 "References" 를 우클릭하고 "Edit Preferences" 메뉴를 선택한 뒤 ".Net Assemply" 탭에서 유니티가 설치된 디렉토리 아래 .../Editor/Data/Managed/ 폴더로 이동, UnityEngine.dll 을 선택한 뒤 Add버튼을 눌러준다. 



이 DLL을 포함시키는 순간, MonoDevelop의 Run 메뉴는 비활성화되고 Debug 메뉴가 활성화된다. 
UnityEngine 네임스페이스에 접근할 수 있으므로 UnityEngine의 자료형을 테스트 해볼 수도 있다. 

.....

UnityEngine.Vector3 vt = UnityEngine.Vector3.left;
Console.WriteLine ("{0}, {1}, {2}", vt.x, vt.y, vt.z);

...... 


실행버튼이 비활성화되어있으니 Ctrl+F8로 빌드하고 생성된 실행파일을 탐색기에서 직접 돌려보자. 



오호~~ 뭔가 감이 잡히는 듯 해~~

당연한 얘기겠지만, 이렇게 만들어진 실행파일은 유니티 프로젝트가 아니므로 실제 뭔가를 하는 것은 불가능하다.
틱을 얻기 위해 여기저기 찔러서 알아낸 다음과 같은 코드도 빌드는 되지만 실행시키면 에러가 난다. 

......
float f = UnityEngine.Time.realtimeSinceStartup;
Console.WriteLine(f);



그래도 유니티와 모노가 이렇게 연결되어 동작하는구나~~ 짐작하게 되었으니 이것만으로도 큰 수확!

 



실제로 간단한 코드를 만들어 디버깅을 걸어보자. 
델파이를 오래 쓰다보니 뭔가 하려면 무조건 GUI가 있어줘야 하는 부작용이 있네. 
기왕 이렇게 된 거, 유니티의 GUI 요소들을 직접 가지고 놀아보자. 

GUI 스크립팅에 대한 레퍼런스 메뉴얼은 여기 .
http://unity3d.com/support/documentation/Components/GUI%20Scripting%20Guide.html 

유니티 강좌는 여기저기 많이 있으니 자세한 설명은 패스. 
유니티를 실행하고 빈 프로젝트를 생성하고 프로젝트 창에서 우클릭, GuiTest 라는 C#스크립트를 생성하자.
이 스크립트를 더블클릭하면 MonoDevelop가 실행된다. 여기에 다음과 같이 코딩해준다. 

using UnityEngine;
using System.Collections;

public class GuiTest : MonoBehaviour {

void OnGUI () {
if (GUI.Button (new Rect (10,10,150,100), "I am a button")) {
float f = Time.realtimeSinceStartup;
print ("Time from Start: " + f);
}
}
}





이 녀석을 끌어다 Hierachy 에 외롭게 혼자 있는 MainCamera 에 던져넣자. 



 
"Main Camera" 를 선택하고 Inspector 를 살펴보면 방금 추가한 GuiTest가 아래쪽에 보인다. 

 

Ctrl+Shift+C 를 눌러 콘솔을 띄운 뒤 유니티 상단의 실행 아이콘을 눌러주자. 
Game창에 버튼이 하나 생겨나고 이 버튼을 누를 때 마다 콘솔창에 이 게임이 실행된 후 경과된 시간값이 초단위로 출력된다. 


 
이제 실제로 디버깅을 걸어보자. 유니티를 닫고 모노만 남겨둔다.

모노에서 Run->Debug 메뉴를 선택하면 유니티가 다시 실행되면서 디버깅이 연결된다. 
아까 스크립트의 실행을 연결해두었던 MainCamera 가 어찌된 일인지 사라져버렸다. 
뭐 GameObject->CreateOther->Camera를 선택해 다시 만들자. 
새로 추가한 Camera에 아까와 같은 요령으로 GuiTest 스크립트를 연결해주고 실행아이콘을 누른다. 
모노에서 Print (...) 부분에 F9키로 브레이크 포인트를 걸고 유니티의 게임창에서 Gui버튼을 눌러보자. 

 

 

게임 실행이 브레이크 포인트에서 멈춘다. GUI버튼도 눌린 상태로 멈춰있다. 
당연히 Watch도 잘 동작한다. Step Over 로 한줄씩 지나가며 상태가 궁금한 변수는 들여다 볼 수 있다.
함수가 있다면 Step Into, Step Out 으로 들락날락 할 수도 있다. 이정도면 뭐~~ 쓸만하다. 

하지만... 디버깅이 길어질 수록 유니티가 더럽게 느려진다는 게 문제. 그리고 디버깅을 하려면 유니티를 다시 띄워야 하는 것도 불만.
기존 작업중인 상태에서 직접 디버거를 연결할 수 있다면 자주 쓰겠는데... 이 부분은 좀 더 뒤져봐야겠다. 


덤.
느려지는 문제가 집에 컴터가 꾸져서 그런가 싶었는데... 회사에서 재연해보니 마찬가지임. 

 
 덤 2. 
아직 유니티 문서 보는데 익숙치 않아서 해메게 되네. 암튼 찾아보니 디버깅에 대해 잘 정리된 문서가 있다. 
http://unity3d.com/support/documentation/Manual/Debugger.html 

Assets -> "Sync ModeDevelop Project" 메뉴를 한 번 실행시킨다. 
모노에서 Run -> Attack to Process... 메뉴를 선택한 뒤 실행중인 유니티 프로세스를 골라주면 끝!!
이 방법은 개발버전으로 빌드된 결과물들을 디버깅 할 때도 동일하다. 
 
 

VMWare 에 Mac OS X Lion 설치하기.

여가생활/맥과 아이폰
맥북을 쓰고는 있지만 실제 작업을 할 때 사용하는 여러가지 툴들은 아무래도 윈도의 것들이 손에 익는다.
델파이 XE2 도 나왔고, 델마당에 s193382님이 번역중이신 멋진 강좌들에 감동받아서... VMWare에 라이온을 설치하는 과정을 정리해 본다. 





스탭 1. 설치 이미지 만들기. 

참조 사이트. 
http://www.sysprobs.com/create-bootable-lion-os-installer-image-vmware-windows-intel-based-computers
 
준비물. 
1. 라이온 10.7 설치어플에서 뽑아낸 InstallESD.dmg (참고링크1, 참고링크2)
2. 스노우 레오파드(이하 설범)가 구동중인 VMWare Workstation 또는 VMWare Player (참고링크)

 

1) 먼저 기존의 설범 가상머신에 5GB 하드를 추가로 만들어준다. 




2) 설범을 구동하고 디스크 유틸리티를 띄워 새로 추가한 5GB 하드를 다음과 같이 파티셔닝 한다. 
 

이름 - LionInstaller
포멧 - Mac OS 확장
파티션 - 1개의 파티션, Apple 파티션 맵



 
 

3) InstallESD.dmg 파일을 마운트한다. 이 파일은 "Mac OS X Install ESD" 라는 이름으로 /Volumes 에 마운트 된다. 




4) 이 경로로 이동한 뒤 BaseSystem.dmg 를 마운트 한다. 

# cd "/Volumes/Mac OS X Install ESD"  

# open BaseSystem.dmg 

 
 


 

5) "Mac OS X Base System" 이 마운트 되었다.  다시 디스크 유틸리티로 돌아가 방금 마운트한 이미지를 위에서 파티셔닝한 5GB 하드에 복원해 준다. 



 
루트 암호를 입력해주고 완료되기를 기다린다.  



6) 터미널에서 다음 명령을 통해 kernelcache 파일들을 복사해준다. 

# cp "/Volumes/Mac OS X Install ESD/kernelcache" /Volumes/LionInstaller/kernelcache 





7)  방금 복사한 kernelcache를 활성화 하기 위해 plist 파일을 편집한다. 
/Volumes/LionInstaller/Library/Preferences/SystemConfiguration/ 로 이동, com.apple.Boot.plist 파일을 텍스트 편집기로 열어 다음 내용을 추가해준다. 

<key>Kernel Cache</key> 
<string>\kernelcache</string>


이 작업에는 루트권한이 필요하므로 sudo vi, 또는 sudo nano 를 추천한다. 


  

 
8) 이제 설치 패키지를 복사할 차례이다. 터미널에서 다음 명령을 내려준다. 

# sudo rm /Volumes/LionInstaller/System/Installation/Packages 
# sudo cp -R "/Volumes/Mac OS X Install ESD/Packages" /Volumes/LionInstaller/System/Installation/Packages



두번째 명령은 상당히 큰 데이터를 VMDK로 복사하게 된다. 한참 놀다오는 편이 좋겠다. 



9) 거의 끝나간다. VMWare 의 경우 Mac OS X의 서버버전만을 지원하므로, 새로 생성된 설치 이미지를 서버 버전으로 표시해주자. 
터미널에서 다음 명령을 내려준다. 

# cd /Volumes/LionInstaller/System/Library/CoreServices 
# sudo touch ServerVersion.plist



이것으로서 다른 부트로더의 도움 없이 VMWare에서 부팅시킬 수 있는 라이온 설치 이미지가 만들어졌다. 




스탭 2. 라이언 설치 및 설정. 

참조 사이트
http://www.sysprobs.com/working-method-install-mac-107-lion-vmware-windows-7-intel-pc


준비물

1. VMWare Workstation 또는 VMWare Player
2. 스탭 1에서 만든 Lion OS X bootable VMDK 파일. 
3. 추가 파일. 아래 세 종류 작업의 묶음이다. 
  3-1. VMWare 에서 Mac OS X와 OS X 서버를 구동시킬 수 있는 패치 (원본 위치),  
  3-2. 미리 만들어진 가상머신 파일 (원본 위치). 
  3-3. 다양한 해상도 및 공유폴더 기능을 가진 VMWare tools 설치용 darwin.iso.



1)  추가 파일을 다운로드 받고, 여기서 macosx_guest_vmware_7.tar.gz 파일의 압축을 풀고 관리자 권한으로 명령 프롬프트를 열어 windows.bat 를 실행한다. 이 때 실행중인 모든 가상머신은 종료되어야 한다. 
 




2) Lion_107.zip 파일의 압축을 풀고 VMWare 에서 Mac OS X Server 10.6 64-bit.vmx 파일을 열어준다. 
VM -> Settings... 메뉴에서 앞에서 만들어준 5GB 짜리 Lion_Installer.vmdk 가상하드를 추가한다. 



메모리와 프로세서는 적당히 설정해준다. CD/DVD 은 "Auto detect" 로 맞춘다. 



3). 가상머신을 시작하면 자동으로 설치가 이루어진다. 첫번째 화면에서 언어를 선택해주고 설치를 진행하자. 




4) 설치가 완료된 후 5GB 가상하드는 제거한다. 이 가상머신에는 사운드카드가 설정되어있지 않으므로 추가해준다. 



darwin.iso 를 마운트, VMWare Tools 를 설치해준다. 




5) 아직 소리가 나지 않는다. 사운드 카드는 추가되었으니 드라이버를 설치해보자. 
다음 사이트에서 EnsoniqAudioPCI_v1.0.3_Lion.pkg 를 다운받는다. 
http://vmsvga2.sourceforge.net/

조금 느리기는 하지만 일단 소리 재생은 된다. 

그래픽 드라이버인 VMsvga2_v1.2.3_Common_Installer.pkg 도 기분상 설치해줬다.
내가 주로 사용하는 Quick Switch 모드에서 호스트 컴퓨터 해상도가 유지되는 장점이 있다. 화면도 왠지 부드러워지는 느낌. 



가상머신의 에너지 절약은 의미가 없으므로 "시스템 환경설정" -> "에너지 절약" 에서 "사용 안함"으로 설정한다. 




6) 마지막으로 소프트웨어 업데이트를 하면 설치는 마무리. 




7) 맥 앱스토어에서 Xcode 4 다운로드 및 설치. 
설치프로그램은 /Applications 에 들어온다. 다시 다운받기 귀찮으니 "Install Xcode.app" 을 적당히 압축, 보관해두자. 




8) 설범으로 오면서 생긴 문제라는데, 애플 자사의 시네마 디스플레이에서는 EDID 정보를 읽어내 제대로 된 폰트 서브픽셀 렌더링을 해주므로 LCD 모니터에서 폰트 가독성이 좋아지지만 일반 모니터에서는 그렇지 않단다. 어쩐지 맥북에서는 깔끔한 글자가 VMWare에서는 흐리멍텅하게 보이더라니... 
 
http://x86osx.com/bbs/view.php?id=osxtips&no=2584

LDC모니터를 사용한다면 위 링크를 참조, 콘솔에서 다음 명령을 내린 뒤 재부팅 한다. 말 그대로 신세경이네. 

# defaults -currentHost write -globalDomain AppleFontSmoothing -int 2



화면을 캡쳐해 확대해보면 서브픽셀 랜더링이 제대로 동작하는 것을 확인할 수 있다. 







부록. 탈옥 디바이스용 코드사인. 


테스트 프로젝트를 생성하고 타겟을 iOS Device 로 설정한 뒤 Cmd-B 로 빌드해보면, 다음과 같이 코드사인 에러가 나며 빌드에 실패한다.



Xcode에서 작성한 아이폰/패드용 앱을 실제 기계에 올리기 위해서는 개발자 프로그램에 가입해 일년에 99달러를 지불한 뒤 프로비저닝 코드를 받아 설치해야 하기 때문이다. 그러나 탈옥된 iOS 기기에 AppSync가 설치되어있다면 아래와 같은 방법으로 일단 돌려볼 수는 있다. 


응용프로그램 -> 유틸리티 -> 키체인 접근 을 실행하고 키체인이 "로그인"으로 되어있는지 확인한다. 
 



키체인 접근메뉴에서 "인증지원 -> 인증서생성" 선택. 다음과 같이 기록해 준다. 

이름 : iPhone Developer 
신원유형 : 자체 서명 루트
인증서유형 : 코드서명
기본값 덮어쓰기 : 체크. 




나머지는 모두 기본값. 유효기간만 한 10년 잡아주자. (3650일)

생성된 iPhone Developer 인증서는 X표시가 되어있음. 키를 더블클릭하고 "신뢰"를 펼친 뒤, 이 인증 사용시 (항상신뢰) 로 설정. 



/Developer/Platforms/iPhoneOS.platform/Info.plist 파일을 백업하고 편집, 

# cd /Developer/Platforms/iPhoneOS.platform/
# sudo cp Info.plist Info.plist.bak



파일 내의 XCiPhoneOSCodeSignContext 를 찾아 XCCodeSignContext 로 변경. (76, 111, 123 번째 줄)



다시 한 번 빌드해보면 방금 만든 인증서로 코드사인이 되는 것을 볼 수 있다.
(iOS Device용 실행파일은 Arm6/Arm7 바이너리가 하나로 합쳐진 FAT 바이너리이므로 코드사인이 두 번 이루어진다.)



Run 버튼을 눌러주면 탈옥된 디바이스로 실행파일이 전송된다. 



잘 동작하지만 애석하게도 디버깅은 되지 않는다.
실제 기계에서 디버깅은 생각보다 중요하므로 어지간하면 개발자 프로그램을 구입하는 편이 좋겠다.
(이 때, 앞에서 백업해 둔 Info.plist 를 원래대로 돌려놓는 것을 잊지 말 것!)



Xcode 3.2.5, iOS SDK 4.2 에서 파스칼로 코딩하기.

여가생활/맥과 아이폰
사실 이 글의 분류는 라자루스에 가깝지만... 자잘한 삽질이야기는 차차 하기로 하고 여기서는 그 결과만 공유해 봅니다. 
FPC for iPhone 의 동작원리 등 좀 더 자세한 이야기는 이후 하기로 하지요.  
제 블로그에서 존대말을 쓰려니 뻘쭘하지만... 삽질기가 아니기 때문에... ^^;  

프리파스칼의 위키에서 아이폰 SDK용 인테그레이션 키트에 관한 글을 발견한지 햇수로 2년이 흘렀습니다. 

이 키트는 당시에도 컴파일 한 번 해보려면 많은 삽질을 해야했는데, 그 이후 별다른 버전업이 없었기 때문에 최신 버전인 iOS SDK 4.2 에서 FPC를 쓴다는 것은 예전보다 훨씬 더 큰 삽질을 요구하게 되었습죠. 이때문에 많은 파스칼 사용자들이 부푼 꿈을 안고 도전했다가 절래절래 고개를 저으며 그냥 오브젝티브-C 로 자신의 코드를 다시 만드는 길을 선택하는 듯 합니다.  

하지만... 저는 거의 십년간 윈도에서 델파이와 OpenGL을 사용해 게임을 만들어왔습니다. 오브젝티브-C는 분명히 매력적이고 장점이 많은 언어지만 제가 작성해온 코드들를 오브젝티브-C로 다시 쓰기에는 너무 먼 길을 와버렸지요. 무엇보다 저는 파스칼로 생각하고 만드는 일을 즐거워하기 때문에 아이폰이라고 해서 이 즐거움을 포기하고 싶지는 않았습니다. 

그럼 시작해봅시다. 

먼저 애플에서 배포중인 최신버전의 Xcode를 설치합니다. 이 글을 적는 시점에서 Xcode는 3.2.5, iOS SDK는 4.2 로군요. 
그리고 프리파스칼의 위키에서 설명하는 대로 다음 두 개의 FPC 배포판을 차례로 설치하세요. 

FPC 2.4.0 for Mac OS X : ftp://ftp.freepascal.org/pub/fpc/dist/2.4.0/i386-macosx/fpc-2.4.0.intel-macosx.dmg 
FPC 2.5.1(r14397) for iPhone: ftp://ftp.freepascal.org/pub/fpc/snapshot/v25/arm-macosx/fpc-2.5.1v1.arm-iphone.dmg 
(tistory가 링크 앞에 자동으로 "http://" 를 붙이는군요. 자동링크 삭제합니다. 본문을 긁어 주소창에 넣어주세요. 광일님 죄송~~ ^^)

iPhone용 FPC를 2.4.0이 아닌 2.5.1 버전을 쓰는 이유는 이 버전부터 arm 컴파일시에 VFP라 불리는 수치연산 보조기능을 사용할 수 있기 때문입니다. 저는 게임을 만드는 것이 목적이기 때문에 선택의 여지가 없지요. 또한 "오브젝티브-파스칼" 이라는 해괴한 코드를 쓸 수 있다는 장점도 생깁니다만 여기서는 논외로 하겠습니다. 

FPC 설치가 끝나면 설치 스크립트가 iOS SDK의 경로를 물어옵니다. 문제는 이 FPC for iPhone이 iPhoneOS 3.1 시절의 물건이기 때문에 설치가 제대로 되지 않습니다. 때문에 스크립트를 고쳐 최신버전의 SDK를 인식할 수 있게 해야하지요. 저는 착한 프로그래머이므로 고친 스크립트를 첨부합니다. 

위 압축파일을 내려받아 /Developer/FreePascalCompiler/iPhoneSnapshot-2.5.1-r14397/InstallScript 에 풀어주세요. 이 스크립트를 실행시키면 뭐라 뭐라 좌르륵 떠들며 FPC 환경을 설치해 줄 것입니다. 

# cd  /Developer/FreePascalCompiler/iPhoneSnapshot-2.5.1-r14397/InstallScript
# ./finish_fpc_iphone_install.command


 


이제 Xcode를 실행시켜보면 "User Templates" 항목에 "OpenGL ES App (FPC) 2.5.1" 이라는 템플릿이 보입니다. 




그러나 이 템플릿을 기반으로 프로젝트를 만들면 빌드조차 되지 않습니다. VFP를 사용하는 FPC 컴파일스위치가 기본값으로 되어있어 시뮬레이터용 i386 빌드가 실패하기 때문입죠. 뭐 이후 제가 겪은 삽질은 미처 공개하지 못한 블로그의 행마다 절규하는 욕설로 그 처참함을 짐작할 수 있지만 생략하고... 저는 선량한 프로그래머인지라 지름길로 인도해 드리겠습니다.  

위의 파일을 내려받아 압축을 풀어 /Library/Application Support/Developer/Shared/Xcode/Project Templates 에 옮겨주세요. 다시 Xcode에서 새 프로젝트 메뉴를 클릭하면 다음과 같이 새로운 템플릿이 표시됩니다. 



(아이콘이 기분나쁘시다면 정말 기분탓입니다~~ ^^)

빌드해보시면~~ 시뮬레이터에서 얌전히 꿈틀거리는 사각형을 보실 수 있습니다. 



기존의 템플릿과 비교해 수정된 사항은 다음과 같습니다. 

1. 최신버전의 SDK에서 빌드되도록 하고 Deployment 옵션에서 대상 OS는 3.0으로 함. 
2. FPC 로고 애니메이션 대신 Xcode의 기본 OpenGL ES 템플릿과 동일한 화면으로 수정.  
3. 화면 갱신에 NSTimer 대신 CADisplayLink 를 사용. 
4. fpclogo.pas 를 MainUnit.pas 로 바꾸고, 의미를 혼동할 수 있는 glInit, glDraw 함수는 InitScene, DrawScene 로 변경. 
5. 파스칼 유니트에서 앱 종료시 데이터를 정리할 수 있도록 CloseScene 프로시저를 만들어 둠. 
6. Extended 를 사용하는 math 유니트의 삼각함수 대신 C런타임의 sinf, cosf 를 사용. 
7. 디바이스 릴리즈 모드의 팻바이너리 생성시 armv6, armv7 용으로 각각 다른 VFP옵션을 주도록 함. 
8. 앱 빌드 후 코드사인 전에 strip을 구동, 실행파일의 크기를 20~30% 정도 줄임. 
9. 타이틀바를 없애고 전체화면을 기본으로 함. 


아직 해결해야 할 문제도 있습니다.  

1. 릴리즈 모드의 팻바이너리에서 libfpc.a 를 중복해 만드는 문제. 
2. 아이패드용 템플릿도 필요하다. 
3. 그 외에는... 음... 생각나는 대로 추가할 예정... 



마지막으로, Xcode는 이미 파스칼에 대한 문법 하이라이팅을 지원하지만 이게 초창기 문법에 대한 것이라 실제 코딩하려고 하면 영 깨림직합니다. 




보시는 것 처럼 한줄주석도 제대로 처리되지 않고 Library 도 인식하지 못하지요. 

저란 놈은 지난번 허영일님의 세미나에서 딴지를 걸었듯, 문법 하이라이팅 없으면 어떤 코드도 만들기 싫어하는 게으름뱅이인지라... (오죽하면 윈도에서 오브젝티브-C 공부하려고 Dev-C++ 의 소스를 건드릴까요.) 다음 링크를 참조합시다. 


위 파일을 내려받아 /Developer/Library/PrivateFrameworks/XcodeEdit.framework/Versions/A/Resources/Pascal.xlangspec 와 바꿔치기 합니다. 결과는 다음과 같이 깔끔 그 자체입니다. 




이상으로 Xcode에서 파스칼로 OpenGL 랜더링을 하기 위한 삽질의 액기스만 뽑아보았습니다. 
템플릿에서 만들어준 MainUnit.pas 의 DrawScene() 프로시저에 원하시는 그림 그리기 코드를 넣어보세요. 


많은 일들이 있었지만... 이렇게 적어 놓으니 참 별것 아닌 길을 어렵게 걸어왔네요. 
아직 갈 길이 멀고 더 많은 어려움이 있으리라 짐작되지만... 파스칼에 혼을 빼앗긴 우리는 충분히 견뎌내리라 믿숩니다. 
파스칼 만세!




여기까지 해 보시고 궁금해하실 부분에 대해 몇가지 답변을 미리 달아둡니다. 

1.
build 디렉토리에 만들어지는 덩치 큰 libfpc.a 파일은 링크시 사용되며 실행파일에 통째로 들어가지는 않습니다. 안심하세요. 


2. 
FPC 는 PascalLibrary.pas 파일을 컴파일하고 그 결과를 오브젝트파일이 아닌 어셈블리 파일로 변환합니다. 이후 앱의 소스 컴파일 시점에서 이 어셈블리를 GCC로 컴파일하고 앞에서 만들어둔 libfpc.a 와 링크하지요. 때문에 프로젝트에 임의로 추가한 파스칼 소스는 '반드시' PascalLibrary 에서 참조되도록 해서 어셈블리 파일이 생성되도록 해야합니다. 안그러면 빌드시 다음과 같은 에러를 만나게 됩니다. 

... warning: '-x assembler-with-cpp' after last input file has no effect
... no input files
... failed with exit code 1

파스칼 코드를 추가한 뒤에는 MainUnit.pas 등의 uses 항목에도 꼭!! 추가해주세요.


3. 
다른 프로젝트와 마찬가지로 FPC도 뭔가 조금 이상하다고 생각되면 일단 Build->Clean 메뉴부터 실행시켜보세요. 


4. 
패키지 설치할 때 함께 들어있는 Readme.rtf 는 정말 주옥같은 정보를 담고 있으니 반드시 읽어보세요. 









어제는 제 둘째놈 백일이었습니다. 
이 글이 도움이되신다면 맘속으로 제 자식놈들 무탈하라고 한번씩 기원해주시와요~~ ^^; 


책장 넘기는 효과 구현하기 - 2.

여가생활/산수공부

이번에는 앞에서처럼 페이지를 왕창 접지 말고 아래와 같이 약간만 접어놓는다.




좌상단을 원점으로 하는 좌표계를 떠올린 뒤 마음속에 아래와 같은 선을 그어보면 재미난 규칙이 보인다.




좌상단 모서리 이동점이 페이지상 임의 위치 MvTL (x: c, y: b) 에 있을 때, 접힘양 a 는 피타고라스 정의에 의해 다음과 같은 관계를 가진다.



제곱근도 빠진 아주 간단한 1차식으로 위쪽 접힘점의 위치를 계산할 수 있다.

이제 접힘점에서 수직으로 내려진 파란선과 C변의 교점을 K 라고 하자. 또한 MvTL 점을 지나는 수평선과 좌변의 교점을 M 이라고 하자.




접힘점1 - MvTL - K 가 이루는 삼각형은 MvTL - 접힘점2 - M 이 이루는 삼각형과 닮은꼴이 된다.
따라서 다음과 같은 비례식을 세울 수 있다.




접힘점2의 위치는 원점에서 d + b 만큼 떨어진 곳이 된다.
타원으로 풀었던 방식에 비해 뭐가 이래~ 이렇게 쉬워?? 싶다. 역시 구조를 바꾸면 코드도 간편해지는 법.

고민해야 할 상황이 두가지 더 있다.
첫번째는 접힘점2 가 페이지 좌변이 아닌 밑변에 있는 경우, 즉 d + b 값이 페이지의 높이값 ph 보다 클 때이다.



이 경우 O - 접힘점1 - L 이 이루는 삼각형은 N - 접힘점2 - L 이 이루는 삼각형과 닮음이다.
점L 과 점O 의 거리는 위에서 구한 d + b 값이고,
점L 과 점N 의 거리는 d + b 에서 높이 ph 를 뺀 값이다.
따라서 구하고자 하는 점 N 과 접힘점2 사이의 거리를 e 라고 하면 다음과 같은 비례식이 성립한다.




그리고 두번째는 MvTL 이 페이지 위쪽에 있을 때, 지금 좌상단을 기준으로 한 좌표계에서는 b가 음수값이 될 때인데...
반복되는 설명이니 이 부분은 나중에 시간날 때 업데이트 하기로 하고, 결론부터 말해 다음과 같은 식으로 하단 접힘점을 구할 수 있다.




이상의 수식을 가지고 실제 코드를 만들어보면 바로 눈치채겠지만, 페이지상에는 MvTL 이 위치할 수 있는 범위가 정해져있다. 기본적으로 페이지의 우상단 기준으로부터 거리가 pw인 원 이내지만, 이 조건에 맞는 MvTL 값만으로 페이지의 접힘점을 계산하면 때로는 페이지가 찢어진 것 처럼 될수가 있다. 실세계에서 MvTL은 또 다른 움직이는 좌표인 좌하단 모서리 이동값 (이하 MvBL) 에 의해 영향을 받고 있기 때문이다. 따라서 타원에 의한 해법이건 비례식에 의한 해법이건, 유저의 입력에 대해 이 값을 그대로 적용할 수 없고 상호구속적인 두 절점의 적절한 위치를 결정해주어야 한다.

이 방법에는 책장넘김 효과를 구현하는 개개인마다 여러가지 선택이 있겠지만... 아무튼 내가 사용한 방법에 대해서는 3편에서 계속하기로 하자.