Comment des appareils comme le Game Boy Advance atteignent-ils leur taux de rafraîchissement?

31

J'ai conçu mon propre appareil de jeu portable basé sur un microcontrôleur AVR et un petit écran OLED.

J'ai commencé avec un écran monochrome 128x64 pixels et je peux facilement y dessiner à plus de 60 images par seconde.

Je l'ai récemment retravaillé pour utiliser un OLED RVB, 128x128 pixels sans vraiment trop réfléchir pour constater que je ne pouvais atteindre que 4 FPS. Après une réflexion et une refactorisation soigneuse, je peux obtenir jusqu'à 12 images par seconde si je ne me soucie pas trop de faire autre chose!

Ma question est - comment un appareil comme le GBA (Game Boy Advance) a-t-il atteint une fréquence d'images de près de 60 images par seconde? J'ai pensé à avoir un «processeur graphique» séparé mais j'ai réalisé que je serais toujours goulot d'étranglement en transférant les données d'affichage à cela.

Je me demandais également à propos de l'utilisation de l'interface parallèle 8 bits résiduelle que la plupart de ces écrans ont tendance à avoir, ce qui pourrait me permettre d'accélérer de 8 fois, sauf que les MCU modernes n'ont pas tendance à avoir des interfaces matérielles parallèles comme elles le font pour la série et le bit. frapper mangera probablement beaucoup de gain de vitesse.

Quelles autres options existent?

J'utilise actuellement un ATmega1284P connecté à un contrôleur OLED SSD1306 via USART-SPI. Voilà la version monochrome.

L'écran couleur était un SSD1351, non connecté à l'origine au SPI matériel. Je n'étais pas convaincu que cela ferait suffisamment de différence, c'est tout simplement trop lent dans l'ensemble

Je sais que je peux obtenir des MCU plus rapides, mais je veux savoir quelles autres options je pourrais explorer - le processeur GBA est beaucoup plus lent que mon 1284!

MalphasWats
la source
6
"Je serais toujours goulot d'étranglement en transférant les données d'affichage à cela." DSI a quatre voies chacune jusqu'à 1,2 Gbits / sec. Je vous laisse le reste des calculs.
Oldfart
1
Comme tous les graphiques dans n'importe quel appareil de jeu vidéo, il y a de la mémoire pour gérer les graphiques. Selon ce site Web, il y a un emplacement d'adresse pour les graphiques, le son, etc. Les instructions y seraient stockées. En supposant qu'il n'y a pas beaucoup de données qui créeraient des conflits avec le temps de performance, il exécuterait ces instructions pour charger facilement les données graphiques.
KingDuken
5
achetez l'écran sans le contrôleur et créez votre propre contrôleur
old_timer
4
@immibis: Presque sûrement un horrible contrôleur basé sur I2C ou SPI. Les trucs d'amateur sont pleins de trucs lents trop chers comme ça quand vous pouvez obtenir un écran iPhone 400+ dpi pour 20 $ à cause des économies d'échelle.
R ..
6
@R .. Je veux juste souligner que la raison de ces contrôleurs amateurs est qu'ils puissent s'interfacer avec presque n'importe quel processeur, car vous donnez l'impression qu'ils sont inutiles. Vous ne seriez pas en mesure de vous connecter à un écran iPhone facilement, voire pas du tout. Il se connecte probablement à un processeur graphique dédié et peut-être personnalisé.
user253751

Réponses:

64

D'autres réponses couvrent assez bien votre question à un niveau abstrait (matériel), mais ayant une expérience réelle avec la GBA en particulier, j'ai pensé qu'une explication plus détaillée pourrait valoir la peine.

Le GBA avait de nombreux modes et paramètres de dessin qui pouvaient être utilisés pour contrôler la façon dont le processeur graphique interprétait la RAM vidéo, mais une chose était incontournable: la fréquence d'images. Le processeur graphique dessinait à l'écran dans une boucle presque constante (plus de détails ci-dessous). (C'est probablement le bit le plus pertinent pour votre question.)

Il tracerait une ligne à la fois en prenant une très courte pause entre chacun. Après avoir tracé la dernière ligne du cadre, il faudrait une pause à peu près égale au temps nécessaire pour tracer 30 lignes. Puis recommencez. Le timing de chaque ligne et le timing de chaque image étaient tous prédéterminés et gravés dans la pierre. À bien des égards, le processeur graphique était vraiment le maître de ce système et vous deviez écrire vos jeux sur son comportement, car il continuerait à faire ce qu'il faisait, que vous soyez prêt ou non.

Environ 75 à 80% du temps, il poussait activement vers l'écran. Quelles fréquences d'images pourriez-vous atteindre si vous faisiez de même?

Ce 80% du temps était également ce que le CPU devait traiter les entrées utilisateur, calculer l'état du jeu et charger les sprites / tuiles dans les zones de VRAM qui étaient actuellement hors écran (ou du moins non incluses dans la ligne en cours de tracé).

Les 20% entre les images étaient tout ce que le CPU devait modifier les paramètres vidéo ou la RAM qui auraient un impact sur l'ensemble de l'image suivante.

À la fin de chaque ligne, le processeur graphique enverrait une interruption de synchronisation de ligne au CPU. Cette interruption peut être utilisée pour modifier les paramètres de quelques sprites ou de quelques calques d'arrière-plan (c'est ainsi que vous pouvez obtenir un effet comme un projecteur conique, en modifiant la taille et l'emplacement de l'un des masques rectangulaires entre chaque ligne tracée. en ce qui concerne le matériel, toutes ces régions sont rectangulaires.). Vous devez faire attention à garder ces mises à jour petites et terminer avant que le processeur graphique commence à dessiner la ligne suivante ou vous pouvez obtenir des résultats moches. Le temps passé à traiter ces interruptions réduit également ces 80% du temps de traitement du processeur ...

Pour les jeux qui ont tiré le meilleur parti de ce système, ni le CPU ni le processeur graphique n'ont jamais pris une vraie pause; chacun se poursuivait dans la boucle en mettant à jour ce que l'autre ne regardait pas actuellement.

Mr.Mindor
la source
5
Bienvenue et bien mis.
Mindwin
2
Certains systèmes "plus récents" comme la Nintendo DS ont contourné la limitation de fréquence d'images fixe en ajoutant le registre VCOUNT pour retarder la trame suivante pendant une durée configurable (généralement pour aider les jeux multijoueurs à se synchroniser).
forêt
21

La caractéristique clé de toutes les consoles de jeux qui les distinguaient des premiers PC et pratiquement tous les ordinateurs personnels (1) était les sprites matériels .

Le guide de programmation GBA lié montre comment ils fonctionnent du point de vue du processeur principal. Les bitmaps représentant le joueur, l'arrière-plan, les ennemis, etc. sont chargés dans une zone de mémoire. Une autre zone de mémoire spécifie l'emplacement des sprites. Ainsi, au lieu d'avoir à réécrire toute la RAM vidéo à chaque image, ce qui prend beaucoup d'instructions, le processeur n'a qu'à mettre à jour l'emplacement des sprites.

Le processeur vidéo peut alors travailler pixel par pixel pour déterminer le sprite à dessiner à ce point.

Cependant, cela nécessite une RAM à double port partagée entre les deux, et je pense que dans le GBA, le processeur vidéo est sur la même puce que l'ARM principal et le processeur Z80 secondaire.

(1) Exception notable: Amiga

pjc50
la source
Seulement un peu - les premiers jeux d'arcade avaient les sprites dans une ROM associée au processeur graphique, pas une RAM à double port. Je n'ai aucune idée si c'était également le cas avec les premières consoles, même si cela aurait certainement pu être fait de cette façon.
TimWescott
@TimWescott, la GBA avait plusieurs modes de dessin et je n'ai pas d'expérience avec la plupart, donc cela peut ne pas être universellement vrai, mais je ne pense pas que l'un de ces modes avait un accès direct aux ROM (sur cartouche): généralement tous les les données de tuile / sprite / palette devaient être transférées de la ROM vers la mémoire vidéo et le processeur graphique y travaillait.
Mr.Mindor
@ Mr.Mindor Désolé si je n'ai pas été clair - je ne prétends pas savoir comment le GB ou le GBA l'ont fait. Je commentais juste les jeux d'arcade Nintendo très anciens à la fin des années 70 et au début des années 80, qui nous avaient tous demandé comment ils avaient fait ça.
TimWescott
@ TimWescott: Je pense que la même chose était vraie de la NES, bien que la ROM en question se trouve dans les Game Paks.
supercat
19

"Ma question est - comment un appareil comme le GBA a-t-il atteint une fréquence d'images de près de 60fps?"

Pour répondre à la question, ils l'ont fait avec un processeur graphique. Je suis sûr que le Game Boy a utilisé des graphismes de sprites. À un niveau supérieur, cela signifie que le processeur graphique reçoit des éléments tels qu'une image d'arrière-plan, une image de Mario et une image de Princess Peach, etc. beaucoup en x et y, superposer l'image n ° 3 de Mario à cette position x, y ", etc. Ainsi, le processeur principal ne se préoccupe absolument pas de dessiner chaque pixel, et le processeur graphique ne se préoccupe absolument pas de calculer l'état de la Jeu. Chacun est optimisé pour ce qu'il doit faire, et le résultat est un très bon jeu vidéo sans utiliser beaucoup de puissance de calcul.

TimWescott
la source
7
Le qualifier de "processeur graphique" exagère ce qu'il fait, suggérant qu'il s'agit d'une sorte de CPU qui lui est propre. Ce n'est qu'un contrôleur vidéo, qui est essentiellement un type de séquenceur compliqué. En comptant les pixels horizontaux et verticaux, il récupère les données de titre et / ou d'image-objet, les place dans les registres à décalage et combine la sortie des registres à décalage dans un pixel de sortie. Il n'est pas capable d'exécuter un programme comme un véritable processeur graphique "GPU".
Ross Ridge
14

Le GBA avait un processeur assez lent. L'ARM7 est très agréable; ils l'ont juste exécuté lentement et ne lui ont donné presque aucune ressource.

Il y a une raison pour laquelle beaucoup de jeux Nintendo à ce moment-là et avant étaient des défileurs latéraux. MATÉRIEL. Tout se fait en hardware. Vous aviez plusieurs couches de tuiles plus un ou plusieurs sprites et le matériel a fait tout le travail pour extraire les pixels de ces tables et piloter l'affichage.

Vous construisez la tuile à l'avant et avez ensuite une petite mémoire qui était une carte de tuiles. Vous voulez que la tuile inférieure gauche soit la tuile 7? Vous mettez un 7 dans cet emplacement mémoire. Vous voulez que la prochaine tuile soit la tuile 19? Dans le jeu de tuiles, vous y mettez un 19, et ainsi de suite pour chaque couche que vous avez activée. Pour le sprite, vous définissez simplement l'adresse x / y. Vous pouvez également effectuer une mise à l'échelle et une rotation en définissant certains registres et le matériel s'occupe du reste.

Le mode 7, si je me souviens bien, était un mode pixel, mais c'était comme une carte vidéo traditionnelle où vous mettez des octets qui couvrent la couleur d'un pixel et le matériel s'occupe du rafraîchissement vidéo. Je pense que vous pouvez jouer au ping-pong ou du moins lorsque vous avez un nouveau cadre, vous pouvez les retourner, mais je ne me souviens pas. Encore une fois, le processeur était assez sous-synchronisé pour ce jour-là et ne disposait pas de trop de ressources rapides. Donc, alors que certains jeux étaient en mode 7, beaucoup étaient des défileurs latéraux à base de tuiles ...

Si vous voulez une solution qui est une fréquence d'images élevée, vous devez concevoir cette solution. Vous ne pouvez pas simplement prendre n'importe quel ancien écran que vous trouvez et lui parler via SPI ou I²C ou quelque chose comme ça. Placez au moins un framebuffer devant, idéalement deux, et contrôlez les lignes et les colonnes si possible sur cet affichage.

Un certain nombre d'écrans que je soupçonne que vous achetez ont un contrôleur sur lequel vous parlez réellement. Si vous voulez des performances de type GBA / console, vous créez / implémentez le contrôleur. Ou vous achetez / construisez avec un GPU / une puce vidéo / un blob logique et utilisez HDMI ou une autre interface commune dans un moniteur de stock.

Ce n'est pas parce qu'un vélo a des pneus, une chaîne et des engrenages qu'il peut aller aussi vite qu'une moto. Vous devez concevoir le système pour répondre à vos besoins de performance de bout en bout. Vous pouvez mettre cette roue de vélo sur cette moto, mais elle ne fonctionnera pas comme souhaité; tous les composants doivent faire partie de la conception globale.

Les astéroïdes ont également fonctionné de cette façon; il n'en fallait qu'un 6502. Les graphiques vectoriels ont été réalisés avec une logique distincte; le 6502 a envoyé une petite chaîne de données au contrôleur graphique vectoriel, qui a utilisé une ROM et ces données pour faire le tracé xy du faisceau et z, on / off ... Certains standups avaient des processeurs séparés pour gérer l'audio et la vidéo séparément de le processeur qui calcule le jeu. Bien sûr, aujourd'hui, la vidéo est gérée par des centaines, voire des milliers de processeurs séparés du processeur principal ...

old_timer
la source
Je jure que je me souviens que le mode7 a été décortiqué par le marketing en réponse au "mode hyper" de Sega ou quelque chose ... peut-être "Super FX?" en.wikipedia.org/wiki/Mode_7
Caleb Jay
coranac.com/tonc/text/bitmaps.htm#sec-modes Je me suis peut-être souvenu que je me trompais Je pense peut-être au mode 5, ou à l'un des modes bitmap, il y a des modes tuiles avec des sprites et des modes bitmap / framebuffer . il y a peut-être un 7. ne savait pas celui que vous avez lié mais c'est bon à savoir.
old_timer
hmm lire plus sur le mode 7 et ce n'est pas seulement un mode. Quoi qu'il en soit, la GBA a des modes de mosaïque et des modes bitmap qui sont plus lents car vous devez être responsable de chaque pixel où les modes de mosaïque d'un octet dans la carte de mosaïque produisent de nombreux pixels. Ils ont également exploité la taille des bus (largeur) et la vitesse de la mémoire, ainsi qu'une fonction de cache de pipeline de rom pour aider à extraire un peu plus rapidement les informations (instructions) de la rom. Mais dès le premier jour, vous avez eu du mal à faire fonctionner le logiciel à un rythme décent et, heureusement, la logique a pris en charge la plupart du travail vidéo.
old_timer
si vous regardez ces écrans que vous achetez qui ont ces interfaces parallèles 8 bits ou 4 bits ou spi ou i2c qui sont sur votre chemin pour les performances, vous voulez que l'affichage brut sans ces contrôleurs et ensuite vous pouvez contrôler la façon dont l'écran est géré , créez un ou deux framebuffer pour pouvoir ping / pong et une interface rapide de votre CPU vers le framebuffer. en supposant que vous commencez avec un affichage assez rapide en premier lieu.
old_timer
7

Comment un appareil comme le GBA a-t-il atteint une fréquence d'images de près de 60 images par seconde?

Matériel.

Il a une mémoire graphique, qui peut ou non partager le même bus que la mémoire programme / données ... mais le bit important est qu'il dispose d'un processeur graphique qui lit la mémoire 60 fois par seconde et envoie les données à l'écran LCD à l'aide d'un interface optimisée conçue pour le faire efficacement.

Vous pouvez faire de même avec n'importe quel microcontrôleur moderne équipé d'un périphérique "interface LCD", par exemple le LPC4330 bien que cela puisse être excessif. Bien sûr, vous aurez besoin d'un écran LCD compatible.

Avec les microcontrôleurs rapides modernes (c.-à-d. ARM et non AVR) et un écran si petit, vous n'aurez probablement pas besoin de sprites ou d'un blitter pour accélérer les opérations graphiques. Avec un AVR 8 bits, cela peut être lent.

Mais peu importe le processeur, le fait de cogner l'interface à l'écran va être nul.

Je pense que l'Atari 2600 a utilisé le bit banging du processeur pour envoyer l'image au téléviseur. C'est un peu obsolète.

peufeu
la source
Même le 2600 avait des sprites matériels, bien qu'un nombre très limité (deux joueurs et deux balles je pense)
pjc50
2
@ pjc50, le genre Atari 2600 avait des sprites matériels. Comme toutes les autres parties du sous-système graphique, il s'agissait d'objets à une dimension. Si le programmeur voulait autre chose qu'un ensemble de lignes verticales, le programme devait mettre à jour les sprites après que chaque ligne ait été dessinée à l'écran.
Mark
1
@Mark: Le 2600 avait définitivement des sprites matériels. Le matériel ne contrôlait que le positionnement horizontal, mais les sprites du 2600 permettaient aux jeux de produire des jeux beaucoup plus colorés que tous ses concurrents.
supercat