PUMPIT UP: Exceed의 PSP용 버전인 PUMP IT UP: Exceed Portable 제작 초기에 찍은 사진.
기본적인 PSP의 그래픽 성능을 테스트하고 물리적인 한계점을 체크하기 위하여 BGA엔진을 제일 먼저 이식하였다. 결국 메모리의 부족과 과도한 프레임 드랍으로 인하여 로우레벨쪽에 대대적인 수정이 가해졌지만 PSP 제작당시 처음으로 PSP에 띄웠던 제대로 된 화면이라 그 감회는 남다르다.
블랙잭을 이용하여 프로그램을 작성하던 도중 특정 구문을 수행할시에 Data Abort 에러가 발생하는 것을 확인하였다.
평소 Win32 용 프로그램만 작성해 보다가 처음 하고 있는 Windows Mobile 디바이스 작업이기 때문에 처음 보는 에러였는데, 구글을 통해 검색해 보니 대충 윈도의 잘못된 연산 수행이나, 리눅스의 Segmentation fault 와 비슷한 것이라는 얘기가 나왔다.
그런데 이상한 점이, 분명히 윈도용 프로그램을 개발할 때에는 잘못된 연산을 수행하면 즉시 그 부분에 브레이크가 걸리고 무엇이 잘못되었는지 표시가 되는데 여기서는 그렇지가 않다는 것이었다.
멈추지 않고 에러가 계속 발생한다.
나같은 초보 프로그래머들은 저 에러메시지만 보고서는 대체 무슨 에러인지도 모르겠고, 소스에도 의심가는 부분이 없게 된다면 무척이나 당황하게 된다.
결국 Trace 를 통해 문제가 되는 부분을 찾았는데, 전혀 이상이 없다. 해답을 찾아 삼만리..
결국 발견한 것은 다음과 같은 방법이다.
Debug>Exceptions 메뉴를 실행한다. 다음과 같은 창이 뜬다.
Win32 Exceptions
주의해서 봐야 할 부분은 여기 Win32 Exceptions 부분이다.
여기 체크된 예외만이 디버거 실행을 멈추게 되어있다. 기본값은 위와 같고 (물론 항목은 더 많다.) 잘 보면 기본적인 Access violation 이나 Illegal Instruction, Datatype misalignment 가 체크되어 있지 않은 것을 알 수 있다.
위 항목을 체크하고 OK를 눌러주자
멈추길 바라는 항목들을 체크
다시 프로그램을 실행하면 결과가 아까와는 조금 달라진다.
뭐가 달라졌을까?
과연 어떤점이 다를까.
아까는 볼 수 없었던 줄이 하나 추가 된것을 볼 수 있다.
First-chance exception at 0x00028048 in xxxxxxxx.exe: 0x80000002: Datatype misalignment.
그리고 훌륭하게 디버거는 문제가 발생한 지점에서 실행을 중단하고 메시지 창을 띄운다.
Datatype misalignment
Data Abort 를 일으킨 장본인은 바로 Datatype misalignment 에러였다.
자! 문제가 무엇인지 좀 더 분명해 졌다. 왜 이런 Exception 들을 기본으로 체크해 놓지 않았는지 의문이 생기지만, 어쨌든 해결하게 된 것 만으로도 기쁘게 생각한다. 이제 문제가 무엇인지 알았으니 이제 문제를 해결하기만 하면 된다! (아직 해결 안됐음)
Windows Mobile 용 프로그램은 자체 전원관리에 의하여 백라이트가 꺼지고 화면이 꺼지는 작동을 하게 된다.
만약 동영상 플레이어나 기타 프로그램을 만들 경우 백라이트가 꺼지지 않는 것을 원할 수 있는데, 다음과 같은 코드를 이용하면 된다.
// IN BOOL fBacklightOn - TRUE to keep the backlight on. void SetBacklightRequirement(BOOL fBacklightOn) { // The name of the backlight device. TCHAR tszBacklightName[] = TEXT("BKL1:");
static HANDLE s_hBacklightReq = NULL;
if (fBacklightOn) { if (NULL == s_hBacklightReq) { // Turn the backlight on by setting the requirement that the backlight device // must remain in device state D0 (full power). Replace D0 with D4 (zero power) to // turn the backlight off. s_hBacklightReq = SetPowerRequirement(tszBacklightName, D0, POWER_NAME, NULL, 0);
if (!s_hBacklightReq) RETAILMSG(1, (L"SetPowerRequirement failed: %X\n", GetLastError())); } } else { if (s_hBacklightReq) { if (ERROR_SUCCESS != ReleasePowerRequirement(s_hBacklightReq)) RETAILMSG(1, (L"ReleasePowerRequirement failed: %X\n", GetLastError()));
사이버 포뮬러라는 만화를 보셨거나.. 아니면 자동차 경주에 관심이 있으신 분들이 들어보셨을만한 Slipstream이라는 용어를 쓰고 있는게 재미있네요. 영어가 짧아서 저 문장 자체가 어떻게 해석되는지 잘 모르겠지만, Visual Studio 2005 를 설치할때 자동으로 Service Pack1 을 끼어들게 한다는 의미로 쓴것 같기도 하고.. 영어는 참 어렵네요?? (이게 결론??)
별로 그럴일은 없겠지만, 이렇게 설치한 SP1 은 따로 삭제할 수 없다고 합니다. 저는 이 글을 쓰기 전에 시키는대로 따라 해 보았는데, 이렇게 설치한 VS2005가 지금 잘 돌아가고 있습니다. Service Pack1 을 까는 악몽같은 시간이 없으니 정말 상쾌합니다.
XNA Game Studio Express 라는 XNA 개발환경을 일반에게 공개하기로 한 것입니다.
이 플랫폼은 Visual C# Express 2005 와 XNA Framework (DirectX + Managed Code) 를 기본으로 하는데, 중요한점은 무료라는 것이지요.
이를 통해 집에서 Xbox 360 을 겨냥한 게임을 개발할 수 있게 됩니다. (물론 C# 으로 해야 하지만)
지난 GDC 에서 Managed Code 로 개발한 바이너리가 Xbox 360 에서 돌아가는 것을 시연한 예도 있기 때문에 실제로 실현 가능한 예라고 볼 수 있습니다.
게다가 약간의 돈을 더하면 자신이 가지고 있는 (혹은 남의) Xbox 360 에서 돌아가는 게임을 만들 수 있게 됩니다.
XNA Creator's Club 이라는 것을 가입하면 되는데, 이것은 Xbox Live 가입의 일종으로 볼 수 있으며 이것을 통해 비상업적인 게임을 (XNA Framework에 기반한) 개발하기 위한 추가적인 도구들을 지원 받을수 있다고 합니다.
가입 비용은 1년에 $99, 혹은 4개월에 $49 가 될 것이라고 하네요.
아직은 Xbox 360 의 해킹이 제대로 이루어지지 않은 상황에서 Microsoft 는 이 옵션을 통해 수 많은 homebrew 개발자들을 음지에서 양지로 끌어낼 수 있을것이라고 생각됩니다.
게다가 XNA Game Studio Express 를 통해 Xbox 360의 개발에 익숙해진 개발자가 실제 상업용 게임을 내 놓을 상황도 충분히 가정할 수 있을 것입니다.
이른 예측이긴 하지만 Microsoft 가 이렇게 Xbox 360 의 개발환경을 퍼트리는데 노력을 기울인다면 Sony 의 PlayStation 3는 좀 더 많은 노력을 기울이지 않으면 PS2 때와는 달리 많은 고충을 겪지 않을까 합니다.
Java 소스나 바이트 코드를 CPU-OS Native Code로 컴파일 해준다는 GCJ 를 최근 알게 되었다.
GCC 컴파일러의 확장 기능인 셈인데, 이거 생각보다 꽤 재미있는 녀석인것 같다.
본인이 Linux 나 기타 *nix 계열을 안쓰는 고로 MinGW (Win32) 에서 테스트 해 보았다.
평소에 Java Language 를 전혀 안쓰는고로 JRE 등은 전혀 안깔려있어서, 그냥 무작정 MinGW 패키지만 집어다 설치했다.
쓰기는 생각보다 간단했다.
Hello, World! 를 출력하는 코드만 컴파일 해 봤다.
Hello.java
class HelloWorldApp
{
public static void main(String[] args)
{
System.out.println("Hello, World!"); // display the string.
}
}
gcj --main=HelloWorldApp -o hello.exe hello.java
이 정도면 hello.java 가 컴파일 되어 Win32 PE 실행파일로 떡. 하니 떨어진다. (하지만 무려 3.4MB, UPX 로 압축하니까 1.9MB 나온다. --strip-debug 도 안먹는다. OTL)
들리는 말로는 Eclipse 의 byte code 를 gcj 로 컴파일해서 쓸 수 있다고 하는데, 본인이 Eclipse 도 안쓰는 고로... 모르겠다 ;
개발자로써 (특히 게임 개발자로써) 느끼는 바는, 언어의 취지에는 심히 맞지 않겠지만 (high-portable 에 관해서는) java 언어의 장점을 살려서 native 코드를 생성하는 용도로도 충분히 괜찮지 않을까 하는 생각이 든다. (왜냐면.. byte 코드보다는 당연히 빠르니까!)
흔히 게임 본체를 생성하는 용도 외에, 개발툴을 만드는 용도로 C/C++ with MFC 가 많이 이용되고, 커맨드라인 툴에는 역시 C/C++/Python 등등이 많이 이용되는데, Java언어가 손에 익숙하다면 Java 언어도 충분히 괜찮지 않을까 ; (Swing 같은 GUI 툴킷도 컴파일된다면 금상첨화!)