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 방식으로 지원 가능한 부분.
