- 안영기의 개발실 - (WIZ / CAANOO / bada)

OpenGL ES 2.0 샘플 (Android ver.)

2011-12-01T23:17:16+09:00

원래는 Android용 게임을 만들어 보려고 OpenGL Es 2.0을 이용하여 3D 및 스프라이트 등을 출력하는 기본 라이브러리를 만들고 있었다. 그렇게 시작한 것이 벌써 1년이 지났다.

하지만 시간에 쫓기다 보니 우선 순위에서 계속 밀리게 되었고 자칫하다가는 영원히 Android용 게임은 완성되지 않은 채로 프로젝트가 끝나지 않을까 하는 우려까지 하고 있다. 여전히 Android용 게임 제작은 전체 우선 순위에서 밀리고 있고(Java에 익숙하지 않은 탓과 Java로는 개인 라이브러리가 구축된 것이 없다는 것이 가장 큰 걸림돌이다) 끝까지 성공해낼 확률은 꽤 낮은 편이다.

이것은 가장 초기에 만들었던 출력 테스트 샘플이다. Cube가 제대로 도는지 확인 해본 것이고 shader로 vertex, diffuse color, texture 출력까지 만들어 본 것이다. 간단한 터치도 테스트 해보기 위해 터치를 한 위치에 cube가 돈다.

CubeSampleViewActivity.zip

Android용 OpenGL ES 2.0 출력 샘플 (44K)

프로젝트가 1.5 이상용인데, 너무 구형 프로젝트인지 실제로 import를 해보면 프로젝트 파일 관련 에러가 난다. 에러가 난 메시지로 구글에 검색해보면 프로젝트 파일 고치는 법이 나오는데, 그 방법을 써서 수정하면 된다.

동급생2 맵출력 샘플 (bada ver.)

2011-11-06T08:42:51+09:00

여느 때처럼 아침에 일찍 일어 났다. 하지만 오늘은 토요일이고 모처럼 회사를 안 가도 되는 토요일이다 보니 갑자기 시간이 너무 많아졌던 것이다.

딱 하루짜리 프로젝트를 해 보자는 생각에 15년 전에 한글화 할 때 끄적였던 리소스들을 꺼내어서 간단한 맵 출력 샘플을 만들기로 하고 아침에 app 개발을 위한 manifest.xml 을 발급 받았다. 그리고 오전과 밤시간을 이용해서 만든 것이 아래의 결과물이다.

십 몇 년 전에, 게제동을 통해서 DOS용으로 pascal과 asm을 이용해서 만들어서 소스를 공개했던 것인데 이것을 bada 용으로 만들어 보았다. 언어도 pascal + asm에서 C++로 바뀌었고 구조도 완전히 다 바뀐 것이라 완전히 새로 만드는 기분이었다.

일단 bada app의 이야기인 app을 만든 방법은,

- 기본 C++ project에서 Form-Base app을 선택

- 처음부터 있는 기본 Form을 타이틀이 없는 Form으로 수정

- 더불어 UI 관련 xml은 삭제

- application.xml 에서 auto scaling 관련 옵션 제거
(게임에는 사용하지 않는 편이 품질을 보장할 수 있음)

- manifest는 API 1.0 version으로 발급
(더 많은 기기와 버전에서 동작하도록 하기 위함)

- Application에는 Timer와 관련 listener를 추가

- Application의 OnForeground에서는 timer를 ON

- Application의 OnBackground에서는 timer를 OFF 했습니다.

- Timer 이벤트가 발생할 때마다 10 ms의 간격으로 게임의 메인 루프를 실행

- 게임은 1995~6년도의 원작의 resource를 그대로 사용

(ELF사에 저작권이 있는 부분입임)

- 당시 4-bit용 게임이었으므로 GetCanvasN()의 포맷인 ARGB8888로 리소스를 변경

- 터치 입력을 추가, 스크린의 4 방향의 가장자리를 누르면 유이가 움직임

dokyusei2_public_.zip

bada용 동급생 2 맵 출력 샘플 (257K)

대변 파이터 (bada 이식作)

2011-10-21T07:58:22+09:00

이번에는 DOS -> Windows -> WIZ -> CANNOO를 거쳐 bada 플랫폼에도 대변 파이터를 이식해 보았다. (앱스토어에 올릴 수가 없으니 풀소스로 첨부)

해상도가 800x480으로 커졌기 때문에 CANNOO에서까지 써왔던 320x240용 리소스는 모두 교체를 했다. 예전의 DOS용 16컬러 데이터를 복원하였고 일부 대사도 현재에 맞게 수정하였다.

제일 어려웠던 것은, 키보드 전용 게임을 풀터치로 만드는 일이었는데 결과적으로는 재미없는 게임이 되고 말았다. 처음부터 풀터치로 기획되지 않은 게임을 풀터치에 올리려는 자체가 잘 못 된 것이다. 게다가 2인용도 불가능 해서 하나의 조작으로 둘 다 동시에 움직이는 키배치로 수정을 하였다.

_ShitFighter_public_.zip

bada용 대변 파이터 (569K)

나머지 연산자에 의한 실수

2011-08-07T21:12:45+09:00

아래와 같은 코드를 만들었다.

예로 들기 위해서 만든 것이라 별 의미는 없는 struct인데, time_stamp라는 값이 들어 왔을 때 이 값을 짝수이면 내부 변수에 -1을, 홀수이면 +1을 대입하도록 하였다. 그리고 다음과 같이 짝수는 2로 나눈 나머지가 0이라는 것을 이용해 switch - case 문을 만들었다.

struct Step

{

explicit Step(int time_stamp)

{

// 어떤 값을 2로 나누었을 때,

// 나머지 값은 0 또는 1만 가능하다.

switch (time_stamp % 2)

{

case 0: m_step = -1; break;

case 1: m_step = +1; break;

}

int m_step;

private:

Step();

};

이런 방식의 코드를 Test case를 만들기 위한 유틸리티로 집어 넣었고, 곧바로 정적 코드 분석 툴에 의해 위의 코드는 잠재적인 문제가 있다는 통보를 받았다. 지금 보면 당연한 것인데도 보고를 받고 문제를 알아차리는 데는 십 분 정도 걸렸다.

정답은, 특정 조건에서는 생성자에서 m_step에 값을 대입하지 않아서 가비지 값으로 남아 있을 수 있다는 것이고, 그것에 대한 직접 적인 원인은 time_stamp 변수가 음수일 때를 고려 하지 않았기 때문이다.

0 이하일 때 나머지 계산의 값을 보면,

time_stamp = 0, -2, -4, -6, -8, … 일 때는 0

time_stamp = -1, -3, -5, -7, -9, … 일 때는 -1

의 값이 된다. 따라서 이 경우는 위의 코드에서 case -1: 을 추가 해야만 정적 분석 툴에서 문제를 통보하지 않는다.

극한 테스트

2011-06-29T21:57:17+09:00

Embedded 기기의 양산 제품에 대한 SW 테스트는, 거쳐야 하는 관문이 꽤 많다.

보통은, 개발자에 의한 (1)Unit test, QA 팀의 (2)Integration test / (3)Stress test, 그리고 SW 인력의 손을 떠난 (4)Monkey test나 (5)극한테스트(가칭)가 있다. 그 중에서 극한테스트(가칭)의 경우는 나에게 잊을 수 없는 개발 경험을 준 적이 있다.

때는 5~6년 전 어느 날, 갑자기 양산 검증 쪽에서 급보가 날아 들었다.

고온의 불가마에서 TV가 제대로 나오는지를 테스트 하는 실험이었는데 20일 정도를 계속 켜 놓았더니 TV가 죽었다는 것이다. 시리얼로 덤프를 받아서 개발팀에 넘겼고, 문제를 일으킨 것은 나의 코드였다. 양산 검증 막판에 이런 식의 에러가 발생하면 생산 라인이 가동을 멈추어야 하기에 이것은 꽤 큰 일이었다.

급하게 문제의 소스를 확인 해보니 다음의 위치였다.

(방금 창작한 코드라 당시의 코드와 조금은 다를 수 있다)

if (dst_alpha > 0)

{

unsigned long src_rate = (src_alpha * (MAX_ALPHA_VALUE - dst_alpha)) / MAX_ALPHA_VALUE;

unsigned long last_rate = src_rate + dst_alpha;

assert(src_rate < 256);

assert(last_rate < 256);

assert(last_rate > 0);

}

양산 제품에 왜 assert()가 빠지지 않았냐는 일단 차치하고(최종 버전을 릴리즈 모드로 하지 않은 듯 하다) 어떤 상황에서 assert()에서 죽을 수 있는 지를 검토해 보았다.

다음과 같은 검증 코드를 만들어서 돌렸고, 모든 유효한 값을 다 넣어 봐도 assert(false)는 일어 날 수 없다는 것을 증명하고서야 나의 혐의는 풀렸다.

void probe(unsigned long src_color, unsigned long dst_color)

{

#define MAX_ALPHA_VALUE 255

unsigned long src_alpha = (src_color >> 24);

unsigned long dst_alpha = (dst_color >> 24);

if (dst_alpha > 0)

{

unsigned long src_rate = (src_alpha * (MAX_ALPHA_VALUE - dst_alpha)) / MAX_ALPHA_VALUE;

unsigned long last_rate = src_rate + dst_alpha;

assert(src_rate < 256);

assert(last_rate < 256);

assert(last_rate > 0);

}

테스트

for (unsigned long s = 0; s <= 0xFF; s++)

for (unsigned long d = 0; d <= 0xFF; d++)

{

unsigned long src_color = (s << 24);

unsigned long dst_color = (d << 24);

probe(src_color, src_color);

}

정상적인 상황에서는 절대 발생할 수 없다는 것이 쉽게 증명이 되는 상황이었기에 다행인 것이지, 만약 이런 것을 증명하기 애매한 경우라면, 며칠을 밤을 새워 가며 시달렸을지도 모른다.

이 경우는 극악한 환경에서의 CPU 오동작과 관계가 있었겠지만, 이런 것 이외에도 memory cache의 타이밍 문제나, LCD controller의 전송 특징과 같이 S/W와는 직접적으로 관련 없어 보이는 것도 S/W의 문제로서 처리해야 하는 경우가 많다. 그리고 우리가 그런 문제점을 통보 받게 되면 S/W에서 처리 가능한 문제가 아니라는 것을 증명하기 위래 아까운 시간을 낭비하게 된다.

그나마 다행인 것은, 이런 문제를 많이 접하면 접할수록 과거의 경험을 통해 S/W의 문제가 아니라는 증명을 그나마 빨리 해낼 수 있게 되었다는 점이다. (물론, H/W device나 compiler를 의심하는 것은 S/W 엔지니어가 가장 마지막에 검토해야 하는 것이다)