Version imprimable
bonjour, j'ai une question qui me tracasse un peu ces dernier temps, comment peut on, avec seulement les instructions de base du langage "c" coder une fenêtre interactive (avec menus si vous voulez), sans utiliser des API ou un environement de développement, ou il y a des fenêtres et des boutons pré-préparés.
Auparavant, y avait pas ces outils d'aide comme aujourd'hui, pourtant les anciens os affichait des graphes et des fenêtres en utilisant seulement l'algorithme, maths et c .
Merci
Attention ca va être très bref:
On ne peut pas.
Bien sûr qu'on peut :mouarf:
Mais (un exemple) tu prends OpenGL ou DirectX (bon ce sont 2 bibliothèques, mais quoique tu fasses maintenant tu as l'accélération graphique) et tu recodes tous les uis (boutons, label, listes déroulantes, ....) (au choix: images ou formes) et toutes les interactions (clavier, souris, ...)
Et après (ou en même temps) si tu es fort, tu fais un générateur de fenêtre en ouvrant un fichier XML/ json/ texte/ ....
Et avec OpenGL, tu seras multi-plateforme :D
En version un peu moins brève:
Ils utilisaient la mémoire vidéo directement, chose que tu ne peux plus faire avec les OS modernes.
Tu es contraint de passer au pire par les drivers vidéos, ce que font les toolkits.
Ca veut dire que pour dessiner une fenêtre avec des boutons, il va te falloir la coder.
Un point de départ dans cette approche, c'est la SDL, qui ne fournit que les primitives de dessins (ce qui est déjà beaucoup)
Tu vas te retrouver à coder ton propre toolkit, qui sera mon bon que ceux déjà disponibles, vu que tu partiras de zéro.
Même si c'est pour refaire la roue, c'est une mauvaise idée de partir de moins que la SDL.
PS: je te conseille vivement d'utiliser la SDL2 (plutot que l'ancienne SDL1)
Il me vient à l'idée que dans les deux cas, il te faut passer par une bibliothèque de fenêtrage (SDL en est une, d'ailleurs).
Sinon, tu ne pourras pas t'intégrer dans l'OS.
Concrètement, sous windows, tu ne pourras pas faire autrement.
Sur un unixoïde, ca sera éventuellement possible de t'en passer, mais ca veut dire te substituer à l'environnement graphique (le serveur X).
Autrement dit, ne pas disposer des autres applications graphiques.
Sur un unixoïde, il y a aussi la méthode de contacter soi-même le serveur X par socket, bypassant les bibliothèques qui y touchent.
L'inconvénient, c'est que c'est se compliquer la vie pour rien.
Et encore, c'est lui qui dessine, tu utilises le toolkit de X.
Concrètement, en l'absence de framework dédié, il faudra écrire le tien. Et pour éviter de tout refaire à chaque fois — et surtout en double — tu vas devoir définir toi-même tes API, puis t'appuyer dessus. C'est passionnant en soi parce que parcourir ce chemin va t'amener toi-même à envisager les concepts d'objets, d'événements, de boucle principale, etc. qui DEPUIS ont été formalisés et qui sont maintenant enseignés aux étudiants comme s'ils dataient de l'antiquité.Citation:
Envoyé par nawfal.f
À l'époque, c'était plus facile parce qu'il n'y avait pas de mode protégé et que la plupart des systèmes étaient monotâches. Donc, aller écrire directement à l'écran était possible et sans conséquence. Aujourd'hui il y a plus d'étapes à franchir mais le concept reste globalement le même.
Comme on te l'a suggéré, le mieux que tu aies à faire aujourd'hui pour « simuler » l'environnement de l'époque est d'utiliser la SDL pour ouvrir une fenêtre de travail : ceci va te permettre de l'intégrer à ton environnement actuel. Mais une fois ouverte, tu t'interdis d'utiliser toute primitive SDL supplémentaire : tu n'utiliseras QUE le pointeur qui référence le début de la fenêtre et qui te permet d'écrire dedans. Tu t'apercevras qu'écrire des données à l'emplacement indiqué par ce pointeur provoque l'affichage de pixels dans cette fenêtre. Il en va exactement de même pour les périphériques vidéos : ils sont dotés de mémoire vive, et parfois utilisent directement la mémoire centrale de l'ordinateur, et la lisent automatiquement, linéairement, pendant les phases d'inactivité du CPU, de façon complètement transparente pour l'utilisateur : chaque valeur lue est transcrite en un pixel de couleur différente parce que l'automate se sert de cette valeur pour moduler le signal envoyé au moniteur.
Quand tu feras la même chose avec la SDL, ce ne sera pas aussi direct (autrement tu risquerais de sortir de la fenêtre) mais presque : la bibliothèque se débrouillera pour intercepter ton accès (soit à l'aide d'une exception sur une page, soit en faisant des rafraîchissements à intervalles fixes) et pour le traduire vers l'environnement qu'elle gère.
Quoi qu'il en soit, en faisant des accès mémoire, tu parviendras à allumer des pixels : de là, sers-toi de cette possibilité pour écrire une fonction Plot(x,y) qui te permettra d'en allumer un à la position de ton choix et avec la couleur de ton choix. Quand tu auras réussi, sers-toi de cette fonction pour écrire une autre fonction Line(x1,y1,x2,y2) pour tracer un segment de droite, etc. Fais-en une autre permettant de remplir une zone, directement avec le pointeur plutôt qu'avec Plot() et Line() pour des raisons de performance. Ensuite, tu peux essayer de lire un fichier bitmap et voir si tu arrives à le faire afficher directement dans ta fenêtre.
Quand tu auras écrit cela, tu auras recomposé une bibliothèque graphique permettant de dessiner des primitives à l'écran à partir d'un simple pointeur, et tu auras fait 80% de ce que les interfaces de l'époque faisaient.
Deux mots clés pour t'aider dans cette tache:
raster: le fait de créer une image discrétisée en pixels.
Bresenham: algorithme de tracer de segment (du nom de l'inventeur)