[Index Software] Coin des développeurs :]

[Tugdual]

Sur Developpez.com :

• Call for Code d'IBM : jusqu'au 28 septembre, soumettez un prototype de solution
  qui permet de mieux préparer l'humanité aux catastrophes naturelles ...

[Bubu]

En infographie 3D chez les développeurs : On distingue les peintres et les photographes.
Les peintres se fichent de savoir si le résultat graphique est photo-réaliste, ce sont des artistes.
Les photographes s'évertuent à rendre le rendu 3D aussi réaliste que possible, ce sont des scientifiques.

Après les deux se valent.
Pour des jeux comme Mario, ou Zelda, les peintres suffisent.
Dans des jeux photo-réalistes, comme Call of Duty, on a besoin de ces scientifiques.

Ceci dit, dans les deux cas la précision photo-réaliste est limitée. En plus les deux visions ne sont pas exclusives.

Pour avoir une vision vraiment scientifique et un rendu photo-réaliste avec moins d'approximations, il faut tourner une page, passer au lancer de rayons.
Mais c'est trop coûteux en performances pour être utilisé en temps réel de nos jours.
Mais cette technique, le lancer de rayons, est massivement employée pour les images de synthèse dans le cinéma.

[Tugdual]

Sur Developpez.com :

• Des chercheurs utilisent des techniques de machine learning pour identifier
  des codeurs anonymes en analysant des échantillons de code source ...

[Bubu]

J'ai trouvé le code source de Super Mario Bros. (sur NES)

smb_code.txt

C'est en assembleur (évidemment à cette époque)
Mais il y a des commentaires.

Ma première surprise est de voir que les données des niveaux sont ridicules en taille. [Ce ne sont pas des tableaux 2D qui contiennent tout, ils partitionnent et différencient le sol, le fond, etc]
Et qu'ils utilisaient des bounding boxes pour les collisions ! [Je pensais qu'ils utilisaient des masques sur les sprites. Mais il faut dire que c'est réussi. C'est très précis.]
Et que chaque ennemi a son propre code. [Quelques ennemis ont du code en commun cependant]

Ils mélangent données et programme. Après ça se comprend, il n'y a pas de système de fichier, c'est de la ROM.

C'est un fichier de plus de 16000 lignes, il m'a fallu 1h30 pour juste le parcourir. (lire les commentaires, de toute façon je ne connais pas l'assembleur du 6502)

[Tugdual]

Amusant, le 6502 est le microprocesseur sur lequel j'ai découvert,
approfondi avec enthousiasme, et pratiqué assidument l'assembleur ...



Mais à la lecture du code source, j'ai oublié bien des choses ...

[lepton]

Moi j'ai découvert l'assembleur sur le 6809. La hi-tech par rapport au 6502, quoi...

[Tugdual]

L'assembleur du 6809 était effectivement très agréable et cohérent
(quoique mal implémenté au niveau électronique et optimisation).

Il y avait bien pire que le 6502 : le 6800 était carrément rustique !

Et puis il y avait le Z80 : performant, mais "bricole" sur les bords ...

Nostalgie ...

[lepton]

(quoique mal implémenté au niveau électronique et optimisation).

Je me souviens d'avoir bien galéré pour arriver à faire tourner le timer 6840.
Ah ça ne nous rajeunit pas, tout ça...

[Bubu]

L'assembleur du 6502 a été le premier assembleur que j'ai essayé au collège avec un AppleIIc, mais j'avoue ne pas avoir réussi à faire grand chose.
Vers 20 ans, j'ai bossé sur le Motorola68000 de ma calcu (TI 92 II), le plus gros projet était un niveau de jeu de plateforme. (en 2D évidemment, en 4 niveaux de gris, comme le permet la GameBoy)
Je voulais faire un moteur équivalent à celui de Super Mario Bros. 2 sur GameBoy. (scrolling vertical et horizontal, avec les mêmes contrôles. Un bouton pour courir. Saut dépendant du temps de pression sur le deuxième bouton et de la vitesse. La croix et les boutons A et B de GameBoy). (J'avoue, la GameBoy est ma console préférée de tous les temps !!! )
(Caméra indépendante avec 2 axes de liberté, et une physique qui faisait que le personnage (un rectangle ! ) pouvait accélérer en courant, sauter plus ou moins haut)
(Il fallait passer par un ordi (bloc note ...) et envoyer le fichier compilé dans la calcu via un port série bricolé).

Il fallait aussi que la calcu ait un autre OS superposé, appelé fargo.
Mais on pouvait lancer les programmes depuis l'OS officiel comme n'importe quel programme en langage TI.

L'assembleur du 68000 est très simple (le 68000 gère les mots jusqu'à 32 bits, et c'est un processeur puissant).

[EDIT]
Pour permettre 4 niveaux de gris, on superpose très rapidement 2 écrans avec un temps d'affichage 2 fois moins grand pour un des écrans (le plus clair)...
(Sur la TI, il y avait une bibliothèque (non officielle, la TI92 est sur deux couleurs, blanc et noir) pour cela. Qui permettait aussi 8 niveaux de gris, en superposant 3 écrans selon le même principe. Mais si on a une hypersensibilité visuelle c'est désagréable, on sent que l'écran clignote très vite. Epileptiques s'abstenir. C'est pourquoi je me suis limité à 4 niveaux de gris.)
C'était un affichage 2 bits. Mais sur deux buffers (qui couvrent l'écran) distincts. Le clair et le foncé.
Clairement :
Buffer clair / Buffer foncé
1 1 = Noir
0 1 = Gris foncé
1 0 = Gris clair
0 0 = Blanc

Du coup c'est assez coûteux en mémoire. Il faut deux buffers pour un seul écran.
Et ça va de même avec les sprites. (Données).

Donc sur chacun des 2 écrans, 8 bits codent pour 8 pixels qui se suivent horizontalement.
1 bit par pixel. Sur les deux calques qui composent l'écran final.
Je vous laissent imaginer du coup la difficulté d'afficher un sprite à des coordonnées quelconques.
Il faut décaler les octets, et afficher le reste sur les octets prochains. (mnémoniques ror et rol).
Sans parler de la gestion du clipping (afficher des sprites qui sortent en partie de l'écran. Il faut afficher le restant visible, et c'est assez dûr)

Un autre problème c'est qu'il faut pouvoir faire la symétrie horizontale des sprites... (Quand un objet est dans l'autre sens)
Or aucune instruction ne le permet. (Je crois que le Z80 customisé de la GameBoy le permettait)
Donc on bidouille par une routine ... qui est très coûteuse !
(Par contre la symétrie verticale ne pose aucun problème).




Une autre subtilité, c'est que l'adressage est sur 16 bits.
Sans doc, j'ai mis du temps à comprendre.
Quand on fait un mauvais adressage, la calcu freeze avec une bannière "ADDRESS ERROR". L'horreur.
Bon à rebouter (enlever toutes les piles et les remettre) la calcu et à réinstaller fargo.
Le débogage pouvait rendre n'importe qui fou. (Une fois j'ai vraiment failli la balancer contre le mur).


Fin

Sur leurs nouveaux modèles, on peut programmer directement en Assembleur, et il y a un débogueur intégré. (TI Navigator je crois)
Mais ça ne m’intéresse plus, je suis plus sur Android et PC maintenant ....

[Bubu]

Autre sujet, je suis admiratif devant les développeurs qui arrivent à implémenter, et faire des opérations flottantes, sur des nombres réels sur de tels processeurs.
Le 6502 par exemple. même le 68000.
Ça me laisse sans voix.

(J'utilisais mon AppleIIc comme calculatrice, simplement en formulant en BASIC mes calculs, et j'avais le résultat. Je ne m'en remettrai jamais, tant c'est épique).
Je précise que ces processeurs ne gèrent que les nombres entiers.

Et le dinosaure 6502 ne gére que les données d'un octet. Calculs avec un entier de 0 à 255.... . Pourtant des développeurs ont réussi à le faire calculer avec des flottants... Chapeau !

En troisième, j'ai fait un Tetris sur ce fameux AppleIIc en BASIC. Franchement injouable. . Trop lent.
J'ai, cette même année, fait un solveur de mots mélés. Il fallait rentrer la grille de lettres, et donner la liste des mots à trouver.
Et tout seul il trouve le mot.
Mais c'est chiant ! Et très lent. C'est pourquoi je me suis intéressé à l'Assembleur. 1000x plus raopide.

Grâce à des cours de fac, j'ai fait un solveur de Sudoku.
Et un générateur de grilles.
En utilisant le back-tracking.
J'ai toujours le programme, même si ça ne sert pas à grand-chose.
Sur PC.

Je suis maintenant désœuvré, mais notre jeu pour Android me donne du fil à retordre, même si le développement est terminé. (Pour la première version ! )
Il faut enlever l’extension .txt. Ensuite double-cliquez dessus.
Les modétateurs et l'administrateur ne vont pas être contents ! Mais c'est un fichier totalement inoffensif. Promis.
Le programme génère des grilles de sudoku. Avec plusieurs niveaux de difficulté.
(En fait il gère la profondeur des arbres pour déduire le bon chiffre d'une case)
Amusez-vous, en difficulté maximale je n'ai jamais réussi !)
Il résoud sans problème AI Escargot, soit disant le Sudoku le plus difficile.
Bon courage !

[EDIT]
Pour sélectionner une case, cliquez dessus.
Vous pouvez aussi mettre des petits chiffres (des chiffres possibles) dans chaque case en appuyant sur Maj. En réappuyant, vous repassez en chiffres normaux.

[Tugdual]

Autre sujet, je suis admiratif devant les développeurs qui arrivent à implémenter, et faire des opérations flottantes, sur des nombres réels sur de tels processeurs.
Le 6502 par exemple. même le 68000.
Ça me laisse sans voix.

En fait, ce n'est pas si compliqué : un fois implémentés l'addition,
la multiplication, la puissance, tout le reste n'est que polynômes ...

Et ça, c'est pour Bubu :

• Conférence Nvidia et ray tracing ...

[Bubu]

Autre sujet, je suis admiratif devant les développeurs qui arrivent à implémenter, et faire des opérations flottantes, sur des nombres réels sur de tels processeurs.
Le 6502 par exemple. même le 68000.
Ça me laisse sans voix.

En fait, ce n'est pas si compliqué : un fois implémentés l'addition,
la multiplication, la puissance, tout le reste n'est que polynômes ...

Et ça, c'est pour Bubu :

• Conférence Nvidia et ray tracing ...

Pour les calculs avec nombres flottants, c'est implémenté comment déjà un flottant .... mantisse et exposant comme aujourd'hui sur CPU?
(Sur GPU, les nombres "normalisés entre 0.0 et 1.0 ne sont pas implémentés pareil.)

Merci pour le lien sur la génération RTX des cartes graphiques à venir.
Après il n'y a pour l'instant aucune documentation, outre le fait qu'elles seraient adaptées pour le rendu hybride (rasterization et lancer de rayons).
Les unités de calcul ont-elles de nouvelles instructions, genre intersection d'un rayon avec un triangle, une sphère, ou un parallélépipède ???
On verra prochainement (fin septembre ils seront plus ouverts si on en croit des articles du net ...)

[lepton]

Autre sujet, je suis admiratif devant les développeurs qui arrivent à implémenter, et faire des opérations flottantes, sur des nombres réels sur de tels processeurs.
Le 6502 par exemple. même le 68000.
Ça me laisse sans voix.

Le 8087 d'Intel a vraiment été une révolution au début des années 80, ça avait simplifié la vie de beaucoup de monde...

[Tugdual]

Pour les calculs avec nombres flottants, c'est implémenté comment déjà un flottant .... mantisse et exposant comme aujourd'hui sur CPU?

Oui, c'est ça.

Le 8087 d'Intel a vraiment été une révolution au début des années 80, ça avait simplifié la vie de beaucoup de monde...

Simplifié, pas trop, puisque les compilateurs de langages évolués
géraient les flottants de façon transparente pour le développeur.
Par contre, ça a accéléré les calculs à l'exécution des logiciels ...

[Bubu]

Savez-vous comment sont générées les ombres dans vos jeux favoris ?
Il y a deux techniques :
1) Shadow volumes
C'est une technique géométrique.
On se place du point de vue de la lumière, et on calcule le volume d'ombre.
Les zones qui sont dans le volume sont ombrées, les autres, non.
C'est précis, mais trop. Aucune notion de pénombre est envisageable.
(C'est simplifié).


2) Shadow map
C'est la technique utilisée partout de nos jours.
On se place au point de vue de la lumière.
Et on note la profondeur d'impact de la lumière.
Dans une texture.
Si la profondeur est au dessus, le pixel est éclairé, sinon, il ne l'est pas.
L'énorme difficulté, c'est que l'espace de la lumière est différent de l'espace de vue.
On se retrouve avec des gros pixels d'ombres dans certains cas, et c'est franchement dégueulasse.
Il y a des techniques qui tentent de remédier à ce problème.
Mais elles ont toutes des contraintes, qui fait qu'elles sont inutilisables selon certains angles.
Dans les jeux, on utilise les Cascades Shadow Maps. (CSM)
En gros on utilise plus de shadow maps, qui ont chacune leur marge de profondeur.
Mais on voit la limite souvent entre les niveaux de profondeur.

Mais si on fixe les limites de vue de la caméra, on peut utiliser la bonne technique sans problème, en ayant des ombres très précises.