[Index Software] Coin des développeurs :]

[Bubu]

Il n'y a pas eu de suite.
Texas Instruments sont revenus à leurs modèles de bases.

Plus de clavier, plus de possibilité de vraiment programmer.

Je vais me faire allumer.
Mais cette calcu la (TI92) avait un processeur vertueux, le processeur du Mac Classic. Le Motorola 68000. Appelé le 68k par les intimes.
Et il faisait des merveilles !
Le langage qu'a crée Texas Instrument permet de faire du calcul formel. En utilisant ce processeur.
Amusant quand on sait que ce processeur ne sait que manipuler les nombres entiers et naturels.

[Bubu]

Mais comment on fait pour gérer des valeurs réelles avec ce genre de processeurs ? En assembleur.
Toujours en parlant de jeux, car c'est parfaitement implémentable sinon. Mais je ne sais pas trop comment. (Ça ne m'intéresse pas)
Pour le sinus :
On code des tables.
Mais sur des nombres entiers. On multiplie les valeurs par 256, ou 65536 (respectivement une table 8 bits ou 16 bits) Mais cela peut aller plus loin.
De nos jours, c'est désuet car les processeurs ont tous une FPU (floating processing unit). Qui permet le calcul avec flottants.

L'astuce est de calculer toutes les multiplications d'abord, et de diviser ensuite. Sous forme d'entiers.

C'est comme ça que dans Mario Bros sur la NES ils codaient les rotations des boules de feu, et ce n'est qu'un exemple.

Au niveau des valeurs entières, on multiplie tout, on divise seulement à la fin. Il faut juste faire gaffe que les valeurs multipliées ne dépassent pas la capacité de la variable.

[2N3055]

https://fr.wikipedia.org/wiki/Motorola_68881

(à l'époque, j'étais plutôt sur les 8086 => https://fr.wikipedia.org/wiki/Intel_8087)

[lepton]

Le Motorola 68000. Appelé le 68k par les intimes.
Et il faisait des merveilles !

Et il fait toujours des merveilles !
Si tu vas à Paris et si tu prends la ligne 14, le pilotage automatique des trains (SAET pour les intimes) est assuré par de vénérables 68020...

[Bubu]

Oh les sauvages !
Je parle du 68k, pas de ses successeurs !
Et encore moins des x86. Dès le début il y avait des coprocesseurs arithmétiques sur la carte mère.
Mais ils n'étaient pas encore intégrés au processeur, c'était deux chipsets différents.

Dans les années 90, le nouveau processeur Intel calculait mal les divisions flottantes. Vous êtes au courant ? (Le résulta était faux après quelques valeurs après la virgule) Ça a fait un tollé.

[Tugdual]

Dans les années 90, le nouveau processeur Intel calculait mal les divisions flottantes. Vous êtes au courant ? (Le résulta était faux après quelques valeurs après la virgule) Ça a fait un tollé.

À priori, c'est à partir de là qu'Intel a commencé à utiliser des techniques formelles pour développer ses puces (Gérard Berry en parle dans ses cours au Collège de France)...

[Starrk]

Le VHDL je trouvait ça intéressant et assez intuitif, c'était juste dommage que les professeurs ne nous montraient pas d'exemples concrets et à jour de son utilisation. C'était un des soucis que je trouvait à la plupart des profs, ils étaient tellement déconnectés de la réalité et en retard sur l'évolution des techniques de développement ainsi que leur mise en pratique.

J'ai toujours rêvé tomber sur un prof suffisamment passionné pour nous raconter les cours, nous expliquer l'histoire du dev depuis Alan Turing, nous montrer du Fortran ou du Lisp (qui est pour beaucoup d’anciens le langage par excellence), expliquer les choix qui ont été faits, pourquoi tel ou tel langage a vu le jour ...etc

Au final tout ce dont j'ai eu droit à l'université c'est des tutos en travaux pratiques des plus basiques sans réel but, des cours magistraux sans profondeurs...

Bref je trouve ça juste incroyable qu'en 1946 il n'existait qu'un seul développeur et aujourd’hui 73 ans plus tard seulement plusieurs dizaines de millions.

Les développeurs sont les rois du monde même les pure mathématiques commencent à voir l'utilité des outils, j'ai lu un document sur Lean c'est plus que sérieux

[Oxxi_]

Je sais que ce post date d'il y a longtemps mais c'est la première fois que je post ici alors je vais répondre aux questions ^^

- Êtes vous plutôt gros dev pro qui programme beaucoup ? Plutôt un joueur qui fait quelques petit programmes par-ci par-là ? Ou plutôt un débutant qui à déjà programmer mais encore bien débutant ? Ou alors avez vous juste vu ce que c'était un programme et au pire toucher à un code une ou deux fois ?

Je suis plutôt du genre a faire des programmes "par-ci par là" mais même si certains peuvent me prendre beaucoup de temps je lâche pas le projet

- Pour ceux qui programme : depuis quand ? Quel langage connaissez vous (C/C++, Java, JS, PHP, html, .Net etc...) ?

Ça doit faire depuis 2 ans que j'ai commencé à apprendre le python, je suis resté longtemps sur ce langage puisque j'étais sur un projet de jeu avec Pygame qui m'a pris un an, puis en janvier je me suis mis à apprendre le C++ et le Java

- Que préférez vous faire (Web, Applications, Jeux...) ? Quel langages préférez vous, ou quel type ?

Les jeux, puisque c'est ce pour quoi j'ai le plus d'imagination.
J'aime bien le C++ même si je l'utilise moins en ce moment vu que je code une application sur Android (donc Java)

[user6375]

Eh eh j'avais pas vu qu'il y avait une série de question pour se présenter.

Quelques question ? Allez si je suis sûr que vous adorer mes questions hihihi
- Êtes vous plutôt gros dev pro qui programme beaucoup ? Plutôt un joueur qui fait quelques petit programmes par-ci par-là ? Ou plutôt un débutant qui à déjà programmer mais encore bien débutant ? Ou alors avez vous juste vu ce que c'était un programme et au pire toucher à un code une ou deux fois ?

Programmeur 100% geek, pas pro mais ayant une formation pro. Je suis informaticien de gestion, de formation et de profession. Ma formation m'a initié au développement mais j'ai pas de formation de développeur en tant que tel. Je suis un IT qui touche un peu à tout.

- Pour ceux qui programme : depuis quand ? Quel langage connaissez vous (C/C++, Java, JS, PHP, html, .Net etc...) ?

Depuis longtemps ... au tournant des années 2000 durant ma formation, et j'ai jamais lâché.
J'ai commencé en VB6. Je suis depuis resté sur plateforme Windows (.Net).
Aujourd'hui je code surtout en C#, et quant je dois faire du web, en ASP.NET et PHP
Et bien sûr le SQL pour les bases de données.

- Que préférez vous faire (Web, Applications, Jeux...) ? Quel langages préférez vous, ou quel type ?

Applicatif Windows.
En terme de langage, je préfère le VB (pas de prise de tête avec les ; ). Par contre j'utilise préférentiellement le C# (plus complet).

- Avez vous, pour les plus avertis, déjà créé de "gros" programmes tel que des jeux, des sites, application...

Oui au niveau pro j'ai créé notre outil de ticketing, qui s'articule autour d'une DB. Et qu'on utilisent tous les jours au bureau. J'ai également développé nos logiciel serveur et client de DNS dynamique en SSL, pour nos clients qui ont besoin d'un accès externe mais qui n'ont pas d'IP fixe. Ca nous évite de devoir payer un DynDNS !!!

Au niveau perso, j'ai fait quelques projets "importants".
Un moteur 3D en XNA de A à Z, que j'ai fini par abandonné a cause des limitations de XNA au niveau des collisions. Et actuellement je code un MMO en Unity3D et C#. Si je parle de MMO c'est parce que je code à la fois un client Unity3D, mais également 2 applicatif coté serveur : l'applicatif de gestion de l'infra (serveur de login, de DB, serveur maître) , ainsi qu'un hybride Unit3D/serveur de jeu persistant (ça c'est chaud !!!). La partie infra réseau fonctionne bien (du login initiale jusqu’à l'entrée en jeu). Actuellement je bloque sur des problèmes de skybox 3D interactive, au niveau des échelles entre la zone de jeu à l’échelle 1, les différents niveaux de skybox et le basculement de l'affichage des objets selon qu'ils sont trop loin (skybox) ou proche (échelle 1). Mais j'ai de la peine a m'y remettre (question de motivation)

Et j'ai mon portail web en ASP.NET.

[Tugdual]

Oups :

• Un bogue dans un code Python pourrait avoir causé des erreurs de calcul dans plus d'une centaine d'études scientifiques publiées depuis 2014...

[Bubu]

Eh eh j'avais pas vu qu'il y avait une série de question pour se présenter.

Quelques question ? Allez si je suis sûr que vous adorer mes questions hihihi
- Êtes vous plutôt gros dev pro qui programme beaucoup ? Plutôt un joueur qui fait quelques petit programmes par-ci par-là ? Ou plutôt un débutant qui à déjà programmer mais encore bien débutant ? Ou alors avez vous juste vu ce que c'était un programme et au pire toucher à un code une ou deux fois ?

Programmeur 100% geek, pas pro mais ayant une formation pro. Je suis informaticien de gestion, de formation et de profession. Ma formation m'a initié au développement mais j'ai pas de formation de développeur en tant que tel. Je suis un IT qui touche un peu à tout.

- Pour ceux qui programme : depuis quand ? Quel langage connaissez vous (C/C++, Java, JS, PHP, html, .Net etc...) ?

Depuis longtemps ... au tournant des années 2000 durant ma formation, et j'ai jamais lâché.
J'ai commencé en VB6. Je suis depuis resté sur plateforme Windows (.Net).
Aujourd'hui je code surtout en C#, et quant je dois faire du web, en ASP.NET et PHP
Et bien sûr le SQL pour les bases de données.

- Que préférez vous faire (Web, Applications, Jeux...) ? Quel langages préférez vous, ou quel type ?

Applicatif Windows.
En terme de langage, je préfère le VB (pas de prise de tête avec les ; ). Par contre j'utilise préférentiellement le C# (plus complet).

- Avez vous, pour les plus avertis, déjà créé de "gros" programmes tel que des jeux, des sites, application...

Oui au niveau pro j'ai créé notre outil de ticketing, qui s'articule autour d'une DB. Et qu'on utilisent tous les jours au bureau. J'ai également développé nos logiciel serveur et client de DNS dynamique en SSL, pour nos clients qui ont besoin d'un accès externe mais qui n'ont pas d'IP fixe. Ca nous évite de devoir payer un DynDNS !!!

Au niveau perso, j'ai fait quelques projets "importants".
Un moteur 3D en XNA de A à Z, que j'ai fini par abandonné a cause des limitations de XNA au niveau des collisions. Et actuellement je code un MMO en Unity3D et C#. Si je parle de MMO c'est parce que je code à la fois un client Unity3D, mais également 2 applicatif coté serveur : l'applicatif de gestion de l'infra (serveur de login, de DB, serveur maître) , ainsi qu'un hybride Unit3D/serveur de jeu persistant (ça c'est chaud !!!). La partie infra réseau fonctionne bien (du login initiale jusqu’à l'entrée en jeu). Actuellement je bloque sur des problèmes de skybox 3D interactive, au niveau des échelles entre la zone de jeu à l’échelle 1, les différents niveaux de skybox et le basculement de l'affichage des objets selon qu'ils sont trop loin (skybox) ou proche (échelle 1). Mais j'ai de la peine a m'y remettre (question de motivation)

Et j'ai mon portail web en ASP.NET.

Beau parcours.

Mon parcours pour répondre en gros à la présentation du sujet.

Mon premier ordi était l'Apple IIc. Dans les années 90. Obsolète. Mon père me l'avait donné.
J'étais au début du collège.
C'était encore en floppy-disks, grandes disquettes souples. Il y en avait une qui était un tuto interactif sur le BASIC (pas le VB, visual basic, hein, le BASIC), qui contenait plusieurs applications.
Space Invaders, une appli qui jouait une sonate pour piano à 2 voix de Mozart, un jeux de gestion d'une buvette. J'étais fous.
Et j'avais plein d'autres jeux, sur d'autres disquettes.
Au collège, j'ai programmé pleins de programmes sans importance en BASIC.
Les seuls qui valent le coup d'être cités, c'était un solveur de mots-mêlés et un tetris.
Le problème qui me frustrait, c'était que c'était trop lent. Ça ramait comme on dit.
(L'Apple IIc avait un 6502a cadencé à 1Mhz). Mais oh malheur, mon père avait un bouquin sur l'assembleur du 6502.
Son adressage mémoire est sur 16 bits (et encore c'est pas le processeur mais la MMU), mais il ne peut cependant gérer que des mots de 8 bits. C'est un processeur 8 bits.
Il fallait tout calculer avec des entiers qui varient de 0 à 255, ou de -127 à 128.
En plus, quand je parle d'assembleur, c'est presque un anachronisme, car il fallait coder en langage machine.
J'avais entrepris de faire un éditeur d'assembleur, en BASIC.
Il fallait transformer l'instruction (mnémonique en assembleur) en son code hexadécimal. Et inverser les octets des adresses 16 bits.
Mais vu que je restais cloitré dans ma chambre toute la journée, mes parents ont décidé de me le confisquer.
Je n'ai jamais fini ce programme.
Pour passer du BASIC (langage très haut niveau, non typé explicitement) au langage machine sur l'Apple IIc, il y avait 3 commandes BASIC : PEEK, POKE et CALL. Les deux premières servent à lire ou écrire en mémoire, avec un entier décimal en paramètre pour l'adresse concernée, et CALL servait à lancer le programme en langage machine, en précisant l'adresse de début encore en décimal. (Nombres entiers en base 10)

Adolescent et jusqu'à maintenant, je me suis mis au 68k(Ah là, la génuflexion est de rigueur ) , puis au C, puis au C++ (et le HLSL), puis à Java (et le GLSL) , puis au C# (balbutiements, je débute, mais c'est le même langage à quelques mots clés près, et le même paradigme que le Java)
Un moteur de jeu en C++ qui m'a pris plusieurs années. Les ombres m'ont bouffé la vie. Ma seule fierté était de gérer les ombres engendrées par les surfaces transparentes. (Des ombres colorées quoi, pas en noir et blanc). Et avec des contours lissés et non pixélisés. Oh malheur. . Avec mon binôme depuis plus de 20 ans, ce petit moteur nous avait permis de faire un prototype de jeu de cours ala Mario Kart. Mais on a abandonné ce projet. Car un seul développeur (mon binôme est concepteur, il connait rien en codage mais est une tête en modélisation 3D), ne je peux pas suivre tout seul l'évolution des technologies et les implémenter à temps.

On a publié un jeu 2D sur le playStore, un jeu de réflexion, qui est en 2D. J'ai dû créer une API 2D utilisant GLSL (langage de shader d'OpenGL), pour les graphismes, avec l'avantage de pouvoir créer ses propres shaders (Niveaux de gris, colorisation d'un sprite en niveau de gris, normal mapping … Et ouais ma grosse, bien que le sprite soit toujours parallèle à l'écran, cela permet de calculer la lumière d'une lampe et la brillance selon une normal map et l'inclinaison du sprite, en 2D. Bien entendu, il faut appliquer des rotations et des translations sur les sprites qui utilisent le normal mapping, pour que l'on voit les changements de luminosité et de brillance dessus car sinon cela ne servirait à rien. Autant coder ces informations direct sur l'image si c'est une illumination statique. Comme en 3D, il faut 2 texture pour faire du normal mapping, même en 2D. Une color map, qui ne contient que les couleurs sans informations d'illuminations. Couleurs brutes. Et une normal map, qui code l'inclination de chaque pixel par rapport à sa surface. En 2D c'est pas compliqué. En 3D c'est autre chose, car chaque facette a son inclinaison propre. (Son propre repère, que l'on appelle TBN, chaque vertex contient un repère 3D utilisé pour le normal mapping, et le displacement mapping (qui ne crée pas de géométrie contrairement à ce qui est dit sur certains tutos. C'est autant une approximation de volume que le normal mapping, mais qui feint la hauteur grâce à une height map en plus). Je ne vais pas plus loin).

Je me suis mis à Unity très récemment, et j'ai déjà des déboires, notamment avec le "character controller". Dans une scène, j'ai mis un personnage et quelques plateformes animées.
Notamment, une qui va de haut en bas. Le personnage tombe sous le terrain quand je le mets sous cette plateforme quand elle descend et l'écrase…
Une autre plateforme qui tourne. Quand le personnage va dessus, il ne tourne pas avec...

On en est là.

[Bubu]

Il y a plusieurs types de skybox.
La plus simple est juste un cube mappé.
Par contre il faut utiliser un shader spécial pour que sa profondeur soit à 1. Le maximum.
Quand tu rends la position du point (vertex) dans le vertex shader, il faut utiliser position.xyww. Comme ça la division faite en coordonnées homogènes t'assure que ton point sera toujours à la profondeur maximale.

Code : Tout sélectionner

#ifndef SKYBOX_FX
#define SKYBOX_FX

//--------------------------------------------------------------------------------------
// Global variable
//--------------------------------------------------------------------------------------
Texture2D g_DiffuseMap;

//--------------------------------------------------------------------------------------
// Constant buffers
//--------------------------------------------------------------------------------------
cbuffer everySubset
{
	row_major matrix	g_mTransform;
};

//--------------------------------------------------------------------------------------
// CM sampler
//--------------------------------------------------------------------------------------
SamplerState samLinear
{
    Filter=MIN_MAG_MIP_LINEAR;
    AddressU=Wrap;
    AddressV=Wrap;
};

//--------------------------------------------------------------------------------------
// Vertex shader input structures
//--------------------------------------------------------------------------------------
#include "VS_INPUT.fx"

//--------------------------------------------------------------------------------------
// Pixel shader input structure
//--------------------------------------------------------------------------------------
struct PS_INPUT_SKYBOX
{
    float4 vPosProj : SV_POSITION;
    float2 vTexUV   : TEXCOORD0;
};

//--------------------------------------------------------------------------------------
// Pixel shader output structure
//--------------------------------------------------------------------------------------
struct PS_OUTPUT_SKYBOX
{
	float4 color		: COLOR0;
	float4 normal		: COLOR1;
};

//--------------------------------------------------------------------------------------
// Vertex shader
//--------------------------------------------------------------------------------------

PS_INPUT_SKYBOX SkyboxVS(VS_INPUT input)
{
    PS_INPUT_SKYBOX output;
    
    output.vPosProj=mul(float4(input.vPosition,0),g_mTransform).xyww;
    output.vTexUV=input.vUV.xy;

    return output;
}

//--------------------------------------------------------------------------------------
// Pixel shader
//--------------------------------------------------------------------------------------

PS_OUTPUT_SKYBOX SkyboxPS(PS_INPUT_SKYBOX input) : SV_Target
{
	PS_OUTPUT_SKYBOX output;
	output.color=g_DiffuseMap.Sample(samLinear,input.vTexUV);
	output.normal=float4(1.0f,1.0f,0.0f,0.0f);
	
	return output;
}

//--------------------------------------------------------------------------------------
// Technique
//--------------------------------------------------------------------------------------

technique10 Skybox
{
    pass P0
    {
        SetVertexShader(CompileShader(vs_4_0,SkyboxVS()));
        SetGeometryShader(NULL);
        SetPixelShader(CompileShader(ps_4_0,SkyboxPS()));
    }
}

float4 main() : SV_Position
{
	return 0;
}

#endif

La skybox n'a pas vraiment de dimensions. Après le shading est ultra basique, car on a juste à la placer et prendre la couleur de la texture.
C'est sans doute l'objet le plus simple à rendre. La subtilité est juste de calculer sa position de telle façon que chaque point soit à la profondeur maximale. Dans le cube unitaire après la projection cette profondeur est à 1f (Toute la scène est dans un cube de -1 à 1 en x et y, et de 0 à 1 selon z qui est elle stockée dans le z-buffer)., donc après la division par la 4ème composante du point exprimé en coordonnées homogènes. Cette division est faite automatiquement par le GPU. Espace projectif. Le point input.position.xyww devient (x/w, y/w, 1) après la division pour convertir le point en coordonnées homogènes en coordonnées cartésiennes. La conversion se fait en divisant toutes les coordonnées par la dernière composante homogène, w.
Pour passer des coordonnées homogènes aux coordonnées cartésiennes :
(x, y z, w) (homogènes, 4 composantes) = (x/w, y/w, z/w) (cartésiennes, 3 composantes).


Après je pinaille. Mais si on est sûr de rendre la skybox à chaque frame, on a pas besoin de flusher le buffer graphique.

[EDIT]
Toujours sur les skybox, il faut donner au GPU position.xyww au lieu de position.xyzw. (En rapport avec les coordonnées homogènes).
Et manipuler la position comme si c'était un vecteur. (0 en coordonnée homogène et non 1 comme habituellement).
Comme ça la position ne prend pas en compte les translations. Juste les rotations.

Code : Tout sélectionner

output.vPosProj=mul(float4(input.vPosition,0),g_mTransform).xyww;

Tout est là.
Par contre je ne sais pas ce que j'ai voulu faire avec une normale en sortie du pixel shader …. Codée en dur en plus. Nawak.
A ignorer ! Car on a juste à sampler la texture de la skybox. (première ligne du pixel shader)

Je ne suis pas sûr d'avoir bien cerné ton problème de taille de skybox, car justement elles n'en ont pas (plus précisément elles ont une taille infinie invariante aux translations). Leur éventuelles mises à l'échelle (scaling) seraient sans effet.
Après il faut des textures très précises, car le ciel c'est important. (J'espère y monter un jour Car ça me dirait bien de bouffer une moussaka avec Dieu).
J'utilise des demi-cubes mappés, surtout pour limiter l'usage mémoire. Et parce que ça suffit s'il y a un sol.
Bien entendu, c'est une explication des skyboxes les plus basiques, car on peut gérer en plus un soleil, des nuages dynamiques à grands coups de voxels, etc.

[EDIT2]
Par contre il faut désactiver en lecture le z-buffer lors du rendu de la skybox s'il on veut pas de z-fighting: Le zbuffer est flushé avec la valeur 1, or la skybox est affichée à cette profondeur. Cela créerait des conflits. L'idéal est de configurer le z-buffer pour le rendu de la sky-box en écriture simple, comme ça le rendu de la skybox remplira le z-buffer avec cette valeur, 1 (ou très proche).
Et donc il n'est pas utile de flusher le z-buffer non plus en début de frame.
Par contre il faut rendre la sky-box dès le début, avant tout.

[Bubu]

Puisqu' il s'agit pour l'instant de 3D ?
Connaissez-vous l'algorithme appelé "deferred rendering" ?

C'est pas compliqué, mais il est implémentable que sur les GPUs qui gèrent plusieurs cibles de rendu à la fois. (MRT : mutliples renders targets)

La première passe sert à rendre la profondeur de la scène. (z pass)
Et la deuxième, selon la première, sert à rendre à la fois la diffuse map et la normal map. Chacune rendue en parallèle.
On obtient donc 3 textures : une qui code la profondeur, une autre les couleurs, et une autre, les normales.

La troisième passe combine les 3 précédentes textures pour afficher la scène finale.

L'avantage principal est l'utilisation du z-pass : grâce à cela, on n'envoie les shaders que vers les pixels visibles.
Car à quoi ça sert de coloriser une surface qui finalement est recouverte et donc non visible ?

Je suis sûr que cet algorithme est le seul utilisé de nos jours.

Imaginez un topographe, mais qui ne parcourt que la scène. (pas 360°, juste la scène). Et bien il va vous donner la profondeur de chacun des points (pixels) de la scène.
Et bien c'est à cela que sert le z-buffer, il donne la profondeur de chacun des points de la scène à rendre.
Il donnera la profondeur minimale de chaque point de la scène à rendre.
Le z-buffer à mangé des épinards étant petit. Pléthore.
C'est la première phase. Peu couteuse.

Ensuite viennent les gros mammouths (vous savez, ceux qui vivent de nos jours dans la savane).
C'est presque de la 2D.
On reparcourt la scène mais avec les objets qui la compose, mais on rejette immédiatement tout point qui est derrière la z-map, calculée lors de la z-pass.
Et on stocke dans une texture la couleur brute (sans informations d'illuminations), et dans une autre la normale. (en bidouillant grave …)

La dernière étape du rendu consiste à calculer la couleur d'un point de la texture (plein-écran, c'est la scène), en utilisant ces informations intermédiaires. (color, normal and depth eventually).

[EDIT] c'est par contre inutilisable pour les objets transparents. Pour eux on utilise la technique classique (forward rendering). Ou plus couteux, comme le depth peeling.

Vous voyez pourquoi il n'y a que très rarement des surfaces transparentes dans les jeux. Le plus simple est de les trier par leur profondeur (ce qui est approximatif), et de les rendre de la plus profonde à la plus proche… Ça suffit souvent. Les concepteurs de niveaux (level designers) , bien au courant du problème, s'attachent à ca.

Le stockage de la normale peut être … ésotérique. La plus simple est juste de stocker chaque composante dans un flottant. Donc une texture sur 3 flottants par pixel.

Mais vu qu'on sait que les normales ont une norme de 1, on peut juste stocker les composantes x et y, et un signe (-1 ou +1). Là encore c'est plutôt simple.
J'explicite parce que c'est la technique qui est utilisée en général :
On utilise Pythagore : x² + y² + z² = 1. Avec x et y donnés. Donc on peut déduire le carré de z facilement.
z² = 1 - x² - y². Le problème c'est qu'on ne peut pas savoir le signe de z. C'est pourquoi il faut en plus de stocker x et y, stocker le signe de z.
Après il y a des types de textures gérées par les GPUs qui permettent de stocker 2 flottants et un bit (de signe).

Mais cela peut aller encore plus loin. Et devenir vraiment complexe.

[EDIT2] Vous seriez surpris de voir le nombre de textures différentes que sont capables de gérer les GPUs.
Il y a la définition UNORM. C'est sur 8 bits, et ça gère les flottant de 0 à 1. Donc l'intervalle de 0 à 1 divisé en 1/256 èmes.
Et je vous passe les formats les plus ésotériques, mais ils ont une utilité, tous autant qu'ils sont.
Une texture à ce niveau (bas), ce n'est pas une image, c'est juste un tableau 2D de valeurs.

La texture qui stocke la profondeur (souvent de manière linéaire, et non logarithmique comme le fait le z-buffer), est principalement utilisée pour calculer les ombres avec la technique du shadow-mapping.

[Tugdual]

Une éternité en informatique :

• Joyeux anniversaire à Unix !

[Bubu]

Une éternité en informatique :

• Joyeux anniversaire à Unix !

Article très intéressant.
Pour Android, je peux témoigner, c'est bien un noyau Unix qui est utilisé. Malgré les couches, etc, on a quand même de temps en temps dans la console des chemins de fichiers qui sont exprimés ala Unix.
Mais c'est très encapsulé. En Java on ne pourrait presque pas deviner que c'est Unix dessous.

C'est même plus que magique, c'est presque septentrional. Excusez du peu.
Sous Android, en Java, il y a l'objet R (comme Ressources). Généré automatiquement. ( Et ouais ma grosse, ça t'en bouche un coin non ?)
On a pas besoin de citer les ressources par leur chemin de fichier, juste par leurs ID. C'est la fête du slip. Et ouais ma grosse.
Et cela fonctionne pour tous les types de ressources. (Images, son, texte).
Assieds-toi ma grosse, mais ça gère les traductions automatiquement. Tu demandes un texte et sans rien préciser il te le fournit dans la bonne langue.

C'est septentrional. Demain j'utiliserai équatorial. (J'aime bien les mots compliqués même si je sais pas ce qu'ils veulent dire). Ouais grosse. 1 2 .