Characters_To_Linux_Buffer_THE_HARD_WAY
1.0.0
Des caractères rapides et sales vers le tampon Linux en C - à la dure - avec des "tableaux de glyphe", un array Fu, Pointer fu, mais pas de seins, d'explosions ou de poursuites en voiture Ce projet est une question de caractère. Lorsque je cherche à mettre des caractères à l'écran pour un tampon Linux, je voulais créer un affichage pour les données, mais le texte réel de la console était trop petit sur le Barbones non Gui Raspberry Pi qui a été tarré pour ce projet. Ce projet est basé sur d'autres travaux, un bon exemple de manipulation de FrameBuffer dans Linux. See http://raspberrycompote.blogspot.com/2015/01/low-level-graphics-on-raspberry-pi-part.html So what was done in for this project was a bunch of arrays of 1s and 0s representing characters and numbers were created and these arrays are looped through with a "set pixel" routine to determine when and where an actual pixel is written to with a color value. Les polices sont basées sur les Aliens Sentry Guns. https://www.youtube.com/watch?v=hqdy-5iqvuu Cette démo suppose que tous les systèmes ne seront pas rapides et n'auront pas un écran HDMI (qui surchauffe dans mon cas - ne soyez pas moi) alors faites attention à cette ligne:
Vinfo.bits_per_pixel = 8;
Les valeurs de couleur varient de 0 à 15. Ce n'est pas la couleur la plus profonde bien sûr. Si vous augmentez cette "profondeur", vous pourriez ralentir les choses, mais vous obtenez une gamme de couleurs plus large. Et ceux-ci:
Vinfo.xres = 1184;
Vinfo.yres = 624;
Votre écran, que ce soit HDMI, ou un écran LCD TFT peut-être - cela ne compte pas pour une routine Linux FrameBuffer tant que vous obtenez le droit / dev / fbn, où n est le nième nombre d'affichages - est susceptible de différer. Ainsi, les dimensions de l'écran et de la "profondeur" peuvent différer. J'ai un écran LCD TFT qui gère bien la sortie d'un vieux caméra de framboise infrarouge noire, mais essayez n'importe quel bitmap x32 dessus sans conversion et les choses deviennent intéressantes. Mon objectif dans l'ensemble était "Il suffit de mettre du texte à l'écran". Les tableaux ont été créés en utilisant quelque chose de proche de la «police automatique des extraterrestres» et des routines écrites pour définir des pixels sur une valeur de couleur donnée en fonction de l'endroit où nous le voulons, X et Y et tout cela, et ce qui est 1 ou 0 dans le tableau des glyphes.
De là, d'autres routines ont été engendrées: l'impression d'une chaîne. Impression d'un affichage numérique. Et des rectangles, remplis ou creux d'une bordure et de lignes.
Cette démo montre un peu d'animation, mais ce n'est pas l'objectif. En utilisant une sorte d'approche "Buffer Flipping", qui est la façon dont la plupart des graphiques fonctionnent - l'écriture dans un espace mémoire, comme un tableau d'abord, qui équivaut à l'affichage en taille et en profondeur de couleur, avec des valeurs de couleur, puis en "blissant" (un vieux mot des années 1990 probablement) cette mémoire à la même mémoire qui est mappée à l'écran. Cela permet une transition très fluide d'un écran à l'autre.
L'animation est donc possible, mais pas l'objectif. Il est assez simple pour tout pour tout dans ce "tampon arrière", puis l'écrivez dans le tampon d'écran. Une fois que vous avez ce type de code, comme le code de Raspberry Compote, ce que vous faites à ce tampon arrière est votre entreprise: de notre humble texte au rendu 3D.
Cette démo suppose que des systèmes plus anciens ou moins capables pourraient être utilisés. Ainsi, tous les personnages sont dans un pâté de maisons. Les glyphes réels - représentés par des tableaux sont "maintenus" via un tableau "pointeur vers le tableau". Dans le bloc, ce tableau se voit attribuer des pointeurs sur les données du tableau, donc une fois le bloc passé par, ces objets ont disparu. Cela vous permet de choisir et de choisir les caractères que vous utilisez et de jeter le reste. Pour noter également, il existe deux tableaux représentant deux tailles de police. Chacun est 128 éléments, et le nième élément correspond à la valeur inth non signée du caractère. Donc, pour cette raison, un espace est dans l'élément 32. La valeur ASCII de "S" est de 83, donc les 83e éléments des tableaux sont un pointeur vers le tableau de S.
Des tableaux de nombres plus petits sont également utilisés pour être des éléments qui pointent vers les tableaux représentant des nombres, le nième élément correspondant au nombre, allant de 0 à 9. Cela nous épargne l'appel atoi qui serait utilisé pour les lettres.
Dans l'ensemble, testé sur une framboise à noyau unique de 1ère génération, il était assez rapide. Les résultats peuvent varier. C'est aussi le code C de base.
Il existe d'autres moyens de faire des personnages sur un écran. Mais j'ai opté pour cette mesure rapide et sale pour assurer la flexibilité et la simplicité. Le "Array Fu" de ce code peut également s'avérer utile pour d'autres choses. Le tableau n'a pas besoin d'être une lettre ou un numéro ou un glyphe de quelque sorte - il peut être un sprite par exemple, ou tout ce que vous voulez. Vous êtes limité par l'écran que vous utilisez et le processeur.
Si vous voulez plus de polices de fantaisie, il y a des démos sur Internet qui prennent de "vraies" polices et les convertissent en pixels. Si vous pouvez les mettre dans des tableaux, comme un programme qui lit un bitmap et le transforme en un tableau de valeurs de couleur, vous pouvez les utiliser comme polices dans ce programme. Gardez à l'esprit que tous ces éléments, bien qu'il est affiché dans le code sous forme de tableaux 2D, sont vraiment des tableaux 1D. Vous devez donc savoir à l'avance quelles sont les dimensions de vos tableaux. Les tableaux de cette démo ont été créés manuellement. L'ensemble des gammes ASCII - 128 caractères, ne sont pas terminés. Donc, si vous voulez quelque chose qui n'est pas là, comme les personnages minuscules et la ponctuation, vous devrez le créer vous-même. Notes supplémentaires: Je note une défaut de segmentation sur une installation Debian sur Beaglebone avec une résolution 800x600 - mais j'utilise le même écran HDMI. Curieux. Les résultats varieront en fonction du système et du système d'exploitation. J'obtiens même une profondeur de pixel par défaut inférieure sur le Beaglebone. Les deux systèmes sont des systèmes non GUI (les GUIS sont destinés aux femmes au foyer). Je trouve que se débarrasser du tampon "élargi" sur l'astuce yres * 2 qui a bien fonctionné sur Rasperry a éliminé l'erreur d'initialisation et permet la même animation légère avec le scintillement atari 2600 sur lequel j'ai grandi. J'imagine qu'un tableau séparé pour l'écriture puis "blit" pour projeter dans la Voie de l'ancienne pourrait fonctionner à la place, je vais expérimenter cela. La résolution inférieure sur les graphiques seuls Debian Beaglebone me donne des sensations nostalgiques. Je remarque également qu'avec la même "profondeur de pixels" que j'ai utilisé sur le Raspberry Pi, je peux toujours passer plus de 15 dans mes valeurs de la couleur lors de la mise en place d'un pixel dans le tampon. La framboise s'étoufferait là-dessus, mais pas le Beaglebone. Cela permet plus d'options de couleurs. Chaque système est différent, vous devez donc toujours expérimenter. Amusez-vous avec ce code.
