Le topic de la programmation, string, chaînes, cuir et compagnie

**Tomaka17** · 16/01/2013, 16h51

Envoyé par Nacodaco

En haut à droite, mais parce que j'ai fait une modification que je n'ai pas annulée.

Yep, c'est ce que je pensais.
Lis ma réponse plus haut.

---------- Post added at 16h51 ---------- Previous post was at 16h47 ----------

Après tu peux aussi régler uniquement le premier problème (parce que celui là est grâve, c'est un coup de chance si ça marche), et continuer de faire un dessin différent par case comme actuellement (c'est plus simple, parce que générer un grand vertex buffer c'est pas forcément évident).

Mais à ce moment là il faut que tu fournisses i, j et GRID_SIZE à ton fragment shader via des variables uniform, et que tu fasses un produit en croix à l'intérieur du fragment shader.
Un truc comme : "(vTextureCoord + vec2(i, j)) / GRID_SIZE".

L'idée c'est qu'à l'intérieur de ton fragment shader, toutes les coordonnées de texture que tu récupères vont de 0 à 1.
Si tu fais "textureCoord / GRID_SIZE + vec2(i,j) / GRID_SIZE" tu auras des coordonnées de texture qui vont de (i/GRID_SIZE, j/GRID_SIZE) jusqu'à ((i+1)/GRID_SIZE, (j+1)/GRID_SIZE)
Et du coup de l'extérieur tu auras l'impression que la texture recouvre un seul objet, alors qu'en fait elle recouvre partiellement plein de petits objets.

En espérant ne pas t'avoir largué.

**Nacodaco** · 16/01/2013, 17h10

Envoyé par Tomaka17

En espérant ne pas t'avoir largué.

Dommage.

Non mais il me manques des bases quoi... Mais je comprends certains trucs.

En fait je crois avoir déjà essayé ce que tu expliques dans le dernier paragraphe (mais en faisant n'importe quoi). En fait j'avais modifié vertices de textureCoordBuffer pour ne prendre en compte que des parties de l'image (et ainsi reconstituer une image complète lors du drawScene()).

Bon sinon y a des trucs qui bloquent quoi...
C'est quoi le fragment shader (c'est où à l'intérieur du fragment shader) ? variable uniform ?

**deathdigger** · 16/01/2013, 17h11

Envoyé par SetaSensei

On travaille uniquement sur du XML vu qu'on échange des données typées (string, datetime, ...) et qu'on fait du croisement d'informations, pour faire simple. Donc oui, XML est légitime. Et puis le WCF derrière prends un XDocument en entrée...

Le gars soutenait mordicus qu'avec le content type qu'on demandait, fallait envoyer un fichier xml. Et ouais, il parlait de binaire, mais je vois pas pourquoi.

Ce qui m'emmerde c'est sa définition d' application/xml. D'après lui c'est nous qui avons mal construit le WS (bon en soit c'est pas totalement faux). Mais je ne vois pas pourquoi avec ce content-type on est obligé de passer un fichier.
Ni Fiddler ni aucun autre soft du genre ne m'a jamais emmerdé là dessus.

D'ailleurs j'ai fait des tests pour voir et quand je balance un fichier xml, il me place le content type en text/xml...

Je pense que par binaire, il entendait encodage ANSI. Pour le "xml only", je pense que c'est parce qu'il passe par un XMlSerializer ou un XPathNavigator par défaut, et donc si tu t'amuses à foutre un autre format, ça peut foutre la merde

**SetaSensei** · 16/01/2013, 17h32

Envoyé par deathdigger

Je pense que par binaire, il entendait encodage ANSI. Pour le "xml only", je pense que c'est parce qu'il passe par un XMlSerializer ou un XPathNavigator par défaut, et donc si tu t'amuses à foutre un autre format, ça peut foutre la merde

Ok pour le serializer et tout ... Mais justement, c'est moi qui manipule le xml. Lui il ne fait que de me l'envoyer.

En gros, ma question est :

Je veux qu'il m'envoie du XML en POST (j'ai vérifié, PUT est désactivé sur IIS chez nous) avec un content-type: application/xml
Le client me soutient qu'avec ce content-type, il ne peut que me faire un PUT d'un fichier xml. Ou en tout cas, son système ne lui permet pas de faire autrement. Il a une boîte noire.
Qu'il ait des emmerdes dans le genre, ok. Mais je ne vois pas en quoi ça serait moi le fautif parce que je ne trouve rien qui me prouve que ce content-type là impose un PUT.

Voilà.
Je suis sûrement pas clair parce que ça m'énerve et que je répète la même chose depuis 14h. Désolé.

**Tomaka17** · 16/01/2013, 17h40

Envoyé par Nacodaco

Dommage.

Non mais il me manques des bases quoi... Mais je comprends certains trucs.

En fait je crois avoir déjà essayé ce que tu expliques dans le dernier paragraphe (mais en faisant n'importe quoi). En fait j'avais modifié vertices de textureCoordBuffer pour ne prendre en compte que des parties de l'image (et ainsi reconstituer une image complète lors du drawScene()).

Bon sinon y a des trucs qui bloquent quoi...
C'est quoi le fragment shader (c'est où à l'intérieur du fragment shader) ? variable uniform ?

Ton fragment shader c'est ton <script type="x-shader/x-fragment">

Je vais t'expliquer comment t'es censé faire point par point :

1. Tu initialises WebGL, tu charges les shaders, tu charges la texture, etc., tout ça c'est bon
En préambule : un shader est un programme qui sera exécuté par la carte graphique, une texture est simplement une image chargée dans la carte graphique.
Le code de ton vertex shader c'est qu'il y a dans <script type="x-shader/x-vertex">, et pareil pour le code de ton fragment shader.

2. Tu créé le vertex buffer de l'objet que tu veux dessiner. Actuellement tu en as deux, "squareVertexPositionBuffer" et "squareVertexTextureCoordBuffer".
Un vertex buffer est un tableau des points qui doivent être présents à l'écran. Par exemple si tu veux une grille de 2x2 rectangles, ça te fait 9 points.
Chaque élément du tableau contient les informations concernant le point. Ca peut être ce que tu veux puisque c'est toi qui les manipules plus tard. Là pour cet exemple tu dois mettre la position du point, et les coordonnées de texture qui lui sont associées.

Donc par exemple pour une grille de 2x2 rectangles, tu as le point en haut à gauche avec la position (-0.5,0.5) et les coordonnées de texture (0,1), puis le point en haut au milieu, puis celui en haut à droite, etc. Concrètement tu fais ça comme tu fais actuellement, c'est à dire :
vertices = [ -0.5, 0.5, 0, 1, /* même chose pour le point suivant */, /* même chose pour le point suivant */, etc. ];
C'est à cet endroit que tu dois mettre la seule boucle for du programme. Pour rajouter des points au "vertices".

3. Au moment de dessiner, c'est à dire dans drawScene. Tu bind le vertex buffer, c'est à dire que tu dis à OpenGL "voici le vertex buffer qui contient mes points".
Ensuite tu appelles deux fois "vertexAttribPointer". C'est grâce à ça que tu fais la liaison entre le contenu de ton vertex buffer et les noms de variables de ton vertex shader.
Dans le premier appel tu lui dis "la variable aVertexPosition de mon vertex shader doit contenir les floats numéro 1 et 2 de chaque vertex de mon vertex buffer, et les vertex font chacun 4 floats"
Dans le second appel tu lui dis "la variable aTextureCoord de mon vertex shader doit contenir les floats numéro 3 et 4 de chaque vertex de mon vertex buffer, et les vertex font chacun 4 floats"

4. Tu définis la valeur de tes uniforms dans tes shaders (les variables qui ont "uniform" devant elles). Les variables uniforms sont des variables dont la valeur est fixe et constante. Leur but est justement de pouvoir les modifier uniquement de l'extérieur, c'est à dire via WebGL.
Pour ton fragment shader, tu dis "la valeur de uSampler doit pointer vers ma texture" (les textures c'est un peu plus compliqué, je zappe ça). Pour l'instant tu peux considérer que le mot "sampler" est un synonyme de texture.
Pour ton vertex shader, tu dis "la valeur de uPMatrix doit être telle matrice, la valeur de uMVMatrix doit être telle autre matrice"
C'est la fonction "setMatrixUniforms()" actuellement.

5. OpenGL va maintenant prendre un à un chaque point de ton vertex buffer.
Il va appeller le vertex shader une fois pour chaque point. Si tu as 9 points il va exécuter 9 fois le vertex shader.
Comme tu peux le voir dans ton vertex shader, tu multiplies les coordonnées de position (c'est à dire le contenu de ta variable aVertexPosition, c'est à dire les floats numéro 1 et 2 de chaque vertex) par tes matrices, et tu renvoies le résultat.
De plus tu prends la valeur de aTextureCoord et tu la transmets à ton fragment shader en définissant "vTextureCoord".

À la fin de l'exécution des vertex shaders, OpenGL sait où sont tous tes points à l'écran. Pour chaque point il a encore quelque part en mémoire ses coordonnées de texture.
Il va maintenant créer les triangles et déterminer quels sont les pixels de l'écran qui sont à l'intérieur de ton objet.
Les pixels de l'écran qui ne sont pas à l'intérieur de ton objet sont ignorés. Par contre pour chaque pixel qui se situe à l'intérieur de ton objet, il va appeller le fragment shader.
S'il y a 50000 pixels il va appeller 50000 fois le fragment shader. C'est d'ailleurs pour ça que les jeux vidéos sont plus lents quand tu as une plus grande résolution, c'est parce qu'il faut appeller plus souvent le fragment shader.

Le fragment shader a a sa disposition la texture "uSampler" et les coordonnées de texture. Là où c'est magique, c'est que OpenGL a fait la moyenne des coordonnées de texture autour. Par exemple pour tel pixel, il y a un vertex ici dont les coordonnées de texture sont (a,b), il y a un autre vertex là dont les coordonnées sont (c,d), et un troisième dont les coordonnées sont (e,f). Hé bien il va faire la moyenne de ces trois coordonnées en fonction de la distance. De cette façon, le contenu de ta variable "vTextureCoord" représente les coordonnées de texture de ce pixel précis, qui seront différents pour le pixel à côté.

Enfin ton fragment shader va lire à l'intérieur de la texture quelle est la couleur à ces coordonnées là, et renvoyer cette couleur qui va être écrite sur le pixel. Si tu regardes le résultat tu vois une jolie image, mais en fait ce sont juste des valeurs de couleur que tu as lues une par une dans la texture.

---------- Post added at 17h40 ---------- Previous post was at 17h36 ----------

Le dernier problème, c'est l'ordre dans lequel tu mets tes points à l'intérieur du vertex buffer.
Actuellement tu dis à OpenGL "les points sont dans l'ordre TRIANGLE_STRIP" (regarde ton appel à drawArrays).

Le plus simple pour toi, c'est de faire triangle par triangle, c'est à dire "TRIANGLES_LIST" à la place de "TRIANGLE_STRIP".
Chaque rectangle que tu veux dessiner, tu le découpes en deux triangles rectangles (un en haut à gauche, un en bas à droite).
Tu donnes d'abord les trois points qui composent le premier triangle, puis les trois points qui composent le second triangle.

Ca veut dire que pour chaque rectangle tu n'auras pas 4 mais 6 points. Si tu as 2x2 rectangles, ça te fait 24 points. Evidemment une boucle for est recommendée.

Evidemment ça gaspille pas mal de place de mettre 24 points alors qu'on pourrait n'en mettre que 9. C'est pour ça qu'on a les index buffer, mais ça c'est une autre histoire.

Version TL;DR : achète un bouquin sur le sujet

**Nacodaco** · 16/01/2013, 19h00

Merci beaucoup de prendre un peu de temps pour m'aider

Déjà le soucis, c'est que ça ne ressemble pas à la méthode vu lors des quelques cours que j'ai eu. Ca m'embrouille un peu :/

En tout cas je vais essayer ce que tu décris. Je suis pas très confiant quant au résultat mais ça coûte rien de tenter !

Pour le livre, pas la peine pour le moment. Ça m'intéresserait vraiment de mettre sérieusement à OpenGl/WebGl un jour, mais les espèces de simulacre de cours qu'on a eu avec une partie "découverte par tâtonnement" et une autre partie "y a vraiment de super tutos sur le web", c'est à te dégoûter...

---------- Post added at 19h00 ---------- Previous post was at 18h29 ----------

Envoyé par Tomaka17

2. Tu créé le vertex buffer de l'objet que tu veux dessiner. Actuellement tu en as deux, "squareVertexPositionBuffer" et "squareVertexTextureCoordBuffer".
Un vertex buffer est un tableau des points qui doivent être présents à l'écran. Par exemple si tu veux une grille de 2x2 rectangles, ça te fait 9 points.
Chaque élément du tableau contient les informations concernant le point. Ca peut être ce que tu veux puisque c'est toi qui les manipules plus tard. Là pour cet exemple tu dois mettre la position du point, et les coordonnées de texture qui lui sont associées.

Donc par exemple pour une grille de 2x2 rectangles, tu as le point en haut à gauche avec la position (-0.5,0.5) et les coordonnées de texture (0,1), puis le point en haut au milieu, puis celui en haut à droite, etc. Concrètement tu fais ça comme tu fais actuellement, c'est à dire :
vertices = [ -0.5, 0.5, 0, 1, /* même chose pour le point suivant */, /* même chose pour le point suivant */, etc. ];
C'est à cet endroit que tu dois mettre la seule boucle for du programme. Pour rajouter des points au "vertices".

La seule boucle for du programme ? Il n'y en a pas dans drawScene() alors ?

J'ai essayé d'appliquer ce que tu m'as dis, même si je suis persuadé d'avoir fait n'importe quoi (bon déjà ça se lance pas (out of range dans le vertices)).

J'ai mis à jour le dossier public si tu veux déprimer ( https://docs.google.com/folder/d/0B8...NXNU1kMEU/edit ).

**Frypolar** · 16/01/2013, 19h01

Bijour,

Bon c’est pas purement de la programmation mais je tente ma chance ici quand même. Je commence à collecter quelques infos pour le craft dans un jeu que j’aimerais pouvoir manipuler. J’étais parti au début sous Excel avec un bête tableau à menu déroulant mais vu l’ampleur du bousin il va falloir passer à quelque chose de plus adapté pour traiter tout ça. Je connais un petit peu Access, et j’ai une licence via MSDNAA, mais c’est aussi l’occasion d’essayer autre chose d’où ma question : y-a-t’il une solution à privilégier pour gérer ça ? Quelque chose qui soit particulièrement apprécié/utilisé en ce moment histoire que ça puisse éventuellement me servir plus tard. J’envisage aussi de peut-être le partager donc Access n’est pas forcément le plus adapté à cause de son coût.

Pour ce qui est de la base de données c’est pas violent. À vue de nez je vais avoir 6 tables différentes avec moins de 10 attributs chacune. Si la liste la plus longue contient 1000 éléments c’est vraiment le bout du monde. Ça correspondrait aux objets craftables et je suis quasiment sûr qu’il y en a un paquet qui sont identiques. Le but est aussi d’arriver à trouver comment ça fonctionne si j’ai assez de données pour pouvoir simuler un craft au lieu de stocker toutes les variantes obtenues à la main. Je n’ai quasiment fait que du C/C++ mais je peux tout à fait me mettre à un nouveau langage.

Merci.

**rOut** · 16/01/2013, 20h28

Envoyé par Tomaka17

Le problème c'est que tu ne peux en binder qu'un seul à la fois. C'est à dire que quand tu fais "bindBuffer" à l'intérieur de ton for dans drawScene(), en fait tu unbind le positionBuffer.
Effectivement tu as appelé vertexBindAttribBuffer alors que le positionBuffer était bindé, mais ça ne veut pas dire qu'opengl va lire dans le positionBuffer. Il va lire dans le buffer bindé au moment du dessin, c'est à dire le textureCoords. Du coup OpenGL lit tes coordonnées de texture et croît que ce sont des coordonnées de position.

Il faut donc que tu fusionnes tes deux buffers en un seul.

Ben non, glVertexAttribPointer copie le buffer bindé dans GL_ARRAY_BUFFER vers GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING[attribut] pour chaque attribut. Tu peux changer le buffer bindé, et faire glVertexAttribPointer à chaque fois, et il se souviendra des buffers associés à chaque attributs.

T'imagines la galère sinon s'il faut tout multiplexer dans un seul buffer ?

Avec ta technique, c'est vachement plus chiant si les attributs deviennent complexes, il faut bien gérer le stride pour chaque attribut et tout. Ou alors faire des uniform block, mais je ne sais pas si ça existe en WebGL.

---------- Post added at 20h28 ---------- Previous post was at 20h10 ----------

Sinon je n'ai pas bien compris ce que tu essaies de faire Nacodaco ?

Tu veux afficher juste ton image sur un carré, et la faire roter / translater / zoomée ? Auquel cas un polygone à 4 points te suffit non ?
Ou bien est-ce que tu veux une grille de polygones chacun mappé sur une portion de la texture ? Ou encore répéter la texture plusieurs fois ?

**moimadmax** · 16/01/2013, 20h36

Envoyé par Frypolar

J’envisage aussi de peut-être le partager donc Access n’est pas forcément le plus adapté à cause de son coût.

Pour Access tu peux le distribuer avec un runtime gratuit. Après il faut regarder plus en détail les licences mais bon.
Sinon j'ai personnellement jamais été à l'aise avec access. Alors que j'ai déjà bien roulé ma bosse en comprenant ce que je fais dans d'autre langage (sans pour autant aller à la maitrise).
Si tu veux une appli il y a plusieurs option dans le schéma Appli + BDD pour les Datas, l'avantage de Séparer les Datas du moteur, c'est que tu peux facilement mettre à jour les données sans avoir à recompiler. Alors qu'access met tout dans le même fichier. Pour ton projet ça doit être gérable si les autres utilisateurs ne doivent pas changer la base. Mais au taf un malin à eu l'idée de faire une suite* en access. Du coup quand il y a un bug, il faut faire le tour de tout les users pour le corriger.

Vive l'informatique.

En gros comme autres option tu as avec un logiciel:
- C# (ou VB.net) + Base access. (je pense que ça sera le plus facile)
- C# + SQLite. (pas beaucoup plus dur voir plus facile si l'API SQLite est plus simple qu'Access)
- Tu peux te lacher après avec une appli en C++, en Windev

, ou en Java qui peut être une bonne solution si tu veux une appli multiplateforme. Et je dirais même plus en Java + SQLite, ainsi tu pourras faire un portage Android facilement.

Après y'a l'appli Web sinon:
- Php + Mysql
- Php + Sqlite

*Tu y écris tout ce qu'il s'est passé en ta présence pour tes collègues qui suivent.

**Nacodaco** · 16/01/2013, 20h40

Si en plus vous êtes pas d'accord

En fait pour le moment je veux juste afficher un carré avec la texture, mais à terme il doit être possible d'ajouter des effets (effet de vague par exemple), d'où l'utilité de la "grille".

Donc je veux afficher une grille de polygones chacun mappé sur une potion de texture.

**deathdigger** · 16/01/2013, 20h44

Si tu veux du transportable, c'est Access, SQL CE ou SQLite. Je privilégierai (à mon goût personnel à moi que j'aime pour moi-même) une SQL CE pour pouvoir très facilement taper dedans en .Net (via notamment les entity data models).
Sinon tu peux aussi la faire en Hyperfile si t'aimes les photos de nana à moitié à poil

**rOut** · 16/01/2013, 21h17

Envoyé par Nacodaco

Si en plus vous êtes pas d'accord

En fait pour le moment je veux juste afficher un carré avec la texture, mais à terme il doit être possible d'ajouter des effets (effet de vague par exemple), d'où l'utilité de la "grille".

Donc je veux afficher une grille de polygones chacun mappé sur une potion de texture.

Ok.

Pour commencer, si tu ne sais absolument pas comment OpenGL marche, je ne saurais que te conseiller de lire un peu... Mais bon, c'est pas grave.

OpenGL (et WebGL, c'est pareil) fonctionne comme un pipeline qui va transformer les différentes informations en entrée (que tu lui donnes) en primitives graphiques 3D (des lignes, des polygones), puis ces primitives en pixels affichés sur le support que tu lui as alloué (la fenêtre pour une appli desktop, ton canvas pour ton WebGL).

Pour ce faire, il va y avoir plusieurs étapes intermédiaires, qui sont plus ou moins bien illustrées sur cette image:

La première étape (vertex shader) lui permet de transformer les données brutes que tu lui as fourni, en vertices représentant des points dans l'espace, et possédant un certain nombre d'attributs (la coordonnée du point dans l'espace, mais aussi la coordonnée de texture, ou n'importe quoi d'autre défini dans ton vertex shader).
La seconde étape (triangle assembly, qui devrait s'apeller primitive assembly) consiste à grouper ces vertices pour former les primitives que tu lui as demandé de dessiner (c'est ton TRIANGLE_LIST de gl.drawArrays, qui pourrait être autre chose si tu veux grouper les vertices autrement).
La troisième étape (rasterization) consiste à calculer l'interpolation des attributs des vertices composant une primitive sur chaque pixel ou elle va éventuellement être projetée.
La quatrième étape (fragment shader) consiste, pour chaque fragment de primitive correspondant à un pixel potentielement touché, à calculer la couleur à appliquer au pixel à partir de la valeur interpolée des attributs de vertice.
La dernière étape (testing and blending) consiste, à partir de tous les fragments calculés, de rejeter ceux qui ne sont pas visibles (masqués par d'autres fragments plus proches sur l'axe Z) ou ne modifiant pas un pixel, et de mélanger la couleur des autres suivant les règles de mélange (blending via la composante alpha, etc).

L'étape #1 est programmable, via un vertex shader que tu as dans ton .html. En entrée, il prend des attribute et il passe des varying en sortie (qui seront interpolés) pour les étapes suivantes. gl_Position est un varying spécial qui indique la position du vertex en sortie du vertex shader et qui sera utilisé par GL pour déterminer la position de la primitive à l'écran ensuite.
Chaque variable marquée "attribute" dans le vertex shader, va nécessiter que tu la binde à un buffer avec vertexAttribPointer pour que GL aille y lire la valeur de l'attribut pour chaque vertex. Le nombre de composant de chaque attribute est important et sera le nombre que tu vas passer au paramètre size de vertexAttribPointer.
Par exemple un vec2 a deux composantes, et il faudra donc faire vertexAttribPointer(<location de l'attribute>, 2, ...) avec un buffer contenant 2 * <nb vertex> valeurs. Pour chaque vertex à dessiner, GL lira les deux valeurs de l'index correspondant dans ton buffer et éxecutera le vertex shader pour déterminer les varying en sortie, pour créer des primitives.

Voilà pour un premier temps, dis moi si tu as compris quelque chose (auquel cas c'est pas la peine d'aller plus loin, j'essaierai déjà de clarifier cette introduction)

Edit: Virage du paragraphe sur Viewport qui n'est plus clair dans ma tête.

**GrandFather** · 16/01/2013, 21h21

Envoyé par SetaSensei

Le client me soutient qu'avec ce content-type, il ne peut que me faire un PUT d'un fichier xml.

C'est du pur bullshit, les deux types MIME sont interchangeables. A mon humble avis, le type t'envoie un PUT parce qu'il ne sait/veut/peut pas t'envoyer un autre type de requête, mais ça n'a rien à voir avec les entêtes HTTP.

Selon le formalisme REST (on ne peut pas vraiment parler de norme), PUT correspond à l'ajout d'une nouvelle entité via le web service, POST à la mise à jour (update) ou au changement d'état d'une entité existante. Le blocage provenant de sa boîte noire vient peut-être de ce que tu lui demandes de faire un POST sur une entité non spécifiée.

**Nacodaco** · 16/01/2013, 21h47

Envoyé par rOut

Ok.

Pour commencer, si tu ne sais absolument pas comment OpenGL marche, je ne saurais que te conseiller de lire un peu... Mais bon, c'est pas grave.

OpenGL (et WebGL, c'est pareil) fonctionne comme un pipeline qui va transformer les différentes informations en entrée (que tu lui donnes) en primitives graphiques 3D (des lignes, des polygones), puis ces primitives en pixels affichés sur le support que tu lui as alloué (la fenêtre pour une appli desktop, ton canvas pour ton WebGL).

Pour ce faire, il va y avoir plusieurs étapes intermédiaires, qui sont plus ou moins bien illustrées sur cette image:

http://duriansoftware.com/joe/media/gl1-pipeline-01.png

La première étape (vertex shader) lui permet de transformer les données brutes que tu lui as fourni, en vertices représentant des points dans l'espace, et possédant un certain nombre d'attributs (la coordonnée du point dans l'espace, mais aussi la coordonnée de texture, ou n'importe quoi d'autre défini dans ton vertex shader).
La seconde étape (triangle assembly, qui devrait s'apeller primitive assembly) consiste à grouper ces vertices pour former les primitives que tu lui as demandé de dessiner (c'est ton TRIANGLE_LIST de gl.drawArrays, qui pourrait être autre chose si tu veux grouper les vertices autrement).
La troisième étape (rasterization) consiste à calculer l'interpolation des attributs des vertices composant une primitive sur chaque pixel ou elle va éventuellement être projetée.
La quatrième étape (fragment shader) consiste, pour chaque fragment de primitive correspondant à un pixel potentielement touché, à calculer la couleur à appliquer au pixel à partir de la valeur interpolée des attributs de vertice.
La dernière étape (testing and blending) consiste, à partir de tous les fragments calculés, de rejeter ceux qui ne sont pas visibles (masqués par d'autres fragments plus proches sur l'axe Z) ou ne modifiant pas un pixel, et de mélanger la couleur des autres suivant les règles de mélange (blending via la composante alpha, etc).

L'étape #1 est programmable, via un vertex shader que tu as dans ton .html. En entrée, il prend des attribute et il passe des varying en sortie (qui seront interpolés) pour les étapes suivantes. gl_Position est un varying spécial qui indique la position du vertex en sortie du vertex shader et qui sera utilisé par GL pour déterminer la position de la primitive à l'écran ensuite.
Chaque variable marquée "attribute" dans le vertex shader, va nécessiter que tu la binde à un buffer avec vertexAttribPointer pour que GL aille y lire la valeur de l'attribut pour chaque vertex. Le nombre de composant de chaque attribute est important et sera le nombre que tu vas passer au paramètre size de vertexAttribPointer.
Par exemple un vec2 a deux composantes, et il faudra donc faire vertexAttribPointer(<location de l'attribute>, 2, ...) avec un buffer contenant 2 * <nb vertex> valeurs. Pour chaque vertex à dessiner, GL lira les deux valeurs de l'index correspondant dans ton buffer et éxecutera le vertex shader pour déterminer les varying en sortie, pour créer des primitives.

Voilà pour un premier temps, dis moi si tu as compris quelque chose (auquel cas c'est pas la peine d'aller plus loin, j'essaierai déjà de clarifier cette introduction)

Edit: Virage du paragraphe sur Viewport qui n'est plus clair dans ma tête.

Lire un peu, je comprend, le truc c'est que je n'ai tout simplement pas vraiment le temps :/ (je parle de délai pour faire le truc où je galère)

Pour l'instant je crois comprendre ! Très sympa de prendre un peu de temps pour faire ça, ça m'est vraiment utile !

---------- Post added at 21h47 ---------- Previous post was at 21h37 ----------

EDIT : J'ai mis à jour le dossier partagé, c'était vraiment n'imp le dernier changement.

**rOut** · 16/01/2013, 22h13

Pour les coordonnées, après avoir relu un peu différents trucs, je reviens sur ce que j'ai dit et je pense que Tomaka avait juste.

Le vertex shader (étape #1, et autres étapes dont je n'ai pas parlé qui peuvent avoir lieu avant la rasterisation) doit fournir en sortie un varying gl_Position en "clip coordinate", c'est à dire des coordonnées dans l'espace de la boite de l'image ci-dessous:

Une coordonnée (0,0,0) correspond au centre de la boite, et [-1; 1] aux plans des extrémités sur chaque axe.

Ensuite au moment de la rasterisation, GL va projeter cette boite sur le Viewport configuré qui a la même taille par défaut que la zone de dessin, et va élimiter tout ce qui est en dehors de la boite.

En gros, dans ton cas, pour faire très simple tu peux générer dans un buffer tout un tas de vertex dont les coordonnées spatiales seront entre [-1,-1] et [1,1] et dans ton vertex shader, mapper directement l'attribut coordinate vers gl_Position. Les matrices sont là pour effectuer des transformations supplémentaires si tu veux gérer un angle de vue, etc...

Pour le texturing, chaque vertex doit avoir un attribut supplémentaire de coordonnée de texture, dont la valeur varie entre [0,0] et [1,1] qui correspondra aux deux étrémités de ta texture. Puisque tu fais une grilles de vertex, il faut que tu calcules les valeurs intermédiaires suivant le nombre de vertex et que tu remplisses ton buffer avec.

Pour gérer les deux attributs, soit tu fais deux buffers différents que tu bindes l'un après l'autre, soit tu multiplexes les données dans un seul, et tu utilises le paramètre "stride" et "offset" de VertexAttribPointer(index, size, type, stride, offset) pour indiquer à GL de lire les données en sautant stride octet entre chaque attribut (groupe de size valeurs) lu et en partant de offset octets après le début du buffer pour l'un des attributs.

---------- Post added at 22h13 ---------- Previous post was at 22h09 ----------

Sinon je suis tombé sur ça pour jouer avec WebGL, qui a l'air sympa:
http://webglplayground.net

**Nacodaco** · 16/01/2013, 22h14

Envoyé par rOut

Pour le texturing, chaque vertex doit avoir un attribut supplémentaire de coordonnée de texture, dont la valeur varie entre [0,0] et [1,1] qui correspondra aux deux étrémités de ta texture. Puisque tu fais une grilles de vertex, il faut que tu calcules les valeurs intermédiaires suivant le nombre de vertex et que tu remplisses ton buffer avec.

Pour gérer les deux attributs, soit tu fais deux buffers différents que tu bindes l'un après l'autre

Ben c'est bien ce que je fais dans la dernière version ? (Il n'y a plus de texture qui s'affiche, c'est tout blanc :/)

---------- Post added at 22h14 ---------- Previous post was at 22h14 ----------

Envoyé par rOut

Sinon je suis tombé sur ça pour jouer avec WebGL, qui a l'air sympa:
http://webglplayground.net

Je regarde ça

Merci

**rOut** · 16/01/2013, 22h32

Le truc je pense c'est que tu mélanges les techniques.

Tu as plusieurs possibilités pour afficher ta grille de vertex:
- Soit tu fournis les coordonnées pour afficher 4 vertex et les grouper en 2 triangles, et tu demandes à GL de l'afficher à un endroit, puis tu décales un peu, et tu affiches de nouveau, etc...
- Soit tu fournis les coordonnées pour afficher TOUS les triangles de ta grille d'un coup, et tu n'affiches qu'une seule fois.

Dans ton code, la partie qui remplis les buffer faire des boucles pour rien.

Code:

    squareVertexTextureCoordBuffer = gl.createBuffer();
    gl.bindBuffer(gl.ARRAY_BUFFER, squareVertexTextureCoordBuffer);
    for (var i = 0; i < GRID_SIZE; ++i) {
        for (var j = 0; j < GRID_SIZE; ++j) {
            var vertices = [
                (i+1)/GRID_SIZE, (j+1)/GRID_SIZE,
                i/GRID_SIZE, (j+1)/GRID_SIZE,
                (i+1)/GRID_SIZE, j/GRID_SIZE,
                i/GRID_SIZE, j/GRID_SIZE
            ];
            gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);
        }
    }
    squareVertexTextureCoordBuffer.itemSize = 2;
    squareVertexTextureCoordBuffer.numItems = 4;

A chaque itération, au lieu d'ajouter un nouveau carré dans le buffer, tu remplaces le contenu du buffer par les coordonnées du nouveau carré.
- Soit tu indiques à GL comment dessiner un petit carré (de taille 1/GRID_SIZE) et tu mets juste ça dans le buffer, pas besoin de faire de boucle là, elle sera dans la partie d'affichage.
- Soit tu modifies le code pour créer un tableau JS contenant les coordonnées de tous les vertex, avec la boucle, et tu remplis le buffer à la fin avec tout le tableau. L'affichage se fera ensuite en une seule passe.

Pareil pour les coordonnées de texture d'ailleurs.

Aussi pour les coordonnées de texture, j'ai vu que ton attribute (aTextureCoord) est défini comme vec2 mais tu lui fournis 3 coordonnées de texture pour chaque vertex, ce qui est incorrect je pense.

**Nacodaco** · 16/01/2013, 23h08

Pour la aTextureCoord je comprend pas trop, c'est bien un vec2 non ? (Si je met vec3 ça plante à l'initialisation des shaders en plus)

Je préfère la méthode avec la boucle dans drawScene, ça correspond plus à ce que je faisais avant.

Donc maintenant j'ai ça :

Code:

 /* Initialisation texture */
    squareVertexTextureCoordBuffer = gl.createBuffer();
    gl.bindBuffer(gl.ARRAY_BUFFER, squareVertexTextureCoordBuffer);

    var vertices = [
        1/GRID_SIZE, 1/GRID_SIZE,
        0.0, 1/GRID_SIZE,
        1/GRID_SIZE, 0.0,
        0.0, 0.0
    ];
    
    gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);
    squareVertexTextureCoordBuffer.itemSize = 2;
    squareVertexTextureCoordBuffer.numItems = 4;

    /* Initialisation position */
    squareVertexPositionBuffer = gl.createBuffer();
    gl.bindBuffer(gl.ARRAY_BUFFER, squareVertexPositionBuffer);

    var vertices = [
         .5,  .5,  0.0,
        -.5,  .5,  0.0,
         .5, -.5,  0.0,
        -.5, -.5,  0.0
    ];
    gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);

    squareVertexPositionBuffer.itemSize = 3;
    squareVertexPositionBuffer.numItems = 4;

Et pour le drawScene() :

Code:

/* Backup matrix */
    var tmp = mat4.create();
    mat4.set(mvMatrix, tmp);


    for (var i = -(GRID_SIZE/2); i < GRID_SIZE/2; ++i) {
        for (var j = -(GRID_SIZE/2); j < GRID_SIZE/2; ++j) {
            /* Préparation position */
    gl.bindBuffer(gl.ARRAY_BUFFER, squareVertexPositionBuffer);
    gl.vertexAttribPointer(shaderProgram.vertexPositionAttribute, squareVertexPositionBuffer.itemSize, gl.FLOAT, false, 0, 0);
    
    /* Préparation pos texture */
    gl.bindBuffer(gl.ARRAY_BUFFER, squareVertexTextureCoordBuffer);
    gl.vertexAttribPointer(shaderProgram.textureCoordAttribute, squareVertexTextureCoordBuffer.itemSize, gl.FLOAT, false, 0, 0);
    
            mat4.translate(mvMatrix, [i, j, 0.0]);
            setMatrixUniforms();
            gl.drawArrays(gl.TRIANGLE_STRIP, 0, squareVertexPositionBuffer.numItems);
            mat4.set(tmp, mvMatrix);
       }
    }

Mon problème c'est que la texture ne s'affiche pas (c'est tout blanc).

Si dans le vertices du textureCoordBuffer je met les coordonnées avec 0.0 et 1.0 comme avant, j'ai bien la texture qui s'affiche pour chaque carré, mais comme ça rien :/

**rOut** · 16/01/2013, 23h11

Heu, ben oui, comme je le disais, les coordonnées de texture sont entre 0 et 1, tandis que les coordonnées de vertex doivent être entre -1 et 1 en sortie du vertex shader dans gl_Position.

C'est pas la variable qui doit être en vec2, c'est quand tu remplis le buffer utilisé pour cet attribut. Ton buffer est rempli avec des triplets et tu fais itemSize = 3 pour le textureCoordBuffer alors que l'attribut correspondant est un vec2. Ca marche quand même mais c'est idiot.

---------- Post added at 23h11 ---------- Previous post was at 23h11 ----------

Et sinon qu'est ce que tu veux faire de plus ?

**Nacodaco** · 16/01/2013, 23h38

Envoyé par rOut

Heu, ben oui, comme je le disais, les coordonnées de texture sont entre 0 et 1, tandis que les coordonnées de vertex doivent être entre -1 et 1 en sortie du vertex shader dans gl_Position.

Ben si je fais ça :

Code:

1/GRID_SIZE, 1/GRID_SIZE,
0.0, 1/GRID_SIZE,
1/GRID_SIZE, 0.0,
0.0, 0.0

Les coordonnées sont bien entre 0 et 1 ?

Envoyé par rOut

C'est pas la variable qui doit être en vec2, c'est quand tu remplis le buffer utilisé pour cet attribut. Ton buffer est rempli avec des triplets et tu fais itemSize = 3 pour le textureCoordBuffer alors que l'attribut correspondant est un vec2. Ca marche quand même mais c'est idiot.[COLOR="Silver"]

Je dois faire ça ?

Code:

 var vertices = [
         .5,  .5,
        -.5,  .5,
         .5, -.5,
        -.5, -.5
    ];
    gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);

    squareVertexPositionBuffer.itemSize = 2;
    squareVertexPositionBuffer.numItems = 4;

Sinon ce que je veux faire, c'est réussir à afficher une texture fonctionnel quoi

Voila la situation :

En fait pour le moment, l'impression que j'ai, c'est que la texture s'affiche bien dans chaque carré, sauf que mon vertices de textureCoord pourri ne sélectionne que le haut-gauche de la texture (qui est blanc) et le fout partout.

Du coup j'ai ajouté ce code la dans drawscene après le vertexAttribPointer de textureCoord pour mettre à jour le vertices :

Code:

var vertices = [
      
        (i+1)/GRID_SIZE, (j+1)/GRID_SIZE,
        i/GRID_SIZE, (j+1)/GRID_SIZE,
        (i+1)/GRID_SIZE, j/GRID_SIZE,
        i/GRID_SIZE, j/GRID_SIZE

    ];
    gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);

Et j'ai enfin une texture potable qui s'affiche

Plus de petit carré partout !

Bon c'est loin d'être parfait :
- La texture n'est pas centrée (Bon en fait non j'ai réussi à la centrer

)
- Ca rame complétement dès que je fous une rotation

---------- Post added at 23h38 ---------- Previous post was at 23h31 ----------

-------------
EDIT : Il y a un truc que je comprend pas.

Pourquoi ces lignes :

Code:

 /* Préparation position */
    gl.bindBuffer(gl.ARRAY_BUFFER, squareVertexPositionBuffer);
    gl.vertexAttribPointer(shaderProgram.vertexPositionAttribute, squareVertexPositionBuffer.itemSize, gl.FLOAT, false, 0, 0);

Ca ne change rien qu'elles soient dans ou en dehors de la boucle de drawScene()

En fait je ne comprend pas que ça fonctionne en dehors de la boucle, ça ne devrait dessiner qu'une seul petite carré puisque le vertices n'en n'indique qu'un seul ?

**rOut** · 16/01/2013, 23h51

Parce que tu fais une boucle de dessin et que ta boucle met à jour des matrices de translation pour décaler ton petit carré à chaque appel de drawArray (c'est la multiplication dans le vertex shader par les deux matrices qui donne la valeur de gl_Position).
Les coordonnées des vertices dans le buffer indiquent comment dessiner un petit carré, mais les matrices décalent ce pattern par une certaine quantité.

Tu pourrais te passer de ça et ne faire qu'un seul drawArray si ton buffer de positions contenait les positions de chaque petit carré.

**Nacodaco** · 17/01/2013, 00h09

Ah bien sûr, question idiote

Merci beaucoup.

Sinon y a quelque chose que je fais très mal pour que ça rame autant ?

Remplir les vertices avec toutes les coordonnées puis faire un unique vertexAttribArray c'est plus optimisé ?

---------- Post added at 00h09 ---------- Previous post was at 00h01 ----------

EDIT : Et en fait j'arrive pas à piger comment on peut remplir le vertices du VertexPositionBuffer de façon à ne pas avoir de boucle dans drawScene()

Actuellement je n'ai qu'un carré dans le buffer, et je fait à chaque fois une translation puis le dessin.

Sans boucle et sans translation, comment reproduire le décalage de chaque carré ? (puisque dans le vertice je suis seuillé entre -1 et 1). Doit y avoir un truc que j'ai pas compris

**rOut** · 17/01/2013, 00h13

Et bien tu remplis ton buffer avec des coordonnées entre -1 et 1, avec des itérations de 1/GRID_SIZE ou quelque chose du genre.

**Nacodaco** · 17/01/2013, 01h47

Envoyé par rOut

Et bien tu remplis ton buffer avec des coordonnées entre -1 et 1, avec des itérations de 1/GRID_SIZE ou quelque chose du genre.

Je vais essayer ça alors. Je cherche encore comment étaler les valeurs entre -1 & 1 mais ça doit pas être sorcier !

---------- Post added at 01h47 ---------- Previous post was at 01h37 ----------

EDIT : Bon en fait ça donne rien

On verra ça demain !

Encore merci pour ton énorme aide !

**SetaSensei** · 17/01/2013, 09h48

Envoyé par GrandFather

C'est du pur bullshit, les deux types MIME sont interchangeables. A mon humble avis, le type t'envoie un PUT parce qu'il ne sait/veut/peut pas t'envoyer un autre type de requête, mais ça n'a rien à voir avec les entêtes HTTP.

Selon le formalisme REST (on ne peut pas vraiment parler de norme), PUT correspond à l'ajout d'une nouvelle entité via le web service, POST à la mise à jour (update) ou au changement d'état d'une entité existante. Le blocage provenant de sa boîte noire vient peut-être de ce que tu lui demandes de faire un POST sur une entité non spécifiée.

Ah ben voilà, merci.
J'avais déjà vu ce thread sur stackoverflow mais je n'étais pas sûr de mon coup.

Pour le formalisme PUT / POST, au moment où le client m'envoie ses données, il ne sait pas si ce qu'il m'envoie déclenchera un edit ou un create. D'ailleurs il m'envoie une liste d'entités (c'est de la synchro de données), du coup il est impossible de différencier create, delete et update.

Merci bien, je n'étais donc pas fou.

**Tomaka17** · 17/01/2013, 09h57

Envoyé par Frypolar

Bijour,

Bon c’est pas purement de la programmation mais je tente ma chance ici quand même. Je commence à collecter quelques infos pour le craft dans un jeu que j’aimerais pouvoir manipuler. J’étais parti au début sous Excel avec un bête tableau à menu déroulant mais vu l’ampleur du bousin il va falloir passer à quelque chose de plus adapté pour traiter tout ça. Je connais un petit peu Access, et j’ai une licence via MSDNAA, mais c’est aussi l’occasion d’essayer autre chose d’où ma question : y-a-t’il une solution à privilégier pour gérer ça ? Quelque chose qui soit particulièrement apprécié/utilisé en ce moment histoire que ça puisse éventuellement me servir plus tard. J’envisage aussi de peut-être le partager donc Access n’est pas forcément le plus adapté à cause de son coût.

Pour ce qui est de la base de données c’est pas violent. À vue de nez je vais avoir 6 tables différentes avec moins de 10 attributs chacune. Si la liste la plus longue contient 1000 éléments c’est vraiment le bout du monde. Ça correspondrait aux objets craftables et je suis quasiment sûr qu’il y en a un paquet qui sont identiques. Le but est aussi d’arriver à trouver comment ça fonctionne si j’ai assez de données pour pouvoir simuler un craft au lieu de stocker toutes les variantes obtenues à la main. Je n’ai quasiment fait que du C/C++ mais je peux tout à fait me mettre à un nouveau langage.

Merci.

Envoyé par deathdigger

Si tu veux du transportable, c'est Access, SQL CE ou SQLite. Je privilégierai (à mon goût personnel à moi que j'aime pour moi-même) une SQL CE pour pouvoir très facilement taper dedans en .Net (via notamment les entity data models).
Sinon tu peux aussi la faire en Hyperfile si t'aimes les photos de nana à moitié à poil

N'écoute pas ce mec qui n'utilise que des technologies Microsoft qui ne sont interopérables qu'entre technologies Microsoft

Je te dirais de partir sur SQLite, qui est en fait juste une libraire qui permet d'ouvrir des fichiers de base de données, après il faut encore un logiciel tiers qui ouvre concrètement le fichier et utilise la lib.
Le seul problème c'est que pour rentrer des données, les GUI existants sont assez merdiques.

Par contre de l'autre côté t'as Postgresql qui est un gros logiciel bien bourrin et donc plus chiant à installer, mais qui a un GUI nommé pgAdmin qui est bien plus sympa.

Dans les deux cas, les données sont facilement exportables vers un autre format, donc tu seras jamais bloqué là dessus.

**deathdigger** · 17/01/2013, 10h38

Envoyé par Tomaka17

N'écoute pas ce mec qui n'utilise que des technologies Microsoft qui ne sont interopérables qu'entre technologies Microsoft

Et attends, c'est même pas sûr que ce soit compatible entre produits microsoft

:
J'ai mis en place un serveur Sharepoint 2013. Je peux modifier les docs et tout, tout marche nickel. Afin de pouvoir modifier les pages plus aisément, j'installe Sharepoint Designer 2013.
Et là ça ne marche plus :
http://social.technet.microsoft.com/...9-05d828eecbb3
En fait, Office n'est pas compatible avec Sharepoint si tu installes la version 2013 des deux.

C'est beau

**Tomaka17** · 17/01/2013, 11h00

Envoyé par SetaSensei

Pour le formalisme PUT / POST, au moment où le client m'envoie ses données, il ne sait pas si ce qu'il m'envoie déclenchera un edit ou un create. D'ailleurs il m'envoie une liste d'entités (c'est de la synchro de données), du coup il est impossible de différencier create, delete et update.

Si le client dit dans le XML si c'est une création, modification, etc. c'est que c'est pas du REST.
En REST, t'es censé indiquer ce que tu veux faire avec la méthode (GET/POST/PUT/DELETE), ce que tu veux lire/modifier/créer/supprimer avec l'URL, et les données à insérer directement dans le contenu.

Par exemple si tu veux changer la photo de l'utilisateur n°5, tu fais un PUT vers "/users/5/photo" avec un content-type:image/png et le contenu de l'image directement dans la requête (sans XML ni quoi que ce soit comme fioriture).

Ton service ça a l'air d'être un hybride bizarre entre SOAP et REST.

---------- Post added at 11h00 ---------- Previous post was at 10h52 ----------

D'ailleurs c'est sympa à lire ça : http://www.w3.org/TR/webarch/

**Frypolar** · 17/01/2013, 19h28

Merci pour ces réponses !

Je pense partir sur du SQLite. Pour les données c’est pas trop grave si je peux pas les rentrer via une GUI. De toute façon, si ça marche je pense demander de l’aide à d’autres joueurs pour collecter des données donc il faudra que je fasse un bout de code pour passer les fichiers à la moulinette et extraire les données. Ce que je trouve appréciable dans Access c’est de pouvoir très facilement créer une interface graphique pour traiter les données, là je sais pas comment ça va se passer. Par contre je sais toujours pas si je pars sur du Java ou du PHP. Le deuxième semble avoir SQLite intégré en natif, ce sera peut-être moins prise de tête.

Je ne sais absolument pas où je mets les pieds, ça va être folklo

Vous avez quelques sites en réserve pour servir de guide ?

**Tomaka17** · 17/01/2013, 19h36

Tiens ce serait pas mal que dans le prochain standard C++, on ait une certaine forme d'overloading de fonctions pour certaines constantes.

Par exemple, ce serait pas mal si on pouvait remplacer ça :

Code:

void rotatation(Image&, double angle);
void quartDeTour(Image&);
void quartDeTourInverse(Image&);
...

Par :

Code:

void rotation(Image&, double angleDegrees);
void rotation(Image&, std::integral_constant<double,90>);
void rotation(Image&, std::integral_constant<double,-90>);
void rotation(Image&, std::integral_constant<double,360>) { /* rien à faire */ }

---------- Post added at 19h36 ---------- Previous post was at 19h30 ----------

Envoyé par Frypolar

Merci pour ces réponses !

Je pense partir sur du SQLite. Pour les données c’est pas trop grave si je peux pas les rentrer via une GUI. De toute façon, si ça marche je pense demander de l’aide à d’autres joueurs pour collecter des données donc il faudra que je fasse un bout de code pour passer les fichiers à la moulinette et extraire les données. Ce que je trouve appréciable dans Access c’est de pouvoir très facilement créer une interface graphique pour traiter les données, là je sais pas comment ça va se passer. Par contre je sais toujours pas si je pars sur du Java ou du PHP. Le deuxième semble avoir SQLite intégré en natif, ce sera peut-être moins prise de tête.

Je ne sais absolument pas où je mets les pieds, ça va être folklo

Vous avez quelques sites en réserve pour servir de guide ?

Si t'as jamais utilisé de base de données, tu peux chercher des cours sur le SQL de manière générale.
SQLite ne supporte pas toutes (euphémisme) les features du SQL, mais les bases sont les mêmes.

Discussion: Le topic de la programmation, string, chaînes, cuir et compagnie

Outils de la discussion

Règles de messages