Fondamentalement, comment sont rendus les bitmaps 2D?

Supposons que nous ayons un ordinateur 64 bits adressable par mot et que nous voulions le programmer pour produire un caractère 5x7 stocké sous forme de bitmap d'image binaire (comme celui ci-dessous) vers un affichage mappé en mémoire.

Puisque nous avons 5 x 7 = 35 pixels par caractère, nous pourrions stocker un caractère en utilisant 35 bits dans un seul mot. Avec le bit le moins significatif à partir du côté gauche du mot et chaque pixel de l'image étant représenté par la n ième bit , comme indiqué ci - dessus, le nombre « 3 » ci - dessus seraient stockées dans la mémoire en tant que: 01110100010000100110000011000101110, suivi par 29 utilisé bits mis à 0.

Est-ce ainsi que les personnages étaient / sont stockés dans des ordinateurs anciens / modernes? Ou utilisent-ils plutôt un seul octet / mot par pixel?

S'ils sont stockés de cette manière, quelle serait la routine utilisée dans l'assemblage / code machine (en n'utilisant rien de plus que des instructions élémentaires telles que les opérations au niveau du bit, arithmétique et de transport de données de l'architecture du jeu d'instructions de l'ordinateur) utilisée pour convertir ces données en une image sur l'affichage ressemble à? Serait-ce quelque chose comme:

1. Stockez les coordonnées d'affichage x et y du pixel actuel à mettre à jour dans un certain registre.
2. Stockez les deux valeurs RVB choisies (dans ce cas 0,255,0 pour le vert et 0,0,0 pour le noir) dans deux autres registres séparés.
3. Demandez à deux autres registres d'agir comme des compteurs initialisés à 5 et 7 pour garder une trace de la ligne et de la colonne actuelles de l'image rendue.
4. Testez si le registre de colonne n'est pas 0. Si ce n'est pas le cas, testez si le LSB du bitmap est défini sur 1, puis ET le registre de valeur RVB respectif avec les registres de coordonnées x et y en fonction du résultat, puis MOV ce résultat au registre de sortie de l'affichage.
5. Décrémentez le registre du compteur de lignes de 1, testez pour voir s'il est 0. Si tel est le cas, remettez-le à 5 et incrémentez la coordonnée y de 1 et décrémentez le compteur de colonnes de 1.
6. Décalez le registre en maintenant le bitmap 1 bit vers la gauche.
7. JMP à l'instruction 4.

Existe-t-il un moyen plus simple ou plus efficace de procéder? Il semble que même quelque chose d'aussi simple que de restituer un seul petit caractère de texte nécessite un assez grand nombre d'opérations et prendrait environ 200 cycles CPU.

Enfin, existe-t-il de bons livres ou ressources sur le code au niveau de la machine pour afficher des images à partir de zéro, car je n'ai pas pu en trouver car ils glissent sur ce sujet particulier ou le code est écrit dans un langage de haut niveau ou un assembleur utilisant des macros, qui "trichent" et n'expliquent pas ce qui se passe fondamentalement au niveau le plus bas.

Vous devez distinguer les modes texte et graphique de la carte graphique de votre machine.

Autrefois, le mode texte était principalement pris en charge. Dans ce mode, la carte a pris soin de stocker la définition bitmap des caractères et de les afficher à la position actuelle du curseur. Tout ce que vous aviez à faire était de fournir le code ASCII du caractère (un octet par caractère) dans un petit tampon de texte.

De nos jours, un tampon raster haute résolution est fourni, accessible aux pixels et dans lequel vous écrivez des informations de couleur dans un format pris en charge (dans le mode "le plus élevé", 3 octets (RVB) par pixel, pour un mégapixel ou plus).

À l'origine, des bitmaps binaires simples (compressés) de différentes tailles étaient utilisés et " blittés " dans la mémoire raster via une demande au pilote de périphérique, avec une traduction de format possible.

De nos jours, les caractères sont principalement définis comme des dessins vectoriels , qui sont une description indépendante des résolutions des contours, et doivent subir un processus de rendu complexe qui inclut l' anticrénelage pour des résultats fluides.

La sortie rendue peut être mise en cache pour un affichage rapide, encore une fois par blitting.

Le processus global est complexe, peut être accéléré par le matériel et est géré par le système d'exploitation (gestion de l'interface graphique) de manière transparente, conjointement avec d'autres opérations de dessin primitif graphique.

La réponse courte est OUI, vous ne pouvez pas éviter de faire beaucoup de manipulation de bits si votre format en a besoin.

Dessiner un bitmap signifie essentiellement copier un pixel d'une source vers une destination et vous devez faire ce qu'il faut pour le faire. (Citant le capitaine évident)

Une réponse plus longue est que si vous écrivez un rasterizer logiciel, vous pouvez avoir un algorithme et une astuce pour vous faire gagner du temps cpu (en sachant quelle partie vous n'avez PAS BESOIN DE DESSINER (optimisation de la transparence), en ayant un format de pixel de la source identique comme destination (directement ou sous forme de cache), effectuez de manière optimale la copie memc, etc ... En gros, considérez la boucle de dessin de votre rasterizer et voyez comment vous pouvez les restructurer pour gagner du temps CPU (ex: vous pouvez générer au moment de l'exécution un morceau de code assembleur spécialement pour imprimer la lettre A ou avoir des méta à vos informations bitmap source pour vous dire comment ignorer la zone transparente, etc.) Chaque cas d'utilisation peut avoir une solution différente basée sur le jeu d'instructions CPU, le format de tampon, le algorithme de votre rendu primitif (rotation? étirement des bitmaps? quel type de filtrage? etc ...), registre CPU et cache etc ...

Donc oui de toute façon, il a fallu beaucoup de cycle CPU pour écrire un seul pixel dans le temps où l'encodage étrange et la petite mémoire étaient la norme. :-) Mais cela n'interdisait pas aux machines 16/32 bits avec CPU 8 MHZ de faire des choses comme ça: https://www.youtube.com/watch?v=GWwPJU6pp30 (Et une grande partie du CPU a également été utilisée pour la musique)

Dans le cas du rendu HW, HW effectuera la conversion du format source au format de destination et même s'il n'utilisera pas la plupart des astuces disponibles pour le rasteriseur SW, son implémentation générique dans HW battra probablement la plupart de l'implémentation SW.