midp2.0 썸네일형 리스트형 에리테리아 전설 작년 내내 매달렸던 프로젝트가 일본에 런칭이 되었습니다. 일본쪽 타이틀은 에리테리아 전설이군요. 2월 말 au(KDDI), 3월 초 야후 케타이(softbank)에서 서비스 되었고, 그리고 3월 말에 i-mode(NTT)에서 서비스 예정입니다. 기존 인력 다 나가고 프로젝트 중간에 갑자기 맡게 된 것인데다가 본사 입맞에 맞춰주고, 플랫폼도 여러번 바꿔터느라 그 퀄리티가 차마 어디 내놓기 부끄러운 놈이지만 의외로 선전하는 모양입니다. 전 캐리어 통합랭킹(?) 17위, 다음주 야후 케타이 랭킹 7위라는 이야기가 있네요. 정작 저희 팀 내부에서는 '초딩도 외면할 게임'이라며 자책했는데요. =) 사실 설령 일본에서 1등한다고 해도 저랑은 아무 상관이 없는 이야기입니다. 한국에서 잘 나와야지요.(-_-) 하지만 .. 더보기 WIPI의 getRGBpixels/setRGBpixels의 문제점 #2 [1] http://jakes.tistory.com/413 : WIPI의 getRGBpixels는 한 프레임(혹은 한 repaint, 하나의 스레드 타임, 등 뭐라 부르던)에서 여러번 호출이 되면 에뮬과 단말에서 모두 뻗는 것 같습니다. 특히 pixel값을 불러올 영역이 lcd영역 밖 (예를 들어, 그 범위 값이 음수이거나, lcd width/height보다 큰 값을 가진다면)에 있는 경우도 안정적인 동작을 하지 않는 것 같은 의심이 듭니다. (이것은 좀더 확인해 보아야 하는데, 다른 이슈로 바쁘고... 게으른 관계로) [2] http://jakes.tistory.com/414 : drawRGB() 메소드는 4444 ARGB 포맷의 픽셀 데이타를 담은 int[] rgbData를 지정한 좌표에 뿌려주는 메.. 더보기 midp2.0 on WIPI2.0? 스펙상, WIPI 2.0은 midp2.0 API를 포함합니다. 따라서 midp2.0의 API는 소스레벨에서 정상적으로 컴파일되며 또한 거의 대부분의 경우 정상적으로 동작하는 것으로 보여집니다. 하지만 motive 센터의 Q&A를 읽어보면 100% 보장하지 않는 늬앙스를 느낄 수 있습니다. 실제로 정상적으로 컴파일되었음에도 불구하고 midp 상에서의 결과와 WIPI 상에서의 결과가 일치하지 않는 경우를 경험했습니다. 그것은 바로 Graphics.drawRGB() 메소드의 용례에서 찾을 수 있었습니다. drawRGB() 메소드는 4444 ARGB 포맷의 픽셀 데이타를 담은 int[] rgbData를 지정한 좌표에 뿌려주는 메소드입니다. 이 메소드를 WIPI2.0 에서 사용할 경우, rgbData를 찍을 좌표.. 더보기 이전 1 다음
