La programmation en assembleur est ce qu'on appelle un langage de bas niveau, c'est-à-dire qu'il est extrêmement basique, avec un nombre assez restreint d'instructions, mais qui est donc hyper performant au niveau de l'exécution. J'espère que je vais pas dire une connerie, mais l'Assembleur, c'est le langage de programmation qui juste à un niveau au-dessus du langage binaire. Avec l'assembleur, on touche la base de la base en programmation.

Le language C est au contraire un language d'assez haut-niveau, il a une syntaxe "plus compréhensible" pour l'esprit humain, mais il reste assez basique pour être assez performant et exécuter sur plein de machines embarqués.

Et on parle de C++ parce que c'est une sorte de version super évoluée du C.

Le C et le C++ ont été et sont encore des langages assez populaire pour développer des jeux, car on peut directement attaquer la mémoire des machines, ce qui permet des optimisations de malades (mais aussi des risques de fuites mémoires et d'erreurs d'instructions bien plus grandes si c'est mal fait).

Et après, on a plein d'autres langages de programmation comme le PHP, Java, C#, Scala, Javascript etc...
_________________

Pour compléter le post de Yoshiki :
- Il me semble que le nombre d'instructions disponibles/utiles dépend largement du processeur, ça n'est pas forcément un petit nombre comparé à la liste des mots-clé en C.
- (si je ne dis pas de bêtise) Il y a une correspondance directe entre assembleur et language machine. L'assembleur est du language machine représenté sous forme de texte pour être plus lisible pour nous.
- Une des grosses différences est que contrairement au language machine, un programme C ou C++ n'est pas exécutable directement par la machine.
Un programme (compilateur) se charge de le transformer en language machine.

Aujourd'hui, hors certains systèmes embarqués, il est beaucoup plus rare d'avoir recours à l'assembleur qu'à l'époque des premières consoles car on en suffisamment sous le capot.
Les compilateurs sont devenus si efficaces qu'il est beaucoup plus rentable de les laisser générer du code machine à partir d'instruction plus "génériques" que de tout faire en assembleur soi-même.
Il y a d'autres avantages à utiliser un language plus abstrait que l'assembleur (la portabilité du code, notamment).

J'ajouterais quelques détails aux explications données, même si elles sont déjà fort complètes.

En gros, le code de bas niveau est très proche de la machine et cela permet de maîtriser de A à Z toutes les instructions qui lui seront données. Mais le risque de faire des erreurs rédhibitoires est beaucoup plus grand, alors qu'un langage de haut niveau sera généralement conçu pour les éviter automatiquement.

C'est de cette manière qu'on arrive à obtenir des démos techniques de fou sur Amiga ou Atari ST. Le moindre octet de mémoire ou d'instruction CPU est exploité à fond pour obtenir le résultat le plus impressionnant possible. Ce sont des machines à l'architecture relativement simple, ce qui permet à des développeurs de s'y consacrer sans se tuer à la tâche. Il faudrait une quantité astronomique de travail pour exploiter un PC actuel de la même manière. C'est pour ainsi dire mission impossible.

En revanche, la compatibilité de ce type de code est très faible, car il est conçu de manière à exploiter une architecture spécifique. Il faut donc tout reprendre si on veut faire un portage. C'était possible à l'époque, car les machines étaient d'une architecture simple et avaient peu de puissance brute en réserve, ce qui demande donc moins de boulot pour bien les exploiter. Sans oublier les cartouches qui avaient une quantité de mémoire très basse.

Inversement, le code de haut niveau va utiliser des routines génériques qui va être interprété pour créer du langage machine. Cela permet aux programmeurs de travailler beaucoup plus rapidement sur des machines plus puissantes. La comptabilité est également meilleure, car on peut adapter le code de manière à prendre en compte plus facilement les différents hardwares, sans pour autant tout refaire. En contrepartie, l'optimisation est beaucoup moins bonne.

Pour faire une comparaison, c'est un peu comme si on utilisait un langage universel que toutes les civilisations peuvent comprendre. Mais comme il doit être compris par tous, cela ne permet pas d'avoir autant de subtilités qu'avec une vraie langue native.

C'est d'ailleurs comme ça que fonctionnent les moteurs de jeu de type CryEngine ou autre. En tapant 2 lignes de code, tu vas demander à la machine d'en exécuter plusieurs milliers situées à des étages inférieurs. Cela permet de simplifier et de rendre certaines tâches automatiques, car ça prendrait beaucoup trop de temps de tout coder à la main. Et cela permet de faire des portages inter-machines de manière beaucoup plus simple, car le compilateur va prendre automatiquement en compte les spécificités de chaque hardware. À condition bien sûr qu'il soit programmé correctement. Et même dans ce cas, ça reste souvent approximatif, car on arrive pas toujours à bien prendre en compte la manière dont le hardware va se comporter. D'où les différences de performances constatées sur des machines de puissance brute équivalente. (La PS3 face à la 360 par exemple.)

L'inconvénient est bien sûr que le code source du moteur est verrouillé et que les programmeurs ne peuvent pas le modifier pour l'améliorer ou corriger des erreurs éventuelles. C'est pour ça qu'on retrouve souvent les mêmes bugs d'un jeu à l'autre.
(Et l'impression de déjà-joué vient aussi de là, car on retrouve également des propriétés physiques similaires d'un jeu à l'autre.)

En gros, on laisse le moteur et / ou le compilateur faire 95% du boulot pour retranscrire les instructions. Mais en contrepartie, ça sera moins bien optimisé car les commandes sont moins directes et cela génère des instructions inutiles qui vont occuper le CPU ou la carte graphique pour rien. C'est pour ça qu'un jeu navigateur en Flash mal optimisé pourra faire ramer une bête de course. D'ailleurs, les langages Web se situent à un niveau encore plus haut. Car il faut que la compatibilité soit native avec tous les navigateurs, quel que soit la configuration, même modeste. (C'est pour ça que les jeux sur navigateur ou utilisant une machine virtuelle sous JAVA sont bien moins performants que les jeux classiques.)

Après, les moteurs actuels et le haut-niveau systématique ne génèrent pas que du positif. Prenons l'exemple d'un patch correctif appliqué sur un jeu actuel :

Patch mal optimisé :



Patch bien optimisé :



Dans le premier cas, la correction est faite en surcouche du code erroné. Mais dans le second, le code d'origine est directement modifié pour rectifier l'erreur. En général, les moteurs appliqueront toujours le premier cas de figure, car ils n'ont pas une connaissance suffisante du fonctionnement de la machine.

Ce n'est qu'un exemple (foireux) parmi d'autres bien sûr.
_________________

Inconnu au bataillon le Chip 8 ? Pour les joueurs peut etre, pour les codeurs non: emuler le Chip 8, c'est le "Hello World" du monde de l'emulation. Ca me semble une premiere etape normale.

Du reste, il n'y a pas besoin de savoir coder un jeu GB pour coder un emulateur GB par exemple. Si tu as la doc (et la doc GB est trouvable), il "suffit" de simuler le fonctionnement logique du systeme, meme sans comprendre tout ce que ca fait. J'attend toujours le super concurrent a Mario ou Zelda de la part de l'equipe de ZSNES.

Et quand tu parles de savoir comment emuler le rayon d'un ecran CRT pour coder un emulateur... en theorie si tu veux un emulateur 100% exact ok. En pratique, a part dans des cas tres specifique comme la VCS (ou l'on controle effectivement le rayon), tu peux arreter l'emulation avant: a partir du moment ou tu as ta grille de pixel (que ce soit via un framebuffer ou autre), tu peux directement faire ton rendu a l'ecran.

Apres oui, emuler le Chip 8 et emuler ne serait ce qu'une NES, c'est a peu pret la meme difference entre construire une petite cabane dans un arbre et construire une vraie maison. Mais il faut bien commencer quelque part.
_________________

La difference est principalement la quantite de couche d'abstraction entre le fonctionnement de la machine et les manipulations du programmeur.

Imagine que tu veuilles dessiner une image sur un ordinateur.

Tu peux faire ton image pixel par pixel en choisissant la couleur une par une de chacun des pixels. C'est la programmation en langage machine: hyper simple, hyper facile a comprendre, mais hyper long et difficile pour obtenir quelque chose de potable.

Tu peux utiliser MS Paintbrush avec des fonctions genre "tracer une ligne", "tracer un cercle", "remplir une zone", etc. Mais tu vas en chier a faire tes degrades a la main pixel par pixel, si tu veux dessiner la Joconde en HD par exemple, ce sera moins fastidieux qu'avec la methode au dessus mais t'as pas fini. Ca c'est l'assembleur.

Tu peux aussi utiliser Photoshop/Gimp. Tu as plus d'option, des degrades automatique, tu gardes du controle mais tu as plein d'option qui vont te faciliter la vie. Tu pourras facilement obtenir ce que tu veux, mais tu auras pas exactement la Joconde au pixel pres (ou alors tu passeras plus de temps qu'avec les methodes precedante). Ca c'est le C/C++.

Sinon, tu peux toujours combiner les cliparts de Word ou Powerpoint pour representer vaguement ce que tu voulais. Ca sera hyper rapide mais le resultat sera degueulasse et jamais exactement ce que tu veux. Mais ca peut depanner. Ca, c'est les langages interpretes type Python, Perl, Php, etc.
_________________

L'assembleur c'est on va dire le langage machine de base. Le souci c'est que y'a quasi un langage assembleur par processeur, du coup c'est un peu la galère. Mais les principes reste les mêmes.
Le C est un langage bas niveau, en gros ca veut dire qu'on peu quasi tout faire avec les lib de base
http://fr.wikipedia.org/wiki/Langage_de_bas_niveau

Le C++ c'est pas une version "evoluée" du c, c'est une version améliorée. Y'a surtout des objets et plein de lib que y'a pas en C. On se fait aussi moins c**** à gérer la mémoire à la mimine, ma hantise.


J'aime bien ton image FF_Clad Pour le deguelasse je rajouterai Java dans le lot
_________________

Tu veux dire new au lieu de malloc ?
Je ne vois pas bien ce que ça simplifie, ça ne préserve pas des erreurs, fuites mémoires etc.
Si tu parles des garbage collectors, il en existe aussi pour le C.

C'est sérieux ou c'est du troll lol?
_________________

Le Chip D8 n'est en effet pas un Chip physique mais une construction théorique (un peu comme la machine de Turing) qui a eu son heure de gloire dans les années 70...

De là à penser que c'est une étape intéressante dans l'écriture d'un émulateur, je suis sceptique. Pas sûr que les apprentis en BTP passent 1 journée à Deauville à faire des châteaux de sable avec une pelle et un sceau en plastique pour apprendre les bases de la construction...

Le juste milieu serait probablement d'apprendre un vrai microprocesseur (comme le 6502) dans le contexte d'une vraie machine (Atari 8 bit, Apple II, C64, PC Engine, NES, Game Boy...).

Mais si qqun vaut absolument apprendre à émuler la machine X, autant qu'il apprenne directement ce qui concerne la machine X (sinon ça reviendrait à dire à quelqu'un qui veut apprendre l'allemand qu'il n'a qu'à commencer par l'anglais car c'est plus facile...).




Si tu veux émuler 1 seul jeu, il te suffirait de n'émuler que les interactions entre les instructions utilisées par ce jeu et le hardware.

Emuler une machine, c'est partir du principe que ton émulateur ne connait pas le programme (jeux d'instruction) qu'il doit émuler. Et là, les doc ne suffisent pas.

Prenons un exemple simple comme l'émulation de notre bon vieux 6502 (microprocesseur 8 bit 'connu' probablement le plus simple). Les opcodes sont codés sur 8 bit, il y a donc 256 instructions possibles (actions que le processeur peut faire). Or le 6502 n'utilise que 151 instructions, donc on se retrouve avec 105 codes qui ne devraient logiquement (si on suit la doc) ne rien faire... Or sur ces 105 codes, 32 ont des comportements réels (dupliquent le comportement d'autres opcodes valides). On les qualifie de 'faux' opcodes, mais qui en réalité font des choses ! Et je ne parle même pas des opcodes qui lorsqu'ils s'exécutent ont des bugs (le fameux JMP ($xxFF)). La doc ne suffit pas, car elle se place toujours du côté programmeur (utilisez la fonction X et vous obtiendrez le résultat Y), pas du côté de la machine... Pour savoir émuler un correctement un 6502, il faut une machine basée sur un 6502 et essayer TOUS les opcodes et voir ce qu'ils produisent.

La phase de Reverse Engeneering est très fastidieuse mais elle est indispensable car nombreux sont les programmeurs a utiliser des 'astuces' de programmations qui en fait n'ont jamais été décrite nulle part (overscan sur le ST...).

Ca me rappelle un projet fait avec un copain dans les années 1990 où on avait écrit un émulateur Apple IIe sur une station SUN (Solaris). On avait tout codé, le processeur, la vidéo, le son, géré le clavier, le joystick. On avait dumpé la ROM d'un vrai Apple IIe. Tout était prêt et on a démarré l'émulateur. Le fenêtre X apparaît, le mot Apple //e apparaît en haut de l'écran (comme sur un vrai Apple IIe). C'était un grand moment avec un mélange de stress et de bonheur, car on avait bossé dessus pendant des mois. Et là, un message inconnu s'affiche à l'écran : 'KEYBOARD NOT FOUND'. Avec le pote on se regarde, sceptique. J'attrape l'Apple IIe qui était à côté, j'ouvre le capot, retire le câble qui va du clavier à la carte mère et rallume la machine. Ouf, le vrai Apple IIe, si le clavier n'était pas banché, affichait le même message d'erreur ! On a tracé le code de boot présent dans la ROM et on s'est rendu compte que quand le clavier était branché, une zone en mémoire avait une valeur particulière. On a donc initialisée notre zone mémoire mappant la RAM avec cette valeur et l'émulateur a pu démarrer correctement et nous monter le prompt clignotant de interpréteur basic !



Si tu n'émules pas le rayon de l'écran je ne vois pas trop comment ton émulateur aurait une chance de démarrer. Sur les consoles Nintendo (NES et SNES), je te rappelle que la mémoire graphique ne peut être accédée que si le rayon n'est pas entrain de rafraîchir une ligne. On peut donc écrire vers la mémoire graphique que lors des HBL (retour du rayon au début d'une ligne) et lors de la VBL (retour du rayon du bas de l'écran vers le haut). Sur les machines genre Atari ST / Amiga / Apple IIgs, la position du rayon (pour faire simple le numéro de la ligne en cours de rafraîchissement) est stockée dans une zone de la mémoire. Tout programme va se baser sur cette valeur pour synchroniser son animation ou pour la pose de Raster (changement de la palettes de l'écran à certaines lignes). Si tu ne gères pas les informations du rayon, rien ne va marcher.

Tu as beau avoir un framebuffer (page graphique sur les ordi), le code dans les jeux a besoin absolument de savoir ce qui se passe d'un point de vue rafraîchissement (attendre la VBL, se positionner sur une ligne, utiliser certaines valeur du rayon comme générateur de nombres aléatoires...). Et même sur le GameBoy de base (celui avec un écran LCD qui n'a donc pas le même fonctionnement qu'un écran CRT avec son rayon), la notion de VBL et de rafraîchissement est présente.

Olivier

En c++ avancé y'a un garbage. T'es sur pour le C oO ?
Oui les malloc je deteste ça, je sais jamais si l'antislah 0 est inclus ou pas dans les chaines ou s'il faut le prévoir. Et t'as beau me le dire, je m'en rappelle jamais ^^


Les 2 mon capitaine



Z : les opcode c'est les commandes assembleurs ?
N'empeche que ca à l'air sympa ton emu apple ii, ca prouve encore une fois que je suis vraiment pas fait pour ce metier



Edit j'ai trouvé
_________________

heu pourquoi il me bouffe la moitié de mon post précédent oO ?
_________________

Non Rain, pas de garbage collector en C++, ou alors c'est vraiment dans une version très récente du standard (dans la liste des features C++11, qui date de 2011, je lis "Minimal support for garbage collection and reachability-based leak detection" mais c'est bien tout).

Oui je suis sûr pour l'existence d'extensions fournissant la fonctionnalité d'un garbage collector en C, c'est d'ailleurs ce que tu as dû utiliser en C++.
Il en existe plusieurs, apparemment sous forme de librairies.
Il existe tout un tas d'autres exemples d'extensions aux possibilités de base offerte par le language.
Par exemple :
- implémenter des types pour des besoins spécifiques (ex. pour stocker efficacement de très, très grand nombres).
- implémenter la fonctionnalité de refléxion lorsqu'elle manque
- etc.

La question c'est pourquoi un garbagge collector en C oO ? c'est chelou quand même, l'interet du C c'est de gerer soit même la mémoire, si tu veux pas le faire tu prend un autre langage.

Je savais pas que y'avait encore des gnes qui faisaient des lib C
_________________

Ｍｅｒｃｉ　pour toutes ces infos. Ca faisait des annees que je me posais la question.
_________________

The fight is everything. Always seeking the next challenge. Ceremony means nothing to him

aaaaaaaaaaaaaaaaaaaaaaaaaaah mais c'est atroce

_________________

En fait les jeux de F1 des années 90 avaient le bon son de moteurs, ils étaient juste un peu en avance
_________________

Ils sont tous méchants (sauf Sega, qui est juste con).

Bah merde, limite on dirait des Formules 1 à moteur électrique...
_________________

Catastrophe?

Perso j'ai beaucoup de mal aussi avec le son des nouveaux moteurs, mais s'il n'y a que tous ces changements techniques pour apporter à nouveau du spectacle, je prends...
_________________

Je ne sais pas si c'est du second degré, parce qu'en effet la f1 cette année c'est des moteurs hybride.

Et c'est vrai que niveau son ça fait pas rêver mais au niveau ingénierie a priori c'est énorme.