작년 말에 gp32로 게임 작업할 때 회사 게시판에 정리했던 거 올려봅니다. (SDK 상의 주의점들은 수정된 내용들도 있을 거 같습니다.) 참고하세요
1. 4 byte align
4바이트 경계선을 침범하면 다운되어 버리는 치명적인 문제가 생깁니다.
char data[5] = { 0, 1, 2, 3, 4 };
int num;
num = *(int*)(data+1); // <- 다운됨
|
물론 아래처럼 4바이트 경계를 침범하지 않는 다면 캐스팅해서 사용해도 상관없습니다.
char data[5] = { 0, 1, 2, 3, 4 };
short num;
num = *(short*)(data+1);
|
사실 프로그래밍할 때 이렇게 까지 쓸 일은 별로 없지만, 파일 헤더라던가, 스크립트 바이트코드에 접근한다거나 할 때는 문제가 될 수 있겠죠. 이 경우에는 내부 변수에 복사해서 사용해야 안전합니다. (memcpy 는 적당히 잘 잘라서 복사)
char data[5] = { 0, 1, 2, 3, 4 };
int num;
memcpy(&num, (int*)(data+1), sizeof(int));
|
2. enum 은 4바이트형이 아니다
읽고 쓸 때 그냥 편하게 sizeof(...) 식으로 했다가 낭패를 볼 수 있습니다. PC 개발 환경에서는 4 바이트로 잡히지만, 제공되는 arm 컴파일러에선 1바이트로 나올 수 있습니다. (확인 결과 코드 워리어 환경도 마찬가지...)
3. / (float) 0
float 형으로 0으로 나누면 어플리케이션이 멈춥니다. 그런데 PC 환경에서는 #INF(무한)가 나오고 넘어가므로 따로 신경 써서 찾지 않으면 찾기가 힘들 수도 있습니다.
4. 예외 현상
잘못된 프로세스가 이루어지면 두 가지 반응을 보이는 데, 로고화면으로 튕기거나 멈춥니다. 메모리 관련 잘못된 연산은 전자의 반응을, 프로세스상 불가능한 예외현상이 연출된 경우에는 후자의 반응을 보입니다. (Data Abort 의 경우 예외에 대한 기본 설정이 리셋으로 되어 있는 거 같습니다.)
추가 :
5. T_T
이건 어떤 케이스에 생기는 문제인지는 모르겠습니다만 (결국엔 문제되는 부분만 해결했습니다.) 가끔씩 아래와 같은 경우에 d 가 65535 가 되는 경우가 생깁니다. (0xFFFFFFFF 여야 하지만 0xFFFF 라는....) 특별한 케이스에는 문제가 되는 거 같습니다. (구지 short로 해야 할 필요는 없는 놈은 int 형으로 바꿔서 해결...)
#include "gpmain.h"
#include
short abc;
void GpMain(void *arg)
{
int d;
abc = -1;
d = abc;
}
|
위의 루틴도 좀 추가해보면 제대로 되기도 합니다. 잘 나타나지는 않으니 걱정은 안 해도 되겠지만, 나중에 문제되면 한번 의심해보세요.
6. 기타
아래는 직접 체크 해보세요.
A. 실제로 사용되는 최대 프레임은 52.74 FPS 정도임
B. 사운드의 연주 속도는 실제 작업된 것보다 약간 빠릅니다. (정확한 수치는 출시되는 그날까지 측정 못했네요. 약 50/46정도...)
C. 게임파크에서 제공하는 파렛 관련 셈플은 (CreatePaletre... 류 - 메모리 leak 등 확인...) 가급적 사용하지 마시고, GpPaletteEntryChange 를 사용하세요.
댓글을 달아 주세요
너는 아름다운 웹사이트가 있는다!