[Index Software] Jeux vidéo (développement)

[Bubu]

Modération (Tugdual) : Création du sujet par division depuis ici.


Savez vous pourquoi les sprites (personnages) déconnent dans toutes les consoles des années 80?
Ils ne sont pas affichés correctement, quand il y en a trop. Ils clignotent ou ne sont pas affichés en entier. La loose.
C'est valable pour la NES, la Gameboy, la Master System, etc ....
C'est que dans le hardware, il y a dans ces consoles la gestion de l'affichage de sprites, censé alléger la gestion de sprites dans les CPU.
Sauf que cela ne marche pas, et ouais ma grosse.
Le seul jeu que j'ai en tête qui n'utilise pas le gestionnaire de sprites, c'est Mario 2 sur GameBoy. Par contre ça pouvait ramer un peu.
Mais au moins, on ne se retrouvait pas dans une bouillie de personnages mal affichés.
Mario3 sur GB, jeu merveilleux au demeurant, est mal programmé. Les personnages scintillent sauf Wario. Ils utilisent des gros sprites (pas en 8x8), et ça clignote de partout.

Les consoles comme la super nintendo ou la mega drive, n'avaient déjà plus ce problème.

[Bubu]

Sans vouloir en rajouter sur ce problème majeure d'affichage de sprites, de personnages. Car c'était évitable.
Une scan-line c'est une ligne horizontale de pixels. Et bien on ne pouvait superposer qu'un certain nombre de sprites dessus. Au delà, clignotements ou sprites à moitié vides.
Et c'est inévitable.
La puissance des CPU des consoles concernées permettaient de contourner la limitation.
On se retrouve avec tous les personnages correctement affichés, mais c'est plus couteux. Voire ça rame un peu.
Pour les curieux, testez le niveau où il n'y a que des mushrooms dans Mario2. Vous verrez que tous les ennemis sont affichés à la perfection. Mais ça rame !!!

[Bubu]

Un paradoxe : c'est beaucoup plus difficile de gérer les sprites en noir et blanc (niveaux de gris) qu'en couleur.
Sur la GB, il y a 4 niveaux de gris. Blanc, gris clair, gris foncé et noir.
Sur la TI92, aussi ça existe, mais il y a une librairie (ou plutôt bibliothèque), qui peut en gérer 7.
Pour se faire, on superpose très rapidement 2 claques (3 pour 7 niveaux de gris) sur l'écran. Au delà de la persistance rétinienne.

Pour rester sur 4 niveaux de gris, en fait on gère 2 calques, 2 écrans, qui se superposent à toute vitesse.
Seulement l'un des deux reste persistant 2 fois plus longtemps que l'autre. Celui qui fait le gris foncé.

Et chaque pixel de chaque calque est codé sur un bit. Normal.
0 0 : blanc
0 1 : gris clair
1 0 : gris foncé
1 1 : noir.

Pour revenir au début, pourquoi c'est plus difficile en niveaux de gris.
Parce qu'un octet, 8 bits, code pour 8 pixels sur chacun des calques. Alors qu'en couleur, 1 octet code un seul pixel (même en 8 bits, grâce à la palette)
Un écran monochrome est un immense tableau. Sur chaque ligne, un octet code 8 pixels.
Donc pour afficher des sprites sur un écran monochrome, il faut user de décalages (ror, rol), gérer le clipping (quand un sprite est en partie en dehors de l'écran), la symétrie (car un sprite peut être dans un sens ou dans un autre).
Je trouve que c'est très difficile.

C'est pour cela qu'ils ont essayé de simplifier la tâche aux developpeurs en créant un gestionnaire de sprites dans ces consoles dites 8 bits. Mais c'est grandement insuffisant.
C'est pourquoi certains developpeurs ont choisi de s'en passer, quitte à réinventer la roue et faire eux-même le code, le software, pour les afficher correctement.

On en est plus là, mais l'appellation de ces consoles dites 8 bits ou 16 bits etc est du pur marketing.
Si on veut être vilain, la Gameboy est une console 2 bits. Et la GameGear une console 8 bits. Alors qu'elles ont la même architecture grosso-modo.
Ces appellations ne veulent rien dire du tout, car elles ont toutes des processeurs 8 bits (Z80 ou similaires). Mais je ne parle pas de la Super Nintendo et de la Mega Drive.

Heureusement, ces considérations ne laissent pas tout le monde de marbre, des développeurs créent des émulateurs de ces consoles. Et merci à eux !
Certains sont des applets Java, directement jouables sur la page.

[Tugdual]

J'ai des souvenirs encore plus anciens, concernant le Commodore 64 et ses 8 sprites !

Quand les sprites étaient cantonnés à des bandes horizontales de l'écran, on pouvait provoquer des interruptions matérielles sur le balayage d'une ligne particulière de l'écran, pour switcher le contexte des sprites sur un nouveau jeu de 8 sprites...

Souvenirs, souvenirs...

[Bubu]

J'ai des souvenirs encore plus anciens, concernant le Commodore 64 et ses 8 sprites !

Quand les sprites étaient cantonnés à des bandes horizontales de l'écran, on pouvait provoquer des interruptions matérielles sur le balayage d'une ligne particulière de l'écran, pour switcher le contexte des sprites sur un nouveau jeu de 8 sprites...

Souvenirs, souvenirs...

Quand j'étais tout petit, vers 7 ans, mon père en avait un. Attention, avec un lecteur de cassettes pour charger les programmes !
Une demi-heure de chargement, qui foirait une fois sur deux, pour jouer à Mission Impossible.
Je passe pour un vieillard en racontant ça.

Il a existé, Mission Impossible, sur Apple IIc aussi, sans la voix digitalisée quand on tombait. Ahhhhhh ! Mais c'était des floppy disks donc les chargements ne prenaient que quelques minutes.

[Tugdual]

Le Commodore 64 pouvait aussi avoir un lecteur de disquette, c'était plus confortable.

[ブノワ]

J'ai eu aussi un lecteur de cassette, je me demande ce qui se passerait si j'essayais de relire les données (faudrait que l'ordi accepte de booter pour ça, aussi).

Sinon, en fait, les lecteurs de bande sont encore très utilisés dans l'industrie, ça m'avait surpris la première fois que j'avais vu un admin faire une archive comme ça.
La technologie est bien sûr autrement plus efficace (et complexe) que ces bidules des années 80, en particulier il y a une tête de lecture qui vérifie systématiquement les écritures. D'après wikipedia [en] 80% des stockages de l'industrie se font encore sur bande, parce que le prix au GO est toujours moins cher (et qu'une bande, ça n'a aucun risque d'être infecté ou détérioré par un court-circuit, vu qu'elle est bien rangée dans une armoire loin des courants magnétiques).

Le lien en V.F..

[Bubu]

De toute manière de nos jours, tous les jeux sont développés en C++.
Que ce soit pour PC, Mac, ou consoles.
Seule exception, Minecraft développé en Java, mais il rame pour un affichage minable en plus.

[ブノワ]

Est ce qu il y a des alternatives au C++ pour les API des bibliotheques 3D? Meme en 2D c est une horreur a faire avec python et plein d autres langages.

Mais de toute facon tout cela est tellement intégré dans les moteurs type Unity ou Epic que ca reste verrouillé en C like.

[Bubu]

Est ce qu il y a des alternatives au C++ pour les API des bibliotheques 3D? Meme en 2D c est une horreur a faire avec python et plein d autres langages.

Mais de toute facon tout cela est tellement intégré dans les moteurs type Unity ou Epic que ca reste verrouillé en C like.

Mes connaissances commencent à être rouillées, mais jusqu'à Direct3D11, les Apis Microsoft étaient en C. Donc utilisables dans tout projet en C++ (et donc même en C)
Cependant, des portages ont été fait grâce au native code. Mais à la base elles sont en C.
XNA utilisait le C#.
Pareil pour OpenGl, les librairies sont en C. Portées en Java pour Android et PC, même si elles sont disponibles telles quelles en utilisant le NDK, qui permet de coder en C++ pour Android.

Mais comme tu le dis, maintenant il y a des moteurs de jeu accessibles comme Unity, où les scripts sont programmés soit en JavaScript, soit en C#. (qui est un clone de Java)

Les shaders quant a eux sont programmés en GLSL(Microsoft), et HLSL(OpenGl), et ce sont des langages très proches, très concis basés sur la syntaxe C. (Avec des types en plus notamment, comme les vecteurs et les matrices).

[EDIT], il faudrait sans doute décaler les 3 derniers messages, dans Software : Jeux Vidéos. Désolé de demander du boulot aux modos.

[Lilas]

[EDIT], il faudrait sans doute décaler les 3 derniers messages, dans Software : Jeux Vidéos. Désolé de demander du boulot aux modos.

Voilà qui est fait.

[Bubu]

Est ce qu il y a des alternatives au C++ pour les API des bibliotheques 3D? Meme en 2D c est une horreur a faire avec python et plein d autres langages.

C'est une horreur aussi dans les langages "C like". Ce n'est pas plus simple.
La programmation de jeu en général est très difficile. Que ce soit en 2 ou 3D.
Pour la 3D, il faut maitriser les transformations matricielles, ce que l'on apprend normalement en première année d'études scientifiques.
Et au delà, les coordonnées homogènes. A haut niveau si j'ose dire, les vecteurs ont 4 composantes. La 4ème (qui divise les 3 autres) sert pour les projections
Et l'architecture des GPUs (pour coder correctement les shaders), et des CPUs.
Et c'est très calculatoire. (Savoir si un objet est dans le champ de vue, savoir si un portail est visible. Calculer l'itinéraire d'une AI, et j'en passe et des meilleures.
L'affichage des personnages est complexe aussi, si on veut qu'il nous suive du regard quand on est proche de lui ... La liste est longue)

[Bubu]

Comme vous le savez surement, les CPUs et les GPUs sont radicalement différents.
Les CPUs sont plutôt flexibles au niveau de la gestion des tâches, car leurs coeurs sont indépendants.
C'est comme si on avait plusieurs processeurs de disponible.(D'ailleurs les OS de PC ne distinguent même pas la différence. Pour eux, un processeur à 2 cœurs, c'est 2 processeurs).

Les GPUs quant à eux, ont des milliers de coeurs aujourd'hui. Mais très rigides, ils exécutent le même programme, appelé shader.

Les CPUs utilisent le paradigme SISD (Single Instruction, Single Data). Ils exécutent une instruction (un calcul), pour une donnée.
Les GPUs utilisent le paradigme SIMD (Single Instruction, Multiple Data). Le gestionnaire envoie le programme à tous les cœurs. Il n'y a qu'un seul programme pour tous les cœurs.
Sur un GPU, un seul programme est exécuté par des milliers de coeurs. C'est parce qu'un écran contient une immensité de pixels, et qu'ils suivent tous le même programme.

Ce qui est intéressant, et là ou je voulais en venir, c'est que les GPUs sont très sensibles à la synchronicité des tâches. Il faut, quitte à faire des calculs inutiles, veiller à la synchronicité des tâches, sinon ça fout le bazar, et on se retrouve avec une performance catastrophique, divisée par mille si au pire il n'y a qu'un coeur actif.
L'ennemi des GPUs, c'est le fameux if....then...else. Chaque coeur de GPU a sa propre pile, mais pour les tests cités, cela peut engendrer un embouteillage, chaque cœur attendant un autre.
Le shader est inutilisable. Parce qu'il est mal conçu.
Dans les programmes de shaders, dès qu'on voit un if (sauf si c'est sur une constante), ça donne de l'excéma.

Par exemple pour les ombrages.
On pourrait être tenté de dire : si le pixel est dans l'ombre, juste afficher la luminosité ambiante, sinon, l'afficher avec l'éclairage dont il est soumis.
En fait non, il vaut mieux paramétrer l'éclairage (0 si ombre, 1 si éclairé) dans la même équation. Donc même pour un pixel dans l'ombre, on calcul l'éclairage quand même sans le prendre en compte.

[ブノワ]

Je n'en ai pas fait beaucoup mais j'ai bien aimé la programmation sur GPU (avec les kits Nvidia, il faut pas exagérer quand même).

Certes, c'est très contraignant en terme de 'definition' des tâches, en prenant en compte l'architecture de la carte, les "groupes" de coeurs, et le temps nécessaire à synchroniser les sorties, mais c'est vraiment bien je trouve.

J'avais trouvé ça bien pour faire tourner des algorithmes massivement multitâches, plutôt simple il est vrai.

Par contre, j'ai très peu touché aux trucs plus populaires, tenseurs et co très utilisé en IA.

[Bubu]

Par contre, j'ai très peu touché aux trucs plus populaires, tenseurs et co très utilisé en IA.

Tu parles du framework CUDA sans doute, mais il n'est pas (ou peu) utilisé pour les jeux. (Sauf pour les projets graphiques de ray-tracing, qui ne sont pas des jeux, plus des démos).
La carte graphique, le GPU, est entièrement consacré à l'affichage.
Les algos d'IA sont gérés par les CPUs.

En plus CUDA est une propriété de NVidia, il y a aussi son concurrent libre OpenCl.
Cependant ils ne sont pas équivalents, CUDA gère depuis peu l'appel récursif de fonctions, alors qu' OpenCl pas encore.

Mais ils se ressemblent beaucoup, ce sont des petits programmes basés sur le C, mais qui ont de part le support d'exécution une puissance phénoménale.

Les GPUs NVidia ont des coeurs spécialisés pour CUDA, que l'on ne retrouve pas chez les concurrents.

Enfin bref, vu que l'on parle de jeu, CUDA ou OpenCl sont anecdotiques, les GPUs étant réservés à l'affichage. Les CPUs réservés au reste.