IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Pour ou contre le multithreading dans les moteurs 3D ?

Votants
75. Vous ne pouvez pas participer à ce sondage.
  • Pour

    72 96,00%
  • Contre

    3 4,00%
Développement 2D, 3D et Jeux Discussion :

Que peut apporter le multithread au développement de jeux ? [Débat]


Sujet :

Développement 2D, 3D et Jeux

  1. #121
    Membre actif
    Avatar de Fabien Henon
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Points : 226
    Points
    226
    Par défaut
    D'accord merci de ta réponse, ça confirme ce que je pensais. car en fait je me suis demandé pendant un moment si faire de la programmation multithread pour un processeur multi core, était différent de la programmation multithread simple (comme on en voit en effet partout pour les chargement, musique, etc...) => et quand je dis ça je parle au niveau du code, pas au niveau de la conception, qui elle, est en effet différente dans bien des situations.

    Sinon de mon côté pour entrer dans le débat je suis pour la programmation multithread dans les jeux, bien que la conception derrière soit parfois plus complexe (je serais même tenté de dire que c'est tout le temps le cas).

    Et sinon au sujet de revenir au software rendering, ça me parait être bien, mais est-ce que ça va impliquer de gros changements dans la programmation des jeux? Je serais tenté de dire que non, car si c'est le cas, les jeux développés pour ce type de carte ne seraient même pas compatibles avec les cartes actuelles, et pour ma part je me vois mal faire 2 versions du jeu pour gérer les différences (surtout que tout le monde n'aura pas ces cartes en même temps et beaucoup de monde restera donc encore pendant un moment sur les cartes actuelles).

    Et sinon qu'en est il de l'avenir du raytracing dans tout ça?
    Soft Creations - FirmLife

    Soft Creations: Blog de Fabien Henon et site de prestations de sites web et applications mobiles
    FirmLife: Le nouveau jeu de gestion d'entreprises en ligne

  2. #122
    screetch
    Invité(e)
    Par défaut
    Pour synthétiser ce qui a été dit précédemment :

    - de nombreux jeux (presque tous) sont déjà multi-threads, pour pouvoir par exemple gérer le son et le graphisme indépendamment. Mais ils sont en général prévus pour être executés sur des simples cores

    - lorsque ces jeux passent sur des multi-core, on pourrait s'attendre a un facteur x2 puisqu'on a deux CPU, mais en fait il n'en est rien

    - en effet, les tâches effectuées dans des threads "correspondent mal"; dans une frame du jeu qui dure 30 millisecondes, il est possible que le jeu prenne 29 millisecondes (donc sur le CPU 1) et que le son ne prenne que 1 milliseconde (sur le CPU 2) donc le CPU 2 est sous utilisé

    - On peut intuitivement esperer mieux en séparant le jeu en plus de taches (IA, rendu, particules, son, réseau, etc etc)

    - mais cela reste une solution mitigée car cela ne permettra pas de s'adapter a un nombre de CPU importants (16,32 voire... le futur)


    D'ou le début de la discussion, comment changer le design d'un moteur pour pouvoir s'adapter au mieux a la montée en nombre des CPU. Soit, comment occupper 100% de toute les ressources de la machine (CPU, GPU).

    De plus, qui dit nombreux CPU dit nombreuses communications : "t'as fini ta tache ? balance le resultat. attend, pause, je fais un truc!! vas y, reprend. Je t'envoie des données!". Si toute les taches s'interrompent sans cesse pour demander l'état des autres taches, ou tres tres frequemment, en attente de données, alors la machine ne "travaille" pas. Il faut donc réussir a rendre les taches locales le plus possible, et avoir aussi peu de dépendances que possible. Le mieux est lorsqu'il n'y a pas de communication (c'est le principe du "fire and forget" : je lance une tache, elle se debrouille toute seule, pas besoin de quoi que ce soit)

  3. #123
    Membre éprouvé
    Avatar de Ange_blond
    Homme Profil pro
    Ingénieur développement en 3D temps réel
    Inscrit en
    Mars 2007
    Messages
    902
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement en 3D temps réel
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2007
    Messages : 902
    Points : 1 179
    Points
    1 179
    Par défaut
    Sympa le petit résumé, merci beaucoup :-)

    Je peux me tromper, mais de plus ce sont les carte graphiques et leurs GPU qui font de plus en plus de boulot (shader, PhysiX, ...) et donc, sauf connaissances tres avancées, le multi CPU ne sera plus une priorité, la CG fesant le gros du boulot...

    Apres en effet, il restera toujours des difficultées pour gagner en temps de rendu, mais avec la montée en puissance des bécanes, les jeux et leurs codeurs plutot ne prennent plus la peine d'optimiser comme c'était le cas par le passé. De nos jours il suffit de marque sur la pochette qu'il faut une bonne bécane, (sous entendu 2Go de RAM, 2GHz, 10 Go de DD) et hop tout le monde est ravi.
    Bien sûr les graphismes ont évolué, mais je ne pense pas me tromper bcp en disant qu'a présent, avec cette course au photo-réalisme, on perd de vue que le joueur moyen n'as pas envie de changer de bécane tout les 2 ans pour pouvoir jouer aux jeux de derniere génération...
    "le langage C permet de tout faire, y compris se tirer dans le pied. Le langage C++ permet de tout faire, y compris se tirer dans le pied - et réutiliser la balle"

  4. #124
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Citation Envoyé par Ange_blond Voir le message
    Je peux me tromper, mais de plus ce sont les carte graphiques et leurs GPU qui font de plus en plus de boulot (shader, PhysiX, ...) et donc, sauf connaissances tres avancées, le multi CPU ne sera plus une priorité, la CG fesant le gros du boulot...
    Je pense plus que le GPU va progressivement laisser la place au CPU directement. Le GPU devient de plus en plus programmable, il y a déjà des projets de processeurs avec GPU intégré. Et pour que le CPU puisse travailler tranquillement pendant que le GPU fait ses petites affaires, quoi de plus simple qu'un GPU qui soit un CPU ?

  5. #125
    Expert confirmé
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 519
    Points : 5 168
    Points
    5 168
    Par défaut
    Citation Envoyé par Ange_blond Voir le message
    Je peux me tromper, mais de plus ce sont les carte graphiques et leurs GPU qui font de plus en plus de boulot (shader, PhysiX, ...) et donc, sauf connaissances tres avancées, le multi CPU ne sera plus une priorité, la CG fesant le gros du boulot...
    sauf qu'aujourd'hui, les gros jeux qui mettent à jenoux des machines de guerre sont limités par... le CPU

    Citation Envoyé par screetch Voir le message
    De plus, qui dit nombreux CPU dit nombreuses communications : "t'as fini ta tache ? balance le resultat. attend, pause, je fais un truc!! vas y, reprend. Je t'envoie des données!". Si toute les taches s'interrompent sans cesse pour demander l'état des autres taches, ou tres tres frequemment, en attente de données, alors la machine ne "travaille" pas.
    faire cela dans un moteur de rendu temps réel c'est... suicidaire

    que ce soit opengl ou directx seul le thread ayant créé a fenêtre peut envoyer des commandes, partant de ce constat je me suis dit :
    - un thread principal qui s'occupe de communiquer avec le driver et qui demande à un thread de travail (via des events) de faire quelque chose (déplace les objets, gère les collisions, lance un son dans le thread sonore...)
    - le thread de travail dont on peut lancer autant d'instance que l'on veut (en fonction du nombre de coeurs disponibles) va faire le travail à la demande du thread principal

    Ainsi on a le thread principal qui fait office de chef d'orchestre et qui répartit les taches entre les threads de travail
    s'il y a 1000 objets à déplacer il peut en donner 500 à un thread 500 à un autre

    perso je n'ai pas encore eu le temps d'expérimenter la chose mais ça me botte bien comme principe
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  6. #126
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Décembre 2008
    Messages
    59
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Décembre 2008
    Messages : 59
    Points : 18
    Points
    18
    Par défaut
    Sous le nouveau moteur Unreal mes 4 Core fonctionne.
    Il en prend donc partie?

  7. #127
    Expert confirmé
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 519
    Points : 5 168
    Points
    5 168
    Par défaut
    si tu n'a pas d'autre application lancée en même temps que le jeu alors oui il en tire partie, ce qui ne serait pas étonnant puisque ce moteur a été créé en prenant en compte les spécificités des consoles de dernière génération :
    - le processeur Xenon de la Xbox360 et ses 3 coeurs SMT peut gérer 6 threads
    - le processeur Cell de la PS3 peut gérer 2 threads sur le coeur principal + 8 sur les coeurs spécifiques
    et donc il est probable qu'il exploite un certain nombre de coeurs pour optimiser ses traitements
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  8. #128
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Décembre 2008
    Messages
    59
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Décembre 2008
    Messages : 59
    Points : 18
    Points
    18
    Par défaut
    Sur mes jeux je crois c'est le seul, Crysis lui ne prend que 2 Coeurs.

    C'est quoi la différence entre Treadh et Coeurs?
    Un Q6600 à 4 coeurs, soit 4 processeur physique....

  9. #129
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Les cores, c'est en gros le nombre de processeurs. Sauf que certains cores peuvent gérer plusieurs threads à la fois, à savoir plusiurs fils d'exécution. En même temps, si tu es sur cette conversation, tu dois au moins savoir la différence...

  10. #130
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Décembre 2008
    Messages
    59
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Décembre 2008
    Messages : 59
    Points : 18
    Points
    18
    Par défaut
    A ba non je ne connaisai pas la différence, j'ai monter des dizaine de proc sans savoir ca.

    Les intel Quad sont toujours 4 core avec 4 Tread?

  11. #131
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Un thread, c'est un fil d'exécution. Sur les nouveaux Intel, il y a à nouveau 2 fils par coeur.
    Mais ça dépend plus de la capacité multi-thread du programme.

  12. #132
    Rédacteur
    Avatar de Bakura
    Homme Profil pro
    Étudiant
    Inscrit en
    Septembre 2005
    Messages
    1 386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2005
    Messages : 1 386
    Points : 2 640
    Points
    2 640
    Par défaut
    Intel a mis en ligne un papier sur ça : http://software.intel.com/en-us/arti...el-game-engine

    Pas eu le temps de lire par contre

  13. #133
    Expert confirmé
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 519
    Points : 5 168
    Points
    5 168
    Par défaut
    Citation Envoyé par Bakura Voir le message
    Intel a mis en ligne un papier
    papier basé sur leur récente démo dont raptor70 nous a d'ailleurs généreusement fait part

    globalement c'est l'idée que je me faisait d'un moteur multithreadé
    les taches qu'un moteur doit accomplir à chaque image : gérer les déplacements, les collisions, l'IA, envoyer du son, ect
    disons que le thread principal, à son lancement :
    - crée un thread pour gérer une liste de taches à faire à chaque image
    - crée un thread de travail pour chaque coeur disponible (1 sur un dualcore, 3 sur un quadcore 7 sur un i7 vu qu'il est capable de gérer 8 threads)
    puis le thread principal bascule à son tour en thread de travail
    le thread de répartition des taches distribue les taches courante à tous les travailleurs

    c'est pas compliqué vu d'ici mais à coder et pire à débugguer

    mais à l'heure actuelle, les taches de rendu ne peuvent être effectuées QUE par le thread principal, celui qui a créé la surface de rendu
    il va donc être le seul à les faire et il faudra qu'il les gère et en priorité pour éviter de créer un goulot d'étranglement
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  14. #134
    Rédacteur
    Avatar de Bakura
    Homme Profil pro
    Étudiant
    Inscrit en
    Septembre 2005
    Messages
    1 386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2005
    Messages : 1 386
    Points : 2 640
    Points
    2 640
    Par défaut
    - crée un thread pour gérer une liste de taches à faire à chaque image
    - crée un thread de travail pour chaque coeur disponible (1 sur un dualcore, 3 sur un quadcore 7 sur un i7 vu qu'il est capable de gérer 8 threads)
    puis le thread principal bascule à son tour en thread de travail
    le thread de répartition des taches distribue les taches courante à tous les travailleurs
    C'est vrai que dit comme ça, ça a l'air d'une simplicité .

    Par contre pour le papier d'Intel, ils parlent bien de dupliquer toutes les données ? Visiblement c'est un peu ce qu'il ressort un peu partout... J'y connais pas grand chose en programmation multi-thread, mais j'avais lu un papier qui expliquait comment construire un BVH (pour le raytracing) en parallèle, et effectivement ils dupliquaient toutes les données (là ça concernait les vertices des triangles...) et travaillait avec celles-ci, et dès qu'il avait fini, il envoyait son nouveau résultat et il récupérait toutes les données nouvelles, et il repartait... Le problème c'est que si le BVH mettait trop de temps à se construire (bon, c'était pas le cas ici), ben il renvoyait un arbre qui était déjà complètement has-been par rapport aux données, puisqu'il utilisait des données déjà périmées de pas mal de frames ^^.

    Pour ceux qui souhaiteraient lire : http://www.cs.utah.edu/~thiago/paper...BVHJournal.pdf

  15. #135
    Expert confirmé
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 519
    Points : 5 168
    Points
    5 168
    Par défaut
    Je n'ai pas l'impression que le papier d'Intel parle de la duplication des données

    pour ma part, je pense que les moteurs utiliseront de plus en plus de données avec le temps, de ce fait cela risque d'être pénalisant de dupliquer les données
    Citation Envoyé par Bakura Voir le message
    Le problème c'est que si le BVH mettait trop de temps à se construire (bon, c'était pas le cas ici), ben il renvoyait un arbre qui était déjà complètement has-been par rapport aux données, puisqu'il utilisait des données déjà périmées de pas mal de frames ^^.
    et on risque de ce retrouver dans ce cas de figure

    c'est plus un préjugé qu'une réelle expérience
    mais avec l'augmentation des coeurs on pourra peut-etre en dédier un ou plus à la duplication pendant que les autres travaillent au traitement
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  16. #136
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    113
    Détails du profil
    Informations personnelles :
    Localisation : France, Sarthe (Pays de la Loire)

    Informations forums :
    Inscription : Avril 2007
    Messages : 113
    Points : 99
    Points
    99
    Par défaut une API pour développer des jeux vidéo multithread
    Je viens de finir une version exploitable de l'API sur laquelle je travaille actuellement, en gros c'est une API qui promet :
    - un temps de développement, debuggage et maintenance maîtrisé.
    - une grande simplicité d'utilisation
    - des performances dépendants directement de la fréquence du processeur ET du nombre de coeurs.

    Au niveau perf j'ai mis des vidéos qui montre des gains de :
    - 1.8x sur 2 threads
    - 2.4x sur 3 threads, et
    - 2.55x sur 4 threads (le résultat est faussé par l'OS et les applications en tache de fond)

    Si vous voulez plus d'infos : http://www.developpez.net/forums/d67...deo-parallele/

    Vincent

  17. #137
    Membre averti
    Homme Profil pro
    Game Graphics Programmer
    Inscrit en
    Août 2006
    Messages
    408
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Game Graphics Programmer
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2006
    Messages : 408
    Points : 392
    Points
    392
    Par défaut
    Juste pour vous donner quelques liens intéressants en rapport avec le multi-threading:

    JobSwarm, une lib pour créer des micro-threads en grand nombre:
    http://code.google.com/p/jobswarm/
    http://codesuppository.blogspot.com/...work-with.html


    Des papiers sur les "lock-free data structures" (par, entre autres, Andrei Alexandrescu)
    http://en.wikipedia.org/wiki/Lock-fr...ree_algorithms
    http://erdani.org/publications/cuj-2004-10.pdf
    http://erdani.org/publications/cuj-2004-12.pdf
    http://www.research.ibm.com/people/m.../pldi-2004.pdf
    http://www.research.ibm.com/people/m/michael/pubs.htm
    http://www.open-std.org/jtc1/sc22/wg...007/n2427.html

    Google Performance Tools, une lib de malloc/free multi-threadé et compatible STL:
    http://code.google.com/p/google-perf...rformanceTools
    une autre lib similaire: Hoard
    http://www.hoard.org/

    Bonne lecture.

  18. #138
    Membre émérite
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 537
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 537
    Points : 2 548
    Points
    2 548
    Par défaut
    Omagad !

    Super cette documentation. Je m'en vais de ce pas l'engloutir.

  19. #139
    Membre averti
    Homme Profil pro
    Game Graphics Programmer
    Inscrit en
    Août 2006
    Messages
    408
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Game Graphics Programmer
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2006
    Messages : 408
    Points : 392
    Points
    392
    Par défaut
    Voici un petit article sur GamaSutra à propos des moteurs multi-threadés:
    http://www.gamasutra.com/view/featur...gning_the_.php

    Bonne lecture.

  20. #140
    Rédacteur
    Avatar de Bakura
    Homme Profil pro
    Étudiant
    Inscrit en
    Septembre 2005
    Messages
    1 386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2005
    Messages : 1 386
    Points : 2 640
    Points
    2 640
    Par défaut
    Merci pour ce lien

Discussions similaires

  1. Que peut on utiliser à la place des popup
    Par david42 dans le forum Général JavaScript
    Réponses: 6
    Dernier message: 14/02/2006, 09h21
  2. [UML] Que peut-on vraiment faire avec ces logiciels ?
    Par pugnator dans le forum Outils
    Réponses: 6
    Dernier message: 07/12/2005, 12h31
  3. Que peut-on faire avec une vue ?
    Par Invité dans le forum Décisions SGBD
    Réponses: 8
    Dernier message: 20/10/2005, 12h13
  4. [Securité]Que peut-on faire contre un décompilateur?
    Par Hannappel dans le forum Langage
    Réponses: 3
    Dernier message: 02/10/2005, 13h36
  5. Réponses: 1
    Dernier message: 27/05/2005, 10h52

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo