Game Boy Advance와 같은 장치는 프레임 속도를 어떻게 달성합니까?


31

저는 AVR 마이크로 컨트롤러와 소형 OLED 디스플레이를 기반으로 한 핸드 헬드 게임 장치를 설계했습니다.

128x64 픽셀의 흑백 디스플레이로 시작하여 초당 60 프레임 이상으로 편안하게 그릴 수 있습니다.

나는 최근에 약 4 FPS 만 달성 할 수 있다고 생각하지 않고 128x128 픽셀의 RGB OLED를 사용하도록 재 작업했습니다. 몇 가지 생각과 신중한 리팩토링 후에 다른 일을 너무 신경 쓰지 않으면 ~ 12fps까지 얻을 수 있습니다!

내 질문은-GBA (Game Boy Advance)와 같은 장치가 어떻게 거의 60fps의 프레임 속도를 얻었습니까? 별도의 '그래픽 프로세서'에 대해 생각했지만 여전히 디스플레이 데이터를 전송하는 데 병목 현상이 발생한다는 것을 깨달았습니다.

또한이 화면의 대부분은 vestigial 8 비트 병렬 인터페이스를 사용하는 것에 대해 궁금했습니다. 현대 MCU에는 직렬 및 비트와 같은 하드웨어 병렬 인터페이스가 없습니다. 두드리는 것은 많은 속도 이득을 먹을 것입니다.

다른 옵션이 있습니까?

현재 USART-SPI를 통해 SSD1306 OLED 컨트롤러에 연결된 ATmega1284P를 사용하고 있습니다. 이것이 흑백 버전입니다.

컬러 화면은 원래 하드웨어 SPI에 연결되지 않은 SSD1351입니다. 충분한 차이를 만들 것이라고 확신하지 못했습니다. 전체적으로 너무 느립니다.

더 빠른 MCU를 얻을 수 있다는 것을 알고 있지만 다른 옵션을 살펴보고 싶습니다. GBA 프로세서는 1284보다 훨씬 느립니다!


6
"디스플레이 데이터를 전송하는 데 여전히 병목 현상이 발생합니다." DSI에는 최대 1.2Gbits / sec의 레인이 각각 4 개 있습니다. 나머지 계산은 당신에게 맡깁니다.
Oldfart

1
비디오 게임 장치의 그래픽과 마찬가지로 그래픽을 처리하는 메모리가 있습니다. 웹 사이트 에 따르면 그래픽, 사운드 등의 주소 위치가 있습니다. 지침이 저장됩니다. 성능 시간과 충돌을 일으킬 수있는 데이터가 많지 않다고 가정하면 해당 명령을 실행하여 그래픽 데이터를 쉽게로드합니다.
KingDuken

5
그것의 컨트롤러없이 디스플레이를 구입하고 자신의 컨트롤러를 만들
old_timer

4
@immibis : 거의 끔찍한 I2C 또는 SPI 기반 컨트롤러입니다. 애호가의 물건은 규모의 경제로 인해 $ 20의 friggin '400 + dpi iPhone 화면을 얻을 수있을 때와 같이 값 비싼 느린 물건으로 가득합니다.
R ..

6
@R .. 나는이 애호가 컨트롤러의 이유는 거의 모든 프로세서와 인터페이스 할 수 있기 때문에 쓸모없는 것처럼 들리기 때문에 지적하고 싶습니다. 당신은 전혀 아이폰 화면에 쉽게 인터페이스 할 수 없습니다. 전용 또는 맞춤형 그래픽 프로세서에 연결될 수 있습니다.
user253751

답변:


64

다른 답변은 추상적 수준 (하드웨어)에서 귀하의 질문을 잘 다루지 만 GBA에 대한 실제 경험이 있으면 더 자세한 설명이 가치가 있다고 생각했습니다.

GBA에는 그래픽 프로세서가 비디오 RAM을 해석하는 방법을 제어하는 ​​데 사용할 수있는 많은 그리기 모드 및 설정이 있었지만 한 가지는 피할 수없는 것입니다 : 프레임 속도. 그래픽 프로세서는 거의 (아래에 더 자세히 설명 된) 일정한 루프로 화면에 그려졌습니다. (이것은 귀하의 질문에 가장 관련성이 높은 부분 일 것입니다.)

한 번에 한 줄씩 그리며 각 줄 사이에 아주 짧은 휴식을 취합니다. 프레임의 마지막 선을 그린 후에는 30 개의 선을 그리는 데 걸리는 시간과 거의 같습니다. 그런 다음 다시 시작하십시오. 각 라인의 타이밍 및 각 프레임의 타이밍은 모두 미리 결정되어 석재로 설정되었습니다. 여러 가지면에서 그래픽 프로세서는 실제로 그 시스템의 마스터였으며, 준비 여부에 관계없이 계속 수행 할 것이기 때문에 동작을 중심으로 게임을 작성해야했습니다.

화면을 적극적으로 밀고있는 시간의 약 75-80 %. 동일한 작업을 수행하면 어떤 프레임 속도를 달성 할 수 있습니까?

그 시간의 80 %는 CPU가 사용자 입력을 처리하고, 게임 상태를 계산하고, 현재 화면에서 벗어난 VRAM 영역에 스프라이트 / 타일을로드해야했습니다 (또는 현재 그려지는 라인에는 포함되지 않음).

프레임 사이의 20 %는 모든 CPU가 비디오 설정 또는 RAM을 조정하여 다음 프레임 전체에 영향을 미쳤습니다.

각 라인의 끝에서 그래픽 프로세서는 라인 동기화 인터럽트를 CPU로 보냅니다. 이 인터럽트는 몇 개의 스프라이트 또는 몇 개의 배경 레이어에서 설정을 조정하는 데 사용될 수 있습니다 (이것은 각 선 사이의 사각형 마스크 중 하나의 크기와 위치를 변경하여 원추형 스포트라이트와 같은 효과를 얻는 방법입니다. 하드웨어와 관련하여 모든 영역은 직사각형입니다.). 그래픽 프로세서가 다음 라인을 그리기 시작하기 전에 이러한 업데이트를 작게 유지하고 완료해야합니다. 그렇지 않으면 결과가 나빠질 수 있습니다. 이 인터럽트를 처리하는 데 소비 된 시간은 CPU 처리 시간의 80 %로 단축되었습니다 ...

이 시스템을 최대한 활용 한 게임의 경우 CPU 나 그래픽 프로세서가 실제로 중단되지 않았습니다. 각각은 다른 사람이 현재 보지 않은 것을 업데이트하면서 루프 주위에서 다른 사람을 쫓고있었습니다.


5
환영합니다.
Mindwin

2
Nintendo DS와 같은 일부 "최신"시스템은 VCOUNT 레지스터를 추가하여 다음 프레임을 구성 가능한 시간 (일반적으로 멀티 플레이어 게임 동기화를 돕기 위해) 지연시켜 고정 프레임 속도 제한을 극복했습니다.

21

초기 PC 및 거의 모든 가정용 컴퓨터와 구별되는 모든 게임 콘솔의 주요 기능은 하드웨어 스프라이트 였습니다.

연결된 GBA 프로그래밍 가이드는 메인 프로세서 관점에서 어떻게 작동하는지 보여줍니다. 플레이어, 배경, 적 등을 나타내는 비트 맵이 메모리의 한 영역에로드됩니다. 메모리의 다른 영역은 스프라이트의 위치를 ​​지정합니다. 따라서 매 프레임마다 모든 비디오 RAM을 다시 쓰지 않고 많은 명령이 필요하므로 프로세서는 스프라이트의 위치 만 업데이트하면됩니다.

그런 다음 비디오 프로세서는 픽셀 단위로 작동하여 해당 지점에서 그릴 스프라이트를 결정할 수 있습니다.

그러나 이것은 두 포트 사이에 공유되는 이중 포트 RAM이 필요하며 GBA에서 비디오 프로세서는 기본 ARM 및 보조 Z80 프로세서와 동일한 칩에 있다고 생각합니다.

(1) 주목할만한 예외 : 아미가


아주 초기의 아케이드 게임은 듀얼 포트 RAM이 아니라 그래픽 프로세서와 관련된 ROM에 스프라이트를 가졌습니다. 초기 콘솔에서도 마찬가지 였다면 실마리는 없습니다. 물론 그렇게했을 수도 있습니다.
TimWescott

@TimWescott GBA에는 여러 드로잉 모드가 있었으며 가장 경험이 많지 않으므로 보편적으로 적용되지는 않지만 해당 모드 중 어느 것도 ROM에 직접 액세스 할 수 있다고 생각하지 않습니다 (카트리지에서). 타일 ​​/ 스프라이트 / 팔레트 데이터는 ROM에서 비디오 메모리로 전송되어야했고 그래픽 프로세서는 거기서부터 작업했습니다.
Mr.Mindor

@ Mr.Mindor 명확하지 않은 경우 죄송합니다. GB 또는 GBA가 어떻게 수행했는지에 대해서는 잘 모르고 있습니다. 난 그냥 우리 모두가 시간에 ***가 궁금했다가, 다시 후반 70 년대와 80 년대 초 정말 초기 닌텐도 아케이드 게임에 대한 의견을했다 것을.
TimWescott

@ TimWescott : 문제의 ROM이 Game Paks 내에 있지만 NES에서도 마찬가지라고 생각합니다.
supercat December

19

"제 질문은-GBA와 같은 장치가 어떻게 거의 60fps의 프레임 속도를 달성 했습니까?"

그 질문에 답하기 위해 그래픽 프로세서로 문제를 해결했습니다. Game Boy가 스프라이트 그래픽을 사용했다고 확신합니다. 최상위 레벨에서, 그래픽 프로세서는 배경 이미지, 마리오 이미지, 공주 복숭아 이미지 등을로드합니다. 그러면 메인 프로세서는 "이것으로 배경 오프셋 표시"와 같은 명령을 실행합니다. x와 y에서 많이,이 x, y 위치에서 Mario 이미지 # 3을 오버레이합니다. "등입니다. 따라서 메인 프로세서는 각 픽셀을 그리는 것과 전혀 관련이 없으며 그래픽 프로세서는 경기. 각각은 필요한 작업에 최적화되어 있으며 결과는 많은 계산 능력을 사용하지 않고도 꽤 좋은 비디오 게임입니다.


7
이것을 "그래픽 프로세서"라고 부르면 그 기능이 과장되어 자체 CPU가 있다는 것을 시사합니다. 비디오 컨트롤러 일 뿐이며 기본적으로 복잡한 시퀀서입니다. 가로 및 세로 픽셀을 계산할 때 제목 및 / 또는 스프라이트 데이터를 가져 와서 시프트 레지스터에 넣고 시프트 레지스터의 출력을 출력 픽셀에 결합합니다. 실제 "GPU"그래픽 프로세서와 같은 프로그램을 실행할 수 없습니다.
로스 릿지

14

GBA는 꽤 느린 프로세서를 가지고있었습니다. ARM7은 매우 훌륭합니다. 그들은 단지 느리게 달렸고 자원없이 옆에 주었다.

그 시점과 그 이전에 많은 Nintendo 게임이 사이드 스크롤러였던 이유가 있습니다. 하드웨어. 그것은 모두 하드웨어에서 이루어집니다. 여러 레이어의 타일과 하나 이상의 스프라이트가 있었고 하드웨어는 해당 테이블에서 픽셀을 추출하고 디스플레이를 구동하기 위해 모든 작업을 수행했습니다.

당신은 타일 셋업을 빌드하고 타일 맵인 작은 메모리를 가졌습니다. 왼쪽 아래 타일이 타일 7이 되길 원하십니까? 해당 메모리 위치에 7을 넣습니다. 다음 타일이 타일 19가되기를 원하십니까? 타일 ​​세트에는 활성화 한 각 레이어에 19 등을 넣습니다. 스프라이트의 경우 x / y 주소를 설정하기 만하면됩니다. 일부 레지스터를 설정하여 하드웨어를 조정하고 나머지를 처리하여 스케일링 및 회전을 수행 할 수도 있습니다.

모드 7, 내가 기억한다면 픽셀 모드 였지만 픽셀의 색상을 덮는 바이트를 넣고 하드웨어가 비디오 새로 고침을 처리하는 전통적인 비디오 카드와 같았습니다. 나는 당신이 탁구를 할 수 있다고 생각하거나 적어도 새로운 프레임이있을 때 뒤집을 수 있다고 생각하지만, 나는 올바르게 기억하지 못합니다. 다시 말하지만 프로세서는 해당 날짜와 시간에 대해 상당히 언더 클럭킹되었으며 빠른 리소스가 너무 많지 않았습니다. 따라서 일부 게임은 모드 7이지만 타일 기반 사이드 스크롤러가 많았습니다 ...

높은 프레임 속도의 솔루션을 원하는 경우 해당 솔루션을 설계해야합니다. SPI 또는 I²C 또는 이와 유사한 것을 통해 구식 디스플레이를 사용하여 대화 할 수는 없습니다. 적어도 하나의 프레임 버퍼를 2 개 이상으로 배치하고 가능한 경우 해당 디스플레이에서 행과 열을 제어하십시오.

당신이 사고 있다고 생각하는 많은 디스플레이에는 실제로 대화하는 컨트롤러가 있습니다. GBA / 콘솔 유형 성능을 원할 경우 컨트롤러를 생성 / 구현합니다. 또는 GPU / 비디오 칩 / 로직 블롭으로 구매 / 구축하고 HDMI 또는 기타 공통 인터페이스를 사용하여 주식 모니터에 사용할 수 있습니다.

자전거에 타이어와 체인 및 기어가 있다고해서 오토바이만큼 빨리 갈 수있는 것은 아닙니다. 성능 요구를 충족시키기 위해 시스템을 설계해야합니다. 그 자전거 바퀴를 그 모터 사이클에 둘 수는 있지만 원하는대로 작동하지는 않습니다. 모든 구성 요소는 전체 디자인의 일부 여야합니다.

소행성도 이런 식으로 작용했습니다. 하나의 6502 만 필요했습니다. 벡터 그래픽은 별도의 로직으로 수행되었습니다. 6502는 벡터 그래픽 컨트롤러에 작은 데이터 문자열을 보냈습니다. ROM은 ROM과 그 데이터를 사용하여 빔과 z의 xy 플로팅을 수행합니다. 일부 스탠드 업에는 별도의 프로세서가있어 프로세서가 게임을 계산합니다. 물론 오늘날 비디오는 메인 프로세서와 분리 된 수천 개가 아닌 수백 개의 프로세서로 처리됩니다.


세가의 "하이퍼 모드"또는 "어쩌면"슈퍼 FX? " en.wikipedia.org/wiki/Mode_7
Caleb Jay

coranac.com/tonc/text/bitmaps.htm#sec-modes 잘못 기억하고있을 것입니다. 아마도 모드 5 또는 비트 맵 모드 중 하나를 생각하고 있습니다. 스프라이트와 비트 맵 / 프레임 버퍼 모드가있는 타일 모드가 있습니다. . 아마도 당신이 연결 한 것에 대해 몰랐을 수도 있습니다. 그러나 그것은 아는 것이 좋습니다.
old_timer

모드 7뿐만 아니라 모드 7에서 더 많은 것을 읽으십시오. 어쨌든 GBA에는 타일 맵과 타일 맵에서 1 바이트의 타일 모드가 많은 픽셀을 생성하는 모든 픽셀을 담당해야하기 때문에 타일 모드와 비트 맵 모드가 느립니다. 또한 버스의 크기 (폭)와 메모리 속도 및 ROM 파이프 라인 캐시를 활용하여 ROM에서 물건을 빠르게 가져 오는 데 도움을줍니다. 그러나 첫날부터 소프트웨어를 적절한 속도로 실행하기 위해 고군분투했으며 논리적으로 대부분의 비디오 작업을 처리했습니다.
old_timer

병렬 8 비트 또는 4 비트 또는 spi 또는 i2c 인터페이스가있는 구매중인 디스플레이를 보면 성능이 저하되지 않는 컨트롤러를 사용하지 않고 원시 디스플레이를 원할 경우 디스플레이 관리 방법을 제어 할 수 있습니다 , ping / pong 및 CPU에서 프레임 버퍼로의 빠른 인터페이스를 만들 수 있도록 프레임 버퍼를 구성하십시오. 처음부터 충분히 빠른 디스플레이로 시작한다고 가정합니다.
old_timer

7

GBA와 같은 장치는 어떻게 거의 60fps의 프레임 속도를 달성 했습니까?

하드웨어.

프로그램 / 데이터 메모리와 동일한 버스를 공유하거나 공유하지 않을 수있는 그래픽 메모리가 있지만 중요한 비트는 초당 60 회 메모리를 읽고 데이터를 LCD에 전송하는 그래픽 프로세서가 있다는 것입니다. 이를 효율적으로 수행하도록 설계된 최적화 된 인터페이스.

"LCD 인터페이스"주변 장치 (예 : LPC4330)가 장착 된 최신 마이크로 컨트롤러에서도 동일하게 수행 할 수 있습니다. 물론 호환되는 LCD 패널이 필요합니다.

최신 고속 마이크로 컨트롤러 (예 : AVR이 아닌 ARM)와 작은 화면을 사용하면 그래픽 작업을 가속화하기 위해 스프라이트 나 블 리터가 필요하지 않습니다. 8 비트 AVR을 사용하면 느려질 수 있습니다.

그러나 CPU에 관계없이 디스플레이에 대한 인터페이스를 약간 두드리면 빠질 것입니다.

Atari 2600은 CPU 비트 뱅킹을 사용하여 사진을 TV로 보냈다고 생각합니다. 조금 쓸모가 없습니다.


비록 2600 명에도 하드웨어 스프라이트가 있었지만 매우 적은 수 (플레이어 2 개와 총알 2 개)
pjc50

2
@ pjc50, Atari 2600 종류 에는 하드웨어 스프라이트가있었습니다. 그래픽 하위 시스템의 다른 모든 부분과 마찬가지로 1 차원 객체였습니다. 프로그래머가 일련의 수직선 이외의 것을 원하면 프로그램은 각 행이 화면에 그려진 후 스프라이트를 업데이트해야했습니다.
Mark

1
@Mark : 2600에는 확실히 하드웨어 스프라이트가있었습니다. 하드웨어는 수평 위치 만 제어했지만 2600의 스프라이트를 통해 게임은 경쟁 업체보다 훨씬 화려한 게임을 제작할 수있었습니다.
supercat December
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.