스프라이트(컴퓨터 그래픽)
[image]
사진은 초대 젤다의 전설의 링크.
게임 등지에서 사용되는 움직이는 2차원 비트맵 개체를 가리키는 용어. 마치 도깨비불이 둥둥 떠다니듯 배경화면과 독립적으로 움직일 수 있었기 때문에 sprite를 어원으로 삼은 것 같다.
본래 스프라이트란 하드웨어적으로 구현되고, 팔레트의 제약이 있으며 일반적으로 표시되는 화면과 별개로 움직일 수 있는 작은[1] 오브젝트 정도로 한정된 의미를 가지고 있었지만 기술적으로 스프라이트를 사용하지 않게 된 21세기에 들어서는 말의 의미가 확장되어 (진짜 스프라이트처럼) 작고 도트 그래픽으로 되어있는 2차원 이미지를 스프라이트라고 부르기도 한다. 그나마도 요즘은 잘 쓰이지 않는 말.
비디오 게임의 여명기 시절에는 CPU가 직접 매 프레임 표시할 화면을 그려내도 크게 성능상의 문제는 없었다. 해상도도 비교적 낮았고, 화면도 흑백이었던 데다가, 복잡한 배경도 없었기 때문에 움직일 부분과 움직이지 않을 부분을 구분할 필요도 없었고 데이터 크기도 매우 작아 처리량이 적었다. 대표적으로 스페이스 인베이더가 저런 스타일이었다.
하지만 점차 게임의 화면이 디테일해지고, 컬러가 도입되면서 CPU의 처리량이 따라가지 못하는 상황이 발생하였다. 그래서 CPU의 부하를 줄이면서 표현력을 늘리기 위해 화면의 정적인 부분(주로 배경)과 동적인 부분(주로 캐릭터)의 처리를 분리하고 추후에 합성하여 출력하는 방식을 강구하게 된다. 여기서 동적인 부분을 담당한 대표적인 방식이 바로 스프라이트였다. 본래는 아케이드 쪽에서 유래한 기술로, 1980년대 초부터는 가정용 컴퓨터나 게임 콘솔에도 도입이 되었다. 초창기 PC나 게임 콘솔의 경우 스프라이트 표현 기능이 있느냐 없느냐, 조금 더 지나서는 표현할 수 있는 스프라이트 개수가 몇 개냐가 하드웨어 성능의 척도가 되기도 했다.
그러나 하드웨어가 점점 발전하고 가용 메모리가 커지면서 하드웨어 스프라이트 기능은 의미를 잃었다. 가정용 게임 콘솔을 기준으로 하면 5세대가 마지막이다. 전통적인 방식의 2D 하드웨어 스프라이트를 지원하는 콘솔은 거치형은 세가 새턴, 휴대형은 닌텐도 DS가 마지막이며[2], 플레이스테이션은 일단은 스프라이트 기능을 가지고는 있는데 스프라이트-플레인(BG)의 전통적인 구조는 아니라는 모양. 그 이후에는 게임 시장의 판도가 3D로 완전히 옮겨감에 따라 전용 2D 하드웨어를 내장하지 않고 3D 그래픽을 응용하는 형식으로 2D 화면을 표현하고 있다. 기존에 스프라이트가 담당하던 움직이는 2D 오브젝트도 폴리곤을 이용해서 표현하는데 이런 것까지 폭넓게 스프라이트로 부르는 경우도 있다.
1980년대의 하드웨어로는 오늘날처럼 프레임 버퍼를 두고 매 프레임마다 화면 전체의 오브젝트를 모두 갱신하는 기법을 사용하기엔 컴퓨터 성능이 모자랐다. 일단 프레임 버퍼를 하나 따로 두어야 하는 것부터 커봐야 고작 64KB, 보통 16KB 남짓한 비디오 메모리를 지녔던 당시 하드웨어로서는 메모리 부담이 컸으며 프레임 버퍼에 표시될 오브젝트를 얹어 실시간으로 갱신한다는 것은 당시 고작 1~3MHz(!)에 불과한 성능을 지닌 당시 8비트 CPU로서는 속도 면에서도 불가능에 가까웠다. 따라서 배경이 될 이미지를 일단 뿌려놓고 그 위에서 움직이는 오브젝트만 갱신하여 CPU와 메모리의 부하를 줄이는 방법을 강구해야 했는데 여러가지 방법이 있었으나 그 중에서 가장 널리 사용되고 효과도 좋았던 방식이 바로 스프라이트. 이 때문에 당시의 아케이드 기판이나 MSX 등의 일부 컴퓨터, 패미컴 등의 게임기를 비롯한 기기들에는 하드웨어적으로 스프라이트를 출력하는 기술이 들어있었다. 이러한 기기들은 CPU에 부담을 거의 주지않고 배경에 영향을 주지 않고 움직이는 이미지 레이어인 스프라이트의 사용으로 인해 수월하게 액션이나 슈팅 게임을 만들 수 있었다. MSX나 코모도어 64가 동시대의 컴퓨터들에 비해 유달리 슈팅, 액션 장르가 발달한 것도 이 스프라이트를 지원했기 때문이다.
모든 컴퓨터가 스프라이트 기능을 제공했던 것은 아니어서, 애플 II나 PC-8801 등의 기종들은 움직이는 오브젝트를 소프트웨어적으로 처리해야했기 때문에 CPU의 부담이 컸고, 따라서 동적인 게임을 만드는데 제약이 많았다. 따라서 액션 게임의 경우는 한계가 있어 속도감 있는 게임이 나오기 어려웠고 후반으로 갈수록 어드벤처 게임이나 롤플레잉 게임처럼 비교적 정적인 장르가 주류를 차지하게 되었다. 아케이드나 게임 콘솔의 경우에도 아주 초창기의 기기엔 스프라이트 기능이 없는 경우도 있다. 패미컴이 당대에 대단한 인기를 끌었던 이유 중 하나도 아타리 2600이나 콜레코비전 같은 전세대 기기에 비해 스프라이트 기능을 포함한 그래픽 성능이 우수했던 점을 들 수 있다.
참고로 한국에서 가장 먼저 스프라이트 구현을 광고로 내세운 8비트 기종은 효성의 하이콤-800. MSX와 동일한 VDP(TMS-9918)을 사용하고 있어 스프라이트 기능을 가지고 있었고, 1983년 전두환 정부의 정보화교육 정책에 따라 교육용 PC로 도입된 최초의 기종 중 하나였는데 이 중에서 스프라이트 기능을 탑재한 유일한 기종이었다. 같은 VDP를 탑재한 FC-150은 동년 12월, MSX는 1984년부터 도입되었으니 하이콤-800이 가장 빠르다.
참고로 옛날 하드웨어에서 그래픽이 어떻게 그려지는지 궁금하면 아래의 영상을 보자.
초창기 기기의 스프라이트는 메인 비디오 메모리와 별도의 메모리 영역에 스프라이트 데이터를 두고, 화면에 출력할 때 '라인 버퍼'라는 버퍼 메모리를 두고 화면에 출력할 때 라인 버퍼에서 주사선 1개 단위로 합성을 해서 출력하는 원리를 가지고 있다. 별도의 메모리 영역에 올라가 화면에 출력하는 시점에 합성되므로 당연히 배경화면에 영향을 주지 않고 스프라이트가 이동하는 것이 가능해진다. 보통 '스프라이트'는 원리적으로는 이 라인 버퍼 스프라이트를 의미하며 나머지는 나중에 의미가 확대된 것이다.
라인 버퍼를 사용하면 버퍼 메모리가 1라인 분만 있으면 되므로 처리도 빠르고 메모리도 적게 소비해서 메모리 가격이 비쌌던 1980년대에는 매우 유용한 기술이었다. 그러나 반대급부도 있었는데, 스프라이트가 많아지면 라인 버퍼의 처리가 이를 따라가지 못해서 가로로 라인 버퍼의 처리 능력을 넘어서는 양의 스프라이트가 나란히 놓이는 경우가 생기면 우선순위가 낮은 스프라이트부터 표시가 안되는 문제가 발생한다. 하드웨어 성능이 올라간 16비트 시대 이후엔 잘 눈에 띄지 않는 결점이지만 8비트 머신들은 이 문제가 꽤나 심각했다.
당대에 스프라이트 기능을 탑재한 대표적인 기기인 MSX의 경우를 예로 들면 1화면에 표시 가능한 스프라이트 수는 32개까지지만 가로 4개까지 놓일 수 있어서 5개째부터의 스프라이트는 표시가 안된다. MSX는 스프라이트가 단색표시만 가능했기 때문에[3] 적어도 2개의 색은 사용해야 하는 중요한 오브젝트(주로 주인공 캐릭터)는 2개의 스프라이트를 겹쳐서 표현하는 기법도 널리 쓰였는데 이렇게 되면 안그래도 빡빡한 제약이 더욱 심해진다. 화면에 특정 스프라이트가 나오지 않으면 게임에 지장을 줄 가능성이 높으므로 이를 극복하기 위해 5개 이상의 스프라이트가 가로로 늘어서는 경우에는 번갈아가며 스프라이트를 출력하는 기법을 썼는데, 이런 경우엔 스프라이트가 깜빡이는 문제는 있지만 어쨌든 화면에 모두 출력은 되기 때문에 많이 사용된 기법이다. MSX2의 경우는 가로 제약이 8개로 완화되었고 라인마다 색상지정도 가능해져서 이런 깜빡임이 줄었다. 패미컴의 경우도 가로 제약이 8개이지만 패미컴의 스프라이트 기본 사이즈는 8x8 픽셀이기 때문에 16x16 픽셀을 기본 사이즈로 하는 MSX의 스프라이트와 같은 사이즈로 비교하면 가로 제약 수는 MSX1과 다름없어진다. 예를 들면 슈퍼 마리오 브라더스 에서 굼바 같은 적이 단체로 나올 때는 최대 3마리 까지만 나오는데 이는 마리오+굼바 3마리가 가로로 늘어선 상태가 패미컴의 스프라이트 출력 한계이기 때문에 깜박이는 문제를 피하기 위해서 더 많은 적이 나오지 않게 배치한 것이다. 다만 패미컴은 스프라이트에 최대 3색상을 넣을 수 있기 때문에 스프라이트를 겹쳐써야하는 MSX1보다는 형편이 좀 나았다.
이렇게 이야기하면 많이 안습한 옛날 기술 같지만 의외로 라인 버퍼 스프라이트는 네오지오나 X68000처럼 당대엔 고사양이었던 머신에서도 사용된 기술이다. 네오지오의 경우는 아예 배경 그래픽 영역을 별도로 두지 않고 전부 그냥 크고 아름다운 스프라이트를 붙여서 배경처럼 사용하는 것으로 해결하는 굉장한 방법을 사용했다.
1980년대 중후반부터 세가 같은 거대 아케이드 기업이 고사양 기판을 만들 때 사용하기 시작한 방식이다. 가정용 기기에서는 1989년 발매된 컴퓨터 FM TOWNS에서 처음으로 이 프레임 버퍼 방식의 스프라이트를 내장하였고, 콘솔에서는 1993년 발매된 3DO와 1994년 발매된 세가 새턴이 이 방식을 채택하면서 5세대 콘솔에서는 주류가 되었다.
원리는 간단하다. 더블 버퍼링의 원리와 거의 비슷한데, 스프라이트만 그려넣는 스프라이트 전용 프레임버퍼와 화면에 비표시된 상태(오프스크린)에서 그려넣을 프레임버퍼까지 2개의 프레임버퍼를 추가로 준비해서 1프레임 분량의 스프라이트를 다음에 표시할 오프스크린 프레임버퍼에 전부 그려넣는다. 전부 그려지면 현재 화면을 출력하는 온스크린 프레임버퍼와 오프스크린 프레임버퍼를 교환하면 그걸로 끝. 장점은 라인 버퍼와 달리 가로로 놓이는 스프라이트 개수에 근본적인 제약이 없어지므로 깜빡임이 전혀 생기지 않으며 전체 표현가능한 스프라이트 수도 VRAM의 전송 속도와 스프라이트를 담당하는 칩셋의 처리 속도가 올라가면 이에 따라서 선형적으로 올라간다. 이걸 CPU가 처리하느냐 전용 칩셋이 처리하느냐의 차이만이 있을 뿐 그냥 더블 버퍼링으로 비트맵 그래픽을 때려넣는 방법과 차이가 없다. 따라서 스프라이트의 확대/축소/회전 같은 이펙트를 구현하기에도 용이해진다. 기본적으로 스프라이트도 그냥 비트맵 데이터가 되므로 스프라이트 크기의 제약이나 스프라이트당 들어가는 색상의 제약도 의미가 없어진다. 기존의 라인 버퍼 방식 스프라이트가 가지는 한계들이 거의 사라진다고 보면 된다.
반대로 단점은 하드웨어 자원이 많이 들어간다는 점이다. 일단 프레임버퍼가 기본적으로 2개가 더 필요해지니 VRAM을 많이 먹고, 1프레임(1/60초) 안에 오프스크린 프레임버퍼에 1화면분의 스프라이트를 모두 올려야하므로 그래픽 칩셋(VDP)의 처리 속도도 빨라야 한다. 스프라이트 처리가 늦어지면 표시하고자 하는 프레임보다 밀려서 스프라이트가 출력되는 사태가 벌어진다. 초창기 세가 SYSTEM 기판의 경우엔 오프스크린 프레임버퍼를 두지 않고 '수직동기 내에 모든 스프라이트를 전송한다'는 설계로 만들어버리는 바람에 스프라이트 처리가 늦어지면 우선순위가 낮은 스프라이트가 우수수 사라져버리는 현상이 발생했다고.
이렇다보니 당대엔 정말 비싼 기판이나 채택한 방식이었고, PC 역시 FM TOWNS 같이 호화로운 사양을 지닌 기기에나 내장되었다. 콘솔 등에 내장되는 것도 메모리를 많이 먹기 때문에 5세대에 와서야 도입이 된 방식이다.
일본에서는 기존의 스프라이트 방식, 즉 라인 버퍼 방식만을 스프라이트로 인정하는 경향이 있었기 때문에, 원리적으로 다른 이 방식은 '유사 스프라이트'로 불리기도 하였다. 현재 와서는 프레임 버퍼 방식도 스프라이트로 보는 추세.
스프라이트 기능은 없지만 기본적으로 하드웨어 스펙(CPU/RAM)이 높은 기기들에서 주로 사용한 방법이다. IBM PC 호환기종이 대표적으로 이 방식을 사용한 기기이며 현재의 PC 역시 스프라이트 관련 하드웨어는 존재하지 않지만 DirectX에서 스프라이트 기능이 있는 것처럼 사용할 수 있도록 소프트웨어로 처리하는 API를 제공한다[4].
원리적으로는 위의 프레임 버퍼 방식의 스프라이트와 동일하지만 스프라이트를 처리하는 전용 하드웨어가 없으므로 저 처리 과정을 모두 소프트웨어로 만들어서 '''CPU'''가 담당한다. 이렇다보니 기본적으로 하드웨어 성능이 높아야하는 프레임 버퍼 방식보다 더 많은 하드웨어 자원(특히 CPU의 처리속도)을 요구하며, MS-DOS 시대에 IBM PC 호환기가 하드웨어 성능에 비해 게임의 퀄리티가 떨어졌던 원인 중 하나도 이것이다. 그러다가 80286~80386급 CPU와 VGA 그래픽 카드가 일반화되는 1992~3년경 쯤이 되면 그냥 깡스펙의 상승으로 얼추 아미가 500 정도는 비슷하게 따라잡는다. 물론 아미가 500은 '''1985년'''에 나왔다. (...)
아무래도 프레임 버퍼에 비트맵 데이터를 다 얹어서 온/오프 버퍼를 교환하는 방식은 초창기의 PC 하드웨어로는 처리에 과부하가 걸리므로 부하를 줄이기 위해 많은 소프트웨어적 테크닉이 들어갔다. 예를 들면 화면 전체를 합성해서 교환하는 것이 아니라 표시가 갱신되는 부분만 합성해서 얹는다던지....그러나 근본적으로 이런 방법은 전체 버퍼를 교환하는 것에 비해 움직임이 자연스럽지 않은 문제가 있어 초창기 IBM PC의 액션/슈팅 게임들은 오브젝트의 움직임이 별로 보기 좋지 않은 작품이 많았다가 하드웨어 성능이 넉넉해진 90년대 중반 이후로 크게 개선되는 모습을 보인다. (컴퓨터 상황이나 게임의 내용이나 이식도 등의 차이는 있지만) 어느정도 높은 클럭의 펜티엄 정도면 괜찮은 이식 퀄리티의 콘솔 2D 게임 이식작들을 플레이할 수 있을 정도[5]. 물론 3D가 게임의 주류가 된 21세기에 들어와서는 2D 따위는 아오안이고 스프라이트도 CPU의 깡스펙으로 밀어버리는 게 1980~90년대의 전용 하드웨어보다 아득하게 빠른 시대가 되어버렸다보니 아무래도 좋은 이야기.
2020년 현재는 거의 대부분의 2D를 지원하는 게임엔진(게임메이커, RPG 만들기, 유니티 등)은 GPU를 사용하여 렌더링한다.
컴퓨터 성능이 좋아진 지금은 옛날처럼 스프라이트 이미지와 비트맵 이미지를 하드웨어적으로 따로 구별하진 않지만, 애니메이션 작업의 특성상 스프라이트는 배경과 분리되어 움직이는 물체에 쓰이는 만화적 이미지란 의미로 쓰이고 있다.
3D 그래픽이 주류인 2000년 이후가 되어서야 폴리곤을 몇 개 찍네 마네로 하드웨어의 성능을 평가하게 되었다. 6세대 이후의 콘솔에서는 별도의 스프라이트 기능을 내장하지 않는다. 하드웨어적인 스프라이트 처리 기능 따위는 빼버리고 평평한 폴리곤 1매에다 스프라이트로 쓸 텍스처를 입혀서 스프라이트처럼 굴리는 기술을 많이 사용한다. 물론 프로그래밍을 할 때는 래핑을 통해 스프라이트처럼 코딩하도록 되어있다.
2000년대 중반 이후 이 기법이 웹으로 넘어왔다. CSS를 이용하여 웹 페이지를 꾸미는 기법이 발전하면서, 스프라이트 형태로 된 통짜 이미지를 사용하여 버튼이나 메뉴가 눌리거나 마우스 오버로 하이라이트되는 것을 표현할 때 이미지를 보여 주는 좌표값을 변경하는 방식으로 구현하게 된 것. HTTP의 구조상 같은 크기의 이미지라도 여러 개의 이미지로 잘라서 호출하면 그 횟수만큼 오버로드도 늘어나므로 통짜 이미지로 만들어 웹 브라우저에 뿌려주는 이미지 개수를 줄이면 오버로드가 줄어들어 웹 페이지가 로딩될 때의 속도 향상도 기대할 수 있기 때문이다.
1980년대 초에 주로 사용된 그래픽 표현 방식의 하나이다. 컴퓨터에서 '''텍스트'''를 표시하는 방식을 응용한 방법으로 스프라이트처럼 동적인 오브젝트 표현에만 사용하는 방법은 아니고 초창기 아케이드 기판이나 MSX, 샤프 X1이나 SPC-1500, 코모도어 64 처럼 RAM이 비싸서 VRAM을 많이 달 수 없던 1980년대 초에 개발된 하드웨어가 많이 채용했다.
당시 컴퓨터에서 텍스트 화면을 표시할 때는 전체 화면을 8*8~16*16픽셀 정도의 타일 단위로 쪼개고 그 타일 크기만한 폰트를 미리 ROM이나 RAM에 저장해 놓은 뒤, CPU 각 화면의 타일마다 해당 폰트를 지정하는 값만 넣어주면 전용 회로나 프로세서가 매 프레임마다 1라인씩 그려내는 방법을 사용했다. 여기서 폰트를 문자 모양 대신 타일 이미지로 바꾸면 바로 PCG가 된다. 표현 능력의 확장을 위해서 기본적인 텍스트 화면보다 비디오 메모리를 좀 더 할당해서 타일 내 표현 가능한 색상을 늘린다던지 하는 방식을 쓰기도 했지만 기본은 저렇다.
일단 장점은 메모리를 적게 먹는다는 것. 일단 구조상 비트맵을 쓰는 것보다 메모리도 많이 덜 들고 따라서 전송대역폭도 적게 먹어 느린 CPU와 작은 VRAM으로도 그럴듯한 표현이 가능했다. 거기에 이미지의 크기 대비 용량이 적으므로 스프라이트 없이도 움직이는 오브젝트를 구현하기도 쉬웠다.
단점이라면 이미지를 만드는 방식상 비트맵처럼 원하는 위치의 픽셀에 원하는 색상을 넣어 그림을 만드는 게 어려웠고 이미지 작성에 다양한 제약이 있었다. 예를 들면 MSX의 Screen2의 경우는 가로 8픽셀 단위를 기준으로 2색씩만 배치가 가능하다. 그리고 움직이는 오브젝트를 만드는 경우 근본적으로 텍스트 화면에서 문자를 출력하는 방식을 응용한 것이라 픽셀 단위가 아닌 정해진 타일 크기 단위로만 움직일 수 있어 스프라이트에 비해서는 움직임이 거칠다는 단점이 있었다. 또한 배경 이미지와 움직이는 오브젝트를 겹치는 방법이 아니므로 움직이는 오브젝트의 공백 부분에 배경 이미지가 아닌 검정색, 혹은 그냥 배경 이미지의 주색이 단색으로 들어가게 된다.
MSX의 경우는 기본적인 그래픽은 PCG였지만 스프라이트도 쓸수 있었기 때문에 움직임이 많고 크기가 작은 유닛(플레이어 유닛 등)은 스프라이트로, 크기가 크거나 움직임이 많지 않은 유닛은 PCG로 분산해서 표현하는 방법을 썼다. 전술했듯 기술적 이유로 한번에 출력할 수 있는 스프라이트 수에는 제약이 있었기 때문에 배경이 아니라 움직이는 유닛이더라도 PCG인 경우가 꽤 많았다. MSX2의 경우도 비트맵 그래픽을 쓸 수 있었지만 VDP의 속도가 그리 빠르지 않아 게임에 그대로 사용하기엔 부하가 컸기 때문에 게임에서 크기가 큰 유닛은 움직임이 없는 경우가 많았는데 스페이스 맨보우 같은 게임은 이를 극복하기 위해 절묘하게 화면을 분할하여 한 화면에 PCG+비트맵+스프라이트를 모두 사용하는 당시로선 놀라웠던 테크닉을 선보이기도 했다.
1980년대 이후의 거의 대부분의 2D 메인의 아케이드 및 콘솔에서는 스프라이트 외에도 'BG(Background) 레이어' 등으로 불리는, 주로 배경 표시로 사용되는 그래픽 레이어를 갖추고 있었는데, 기본 베이스는 PCG이며 여기에 이것저것 기능들을 추가한 것에 가깝다. 주로 다음과 같은 기능들이 추가되었다.
뱀이나 기린같이 긴 캐릭터의 스프라이트는 기술적으로 만들기가 매우 어려웠으므로 구슬 모양의 스프라이트를 만들어 여러 개를 이어붙이는 형식을 사용하기도 했다. 흔히 말하는 '다관절' 캐릭터가 이런 방식을 사용한 것으로 1980년대에 굉장히 많이 사용된 연출이다. 복잡한 움직임을 낮은 사양의 하드웨어에서 비교적 쉽게 표현가능하다는 이점이 있다. 이것으로 유명한 작품은 사라만다[6], 스페이스 해리어 등이 있다. 사실 스프라이트로 표현해야 할 필연적인 이유는 없으므로 MSX처럼 스프라이트 제약이 빡빡한 기기에서는 PCG나 비트맵 그래픽 등으로 다관절을 연출하는 경우도 많았다.
2D 횡스크롤 뷰로 보면 2D 게임, 도트 게임, 장인정신 등으로 오해를 사는 경우가 종종 있는데, 2D로 보인다고 그것이 도트 작업물이라는 것은 아니다. 고전적인 스프라이트 작업은 현재는 극히 간단한 게임에서만 사용되고 있으며 2010년대 이후로는 적은 수의 폴리곤 혹은 관절 뼈대에 그림을 얹은 다음 각 부분을 움직이는 애니메이션을 더하여 스프라이트처럼 보이게 만드는 이른바 '스파인' 기술이 많이 보편화되었다.[7] 2000년대 중반만 해도 스파인 그래픽은 생소했지만 시대의 흐름에 따라 종래의 스프라이트보다 스파인이 게임개발에 더 효율적으로 비쳐진것을 보면 격세지감.
물론 기본 포즈의 동작을 벗어나는 모습을 보여줘야 한다면 그에 대한 그림도 다 그려야 하는 것은 여전하다.
2000년대 초까지는 코믹스록, 스프라인트, 어나더메가 등 록맨 위주의 스프라이트를 다루는 커뮤니티가 다양하게 존재했으나 2000년대 후반에 이르러 전부 침체되거나 사라진 상태로 거의 모든 관련 커뮤니티 망했다고 봐도 무방하다. 애초에 스프라이트가 꽤나 마이너한 분야라서 그런 듯. 2010년대 초에 네이버 카페중에서 디지몬, 포켓몬이나 메탈슬러그 등을 다루는 카페가 다시 살아나는가 싶었으나 거의 대부분이 침체되었다. 겨우 운영되고 있는 카페들도 정작 제대로 활동되고 글 리젠도 잘되는 곳은 많지 않다. 확실히 살아있는 도트 커뮤니티는 다섯 손가락 안에 꼽을 수준.
사진은 초대 젤다의 전설의 링크.
1. 개요
게임 등지에서 사용되는 움직이는 2차원 비트맵 개체를 가리키는 용어. 마치 도깨비불이 둥둥 떠다니듯 배경화면과 독립적으로 움직일 수 있었기 때문에 sprite를 어원으로 삼은 것 같다.
본래 스프라이트란 하드웨어적으로 구현되고, 팔레트의 제약이 있으며 일반적으로 표시되는 화면과 별개로 움직일 수 있는 작은[1] 오브젝트 정도로 한정된 의미를 가지고 있었지만 기술적으로 스프라이트를 사용하지 않게 된 21세기에 들어서는 말의 의미가 확장되어 (진짜 스프라이트처럼) 작고 도트 그래픽으로 되어있는 2차원 이미지를 스프라이트라고 부르기도 한다. 그나마도 요즘은 잘 쓰이지 않는 말.
2. 상세
비디오 게임의 여명기 시절에는 CPU가 직접 매 프레임 표시할 화면을 그려내도 크게 성능상의 문제는 없었다. 해상도도 비교적 낮았고, 화면도 흑백이었던 데다가, 복잡한 배경도 없었기 때문에 움직일 부분과 움직이지 않을 부분을 구분할 필요도 없었고 데이터 크기도 매우 작아 처리량이 적었다. 대표적으로 스페이스 인베이더가 저런 스타일이었다.
하지만 점차 게임의 화면이 디테일해지고, 컬러가 도입되면서 CPU의 처리량이 따라가지 못하는 상황이 발생하였다. 그래서 CPU의 부하를 줄이면서 표현력을 늘리기 위해 화면의 정적인 부분(주로 배경)과 동적인 부분(주로 캐릭터)의 처리를 분리하고 추후에 합성하여 출력하는 방식을 강구하게 된다. 여기서 동적인 부분을 담당한 대표적인 방식이 바로 스프라이트였다. 본래는 아케이드 쪽에서 유래한 기술로, 1980년대 초부터는 가정용 컴퓨터나 게임 콘솔에도 도입이 되었다. 초창기 PC나 게임 콘솔의 경우 스프라이트 표현 기능이 있느냐 없느냐, 조금 더 지나서는 표현할 수 있는 스프라이트 개수가 몇 개냐가 하드웨어 성능의 척도가 되기도 했다.
그러나 하드웨어가 점점 발전하고 가용 메모리가 커지면서 하드웨어 스프라이트 기능은 의미를 잃었다. 가정용 게임 콘솔을 기준으로 하면 5세대가 마지막이다. 전통적인 방식의 2D 하드웨어 스프라이트를 지원하는 콘솔은 거치형은 세가 새턴, 휴대형은 닌텐도 DS가 마지막이며[2], 플레이스테이션은 일단은 스프라이트 기능을 가지고는 있는데 스프라이트-플레인(BG)의 전통적인 구조는 아니라는 모양. 그 이후에는 게임 시장의 판도가 3D로 완전히 옮겨감에 따라 전용 2D 하드웨어를 내장하지 않고 3D 그래픽을 응용하는 형식으로 2D 화면을 표현하고 있다. 기존에 스프라이트가 담당하던 움직이는 2D 오브젝트도 폴리곤을 이용해서 표현하는데 이런 것까지 폭넓게 스프라이트로 부르는 경우도 있다.
3. 80년대 하드웨어의 스프라이트 지원
1980년대의 하드웨어로는 오늘날처럼 프레임 버퍼를 두고 매 프레임마다 화면 전체의 오브젝트를 모두 갱신하는 기법을 사용하기엔 컴퓨터 성능이 모자랐다. 일단 프레임 버퍼를 하나 따로 두어야 하는 것부터 커봐야 고작 64KB, 보통 16KB 남짓한 비디오 메모리를 지녔던 당시 하드웨어로서는 메모리 부담이 컸으며 프레임 버퍼에 표시될 오브젝트를 얹어 실시간으로 갱신한다는 것은 당시 고작 1~3MHz(!)에 불과한 성능을 지닌 당시 8비트 CPU로서는 속도 면에서도 불가능에 가까웠다. 따라서 배경이 될 이미지를 일단 뿌려놓고 그 위에서 움직이는 오브젝트만 갱신하여 CPU와 메모리의 부하를 줄이는 방법을 강구해야 했는데 여러가지 방법이 있었으나 그 중에서 가장 널리 사용되고 효과도 좋았던 방식이 바로 스프라이트. 이 때문에 당시의 아케이드 기판이나 MSX 등의 일부 컴퓨터, 패미컴 등의 게임기를 비롯한 기기들에는 하드웨어적으로 스프라이트를 출력하는 기술이 들어있었다. 이러한 기기들은 CPU에 부담을 거의 주지않고 배경에 영향을 주지 않고 움직이는 이미지 레이어인 스프라이트의 사용으로 인해 수월하게 액션이나 슈팅 게임을 만들 수 있었다. MSX나 코모도어 64가 동시대의 컴퓨터들에 비해 유달리 슈팅, 액션 장르가 발달한 것도 이 스프라이트를 지원했기 때문이다.
모든 컴퓨터가 스프라이트 기능을 제공했던 것은 아니어서, 애플 II나 PC-8801 등의 기종들은 움직이는 오브젝트를 소프트웨어적으로 처리해야했기 때문에 CPU의 부담이 컸고, 따라서 동적인 게임을 만드는데 제약이 많았다. 따라서 액션 게임의 경우는 한계가 있어 속도감 있는 게임이 나오기 어려웠고 후반으로 갈수록 어드벤처 게임이나 롤플레잉 게임처럼 비교적 정적인 장르가 주류를 차지하게 되었다. 아케이드나 게임 콘솔의 경우에도 아주 초창기의 기기엔 스프라이트 기능이 없는 경우도 있다. 패미컴이 당대에 대단한 인기를 끌었던 이유 중 하나도 아타리 2600이나 콜레코비전 같은 전세대 기기에 비해 스프라이트 기능을 포함한 그래픽 성능이 우수했던 점을 들 수 있다.
참고로 한국에서 가장 먼저 스프라이트 구현을 광고로 내세운 8비트 기종은 효성의 하이콤-800. MSX와 동일한 VDP(TMS-9918)을 사용하고 있어 스프라이트 기능을 가지고 있었고, 1983년 전두환 정부의 정보화교육 정책에 따라 교육용 PC로 도입된 최초의 기종 중 하나였는데 이 중에서 스프라이트 기능을 탑재한 유일한 기종이었다. 같은 VDP를 탑재한 FC-150은 동년 12월, MSX는 1984년부터 도입되었으니 하이콤-800이 가장 빠르다.
참고로 옛날 하드웨어에서 그래픽이 어떻게 그려지는지 궁금하면 아래의 영상을 보자.
4. 구현 방식
4.1. 라인 버퍼 방식의 스프라이트
초창기 기기의 스프라이트는 메인 비디오 메모리와 별도의 메모리 영역에 스프라이트 데이터를 두고, 화면에 출력할 때 '라인 버퍼'라는 버퍼 메모리를 두고 화면에 출력할 때 라인 버퍼에서 주사선 1개 단위로 합성을 해서 출력하는 원리를 가지고 있다. 별도의 메모리 영역에 올라가 화면에 출력하는 시점에 합성되므로 당연히 배경화면에 영향을 주지 않고 스프라이트가 이동하는 것이 가능해진다. 보통 '스프라이트'는 원리적으로는 이 라인 버퍼 스프라이트를 의미하며 나머지는 나중에 의미가 확대된 것이다.
라인 버퍼를 사용하면 버퍼 메모리가 1라인 분만 있으면 되므로 처리도 빠르고 메모리도 적게 소비해서 메모리 가격이 비쌌던 1980년대에는 매우 유용한 기술이었다. 그러나 반대급부도 있었는데, 스프라이트가 많아지면 라인 버퍼의 처리가 이를 따라가지 못해서 가로로 라인 버퍼의 처리 능력을 넘어서는 양의 스프라이트가 나란히 놓이는 경우가 생기면 우선순위가 낮은 스프라이트부터 표시가 안되는 문제가 발생한다. 하드웨어 성능이 올라간 16비트 시대 이후엔 잘 눈에 띄지 않는 결점이지만 8비트 머신들은 이 문제가 꽤나 심각했다.
당대에 스프라이트 기능을 탑재한 대표적인 기기인 MSX의 경우를 예로 들면 1화면에 표시 가능한 스프라이트 수는 32개까지지만 가로 4개까지 놓일 수 있어서 5개째부터의 스프라이트는 표시가 안된다. MSX는 스프라이트가 단색표시만 가능했기 때문에[3] 적어도 2개의 색은 사용해야 하는 중요한 오브젝트(주로 주인공 캐릭터)는 2개의 스프라이트를 겹쳐서 표현하는 기법도 널리 쓰였는데 이렇게 되면 안그래도 빡빡한 제약이 더욱 심해진다. 화면에 특정 스프라이트가 나오지 않으면 게임에 지장을 줄 가능성이 높으므로 이를 극복하기 위해 5개 이상의 스프라이트가 가로로 늘어서는 경우에는 번갈아가며 스프라이트를 출력하는 기법을 썼는데, 이런 경우엔 스프라이트가 깜빡이는 문제는 있지만 어쨌든 화면에 모두 출력은 되기 때문에 많이 사용된 기법이다. MSX2의 경우는 가로 제약이 8개로 완화되었고 라인마다 색상지정도 가능해져서 이런 깜빡임이 줄었다. 패미컴의 경우도 가로 제약이 8개이지만 패미컴의 스프라이트 기본 사이즈는 8x8 픽셀이기 때문에 16x16 픽셀을 기본 사이즈로 하는 MSX의 스프라이트와 같은 사이즈로 비교하면 가로 제약 수는 MSX1과 다름없어진다. 예를 들면 슈퍼 마리오 브라더스 에서 굼바 같은 적이 단체로 나올 때는 최대 3마리 까지만 나오는데 이는 마리오+굼바 3마리가 가로로 늘어선 상태가 패미컴의 스프라이트 출력 한계이기 때문에 깜박이는 문제를 피하기 위해서 더 많은 적이 나오지 않게 배치한 것이다. 다만 패미컴은 스프라이트에 최대 3색상을 넣을 수 있기 때문에 스프라이트를 겹쳐써야하는 MSX1보다는 형편이 좀 나았다.
이렇게 이야기하면 많이 안습한 옛날 기술 같지만 의외로 라인 버퍼 스프라이트는 네오지오나 X68000처럼 당대엔 고사양이었던 머신에서도 사용된 기술이다. 네오지오의 경우는 아예 배경 그래픽 영역을 별도로 두지 않고 전부 그냥 크고 아름다운 스프라이트를 붙여서 배경처럼 사용하는 것으로 해결하는 굉장한 방법을 사용했다.
4.2. 프레임 버퍼 방식의 스프라이트
1980년대 중후반부터 세가 같은 거대 아케이드 기업이 고사양 기판을 만들 때 사용하기 시작한 방식이다. 가정용 기기에서는 1989년 발매된 컴퓨터 FM TOWNS에서 처음으로 이 프레임 버퍼 방식의 스프라이트를 내장하였고, 콘솔에서는 1993년 발매된 3DO와 1994년 발매된 세가 새턴이 이 방식을 채택하면서 5세대 콘솔에서는 주류가 되었다.
원리는 간단하다. 더블 버퍼링의 원리와 거의 비슷한데, 스프라이트만 그려넣는 스프라이트 전용 프레임버퍼와 화면에 비표시된 상태(오프스크린)에서 그려넣을 프레임버퍼까지 2개의 프레임버퍼를 추가로 준비해서 1프레임 분량의 스프라이트를 다음에 표시할 오프스크린 프레임버퍼에 전부 그려넣는다. 전부 그려지면 현재 화면을 출력하는 온스크린 프레임버퍼와 오프스크린 프레임버퍼를 교환하면 그걸로 끝. 장점은 라인 버퍼와 달리 가로로 놓이는 스프라이트 개수에 근본적인 제약이 없어지므로 깜빡임이 전혀 생기지 않으며 전체 표현가능한 스프라이트 수도 VRAM의 전송 속도와 스프라이트를 담당하는 칩셋의 처리 속도가 올라가면 이에 따라서 선형적으로 올라간다. 이걸 CPU가 처리하느냐 전용 칩셋이 처리하느냐의 차이만이 있을 뿐 그냥 더블 버퍼링으로 비트맵 그래픽을 때려넣는 방법과 차이가 없다. 따라서 스프라이트의 확대/축소/회전 같은 이펙트를 구현하기에도 용이해진다. 기본적으로 스프라이트도 그냥 비트맵 데이터가 되므로 스프라이트 크기의 제약이나 스프라이트당 들어가는 색상의 제약도 의미가 없어진다. 기존의 라인 버퍼 방식 스프라이트가 가지는 한계들이 거의 사라진다고 보면 된다.
반대로 단점은 하드웨어 자원이 많이 들어간다는 점이다. 일단 프레임버퍼가 기본적으로 2개가 더 필요해지니 VRAM을 많이 먹고, 1프레임(1/60초) 안에 오프스크린 프레임버퍼에 1화면분의 스프라이트를 모두 올려야하므로 그래픽 칩셋(VDP)의 처리 속도도 빨라야 한다. 스프라이트 처리가 늦어지면 표시하고자 하는 프레임보다 밀려서 스프라이트가 출력되는 사태가 벌어진다. 초창기 세가 SYSTEM 기판의 경우엔 오프스크린 프레임버퍼를 두지 않고 '수직동기 내에 모든 스프라이트를 전송한다'는 설계로 만들어버리는 바람에 스프라이트 처리가 늦어지면 우선순위가 낮은 스프라이트가 우수수 사라져버리는 현상이 발생했다고.
이렇다보니 당대엔 정말 비싼 기판이나 채택한 방식이었고, PC 역시 FM TOWNS 같이 호화로운 사양을 지닌 기기에나 내장되었다. 콘솔 등에 내장되는 것도 메모리를 많이 먹기 때문에 5세대에 와서야 도입이 된 방식이다.
일본에서는 기존의 스프라이트 방식, 즉 라인 버퍼 방식만을 스프라이트로 인정하는 경향이 있었기 때문에, 원리적으로 다른 이 방식은 '유사 스프라이트'로 불리기도 하였다. 현재 와서는 프레임 버퍼 방식도 스프라이트로 보는 추세.
4.3. 소프트웨어적인 유사 스프라이트
스프라이트 기능은 없지만 기본적으로 하드웨어 스펙(CPU/RAM)이 높은 기기들에서 주로 사용한 방법이다. IBM PC 호환기종이 대표적으로 이 방식을 사용한 기기이며 현재의 PC 역시 스프라이트 관련 하드웨어는 존재하지 않지만 DirectX에서 스프라이트 기능이 있는 것처럼 사용할 수 있도록 소프트웨어로 처리하는 API를 제공한다[4].
원리적으로는 위의 프레임 버퍼 방식의 스프라이트와 동일하지만 스프라이트를 처리하는 전용 하드웨어가 없으므로 저 처리 과정을 모두 소프트웨어로 만들어서 '''CPU'''가 담당한다. 이렇다보니 기본적으로 하드웨어 성능이 높아야하는 프레임 버퍼 방식보다 더 많은 하드웨어 자원(특히 CPU의 처리속도)을 요구하며, MS-DOS 시대에 IBM PC 호환기가 하드웨어 성능에 비해 게임의 퀄리티가 떨어졌던 원인 중 하나도 이것이다. 그러다가 80286~80386급 CPU와 VGA 그래픽 카드가 일반화되는 1992~3년경 쯤이 되면 그냥 깡스펙의 상승으로 얼추 아미가 500 정도는 비슷하게 따라잡는다. 물론 아미가 500은 '''1985년'''에 나왔다. (...)
아무래도 프레임 버퍼에 비트맵 데이터를 다 얹어서 온/오프 버퍼를 교환하는 방식은 초창기의 PC 하드웨어로는 처리에 과부하가 걸리므로 부하를 줄이기 위해 많은 소프트웨어적 테크닉이 들어갔다. 예를 들면 화면 전체를 합성해서 교환하는 것이 아니라 표시가 갱신되는 부분만 합성해서 얹는다던지....그러나 근본적으로 이런 방법은 전체 버퍼를 교환하는 것에 비해 움직임이 자연스럽지 않은 문제가 있어 초창기 IBM PC의 액션/슈팅 게임들은 오브젝트의 움직임이 별로 보기 좋지 않은 작품이 많았다가 하드웨어 성능이 넉넉해진 90년대 중반 이후로 크게 개선되는 모습을 보인다. (컴퓨터 상황이나 게임의 내용이나 이식도 등의 차이는 있지만) 어느정도 높은 클럭의 펜티엄 정도면 괜찮은 이식 퀄리티의 콘솔 2D 게임 이식작들을 플레이할 수 있을 정도[5]. 물론 3D가 게임의 주류가 된 21세기에 들어와서는 2D 따위는 아오안이고 스프라이트도 CPU의 깡스펙으로 밀어버리는 게 1980~90년대의 전용 하드웨어보다 아득하게 빠른 시대가 되어버렸다보니 아무래도 좋은 이야기.
2020년 현재는 거의 대부분의 2D를 지원하는 게임엔진(게임메이커, RPG 만들기, 유니티 등)은 GPU를 사용하여 렌더링한다.
5. 현재
컴퓨터 성능이 좋아진 지금은 옛날처럼 스프라이트 이미지와 비트맵 이미지를 하드웨어적으로 따로 구별하진 않지만, 애니메이션 작업의 특성상 스프라이트는 배경과 분리되어 움직이는 물체에 쓰이는 만화적 이미지란 의미로 쓰이고 있다.
3D 그래픽이 주류인 2000년 이후가 되어서야 폴리곤을 몇 개 찍네 마네로 하드웨어의 성능을 평가하게 되었다. 6세대 이후의 콘솔에서는 별도의 스프라이트 기능을 내장하지 않는다. 하드웨어적인 스프라이트 처리 기능 따위는 빼버리고 평평한 폴리곤 1매에다 스프라이트로 쓸 텍스처를 입혀서 스프라이트처럼 굴리는 기술을 많이 사용한다. 물론 프로그래밍을 할 때는 래핑을 통해 스프라이트처럼 코딩하도록 되어있다.
2000년대 중반 이후 이 기법이 웹으로 넘어왔다. CSS를 이용하여 웹 페이지를 꾸미는 기법이 발전하면서, 스프라이트 형태로 된 통짜 이미지를 사용하여 버튼이나 메뉴가 눌리거나 마우스 오버로 하이라이트되는 것을 표현할 때 이미지를 보여 주는 좌표값을 변경하는 방식으로 구현하게 된 것. HTTP의 구조상 같은 크기의 이미지라도 여러 개의 이미지로 잘라서 호출하면 그 횟수만큼 오버로드도 늘어나므로 통짜 이미지로 만들어 웹 브라우저에 뿌려주는 이미지 개수를 줄이면 오버로드가 줄어들어 웹 페이지가 로딩될 때의 속도 향상도 기대할 수 있기 때문이다.
6. 관련 기술
6.1. PCG(Programmable Character Generator)
1980년대 초에 주로 사용된 그래픽 표현 방식의 하나이다. 컴퓨터에서 '''텍스트'''를 표시하는 방식을 응용한 방법으로 스프라이트처럼 동적인 오브젝트 표현에만 사용하는 방법은 아니고 초창기 아케이드 기판이나 MSX, 샤프 X1이나 SPC-1500, 코모도어 64 처럼 RAM이 비싸서 VRAM을 많이 달 수 없던 1980년대 초에 개발된 하드웨어가 많이 채용했다.
당시 컴퓨터에서 텍스트 화면을 표시할 때는 전체 화면을 8*8~16*16픽셀 정도의 타일 단위로 쪼개고 그 타일 크기만한 폰트를 미리 ROM이나 RAM에 저장해 놓은 뒤, CPU 각 화면의 타일마다 해당 폰트를 지정하는 값만 넣어주면 전용 회로나 프로세서가 매 프레임마다 1라인씩 그려내는 방법을 사용했다. 여기서 폰트를 문자 모양 대신 타일 이미지로 바꾸면 바로 PCG가 된다. 표현 능력의 확장을 위해서 기본적인 텍스트 화면보다 비디오 메모리를 좀 더 할당해서 타일 내 표현 가능한 색상을 늘린다던지 하는 방식을 쓰기도 했지만 기본은 저렇다.
일단 장점은 메모리를 적게 먹는다는 것. 일단 구조상 비트맵을 쓰는 것보다 메모리도 많이 덜 들고 따라서 전송대역폭도 적게 먹어 느린 CPU와 작은 VRAM으로도 그럴듯한 표현이 가능했다. 거기에 이미지의 크기 대비 용량이 적으므로 스프라이트 없이도 움직이는 오브젝트를 구현하기도 쉬웠다.
단점이라면 이미지를 만드는 방식상 비트맵처럼 원하는 위치의 픽셀에 원하는 색상을 넣어 그림을 만드는 게 어려웠고 이미지 작성에 다양한 제약이 있었다. 예를 들면 MSX의 Screen2의 경우는 가로 8픽셀 단위를 기준으로 2색씩만 배치가 가능하다. 그리고 움직이는 오브젝트를 만드는 경우 근본적으로 텍스트 화면에서 문자를 출력하는 방식을 응용한 것이라 픽셀 단위가 아닌 정해진 타일 크기 단위로만 움직일 수 있어 스프라이트에 비해서는 움직임이 거칠다는 단점이 있었다. 또한 배경 이미지와 움직이는 오브젝트를 겹치는 방법이 아니므로 움직이는 오브젝트의 공백 부분에 배경 이미지가 아닌 검정색, 혹은 그냥 배경 이미지의 주색이 단색으로 들어가게 된다.
MSX의 경우는 기본적인 그래픽은 PCG였지만 스프라이트도 쓸수 있었기 때문에 움직임이 많고 크기가 작은 유닛(플레이어 유닛 등)은 스프라이트로, 크기가 크거나 움직임이 많지 않은 유닛은 PCG로 분산해서 표현하는 방법을 썼다. 전술했듯 기술적 이유로 한번에 출력할 수 있는 스프라이트 수에는 제약이 있었기 때문에 배경이 아니라 움직이는 유닛이더라도 PCG인 경우가 꽤 많았다. MSX2의 경우도 비트맵 그래픽을 쓸 수 있었지만 VDP의 속도가 그리 빠르지 않아 게임에 그대로 사용하기엔 부하가 컸기 때문에 게임에서 크기가 큰 유닛은 움직임이 없는 경우가 많았는데 스페이스 맨보우 같은 게임은 이를 극복하기 위해 절묘하게 화면을 분할하여 한 화면에 PCG+비트맵+스프라이트를 모두 사용하는 당시로선 놀라웠던 테크닉을 선보이기도 했다.
1980년대 이후의 거의 대부분의 2D 메인의 아케이드 및 콘솔에서는 스프라이트 외에도 'BG(Background) 레이어' 등으로 불리는, 주로 배경 표시로 사용되는 그래픽 레이어를 갖추고 있었는데, 기본 베이스는 PCG이며 여기에 이것저것 기능들을 추가한 것에 가깝다. 주로 다음과 같은 기능들이 추가되었다.
- 실제로 출력되는 화면보다 더 넓은 화면을 VRAM에 담을 수 있고, 이를 하드웨어에서 어느 구간을 출력할 지 설정할 수 있게 되었다. 그리고 이걸 매 프레임마다 x축 또는 y축으로 조금씩 구간을 옮겨가도록 구현하는 것이 하드웨어 스크롤이다.
- VRAM이 커지면서 여러 개의 화면을 담을 수 있고, 이를 특정 순위로 겹쳐서 표현할 수 있다. 주로 '레이어' 등으로 불리는 방식이며, 각 레이어마다 하드웨어 스크롤의 속도를 다르게 하면 좀더 배경이 입체적으로 스크롤되는데 이것을 보통 다중 스크롤(Parallax Scrolling)이라 부른다.
- 전용 하드웨어가 1라인을 그릴 때마다 CPU에 인터럽트를 보내서, 그떄마다 CPU에서 라인마다 스크롤 속도를 변경하는 방식으로 더욱 입체적인 표현이 가능해졌다. 패미컴같이 레이어가 하나인 하드에서 슈퍼 마리오브라더스 3 등에서 보여주는 윗부분은 실제로 스크롤되는 게임 화면, 밑부분은 고정된 UI 화면을 그리는 방식. 스트리트 파이터 2에서 맵 바닥이 입체적으로 스크롤 되는 방식, 슈팅 게임 등 몇몇 게임에서 보여주는 화면이 울렁거리는 효과 등은 전부 이 인터럽트를 사용하여 구현하는 것.
6.2. 다관절 캐릭터
뱀이나 기린같이 긴 캐릭터의 스프라이트는 기술적으로 만들기가 매우 어려웠으므로 구슬 모양의 스프라이트를 만들어 여러 개를 이어붙이는 형식을 사용하기도 했다. 흔히 말하는 '다관절' 캐릭터가 이런 방식을 사용한 것으로 1980년대에 굉장히 많이 사용된 연출이다. 복잡한 움직임을 낮은 사양의 하드웨어에서 비교적 쉽게 표현가능하다는 이점이 있다. 이것으로 유명한 작품은 사라만다[6], 스페이스 해리어 등이 있다. 사실 스프라이트로 표현해야 할 필연적인 이유는 없으므로 MSX처럼 스프라이트 제약이 빡빡한 기기에서는 PCG나 비트맵 그래픽 등으로 다관절을 연출하는 경우도 많았다.
7. 오해
2D 횡스크롤 뷰로 보면 2D 게임, 도트 게임, 장인정신 등으로 오해를 사는 경우가 종종 있는데, 2D로 보인다고 그것이 도트 작업물이라는 것은 아니다. 고전적인 스프라이트 작업은 현재는 극히 간단한 게임에서만 사용되고 있으며 2010년대 이후로는 적은 수의 폴리곤 혹은 관절 뼈대에 그림을 얹은 다음 각 부분을 움직이는 애니메이션을 더하여 스프라이트처럼 보이게 만드는 이른바 '스파인' 기술이 많이 보편화되었다.[7] 2000년대 중반만 해도 스파인 그래픽은 생소했지만 시대의 흐름에 따라 종래의 스프라이트보다 스파인이 게임개발에 더 효율적으로 비쳐진것을 보면 격세지감.
물론 기본 포즈의 동작을 벗어나는 모습을 보여줘야 한다면 그에 대한 그림도 다 그려야 하는 것은 여전하다.
8. 관련 문서
- 도트
- 팔레트스왑
- spriters-resource. 현존 최대급 스프라이트 데이터 마이닝사이트다.
9. 스프라이트 및 도트 커뮤니티
2000년대 초까지는 코믹스록, 스프라인트, 어나더메가 등 록맨 위주의 스프라이트를 다루는 커뮤니티가 다양하게 존재했으나 2000년대 후반에 이르러 전부 침체되거나 사라진 상태로 거의 모든 관련 커뮤니티 망했다고 봐도 무방하다. 애초에 스프라이트가 꽤나 마이너한 분야라서 그런 듯. 2010년대 초에 네이버 카페중에서 디지몬, 포켓몬이나 메탈슬러그 등을 다루는 카페가 다시 살아나는가 싶었으나 거의 대부분이 침체되었다. 겨우 운영되고 있는 카페들도 정작 제대로 활동되고 글 리젠도 잘되는 곳은 많지 않다. 확실히 살아있는 도트 커뮤니티는 다섯 손가락 안에 꼽을 수준.
[1] 네오지오처럼 무식하게 큰 오브젝트를 스프라이트로 뿌리다 못해 배경도 스프라이트로 출력하는 설계를 한 기기도 있고 슈퍼패미컴 쯤 되면 128*128 사이즈 정도까지는 표시가 가능해지지만 스프라이트라는 것이 처음 나온 시기인 1980년대 초중반 대부분의 하드웨어에서 단위 스프라이트 크기는 8*8~16*16 정도로 비교적 작았다. 큰 유닛을 스프라이트로 표현하는 경우는 여러 개의 스프라이트를 타일처럼 붙여서 표시하는 것이 기본.[2] 그러나 DS도 게임보이 어드밴스 하위호환을 위해 탑재한 칩셋을 이용한다. 이 칩셋은 와이파이 커넥션 등 하위호환뿐만 아니라 다른 역할도 한다[3] 스프라이트용으로 할당된 메모리가 적어서 그렇다. 1화면에 표시 가능한 스프라이트 수가 32개로 제약되는 것도 같은 이유.[4] DirectX 7.0까지 있었던 2D 그래픽 API인 DirectDraw는 하드웨어 가속을 지원하긴 했지만 해당 API 자체가 매우 기초적인 기능밖에 없기 때문에 그 외 부분은 자체적으로 알고리즘으로 구현해야 했던지라, 일반적으로는 거의 하드웨어 가속 기능을 상정하지 않고 게임을 개발하는 일이 대부분이었다.[5] 한국에서 가장 많은 수요가 있던 콘솔 게임 이식작 중 하나인 록맨 X4 PC판의 최소사양이 펜티엄 133Mhz였다.[6] 대표적인 예시로 1면 보스인 브레인 골렘의 팔 부분이 이런 방식이다.[7] 대표적으로 바닐라웨어의 액션 게임들, 더 럼블피쉬가 있으며 관련 툴로는 spine2d가 있다.