카트리지 기반 게임은 어떻게 프로그래밍 되었습니까? [닫은]

나는 SNES, N64, Atari와 같은 생각을하고 있습니다 ... 오늘날 DS조차도 생각합니다.

SNES 게임은 일반적으로 4MB 이상의 공간을 차지하지 않았으며 N64 게임은 보통 32-64MB의 데이터였습니다.

요즘에는 "hello world!"를 간신히 컴파일 할 수 있습니다. 결과 컴파일없이 1.21 기가 바이트를 생성하는 프로그램 !! 데이터 (제쳐두고, 오늘날의 파일은 그 당시의 일부 기술에 비해 최대 수톤의 공간을 차지합니다.)

그래서 ... 그들은 어떻게 했습니까?

• 그들은이 게임들을 무엇으로 프로그래밍 했습니까? ASM? ASM의 모든 것!
• 그래픽은 어떻게 만들어 졌습니까? 스프라이트 시트를 만들고 어떤 경우에는 (N64와 같은) 3D 모델을 만들기 위해 어떤 기술이 필요 했습니까?
• 이 카트리지의 여러 레벨, 캐릭터, 퀘스트 및 아이템에 어떻게 맞습니까? 내 말은, SNES의 Super Mario World는 약 1MB의 시계를 가지고 있으며 96 개의 이탈이 있습니다! Ocarina of Time, Banjo-Kazooie, DK64 및 기타 몇 가지 게임은 64MB 미만을 차지하며 거대한 세계, 수많은 콘텐츠 및 3D 모델을 가지고 있습니다!

내 질문이 조금 밖에 보이지 않으면 미안하지만 많은 훌륭한 타이틀이 작은 저장 공간에 적합하다는 사실에 놀랐습니다.

아주 작고 사소한 파일과 게임조차도 최소한 몇 MB를 차지하기 때문에 GoldenEye 007과 같은 거대한 수준의 데이터가 거의 모든 데이터를 처리하지 못한다고 생각하면 정말 매력적입니다.

공간을 차지하는 것은 예술 및 오디오 리소스이며, 프로그래밍 언어의 선택은 하드웨어를 최대한 활용하는 것에 관한 것입니다.

N64를 예로 사용하면 대부분의 타사 게임은 8, 12 또는 16Mb였습니다. 32 & 64Mb 게임은 대부분 닌텐도에서 비롯 되었기 때문에 다른 사람들에게 큰 장바구니에 담기에는 너무 비쌌습니다. 그것은 작게 들리지만 예술 자산과 최종 시각적 결과도 마찬가지입니다. 320x240으로 렌더링되는 대부분의 N64 게임은 현재 1280x760 이상이 아니라는 점을 기억해야합니다. 이러한 작은 출력 해상도로 텍스처와 스프라이트는 오늘날보다 훨씬 작습니다.

N64의 작은 텍스처 캐시로 인해 대부분의 텍스처는 4/8 비트 팔레트 (일명 16/256 색상)의 32x64 픽셀이었습니다. 질감과 정점 색상을 혼합하여 추가 색상 세부 사항을 수행했습니다. Banjo 게임이 이에 대한 좋은 예입니다.

오늘날 언리얼 엔진 게임에서 하나의 돌은 여러 512x512x24bpp 또는 심지어 32bpp를 갖습니다. 또한 단일 확산 텍스처 대신 일반 맵, 스페 큘러 마스크, 반사 마스크, 반사 큐브 맵 등이 있습니다. 따라서 4Kb의 텍스처를 사용했던 오브젝트는 이제 몇 MB의 데이터로 덮여 있습니다.

오래된 게임은 또한 엄청난 양의 예술을 재사용합니다. Super Mario Bros.의 수풀은 구름과 같은 스프라이트이고 언덕은 버섯과 동일합니다. 다른 캐릭터는 같은 예술 자원의 색상이 바뀐 버전입니다. 이 모든 것은 카트에 있던 각 텍스처 또는 스프라이트에서 더 많은 사용량을 얻었습니다.

오디오는 현대 게임의 또 다른 큰 차이점입니다. 예전에는 거의 모든 것이 시퀀스 트랙으로 이루어졌습니다. 이제 음악 트랙, 음성 및 사운드 효과가 다양한 압축 오디오 형식으로 저장됩니다. 압축되지 않은 데이터보다 확실히 작지만 시퀀스 데이터에 비해 훨씬 더 큽니다.

NES (및 SNES가 너무 많음)의 기본 개요는 다음과 같습니다. 나는 NES 게임을 쓰지 않았지만 NES 에뮬레이터 (Graybox)를 작성했으며 오래된 카트를 상당량의 rev-engineering했습니다.

프로그래밍 언어에 관해서는 그렇습니다. 모두 어셈블리였습니다. NES 프로그래밍은 하드웨어 인터럽트, DMA 포트, 뱅크 스위칭 등으로 직접 작업하는 것을 의미했습니다. 다행히도 6502 (또는 2A03) 프로그래밍은 매우 쉽습니다 [1] :

• 레지스터가 거의 없습니다 : A, X 및 Y. 주로 후자 2 개는 인덱싱 및 반복에만 사용할 수 있습니다.
• 명령 세트는 작고 대부분 간단합니다
• 메모리가 많지 않은 경우 : 기본 RAM은 2KB이며 배터리 옵션 8KB 확장을 지원합니다. 이 2KB 중에서 256 바이트는 스택 용으로 예약되어 있으며 페이지 0 (처음 256 바이트)은 특별한 주소 지정 모드로 인해 가장 많이 사용되는 포인터와 값을 저장하려는 위치입니다.

이 3 가지 기능은 함께 작업하면서 기억하기에 충분한 환경을 만듭니다. 예, 모든 메모리를 직접 관리하지만 기본적으로 모든 작업이 진행되는 위치에 대한 전체 맵을 작성하고 2K에 대해서만 걱정하면되므로 맵이 크지 않다는 것을 의미합니다. 모눈 종이. 좀 더 계획하고 RAM과 ROM (카트리지의) 위치에 변수와 상수를 정적으로 할당해야했습니다.

카트리지 데이터가 CPU의 주소 지정 가능한 한계를 초과하면 비트 트릭을 얻습니다. 64KB는 하위 32KB가 스톤으로 설정되어 모든 종류의 하드웨어 포트 및 RAM에 매핑됩니다. 이것은 뱅크 스위칭이 작동하는 곳인데, 이는 ROM의 한 부분을 더 높은 32KB 주소 공간에 (일부) 매핑하는 것을 의미합니다.

이것은 프로그래머가 원하는대로 사용할 수 있지만, 예를 들어, 각 레벨에 대한 모든 레벨 데이터, 메타 데이터 및 코드가 카트리지의 별도 8KB 메모리 영역에 채워진 3 레벨 게임이있을 수 있습니다. 레벨은 예를 들어 초기화, 프레임 업데이트 등을위한 콜백을 가질 수 있습니다. 레벨을 "로드"하는 것은 8KB 메모리 청크 (예 : 0xC000)를 매핑하는 것을 의미합니다. 그런 다음 초기화 루틴이 항상 0xC000에 있고 프레임 업데이트 루틴이 0xC200에 있고 레벨 데이터가 0xC800에 시작되도록 지정할 수 있습니다. 다른 메모리 청크에 저장된 게임의 메인 코드는 오른쪽 청크를 바꾸고 적절한 시간에 절대 주소 0xC000 및 0xC200으로 점프하여 레벨 변경을 제어합니다.

Wrt 그래픽 데이터 : NES의 타일 데이터는 2 비트 8x8 픽셀 맵입니다. 배경의 경우 1/4 해상도 2 비트 레이어와 결합됩니다. 이 4 비트 값은 16 개의 항목 팔레트에 색인화되었으며 53 개의 유효하고 독특한 색상을 사용할 수 있다고 생각합니다. 스프라이트는 또한 2 비트 픽셀 데이터를 사용했으며 각 스프라이트는 자체의 2 비트 그룹 인덱스를 다시 지정하여 4 비트 PAL 인덱스를 형성했습니다. 화면의 BG 이미지는 32x30 배열의 타일 인덱스 번호입니다.

기본적으로 많은 반복 및 인덱스를 인덱스로 사용하면 데이터를 매우 작게 유지할 수 있습니다. 레벨 데이터는 종종 타일 색인의 수직 막대로 저장되었으며 수직 막대도 재사용되기 때문에 색인화되어 카트리지에 한 번만 저장되었습니다. 간단한 데이터 압축 기술도 비슷하게 작동합니다. 이로 인해 Mario 1은 여유 공간이있는 32KB의 데이터와 8KB의 비트 맵 데이터가되었습니다.

개발 환경과 관련하여 사람들이 인증을받을 수있는 고대 컴퓨터에서 작업을 위해 EEPROM 버너에 연결된 일부 사진을 보았습니다. SNES 시대가 지나기 전까지는 툴 지원 디버깅이 실제로 가능하지 않았다 [2]. 이것이 많은 오래된 게임에 "명백한"버그가있는 주된 이유이며, Gameshark와 같은 것들이 그들이하는 일을 할 수있는 이유입니다. 플레이어 체력은 항상 mem-location X에있을 것이므로 항상 100이되도록 할 수 있습니다.

이런 것들이 흥미로워지면 http://wiki.nesdev.com/w/index.php/Nesdev_Wiki 를 보길 권한다. NES는 온라인에서도 찾을 수있는 프로그래밍 과정이 꽤있다.

이 간단한 개요가 80 년대 게임 개발에 대한 통찰력을 얻었기를 바랍니다.

[1] 상대적으로 말하기. 또한 Graybox 자체를 약 85 % PowerPC 어셈블리로 작성했을 때 편견입니다. [2] FF6 기사 만들기 : http://www.edge-online.com/features/the-making-of-final-fantasy-vi/

당신이 묻는 거의 모든 질문에 많은 하위 주제가 있습니다. 최적화는 그 자체로 거대한 분야이며 탐구해야 할 것이 많이 있습니다.

이런 종류의 최적화에 관심이 있다면 데모 씬 입니다. 데모 씬과 관련 예술 문화 중 일부는 가능한 한 적은 공간을 차지하는 컴퓨터를 위해 복잡한 예술을 만들려고 시도하는 것에 대해 오랫동안 궁금해했습니다. 그들 중 많은 사람들이 "트릭"의 일부 또는 전부를 어떻게 수행했는지에 대한 정보를 갖게 될 것입니다.

게임이나 장르에 특정한 "트릭"과 "핵"이 있지만 종종 상식이 교묘하게 혼합되어 있습니다. 종종 약간의 "행운"이 수반되고 팀은 그들이 수행하고있는 한계를 아는 것 (아마도 프로세스 전반에 걸쳐 한계를두고 계속 머리를 치는)과 가능한 트레이드 오프를 알고 필요한 거래를 기꺼이하려고합니다. 한계를 달성하기 위해-오프 및 희생.

다음은 팀이 작은 규모의 게임을하는 데 도움이 될 수있는 몇 가지 사항입니다.

• 가능한 재사용 : 동일한 스프라이트를 재사용하고 단일 스프라이트 이미지 (예 : 반사, 회전, 팔레트 이동)로 쉽게 만들 수있는 변형으로 공간을 절약 할 수 있습니다. 코드, 음악 및 게임의 거의 모든 것들에 대해서도 마찬가지입니다.
• 압축 가능한 기능 : 여러 가지 압축 체계가 있으며 사용할 체계를 알면 공간을 크게 절약 할 수 있습니다. 실행 길이 인코딩과 같은 간단한 압축 체계조차도 놀라운 차이를 만들 수 있습니다. 뿐만 아니라 개별 파일 형식에 대한 압축 체계 (및 정확하게 압축되지 않는 대체 형식)가 있으며 종종 품질이 저하됩니다. 예를 들어 웨이브 / CD 오디오 파일은 약간의 정보 손실로 MP3 파일로 압축 될 수 있습니다. 또한 MIDI 및 샘플러 기반 MOD와 같은 파일 형식은 공간을 덜 차지하는 대체 형식이지만 음악을 완전히 다르게 인코딩하고 사운드를 좋게하려면 다른 기술이 필요합니다.
• 필요없는 것을 잃어 라 : 더 싸게 할 수 있습니까? 예를 들어, 더 적은 픽셀 (또는 다각형)로 캐릭터의 "개성"을 얻을 수 있습니까? 타일 ​​배치는 디자이너가 정확하게 정의해야합니까, 아니면 프로그램 코드에서 임의로 생성 할 수 있습니까?
• 코드가 더 저렴합니다. 코드 컴파일에 일반적으로 얼마나 많은 공간이 필요한지에 대한 농담을 했음에도 불구하고 ( '플랫폼'이 수년에 걸쳐 증가한 이유와 필요한 경우 축소하는 방법이 있습니다), 그러나 일반적으로 알고리즘 / 프로 시저 / 코드 내에서 쉽게 할 수 있다면, 그 접근 방식은 비슷하지만 다른 모양 / 느낌의 자산을 수정하고 재사용하는 것이 더 쉬울 것입니다. 프랙탈은 특히보기 쉬운 예입니다. 복잡한 프랙탈 이미지는이를 생성하는 수학 공식과 비교하여 많은 공간을 차지합니다. 또한 수학 공식에는 유사하지만 때로는 놀랍게도 다르게 보이는 이미지를 생성 할 수있는 매개 변수가있을 수 있습니다.

어쨌든, 이렇게 많은 양의 질문에 대해, 위의 주제 중 일부가 더 많은 것을 배우기위한 좋은 출발점이되기를 바랍니다.

한 가지 확실한 점은 그것이 N64 이후 시대에 여전히 있는지 확실하지 않지만 SNES와 N64는 종종 상당한 공간을 절약하고 배경이 종종 가짜 인 사전 렌더링 된 예술을 다른 3D 객체에서 텍스처를 재사용하는 것입니다. 또 다른 트릭은 테두리 배경 안개를 만드는 것입니다.

샌프란시스코 러쉬 아케이드는 샌프란시스코 러쉬 아케이드가 없었던 밀도를 변경할 수 있지만 N64 버전에 비해 트랙 1의 골든 게이트 브릿지를 볼 수 있지만 샌프란시스코 러쉬 N64는 항상 안개가 낀다.

또한 게임은 종종 Zelda Ocarina of Time과 같은 음악을 재사용하여 음악을 많이 재사용합니다. Banjo Kazooie / DK64가 테마 내에서 테마를 갖는 방식과 같은 더 나은 일을 할 수 있었기 때문에 성가신 것을 발견했습니다!

시간의 Zelda Ocarina는 수중에 가거나 상점 테마의 악기가 Kokiri Forest 상점과 뿔에 플루트와 바이올린을 사용할 외부 영역을 반영하도록하면 Hyrule Overworld를 가질 수 있었고 테마의 수중 버전을 가질 수있었습니다. Hyrule Castle Town 상점의 트럼펫과 Goron 마을의 드럼

PC의 3D 모듈은 라이브러리로 컴파일되어 프로그램의 압축을 풀기 위해 프로그램을 사용하여 빠르게 액세스 할 수 있지만 ROM 기반 Nintendo의 경우인지 확실하지 않습니다. PC는 컴퓨터가 시작되지 않는 지점까지 정보를 덮어 쓸 수있는 가정에 항상 머 무르지 않는 지저분한 방으로 들어가는 RAM입니다.

게임 콘솔은 모든 것이 할당 된 공간에 저장되는 ROM이므로 게임을 켤 때마다 할당 된 공간에서 파일이 남아있을 것입니다.