AS3GB project

Flex/as3gb 2010/01/08 02:15
flash 플랫폼을 위한 에뮬레이터 프로젝트의 2번째.
바로 Gameboy 입니다.

출처-wikipedia

전세계 수억대의 판매를 했던, 휴대용 게임기의 역사를 출발시킨 바로 그 gameboy가 맞습니다.
딱히 gameboy를 다음 프로젝트롤 결정한 이유는 이전 패미컴(또는 NES)과 아키텍쳐가 비슷하고
이 또한 본인의 어린 시절에 불태웠던 추억이 있는 물건이라서.
nintendo ds 라는 기기로 주력 라인이 바뀐이후 이제 추억으로 남겨져 버렸지만..
게임&워치가 nintendo ds로 되살아나듯, 언젠가 gameboy도 다시 나타나겠죠.

현제 알게 모르게 이미 20% 이상 개발된 상태. 패미컴 에뮬레이터 개발의 노하우 덕분인지 개발에 가속도가 붙었습니다.
대략 1주일 안에 첫 릴리즈가 될거라 예상합니다.

(아래는 flikr의 사진들. 링크 걸기 귀찮으니 flikr 아이디들만 같이 적어두겠습니다.)
photograph by allanbarredo

photograph by flo-photos

"Monklets playing Gameboy"
photograph by thecnote

photograph by srestaino

NES PPU 문서

Flex/as3msn 2010/01/05 03:54
http://docs.google.com/Doc?id=dgkczz7v_8cwncmfcn

AS3NES v0.1 Alpha

Flex/as3nes 2010/01/02 02:53
첫 공식 릴리즈합니다. 구글코드 사이트를 통해서 배포하고 있습니다.

as3nes에 대해서 간략하게 정리하자면..
플래시 플레이어에서 돌아가는 패미컴(또는 NES, 현대컴보이, 훼미리 등 여러 이름으로 불립니다) 에뮬레이터 라이브러리 입니다. 롬파일을 ByteArray로 넘겨주면 슥슥 에뮬레이팅 해주는 식이죠.

첫 릴리즈인 만큼 많이 부족합니다. 일단 FPS(Frame per Second)가 5미만이고, 그에따라 사운드도 매우 끊기고 듣기 힘든 수준입니다.
일단 구동이 된다는것에 만족해야 하는 수준이지만 당분간 퍼포먼스의 향상을 기대하기 어렵다는 판단을 하고 이 상태로 릴리즈를 결정했습니다.

(다른 프로젝트도 그렇지만 0.1버전 이후 업데이트는 엄청나게 느립니다. 후후)


(박스안에 담아둔 패미컴 게임들..)
NES의 시스템 아키텍쳐를 안보고 대강 vNES의 소스를 AS3로 직역한것에 불과하지만, 일단은 직역만으로도 구동되는 롬이 상당수.

이제 겨우 1단계가 마무리 되었으니 이제 자연스러운 문장으로 바꿀 단계다.

1단계에서는 이미지 출력이나 사운드 출력을 AS3에 맞게끔 바꾸는게 가장 큰 이슈였고,  java언어의 prime type들은 가장 호환성이 좋은 AS3의 prime type으로 대치하는것이 이슈였지만..

이번 단계에서 필요한건 AS3의 장점을 최대한 살릴수 있는 구조로 아키텍쳐를 변경하는것이다.

AS3에 가장 어울리는 문법과 표현법이 있는거니까.

예를들면.. 원 소스는 파일 입출력을 동기적으로 처리하였지만 AS3는 평소 비동기 입출력이 이용되는 것, Thread를 사용해서 각 Thread가 procedual 하게 처리하는것은 event 기반의 처리로 바꾸는식.
(추가1: event기반 구조로 바꿔본 결과 퍼포먼스가 눈에 띄게 떨어지는 현상. 아마도 event 객체 생성시 딜레이가 주 원인인듯하여 각 PPU, PAPU를 Thread로 처리해봐야겠음)
(추가2: Thread로도 해결되지 않는다. 병목을 찾아보니 Bitmap->Vector->calculation->Vector->Bitmap 이라는 방식에서 생기는 딜레이라고 판단된다. Tile이라 불리는 스프라이트와 프레임 버퍼를 Vector로 변환해서 계산하던걸 BitmapData상에서 모두 처리하는게 도움이 되지 않을까..PPU를 대대적으로 수정해야할것 같은 느낌)
(추가3: palette를 사용하는 indexed color를 사용하고 오브젝트의 색상이 고정적이지 않고 동적으로 팔레트를 교환하는 경우-마리오가 불꽃을 먹을때 마리오의 변신효과같은-가 있어서 BitmapData상에서 모두 처리하지 못하게 되어있다.결국 PPU의 리팩토링 실패로 성능개선의 한계에 왔음)

대신 빼서 버려야 할 것들도 상당수다. 화면의 크기를 조정한다던가, 화면 필터를 적용한다던가 하는 식의 클래스들은 불필요해졌다. AVM의 최대 강점인 벡터 렌더링 엔진이 하드웨어 가속까지 사용하면서 얼마든지 도와줄 수 있는 부분이니.
또한 pixel bender가 있으니 화면 필터는 plugin 방식으로 지원 가능한 부분.

하지만 열혈 응원단 마져 좌절할 만한 속도 또한 문제.
플래시에서 슈퍼 마리오의 음악을 듣게 되는 날도 그리 멀지 않은것 같습니다.

그리고 추가된 '플레이' 스크린샷. 어제 올렸던 구동화면과는 다른!