Journal Programmation 3D à travers les âges : OpenGL 1.1 (1997-2003)

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
49
16
sept.
2025

Sommaire

Salut 'nal,

Si tu suivi mon journal précédent, tu as maintenant les éléments de contexte pour programmer en 3D !

On va passer à la pratique avec un exemple OpenGL 1.1 (cf. spécification), qui correspond au code typique des années fin 90-début 2000. Mais qui, magie de la rétrocompatibilité, tourne encore très bien aujourd'hui.

logo OpenGL

Installer une "glu" de fenêtrage : SDL3

OpenGL s'occupe très peu du système de fenêtrage. Eh oui, ce n'est qu'une API de dessin : gérer les événements clavier-souris-fenêtre de l'OS est en dehors de son périmètre.

C'est ainsi que chaque système fournit sa bibliothèque maison pour ça :

  • sous X11 : Mesa fournit l'API GLX directement dans la bibliothèque principale libGL. Cette fusion entre les deux est d'ailleurs une erreur de conception, qui sera évitée dans la future bibliothèque OpenGL ES pour l'embarqué ;
  • sous Wayland (et récemment X11) : le Khronos Group fournit l'API "universelle" EGL ; […]
  • les autres OS : ne supportent en réalité pas nativement EGL, on y utilise p.ex. ça ou ça ;
  • et en général avec Vulkan : universel mais rien à voir 😛.

Vous l'avez compris, ce fatras nous éloigne du sujet… on va donc faire comme des milliers de codeurs avant nous : utiliser une bibliothèque de "glu" multi-plateforme ! (Free)GLUT et GLFW sont encore très utilisées…

Mais nous préférerons SDL 3 car elle supporte toutes les combinaisons ET nous aidera plus tard pour Vulkan.

logo SDL

Elle n'est juste pas encore empaquetée dans les distributions les plus courantes, alors installons-la rapidement :

Prérequis

Debian/Ubuntu :

sudo apt install build-essential git make \
pkg-config cmake ninja-build gnome-desktop-testing libasound2-dev libpulse-dev \
libaudio-dev libjack-dev libsndio-dev libx11-dev libxext-dev \
libxrandr-dev libxcursor-dev libxfixes-dev libxi-dev libxss-dev libxtst-dev \
libxkbcommon-dev libdrm-dev libgbm-dev libgl1-mesa-dev libgles2-mesa-dev \
libegl1-mesa-dev libdbus-1-dev libibus-1.0-dev libudev-dev

Fedora/RHEL :

sudo dnf install gcc git-core make cmake \
alsa-lib-devel pulseaudio-libs-devel pipewire-devel \
libX11-devel libXext-devel libXrandr-devel libXcursor-devel libXfixes-devel \
libXi-devel libXScrnSaver-devel dbus-devel ibus-devel \
systemd-devel mesa-libGL-devel libxkbcommon-devel mesa-libGLES-devel \
mesa-libEGL-devel vulkan-devel wayland-devel wayland-protocols-devel \
libdrm-devel mesa-libgbm-devel libusb1-devel libdecor-devel \
pipewire-jack-audio-connection-kit-devel

Compiler

git clone https://github.com/libsdl-org/SDL --branch release-3.2.20
cd SDL
cmake -S . -B build
cmake --build build -j `nproc`

Installer

cmake --install build --prefix $HOME/sdl3220
# configurer
sed -i 's!/usr/local!'"$HOME"'/sdl3220!g' $HOME/sdl3220/lib/pkgconfig/sdl3.pc
echo 'export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$HOME/sdl3220/lib"' >> $HOME/.profile
echo 'export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:$HOME/sdl3220/lib/pkgconfig"' >> $HOME/.profile
# (pour éviter un redémarrage)
source $HOME/.profile

Tester

pkg-config --modversion sdl3
# (devrait vous renvoyer :)
3.2.20

La base de tout : la croix

Nous allons afficher une croix plate interpolée en 2D, composée de 4 points reliés : rouge, vert, bleu, blanc.

croix

et utilisant ce code source C.

Pour le récupérer et me suivre pendant que je détaille, faites sur votre Linux :

git clone https://github.com/Tarnyko/suave_code_samples
cd suave_code_samples/tree/master/C/opengl-vulkan/
editor sdl3-gl1.c

Points & Coordonnées

Le repère orthonormé par défaut d'OpenGL s'étend de -1.0 à +1.0 sur tous les axes. Cela se change, mais nous conviendra très bien pour commencer 😉.
Si on place les 4 points plutôt vers le bord :

Repère avec points

on choisit 0.8,-0.8 comme coordonnées symétriques :

Repère avec points marqués

ça se matérialise facilement en code :

#define LINES 2

static const GLfloat vertex_arr[LINES * 4] = {   //  2 * 4 = 8 valeurs flottantes
    -0.8f,  0.8f,    0.8f, -0.8f,                // point ROUGE, point VERT
    -0.8f, -0.8f,    0.8f,  0.8f,                // point BLEU, point BLANC
};

(chacune des 2 lignes étant constituée de 2 points eux-mêmes définis par 2 coordonnées [X,Y], cela nous donne 2 x 2 x 2 = 8 coordonnées)

Couleurs

Pour les couleurs, bien qu'on puisse utiliser des flottants également, j'ai préféré la définition RGBA32/RGBA8888 beaucoup plus usitée (y compris chez les artistes).

Si un canal couleur est défini par un entier 8-bits, c'est-à-dire "2 exposant 8", c'est-à-dire une fourchette de 0 à 255…
…et qu'une couleur complète est définie par 4 entiers "ROUGE-VERT-BLEU-OPACITÉ" dans cet ordre précis…
… cela donne le code :

static const GLubyte color_arr[LINES * 8] = {    // 2 * 8 = 16 valeurs entières
    255, 0,   0, 255,      0, 255,   0, 255,     // ROUGE, VERT
      0, 0, 255, 255,    255, 255, 255, 255,     // BLEU, BLANC (= tout au max)
};

Index

Nous venons donc de définir 2 tableaux ci-dessus :
- vertex_arr : "points", alias vertex
- color_arr : couleurs

Il nous à les associer avec un tableau d'index associatifs nommé index_arr :

static const GLuint index_arr[LINES * 2] = {     // 2 * 2 = 4 points
    0, 1,                                        // point 1, point 2
    2, 3,                                        // point 3, point 4
};

Code

Voici la partie réellement technique de l'API !

On crée d'abord une fenêtre de taille 800x600 à l'aide de SDL :

window = SDL_CreateWindow([...], _width, _height, SDL_WINDOW_OPENGL);    // _width = 800 ; _height = 600

puis à chaque itération se produisant aussi que possible (on n'a pas encore de limiteur de FPS, ce qui n'est pas si grave sans mouvement), on redessine sur l'intégralité de la fenêtre via ce bloc :

glViewport(0, 0, _width, _height);                                       // contexte (au départ : 800x600)
 [...]
 case SDL_EVENT_WINDOW_RESIZED: { _width  = e.window.data1;              // mis à jour si redimensionnement !
                                  _height = e.window.data2; }

_width et _height sont des variables globales qu'on a déjà utilisées pour créer la fenêtre ; on les refournit ici à glViewport() pour dessiner sur exactement la même taille, c'est-à-dire l'intégralité du fond de la fenêtre
(ce n'est pas obligatoire : un contexte OpenGL peut cohabiter avec d'autres éléments sur la même fenêtre, typiquement des widgets comme ici par exemple).

Elles sont globales ici, car on les autorise à être modifiées par un événement externe : SDL_EVENT_WINDOW_RESIZED déclenché par la souris de l'utilisateur, qui mettra à jour _width et _height avant la prochaine itération.
De cette manière, notre croix sera redimensionnée en même temps que la fenêtre (sans SDL, on devrait écrire un code beaucoup plus long et spécifique pour gérer cette partie "système". Vous voyez l'intérêt de la "glu" ?)

Finalement le dessin commence ! D'abord on dessine un fond noir sans rien :

glClearColor(0, 0, 0, 255);    // NOIR
glClear(GL_COLOR_BUFFER_BIT);  // ràz avec la couleur de glClearColor()

puis on fournit nos 2 tableaux vertex_arr & color_arr à OpenGL côté CPU/RAM, en indiquant comment les interpréter :

glEnableClientState(GL_VERTEX_ARRAY);                      // active fonction : "vertices CPU/RAM"
glVertexPointer(2, GL_FLOAT, 0, vertex_arr);               // POINTS : groupes de 2 flottants (= [x,y])

glEnableClientState(GL_COLOR_ARRAY);                       // active fonction : "couleurs CPU/RAM"
glColorPointer(4, GL_UNSIGNED_BYTE, 0, color_arr);         // COULEURS : groupes de 4 entiers 0-255 (= RGBA32)

Finalement, on fournit le dernier tableau index_arr pour lancer le dessin des 2 lignes :

glDrawElements(GL_LINES, 4, GL_UNSIGNED_INT, index_arr);

et on rafraîchit simultanément le contexte et la fenêtre :

SDL_GL_SwapWindow(window);

dessin final

Compiler & exécuter

C'est le moment de tester !

gcc -std=c11 sdl3-gl1.c `pkg-config --cflags --libs sdl3` -lGL
./a.out
a.out

Remarques

Ce code fonctionne partout ; même sur Windows 95 ou RedHat 5/Mandrake 6 (1998) en mode logiciel 😉.

Il est par contre extrêmement rétro. Et pas juste dans sa forme, mais sa fonctionnalité :

  • plutôt que stocker les informations de vertices et couleurs sur le GPU (qui sait le faire depuis environ 30 ans avec les VBOs), il les stocke uniquement en RAM centrale et les transfère à chaque itération au GPU ;
  • il effectue un dessin côté CPU en mode immédiat plutôt que d'utiliser un shader stocké sur le GPU ;

Ces innovations apparaîtront respectivement dans OpenGL 1.5 (2003) et 2.0 (2004).

Concrètement en les utilisant pas, nous empêchons les GPU récents d'optimiser/paralléliser en retenant beaucoup d'état et de données dans notre programme. La programmation 3D récente utilise beaucoup plus d'appels et d'extensions dédiés au GPU lui-même.

Voilà ! Pour élargir ce tutoriel, seriez-vous plutôt intéressés par :
1. faire bouger la croix (ce qui nécessitera de créer un limiteur de FPS) ;
2. afficher 3 triangles formant une pyramide en 3D (ce qui nécessitera d'ajouter le repère [Z]) ?
… ou directement de passer à du code plus moderne avec shader et VBO 😉?

  • # Les trois mon capitaine...

    Posté par  . Évalué à 7 (+6/-0).

    … mais je suis pas bégueule, tu as tout ton temps :).
    Intéressant en tout cas, merci !

    • [^] # Re: Les trois mon capitaine...

      Posté par  (site web personnel) . Évalué à 3 (+1/-0).

      De rien :)
      Dans ce cas, ce serait dans l'ordre présenté (mouvement->pyramide->shaders) car c'est optimal 😛.

      • [^] # Re: Les trois mon capitaine...

        Posté par  (site web personnel, Mastodon) . Évalué à 8 (+5/-0).

        Oui c'est assez classique pour un tuto de présenter d'abord du code basique, pas optimisé, et qui fait les choses de la manière la plus simple possible ("simple" dans le sens de suivre par exemple les mathématiques que tout le monde connaît; même si ce code est potentiellement plus long et finalement plus complexe dans certains cas). Ou encore appelé une "implémentation naïve". Puis ensuite de passer à une réimplementation avec les spécificités d'un langage, ou d'une API, les optimisations, etc.

        En tous cas, ça m'intéresse aussi de voir ce code évoluer (avec du mouvement, puis en 3D…) d'abord dans sa version naïve, puis de voir tout cela réimplémenté dans un second temps avec du code GPU, parallélisé, ou que sais-je encore.

        Cette série de tutoriels s'avère prometteuse.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Les trois mon capitaine...

          Posté par  (site web personnel) . Évalué à 4 (+2/-0).

          Merci du retour Jehan !
          Et oui tu as bien résumé : ici on essaie de viser la simplicité d'abord, bien cerner une notion avant de la raffiner.
          C'est en fait moins courant que l'on pense… à titre perso, j'ai trouvé beaucoup de code utilisant plein de fonctions mais mal expliqué. Et l'impact concret sur les performances, qui est ici plus qu'ailleurs le motif d'utiliser de nouvelles fonctions/extensions au détriment des anciennes ; alors là c'est le plus rare, et c'est pour ça que j'insiste sur cet aspect qui va bien avec le récit en mode "ligne de temps".

          Merci encore ; on va voir si j'arrive à tenir le cap 😉.

          • [^] # Re: Les trois mon capitaine...

            Posté par  (Mastodon) . Évalué à 5 (+2/-0).

            Perso je pars de zéro (sûrement moins même) en matière de 3D (je joue peu à des jeux 3D). Même si j'ai vu la toute première génération de cartes 3D (matrox millenium, 3DFX…) j'ai jamais trop trempé dans le délire.

            Ta façon d'aborder le sujet est parfaite pour moi, merci !

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Les trois mon capitaine...

        Posté par  . Évalué à 3 (+1/-0).

        Merci pour cette série passionnante, et accessible au débutant en 3D que je suis ! Pour la suite, ça ne me semble pas plus mal de suivre l’ordre optimal :-)

  • # Mode direct

    Posté par  (site web personnel) . Évalué à 7 (+5/-0).

    Je m'attendais à voir du glBegin()/glEnd()… Était-ce déjà dépassé à l'époque ?

    Sinon je vote pour les trois tutos aussi, comme mes prédécesseurs :)

    • [^] # Re: Mode direct

      Posté par  (site web personnel) . Évalué à 5 (+3/-0).

      Ah bon sang, glBegin()/glEnd() ! Tu sais que je l'avais presque oublié ?

      Pour ceux qui ne l'ont pas, c'est une très ancienne manière de dessiner, qui ressemble à ça (copie-collé direct de mes archives) :

        glColor3f(1.0f, 0.0f, 0.0f);    /* on définit la couleur ROUGE */

  glBegin(GL_POLYGON);            /* on trace un polygone libre */
    glVertex2f(-0.5f, -1.0f);     /* point 1 en bas à gauche */
    glVertex2f( 0.5f, -0.75f);    /* point 2 en bas à droite */
    glVertex2f( 0.5f,  0.5f);     /* point 3 en haut à droite */
    glVertex2f(-0.5f,  0.5f);     /* point 4 en haut à gauche */
  glEnd();                        /* fin du tracé */

      À un moment vers la fin je parle de mode immédiat ; mais en fait c'est ça le vrai mode immédiat "à l'ancienne" ! Celui qui a dégagé le plus vite des API récentes (car intrinsèquement inoptimisable par le GPU).

      Et donc pour te répondre, je ne l'utilise pas ici car :
      - ça fait tellement longtemps que ça ne m'est juste pas venu (sans rire);
      - ça aurait forcé à réécrire très vite cette partie, alors qu'avec la version par tableaux… eh bien tu verras qu'on pourra la réutiliser après, même avec le très restreint OpenGL ES 😉.

      • [^] # Re: Mode direct

        Posté par  (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 17 septembre 2025 à 14:26.

        C'était ainsi que les fameux tutoriels de NeHe présentaient OpenGL à l'époque. Je suis allé voir le site de la personne derrière ça, où il présente une brève histoire de ses tutos, c'est assez triste. Des années d'efforts et de partage à une époque où c'était clairement la meilleure ressource sur le sujet, pour ensuite se faire rabaisser et mépriser quand le mode direct est devenu dépassé :(

        • [^] # Re: Mode direct

          Posté par  (site web personnel) . Évalué à 2 (+0/-0).

          Ah ? J'ai cherché ce que tu décris chez lui directement, mais j'ai plutôt trouvé ça sur certains réseaux sociaux (je laisserai pas la capture super longtemps) :

          capture_rs

          C'est à ça que tu fais référence ?

          • [^] # Re: Mode direct

            Posté par  (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 17 septembre 2025 à 15:33.

            Dans la section NeHe Tutorials: Some History de https://nehe.me/

            By this point there were dozens of sites hosting my tutorials (rebranded as theirs of course), […]. The questions via email were getting more and more complex and more and more demanding, and I started seeing the bad seeds. I'd get an email from joe blow asking me to plug his site, telling me how if it wasn't for my site, his site wouldn't exist. So I'd work with joe blow to craft a message he was happy with. I'd do a HUGE post about the amazing things on joe blows site, only to see a post from him the next day saying "NeHe's stuff is junk, this is where you need to be".

            • [^] # Re: Mode direct

              Posté par  (site web personnel) . Évalué à 4 (+2/-0).

              Passionnant, merci.
              J'ai supprimé la capture (elle persistera un peu par la magie du cache de LinuxFR…).

              J'ai pas mal ri à :

              My documentation transitioned from physical notebooks to digital .nfo files (the elite extension)

              et après je suis arrivé sur ta partie… déprimant. Mais je synthétiserai avec :

              a pace of releasing three to four tutorials weekly […] that tested both my physical and mental limits.

              NeHE n'était donc que très peu payé en regard de son travail ; l'admiration de la commu était sa réelle rétribution. Sauf que cela créait des attentes disproportionnées, avec la fameuse toxicité du net par-dessus. Le coup de grâce étant d'être jugé après sur des tutos obsolètes qu'il ne peut ni mettre à jour ni supprimer (car hébergés chez d'anciens partenaires qui ont "rompu" avec lui en gardant son contenu).

              Toutes proportions gardées et sans aller si loin en perso, j'ai vécu certaines de ces choses à une époque.
              Ça apprend à prendre de la distance, à toujours prioritiser son fun personnel sur les attentes de truc ou bidule. L'avatar ultime du Chaos étant le mécène qui abuse de son statut pour te traiter comme une lavasse (il y a une vidéo récente où la situation m'a fait penser exactement à ça).

              Perso je trouve qu'il a fait un super taf à l'époque, et qu'il a le droit de se retirer du game quand il veut sans rien devoir à personne. D'ailleurs moi aussi je posterai peut-être plus rien après ça, pas trop décu 😄?

        • [^] # Re: Mode direct

          Posté par  (site web personnel, Mastodon) . Évalué à 6 (+3/-0).

          Cette remarque m'a intrigué donc j'ai dû chercher sur le web car je ne connais pas cette histoire. Pour les autres qui sont intrigués, voici le lien (ça vous évitera de chercher aussi!): https://nehe.me/

          Cette histoire est triste en effet, et malheureusement bien trop courante. Combien de personnes "brûlées" parce qu'elles se sont approchées trop proche du soleil sans jamais l'atteindre pendant des décennies? Rien que cette semaine, je lisais ce post de blog d'un contributeur majeur, pendant 25 ans, de KDE qui arrête après avoir été déçu par d'autres contributeurs (sans commentaire de ma part sur qui a raison ou non car je ne connais pas ces gens, mais c'est une histoire de sous). Ou encore le mainteneur de libxml2 qui arrête après 12 ans de contribution sur cette bibliothèque majeure utilisée massivement. Il avait déjà partagé ses réticences par rapport aux mauvais acteurs du libre qui réclamaient toujours plus de lui (notamment les fameux "chercheurs" en sécurité qui pour beaucoup — pas tous mais énormément — relèvent plus de gens qui remplissent des lignes de CVs avec le genre de bugs basique que n'importe quel dév de base corrige à la pelle plutôt que perdre du temps à faire des "CVEs"), il y a quelques mois.

          Enfin bon, les parasites pullulent malheureusement sur l'internet. Ils se nourrissent du travail des autres et s'en fichent totalement de les suffoquer (ils passeront juste à autre chose si la source se tarit).

          Quant à ceux qui sont productifs, mais crachent sur le code historique (comme on le lit dans l'histoire de ce Nehe) et sur les anciens contributeurs… alors même que tout leur propre travail repose sur ce code historique (et que leur propre notoriété vient de ce fait! Car ils continuent sur une base de code qui a eu des décennies pour s'affiner et se faire connaître), c'est d'une vision court-termiste et d'un manque de classe total aussi. Perso dès que quelqu'un fait une remarque désobligeante sur un bout de code historique dans GIMP, je leur fais poliment remarquer que cela ne se fait pas et que sans ce bout de code, ils ne seraient pas là non plus (sans avoir connu ces développeurs historiques moi-même; car ce n'est pas la question). C'est malheureusement bien trop courant chez certains développeurs plus jeunes qui sont prompts à vouloir faire leurs marques et à prouver qu'ils sont meilleurs que les anciens, à vouloir faire table rase bien trop facilement, quitte à causer de nouveaux problèmes. Combien de fois ai-je calmé les ardeurs de nouveaux contributeurs qui voulaient juste tout casser pour faire "mieux" et n'en avaient rien à faire des usagers ou usages historiques.

          C'est d'ailleurs aussi une tendance que je remarque dans des projets relativement récents (ça peut vouloir dire 10 ou 15 ans, hein!) qui font de super trucs d'un côté, mais de l'autre veulent soit tellement se démarquer soit juste refuser les usages historiques (sans pour autant avoir de solution autre à proposer pour les problématiques qu'ils jugent "obsolètes" mais qui sont pourtant présentes dans le monde réel) parce qu'ils ne les trouvent pas correspondant à leur vision idéalisée de "ce qu'il faut faire".

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Mode direct

            Posté par  (site web personnel, Mastodon) . Évalué à 10 (+7/-0).

            P.S.: y a un truc que j'aime bien dire régulièrement (dans des confs ou autre), c'est que l'expression "des nains sur des épaules de géants" est bidon, et c'est juste une vision marketing où on aime bien faire de certaines personnes des sortes de héros à idolâtrer. En fait, on est surtout tous des nains sur des épaules de nains! Une pyramide de nains quoi! 😄

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

            • [^] # Re: Mode direct

              Posté par  (site web personnel) . Évalué à 2 (+0/-0).

              Combien de personnes "brûlées" […] ? Rien que cette semaine, je lisais ce post de blog d'un contributeur majeur, pendant 25 ans, de KDE qui arrête après avoir été déçu par d'autres contributeurs

              Le truc Jehan, c'est que l'important n'est pas tant de commencer ou arrêter, mais juste de faire.

              On peut se (sur-)impliquer pendant des années sur un super-projet, même pour la gloire ou les vibes au détriment de l'argent, et tout ça est également valide : tant qu'on y trouve son compte.
              Après si la raison d'origine disparaît, il faut parfois se reposer la question la tête froide.

              Humainement on persiste toujours un peu, car il y a le biais des coûts irrécupérables (appelé par moi "effet ex-copain/copine"). Qui n'est finalement pas si mal, sinon les situations difficiles ne seraient jamais sauvées. Mais j'ai bien peur qu'il n'y ait pas d'alternative entre la déprime et relativiser/s'endurcir un peu.

              Le logiciel évolue très vite, les têtes pareil ; il faut plus s'attacher à ses qualité propres qu'à ça. Faire de soi-même un roc solide pour rester stable au milieu du courant (elle est bien celle-là ou 😄 ?).

              • [^] # Re: Mode direct

                Posté par  (site web personnel) . Évalué à 7 (+5/-0).

                C'est une chose d'arrêter un projet parce qu'il ne nous intéresse plus et ce n'est pas vraiment un problème à mon avis. Ce qui est embêtant c'est plutôt cette tendance à vouloir mépriser les méthodes du passé et ceux qui ont créé et diffusé ces pratiques à une époque où c'était nouveau. Trop d'articles et commentaires rabaissent d'anciennes pratiques à coup de come on, it's <insert current year> now et similaires, tous les outils récents se présentent comme « modernes ». C'est à mon sens une marque d'ignorance de l'histoire de l'informatique, en particulier une ignorance des pratiques qui nous ont amené là où nous sommes aujourd'hui. C'est très facile de mépriser les initiateurs d'anciennes pratiques une fois qu'on a des dizaines d'années de recul mais c'est oublier que eux aussi, à l'époque, considéraient qu'ils étaient modernes :)

                • [^] # Re: Mode direct

                  Posté par  (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 17 septembre 2025 à 19:52.

                  Évidemment !
                  Après si tu me permets, je trouve que riposter au nom de NeHE face à ses harceleurs d'époque (à moins qu'il en reste aujourd'hui ?), c'est un bon rappel d'histoire. Un vrai drame de l'époque. Mais juste, une fois fait, un peu redondant ?

                  Car est-ce qu'on méprise ici ? Non ! Jamais 😃. On explique comment ça marchait avant, pourquoi on ne le fait plus, et on se sent temporairement un-peu-plus-moderne jusqu'à atteindre le prochain palier de l'API qui remettra nos acquis en question (pour le meilleur et pour le pire).
                  On espère que ça nous évitera de piétiner sur place. On honore les anciens, on remet le casque de chantier et on retourne au fourneau !

                  (exemple sans rapport : à titre perso, je ne suis pas plus attaché que ça à la POO. Je trouve que c'est une technique excellente sur un type de projet, "meh" sur d'autres, et contre-productive sur encore d'autres. Je ne trouve pas que c'est une technique obsolète, mais qu'elle a un cadre d'usage. Par contre je n'hésiterais pas à en faire la remarque à quelqu'un qui s'acharnerait à l'utiliser "parce que c'est toujours ce qu'il fait d'habitude", hors analyse du cadre)

  • # distro moderne

    Posté par  (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 17 septembre 2025 à 01:57.

    Elle n'est juste pas encore empaquetée dans les distributions les plus courantes, alors installons-la rapidement :

    tu ne donnes des exemples que pour ubuntu et fedora ?

    tu aurais pu donner l'exemple de Debian comme distribution moderne et à la pointe tout de même :

    • apt install libsdl3-0

    et hop c'est bon ;-)
    ok, c'est avec trixie (donc la stable actuelle, dans la continuité de bookworm) cf. https://packages.debian.org/search?suite=trixie&section=all&arch=any&searchon=names&keywords=libsdl et oui c'est la SDL3 en version 3.2.10 (et non 3.2.20)

    Avec Mageia, comme je suis en Cauldron (l'équivalent de sid ou de rawhide), je bénéficie d'un GNOME-49 en cours de finalisation (spa sec :/ c'est bien, ça permet de réessayer enlightenment, lxqt :D) et aussi de lib64sdl3_0 en 3.2.20 (de l'intérêt d'une distribution en rolling-release pour le dév de la version suivante : j'ai les bugs en avance, mais aussi les fonctionnalités avec leurs nouveaux bugs :p). Je laisse les archers et gentooistes défendre leur point de vue :D

    • [^] # Re: distro moderne

      Posté par  (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 17 septembre 2025 à 06:41.

      Ah je t'avoue : je suis plutôt sur des distributions LTS où le paquet n'existe pas encore.
      Et du coup, merci beaucoup pour la procédure ! Même si à mon avis tu auras plutôt besoin de :

      apt install libsdl3-dev

      (le paquet "-dev" contient les headers etc… permettant de compiler avec GCC)

      et oui c'est la SDL3 en version 3.2.10 (et non 3.2.20)

      Alors là-dessus, anecdote (et peut-être que tu pourras me répondre) : j'utilisais au départ la version 3.2.0, mais qui avait un souci avec Wayland. Une mauvaise utilisation de la libdecor qui masquait la fenêtre, et pour laquelle j'avais écrit un patch.
      Sauf qu'après en passant à la 3.2.20, j'ai vu qu'ils avaient corrigé le problème.
      Mais du coup la 3.2.10 de Debian, pile entre les deux ? Eh bien ça pourrait se tester en lançant l'exemple comme ça :

      SDL_VIDEODRIVER=wayland LIBDECOR_FORCE_CSD=1 ./a.out

      Intéressé par ton retour là-dessus (si tu as le temps bien sûr !)

      PS: et du coup Mageia Cauldron, c'est impeccable, même si là ça devient plutôt GNOME l'inconnue 😛.

      • [^] # Re: distro moderne

        Posté par  (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 17 septembre 2025 à 08:17.

        Pour info la compilation de la croix est passée crème sur Arch (KDE/Wayland) :

        sudo pacman -S sdl3
gcc -std=c11 sdl3-gl1.c `pkg-config --cflags --libs sdl3` -lGL

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # SDL 3

    Posté par  . Évalué à 2 (+1/-0).

    Merci pour ces journaux très intéressants sur la programmation 3D  !

    Après des débuts sur Glut, puis un passage par sfml, j'ai longtemps utilisé SDL2 pour mes développements / bidouilles divers en OpenGL, et je suis finalement passée sur GLFW. Les principales raisons étaient une légère préférence pour l'API de GLFW, et que SDL fait plein de trucs en plus dont je n'ai pas besoin ou que je préfère faire différemment. En ce moment, je découvre Vulkan parce que pourquoi pas et je suis restée sur GLFW. D'ailleurs, le tuto que je suis pour Vulkan utilise GLFW, je ne l'ai donc pas remis en question par simplicité.

    Je n'avais pas fait attention qu'une 3ème version de SDL est sortie, quasi toute neuve d'ailleurs. Est-ce que tu pourrais m'en dire plus les raisons de ta préférence pour SDL3 ?

    • [^] # Re: SDL 3

      Posté par  (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 19 septembre 2025 à 12:14.

      Hello et cool que ça te plaise !

      Aaah Glut… le vieil exemple que j'ai retrouvé l'utilisait encore. Et bien que je ne l'aie jamais utilisé, j'ai effectivement vu énormément de GLFW sur les codes Vulkan récents !
      Tu n'as pas entièrement tort sur SDL. Il fait beaucoup de choses, et d'ailleurs on pourrait juste dessiner avec son API haut niveau en lui laissant sélectionner le moteur (OpenGL ou autre)… si ce n'était pas le sujet principal du tuto ;-).

      Ce qui a motivé mon choix :
      - (le point perso dont tout le monde se fiche) je fais un portage avec en ce moment ;
      - un meilleur support fenêtrage de Wayland, visible en comparant le nombre de protocoles supportés par SDL2 contre SDL3 ;
      - le code Vulkan à venir sera très long, je pense que tu vois ce que je veux dire… une fois démontré la première fois, je projette d'utiliser les nouvelles fonctions de SDL_GPU pour le raccourcir et se concentrer sur la boucle de rendu.
      Qu'en penses-tu ?

      • [^] # Re: SDL 3

        Posté par  (site web personnel) . Évalué à 2 (+0/-0).

        • un meilleur support fenêtrage de Wayland, visible en comparant le nombre de protocoles supportés par SDL2 contre SDL3 ;

        Ah zut, je ne peux plus éditer, mais je comparais aussi avec le support Wayland de GLFW : au doigt mouillé, c'est entre les 2.
        En vrai c'est loin d'être si important, la plupart n'utiliseront jamais tous ces protocoles, et nous alors… mais il y en a un dont je voulais être 100% sûr (même si GLFW a aussi l'air de le supporter) c'est le "pointer lock" pour verrouiller la souris dans une fenêtre ; et hors bas niveau je ne l'avais testé que là 😓.

        • [^] # Re: SDL 3

          Posté par  . Évalué à 2 (+1/-0).

          Merci pour ton retour ! Je jetterai un oeil aux différences entre les 2 en terme de support, mais il y a des chances que ce qui tranche pour moi soit le même type de "point perso dont tout le monde se fiche" : si les différences sur ce dont j'ai besoin ne sont pas significatives, autant ne pas changer de bibliothèque.

          • le code Vulkan à venir sera très long, je pense que tu vois ce que je veux dire… une fois démontré la première fois, je projette d'utiliser les nouvelles fonctions de SDL_GPU pour le raccourcir et se concentrer sur la boucle de rendu. Qu'en penses-tu ?

          Haha, je vois carrément ce que tu veux dire ! Quand j'ai suivi le tuto Vulkan, j'ai pas compté les heures mais il m'a fallu plusieurs soirées pour simplement afficher fièrement un bête triangle !

          C'est une très bonne idée en effet de ne le faire qu'une fois, et ensuite puisqu'il y a des fonctions SDL qui font ça, de les laisser gérer une partie du travail déjà montré pour que la suite ne soit pas noyée dans ce qui a déjà été fait.

          • [^] # Re: SDL 3

            Posté par  (site web personnel) . Évalué à 2 (+0/-0).

            si les différences sur ce dont j'ai besoin ne sont pas significatives, autant ne pas changer de bibliothèque.

            Oui voilà ! C'est beaucoup une question d'habitude, et là on ne les utilise pas (encore) de manière assez poussée pour voir la différence.

            il m'a fallu plusieurs soirées pour simplement afficher fièrement un bête trianglé

            On se comprend 😄.

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.