Bonjour.
Je veux faire quelque chose qui me semblais extrêmement simple il y as 20 ans (ou 22 … 25 … 28 … Merde, je suis vieux) mais qui semble très compliqué aujourd’hui : Afficher un point de couleur à l’écran.
A l’époque, QuickBasic 4.5, MS-DOS et un ordinateur qui dépassais même (un peu) les 150 MHz. Trois lignes de codes suffisais à afficher un point. La porte ouverte à des armées de points de toute les couleurs avec pour seule limite l’imagination … et la résolution d’écran.
J’ai cru hier trouver mon saint graal avec un tout simple module GO pour écrire des points dans le framebuffer.
Le module tiens en trois fichiers et ne permet que trois choses :
- Se connecter sur /dev/fb0
- Renvoyer la résolution de l’affichage disponible
- Dessiner un point aux coordonnée X Y avec la couleur RGBA
Simple, minimaliste : Tout ce que je veux (avec les résolutions modernes à portée de main).
… sauf que /dev/fb0 existe plus (en tout cas pas sur la Fedora sur laquelle j’ai essayé), ça serais un vieux truc dépassé avec l’étiquette «Déprécié» depuis une décennie.
Soit, je veux bien.
Je suis pas forcément un très grand développeur, mais j’ai cette manie de coder avec la documentation et d’éviter tout ce qui est déprécié.
Mais comment on fait pour juste afficher un point de façon moderne, pérenne, durable … mais, et peu être surtout : Le plus sobrement possible.
Sans empiler les framework, toolkits et autres couches d’abstractions qui font de nos applications modernes des pachydermes (mais non j’ai rien contre PHP) prêt à engloutir la mémoire RAM par Gigaoctet.
J’arrive au bout de ce que je sais réfléchir moi même, mais peu être certains d’entre vous on ils eu des questions semblables.
--
Tout ceci s’inspire de quelques idée poussé par T.Nitot et Ploum
# Simple DirectMedia Layer
Posté par nigaiden . Évalué à 7 (+7/-1).
Je ne connais pas le contexte dans lequel tu as besoin d'un rendu graphique, mais SDL est peut-être une piste à étudier. Il y a un site avec des exemples, et en particulier un avec des primitives (code source en bas de page) pour te faire une idée. C'est un peu plus abstrait qu'un accès direct à une mémoire vidéo, mais sans être trop lourdingue et avec beaucoup d'avantages (portabilité…).
[^] # Re: Simple DirectMedia Layer
Posté par cli345 . Évalué à 1 (+1/-1).
Désolé, j'ai cliqué sans le vouloir sur "inutile". Peut-on corriger le vote en un vote positif ?
[^] # Re: Simple DirectMedia Layer
Posté par SlowBrain (site web personnel) . Évalué à 4 (+2/-0).
Je répond plus tardivement à cette piste du SDL, car elle est effectivement intéressante et qu’elle mérite que je prenne plus de temps pour y répondre.
J’ai passé la soirée de dimanche entre «Pourquoi l’exemple il compile pas ?» et «Ça s’utilise comment "gcc" ?» pour qu’un
gcc primitive.c -o prog -lSDL3finisse par me créer un petit programme.Donc, oui, c’est une librairie d’abstraction, qui est notamment assez largement utilisé dans les jeux et les émulateurs (qui cherchent à afficher autre chose que les widgets de l’interface du système)
Après c’est très portable, et du C est presque le graal du minimalisme (ou alors faut taper dans de l’assembleur … mais j’ai pas trop envie).
Je continue à suivre la piste.
# Back to BASIC
Posté par Colargol . Évalué à 5 (+3/-0).
Go étant un langage développé par Google pour l'utilisation en backend sur les serveurs, le graphisme / GUI n'est pas son point fort. Puisque tu évoques le QuickBASIC tu peux utiliser un de des cousins : FreeBASIC. C'est un compilateur BASIC multi plateforme (FreeBSD, Linux, Windows) compatible avec la syntaxe QuickBASIC y compris les fonctions graphiques.
[^] # Re: Back to BASIC
Posté par SlowBrain (site web personnel) . Évalué à 4 (+2/-0).
Je suis un peu touche à tout du numérique, dont différents langages informatiques.
Je prend même un certain plaisir à faire du CSS … le coté graphiste qui s’exprime un peu.
Le GO n’est qu’un des langages sur lesquels je bricole, plutôt celui avec lequel je travaille (et monte en compétence) en ce moment. Mais pas forcément celui que je tiens absolument à utiliser pour faire un projet différent.
Il y as effectivement différents dialectes de BASIC, plus ou moins confidentiels, dont un «QB64» qui as quelques fork, qui se veux pleinement dans l’esprit du QuickBasic de l’époque.
Il y as aussi Processing, pleinement orienté vers la création graphique.
Je prend l’idée.
Et je cherche peu être une simplicité, un coté très direct, qui n’existe plus vraiment.
[^] # Re: Back to BASIC
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3 (+2/-0).
De ce que je comprends son problème est qu'il y a toujours une fenêtre. On dessine dans une application qui est encapsulée dans une fenêtre. Pour ne pas avoir la fenêtre il faut aller au niveau au dessus. Peut être aller sur les tutos pour dessiner un Widget. Le problème c’est qu’il risque d’être dépendant d’un gestionnaire de fenêtre (Gnome ou KDE ou …)
Sinon il faut aller au niveau du dessus. Un tutoriel Wayland pour faire sa surcouche…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Back to BASIC
Posté par SlowBrain (site web personnel) . Évalué à 4 (+2/-0).
Ce qui as changé depuis mes programmes sous Dos est effectivement qu’il y as une fenêtre. Et aujourd’hui les applications se séparent entre Non Graphique et Graphique.
Je fait pas mal de petits programmes en GO ou Python, qui n’affichent rien.
Parfois elles affichent quelques lignes dans le terminal, c’est assez simple dans de très nombreux langages.
J’ai un programme que j’ai créer il y as peu (en GO) qui génère des rapports en PDF suite à son traitement.
Mais quand on veux faire une application Graphique, il faut gérer un élément parmi plein d’autres, sa fenêtre parmi les autre des autres programmes, la tout dans une cohérence graphique cohérente. Et ça deviens vite compliqué : Beaucoup plus qu’un print() pour afficher une information dans un terminal.
Même en GO, qui n’est pas vraiment fait pour, j’ai réussi à faire afficher un message d’erreur. Le bout de code fait un appel direct à l’api Win32, et reste assez simple pour que j’arrive à le comprendre.
—-
Ce que j’aimerais c’est avoir une toile vierge dans laquelle dessiner librement et simplement.
Que cette toile soit une fenêtre ou plein écran, dans ou hors d’un compositeur Xorg ou Wayland … ça m’importe peu. Écrire directement dans la mémoire graphique (framebuffer), hors d’un compositeur, d’un gestionnaire de fenêtre, d’un bureau n’est pas un problème.
Je ne cherche pas de vitesse, de possibilité avancée, ni autre chose.
—-
Oui, il y as plein d’idée que j’ai l’envie de voir naître derrière cette simplicité, et surtout beaucoup que je suis parfaitement incapable de développer tout seul.
Mais pour l’ « Appel aux développeurs pour un projet (un peu) fou » j’attendrais de faire un journal sur le sujet :)
[^] # Re: Back to BASIC
Posté par Colargol . Évalué à 4 (+2/-0).
Si tu veux rester en Go tu peux essayer :
[^] # Go into console/term
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
N’oublions pas que l’application qui est encapsulée dans une fenêtre était la fenêtre dans les années 70—80—90 ; et donc peut-être que la demande est de dessiner directement au niveau du terminale… Partant de cette supposition, j’oriente vers
LOCATE x,yen BASIC)Par contre, le curseur c’est moins fin qu’un pixel (l’équivalent de
PIXONsur certaines calculatrices) mais ça fait l’affaire si on reste en mode texte (où l’on peut dessiner des boîtes en utilisant les caractères qui vont bien…)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Back to BASIC
Posté par abriotde (site web personnel, Mastodon) . Évalué à 5 (+4/-0). Dernière modification le 13 avril 2025 à 00:45.
Sinon
https://linuxfr.org/users/tarnyko/journaux/wayland-l-obsession-eternelle-du-carre-blanc
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# surpris
Posté par ChocolatineFlying . Évalué à 1 (+1/-1).
j'ai pas approfondi le sujet de suite, il me semble que cela fonctionne toujours et doit être en natif ou autre choses équivalent, c'est ce qui permet d'afficher les fameux OK en couleur en 1280x1024 au démarrage de linux, a defaut d'avoir perdu le petit linux qui s'affichait
essaye lsmod | grep fb et regarde si c'est les option dans default ou qqpart sont bien active, cela depends peut etre de ta distribution, c'est laquelle ?
[^] # Re: surpris
Posté par NeoX . Évalué à 7 (+4/-0).
si je ne me trompes pas le framebuffer se deactive quand le pilote graphique de la carte se lance pour gerer l'affichage en pleine resolution et afficher le prompt de login graphique, puis le bureau une fois la session ouverte.
si on veut garder l'usage du framebuffer, il faudrait ne pas lancer d'interface graphique
[^] # Re: surpris
Posté par ChocolatineFlying . Évalué à 1 (+1/-1).
oui je pense que c'est cela, il faut démarrer en mode console car une fois X ou wayland lancé impossible de l'avoir de nouveau SAUF si x ou wayland se lance en frame buffer aussi, ca arrivé assez souvent avec les carte graphique dans les années 2000, pas de drivers -> pouf x en frame buffer et accessible en console
[^] # Re: surpris
Posté par totof2000 . Évalué à 4 (+2/-0).
Ce n'est pas comme ça que j'ai compris le fonctionnement …. il me semble que tu peux faire cohabiter frame buffer et X mais que justement il ne faut pas que X utilise le frame buffer. Tu switche entre X et frame buffer via ctrl+alt+Fn. Je voulais le tester d'ailleurs mais j'ai un problème de bascule via ctrl+alt+Fn (voir mon appel en forum).
[^] # Re: surpris
Posté par SlowBrain (site web personnel) . Évalué à 3 (+1/-0).
La machine sur laquelle j’ai testé est fraichement installé sous Fedora.
Les terminaux non graphiques (tty2/3/4) s’affiche dans la résolution native de l’écran, et donc assez loin de l’ancien standard des 80 colonnes. J’était justement passé sur un terminal non graphique (le CTRL + ALT + F2 fonctionne toujours :) ) pour essayer mon bout de librairie et éviter de rentrer en conflit avec un serveur graphique X ou Wayland.
C’est suite à une erreur /dev/fb0 introuvable que j’ai constaté sa disparition.
Mais peu être qu’il pourrais se retrouver soit sur une autre distribution, soit dans une installation plus minimaliste.
[^] # Re: surpris
Posté par Renault (site web personnel) . Évalué à 4 (+1/-0).
Ce n'est pas un problème de distribution, c'est un problème de pilotes.
La pile graphique moderne est très complexe, pour des raisons de perfs un Framebuffer à l'ancienne n'est plus du tout d'actualité dans le noyau Linux et a été remplacé par DRM qui a un fonctionnement plus complexe.
Seuls quelques pilotes pour des systèmes embarqués peuvent avoir encore un usage du framebuffer car les pilotes graphiques de ces appareils sont plus simples mais peut être qu'un jour ils seront évincés du noyau aussi.
Du coup sur PC moderne tu n'as aucun moyen de retrouver ce framebuffer en l'état avec Linux.
[^] # Re: surpris
Posté par ChocolatineFlying . Évalué à 0 (+0/-1).
je me permet encore de douter il est probable que tu ai raison mais de ce que je vois un peu partout c'est toujours d'actualité (c'est tellement pratique!)
https://www.kernelconfig.io/config_fb?q=&kernelversion=6.14.2&arch=x86
mais peut être que rien n'est à jour !
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/video/fbdev?h=v6.14.2
je reste persuadé que c'est du a sa configuration de fedora, il faut qu'il active son framebuffer device, j'ai su le faire il y a quelques années, peut etre voir coté chatgpt
[^] # Re: surpris
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
Tu montres juste que l'option existe dans le noyau, pas que les pilotes des cartes graphiques modernes dans un PC s'en servent.
Par exemple dans ma Fedora Linux qui a une config noyau standard, l'option que tu pointes est bien activée.
Le problème n'est donc pas là.
[^] # Re: surpris
Posté par ChocolatineFlying . Évalué à 1 (+1/-1).
si il a une carte Nvidia forcement c'est mort
et concernant la fin de vie tu insiste, moi aussi ! depuis le début dans les sources du noyau lorsqu'une partie va être supprimé ou arrêter, il y a des annonces et c'est mentionné que cela va être retiré du noyau dans les sources concerné.
dans tous fbdev/ il n'y en a aucune mention
j'ai prouvé que c'etait viable, aurait tu un quelconque lien vers lkml ou un code source sur kernel.org qui PROUVE ce que tu dis ici ? la confiance n’empêche pas le contrôle et j'aimerais le contrôler.
[^] # Re: surpris
Posté par Renault (site web personnel) . Évalué à 4 (+1/-0).
Tu n'as rien prouvé du tout.
Le simple fait que ce ne soit pas dispo même quand l'option est active montre le contraire.
La meilleure solution semble de récupérer un framebuffer virtuel via le sous-système DRM comme effectué ici : https://github.com/embear-engineering/drm-framebuffer
Pas testé mais ça peut fonctionner, ça rempli le job voulu mais ne passe pas par l'ancienne interface et ajoute un peu de complexité pour obtenir le framebuffer.
Évidemment cela ne peut pas fonctionner si un environnement graphique est lancé.
[^] # Double tranchant
Posté par SlowBrain (site web personnel) . Évalué à 4 (+2/-0).
Ce que j’ai tendance à en comprendre, c’est que même si on peux encore le trouver (soit par une configuration, soit via une distribution qui as d’autres choix que Fedora), le FrameBuffer est plus proche de sa fin de vie qu’autre chose.
Donc effectivement, pour jouer avec un écran et une vielle machine (même pas forcément connecté au réseau) ça doit encore être tout à fait fesable.
Mais pour un projet qui pourrais se vouloir plus solide c’est peu être mieux d’éviter de se baser sur un truc en cour de disparition.
—-
Pour ma part n’ayant pas un projet spécifique mais plein d’idées, plus ou moins intelligente, ça peux convenir … ou pas … suivant les cas.
Dans tout les cas ça fait avancer ma réflexion.
# Contexte
Posté par arnaudus . Évalué à 3 (+0/-0). Dernière modification le 16 avril 2025 à 18:57.
En fait, je pense que je n'ai pas connu l'époque où ça pouvait être intuitif, mais je n'arrive pas à comprendre ce que peut bien vouloir dire "afficher un point" sans plus de contexte. Afficher un point… où? Imaginons que je suis sous une distrib Linux quelconque, j'ai plusieurs bureaux, plusieurs fenêtres, des programmes qui tournent en arrière plan, des widgets qui restent au premier plan, etc. J'ouvre un (émulateur de) terminal et je lance "./affichepoint ", qu'est-ce qui est censé se passer?
Les solutions logicielles pour chacune de ces options me semblent très différentes, ainsi que leur portabilité, la taille des dépendances, etc. Je pense que la notion de "dessiner des points sur l'écran" n'a pas de sens.
À mon avis il y a deux couches qui n'ont rien à voir dans la question. La première est l'implémentation du champ de pixel (une matrice ou lattice) dont on va changer les valeurs. La deuxième couche est l'affichage de ce champ, qui va nécessairement faire appel à des bibliothèques graphiques en fonction du contexte. J'ai l'impression qu'à l'époque du framebuffer, on pouvait confondre les deux couches, parce qu'on pouvait modifier directement les zones de mémoire qui correspondaient aux pixels affichés, mais ça semble absurde avec une système fenêtré, personne ne souhaite que ça soit possible. Pour moi, tripoter les pixels en dehors de sa fenêtre, c'est comme tripoter la RAM en dehors de sa zone mémoire, c'est un comportement qui n'est absolument pas tolérable.
Pour la solution, pourquoi ne pas carrément exporter le champ de pixel dans un format d'image (png?) qui pourra facilement être affiché avec le logiciel de son choix?
[^] # On parle d’un temps …
Posté par SlowBrain (site web personnel) . Évalué à 3 (+1/-0).
Le premier IDE que j’ai véritablement utilisé est Microsoft QuickBasic qui fut édité entre 1985 et 1989. Il est assez représentatif des BASIC de l’époque (dont beaucoup était édité par Microsoft). La version que j’utilisais était un programme prévu pour MS-DOS, mais on trouvais des équivalent sur les ordinateurs Non PC des années 80.
Deux ligne de code suffisent à afficher un point sur l’écran :
SCREEN 12PSET (100,100)Le
SCREENN°12correspond au VGA - Écran graphique en 640×480 en 16 couleurs configurable. Sous Windows l’affichage se fait en plein écran … sous DOS on est toujours en plein écran.Il faut que la carte graphique prenne en compte le mode voulu.
Le QuickBasic avais 13 modes d’écran, avec leurs propres caractéristiques et pas tous avec des capacités graphiques.
Le
PSET (100,100)permet d’afficher un point aux coordonnées X = 100 & Y = 100, un troisième argument permettais de définir l’une des couleurs.D’un point à une image
Afficher uniquement un point n’est pas très utile, et c’est en afficher plusieurs centaines qui est vraiment interessant. Certaines fonctions permettant quelques formes plus avancée : Ligne / Rectangle / Cercles.
Même si du moment qu’on peux afficher un point, on peux créer des fonctions pour créer d’autres formes sur mesure.
Dans les limites du mode d’affichage cela permet de créer ce que l’on veux comme graphismes, l’autre limite étant la dextérité du développeur.
La différence avec ce qui se fait actuellement
Aujourd’hui les framework graphiques dessinent des widgets, des éléments préconçus : Boutons, Listes, Étiquette, …
C’est très bien pour avoir des interfaces cohérentes entre les différentes applications, des comportement semblables et les développeurs allergiques aux graphismes.
J’ai plus l’âme d’un graphiste et cette envie de dessiner «Point par point» des choses à l’écran.
Ce que je veux
Dessiner des points, des lignes, des rectangles, … faire mes propres graphismes, détaché du système d’exploitation. Peu importe que cela soit dans une fenêtre ou en plein écran … j’aimerais juste pouvoir dépasser les 640×480 en 16 couleurs.
De ce que j’ai essayé de la librairie SDL (suite au premier commentaire de ce message) elle fait plutôt ce que je veux : Afficher des points isolés et des triangles.
À partir de ces essentiels, on peux coder des fonctions pour faire un peu tout ce que l’on veux comme graphismes, et inventer son bout de monde graphique.
L’idée étant de pouvoir afficher quelque chose à l’écran, pas simplement de créer des images (Je me débrouille bien avec Inkscape pour cela)
Quelques exemples
Cela peux être du jeu (La librairie SDL gérant en plus les entrées), des animations, des interfaces, … ou plein d’autres choses.
Des interfaces semblable à de l’embarqué, un compte à rebours pour le nouvel an qui s’affiche sur la TV, … laisser parler mon imagination …
[^] # Re: On parle d’un temps …
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Bref, retour à la DemoScene en gros
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: On parle d’un temps …
Posté par flavien75 . Évalué à 1 (+0/-0).
QBasic (et GwBasic au passage) permettaient effectivement un accès direct et facile au matériel, par contre ce n'est juste pas possible dans un contexte multi-taches.
Imagine deux secondes différentes applications essayant chacune de configurer l'écran différemment (screen 0 et screen 12) qu'est-ce qui est censé se passer ?
Maintenant il reste deux solutions:
1. travailler bare-metal, c'est à dire sans OS en étant seul à utiliser le matériel. par contre il va falloir se coltiner la gestion dudit matériel qui s'est bien complexifié. Pour rappel un 8086 c'est (environ) 29000 transistors quand un processeur moderne contient en plus d'un milliard. Et ne parlons pas de la carte graphique.
Bref deux salles, deux ambiances
Les vrais naviguent en -42
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.