아마, 창조도시에서 개임개발자의 꿈을 꾸고 만들기툴을 사용하는
사람들이 많을 껍니다.
저 또한 중고딩 시절 그러했었고, 어느덧 대학생이 되어
이렇게 현역 프로그래머의 길을 걷고 있습니다.
====================================================================
PC게임 시장에서 Offline 게임 시장은 패망했습니다.
CD Package 유통망 자체가 국내에서는 파탄난 지경인데다가
아무리 보안을 철저히 해도, 출시 일주일이면 크랙판이 나돌아다닙니다.
뭐, PC 기반 Online게임의 포부를 가진 분이라면 괜찮지만
솔직히 모바일 게임이 100배 쉽습니다. PC보다는...
====================================================================
모바일 게임에서 가장 큰 문제는
안드로이드의 멀티스크린입니다.
일단 사라져버린
QVGA 240 * 320
HVGA 320 * 480 을 비롯하여
WVGA 480*800 / 480 * 854
qHD 540 * 960
WSVGA 600 * 1024
HD 720 * 1280
WXVGA 800 * 1280 , 768 * 1280
해상도가 있습니다.
여기에 새로나올 해상도가 1200 * 2000 대인 것을 감안하면 (TV size)
개발자의 멀티스크린 지원 능력은 필수입니다.
눈썰미 있는 분들은 눈치챘겠지만,
해상도마다 가로세로 비율이 제각각입니다.
======================================================================
1) Bitmap은 Rect로 그리자
대부분의 프로그래머가 Bitmap Drawing을 좌표로 했습니다.
그러나 Rect로 그리게 되면, Application에서 Rect에 맞춰서 Resizing을 하게 됩니다.
어느정도의 안티얼라이싱은 Paint에서 감당할 수 있습니다.
Window Programming을하다가 넘어오면, 가장 많이 헤맬 것이 여깁니다.
습관이 좌표로 Bitmap을 드로잉하다가, Rect로 그리려니 번거롭죠.
하지만 안드로이드에서 Bitmap 그리기의 기본은 Rect입니다.
2) Default Screen의 크기를 정하자.
개발할 때 기준이 되는 Screen 크기입니다. 얼마전까지만해도 480 * 800 이 대세였는데
요 근래 들어서 720 * 1280 이 대세가 되었습니다.
일단 이런식으로 디폴트 스크린 크기를 정하면
DeviceScreen이랑 비교를 하면, scale_w 값과 scale_h값이 나오게 됩니다.
비율 좀 깨지더라도 화면에 꽉채우고 싶으면, scale_w값과 scale_h값을 각각 가로 세로에
적용하여 로딩 시 이미지를 늘리고 줄이면 되었으나....
옵티머스 뷰2라는 제품이 3 : 4 비율을 들고 나왔으므로
scale_w, scale_h값 중 작은 값을 적용하게 됩니다.
이렇게 되면, 더 긴 쪽은 여백이 남게 되는데 이 여백은 검은색으로 채색을 하시면 됩니다.
3) Drawable-hdpi 폴더를 너무 믿지 말자
사실 안드로이드는 해상도에 맞추어 이미지를 자동 리사이징 해줍니다.
해상도별로 폴더를 따로 나누어서 이에 맞추어서 사용할 수 있게 해놓습니다.
때문에 많은 개발자들이...심지어는 잔뼈 굵은 중견개발자들도
(x, y)로 이미지를 그립니다.
그러나 제조업체의 중구난방식의 제작 때문에
한계가 있습니다.
앞서 언급한 해상도는 Google에서 어느정도 정한 공식 해상도이고
이 외에 제조사 마음대로 만든 해상도도 많습니다.
대표적인게 삼성 갤럭시탭으로, 하단 바를 소프트웨어로 구현을 하였기 때문에
좌표로 이미지를 뿌릴 경우, 하단바에 이미지가 씹어먹히게 됩니다.
즉, 쉽게 말해 갤럭시탭은 768 * 1280 해상도이지만, (Portrait)기준으로
하단바를 감안하면, 갤럭시노트와 얼추 비슷한 가로세로비율을 갖게 됩니다.
같은 hdpi라고 하지만, 탭의 좌표가 더 적죠.
이미지 리사이징 과정이 없으면 어플리케이션은 안드로메다로 가는 겁니다.
4) Sprite는 따로 저장하자.
스프라이트(프레임 이미지)를 각각의 파일로 저장해 만들었을 때의 장점은
최악의 상황에서도 크기만 다른 온전한 이미지가 출력이 되기 때문입니다.
물론 하나의 통이미지를 불러와서 이것을 한칸 한칸 뜯어내서 그리면
이상적이겠지만....
이게 비추인 이유가 뭐냐하면
1픽셀의 손실이 반드시 발생하기 때문입니다.
scale_w, scale_h는 실수값이고
pixel은 정수값이니 형 변환에서 발생하는 문제입니다.
가로세로 비율이 똑같은
480 * 800 // 768 * 1280을 놓고 봅시다.
가로세로비율은 0.625 : 1 입니다.
즉, WVGA에서 Chpset 32 * 32의 크기는
768 * 1280의 탭(하드웨어 버튼을 가진 탭)에서는
51.2Pixcel이 되어버립니다.
픽셀이 인트형 정수이므로 세로 resizing된 셀은
51*51픽셀이 되어버립니다.
잘못만들면 캐릭터 프레임이 돌아갈 때 마다 옆에서 픽셀벽이 깜빡깜빡거리게 됩니다.
어차피 따로따로 개별저장을 하던, Sprite로 저장을 하던
저장되는 이미지 크기는 똑같습니다.
그리고 요즘 누가 쌩코드로 그림 불러오나요?
다 XML로 정리한다음에 읽어들여서 불러오지...
5 Loading할 때, 이미지를 리사이징하자.
DefaultScreen은 상수이고...
DeviceScreen도 상수이므로...Application 구동 시 MainActivity에서
DeviceScreen의 정보를 전달받으면
scale_w, scale_h값을 구할 수 있습니다.
가로세로비율고정이라면 두 값 중 작은 값으로 리사이징을 하면 됩니다.
물론 리사이징 없이 canvas.drawBitmap(bmp, null, rect, null);
로 그려버리면 되나...
도트튑니다. 안티얼라이싱이 없기 때문에, 확대 축소 다 튀죠
그래서 많이 쓰는 방법이
Paint p = new Paint();
p.setAntiAlias(true);
p.setFilterBitmap(true);
p.setDither(true);
이겁니다.
canvas.drawBitmap(bmp, null, rect, p);
이렇게 하면 안티얼라이싱이 되어서 부드럽게 나옵니다.
근데 느려지죠.
이걸로 BackgroundImage를 그리면, 지연이 발생합니다.
그럼 우쩌냐?
scale_w, scale_h가 있습니다.
네 Bitmap을 Load할 때, 이 비율값을 적용해서 메모리에 Load합니다.
후에 이것을 사용하면 편하죠.
1번 안얼이 적용되었기 때문에
canvas.drawBitmap(bmp, null, rect, null); 이렇게 그려도 부드럽게 그려집니다.
