Discussion :

[LittleWhite]

Les développeurs d'un émulateur WiiU reçoivent 24 000 dollars par mois pour leur travail

Depuis 2015, deux émulateurs WiiU sont en cours de développement : decaf et cemu. Le premier est un projet open source alors que le second est entièrement fermé. D'ailleurs, le développeur (ou l'équipe de développeurs) a lancé une campagne Patreon dans laquelle les donateurs pourront accéder à la nouvelle version de l'émulateur une semaine avant les autres. Jusqu'à peu, le Patreon était resté timide.
Généralement, ce genre de projet passe plutôt inaperçu, du moins, tant que les émulateurs ne sont pas assez performants/stables pour faire fonctionner des jeux commerciaux. Toutefois, les sites spécialisés ont mis en avant cemu. En effet, depuis quelques mois, l'émulateur est capable de faire fonctionner les jeux commerciaux (dont Mario Kart, New Super Mario Bros et Xenoblades Chronicles X) malgré quelques problèmes. Même si la WiiU est une console en fin de vie, le dernier Zelda est sorti sur celle-ci. cemu arrive à l'émuler comme le montre cette vidéo :

Et comme cela est montré, un émulateur a la capacité d'augmenter la taille des tampons de rendu afin de gagner en finesse d'image. De même, un émulateur permet aussi d'avoir un rendu fluide là où la console peut être à bout. Évidemment, cela dépend de votre configuration et de cemu (celui-ci n'utilise pas toutes les capacités, telles que l'hyper-threading, et pas à fond la carte graphique).
De ce fait, alors que les joueurs n'ayant pas de WiiU se demandent s'il faut prendre la Nintendo Switch pour pouvoir jouer à Zelda: Breath of the Wild, l'équipe de cemu apporte une réponse plutôt inattendue. Fort de ce constat, la version suivante de l'émulateur améliorera, avant tout, l'émulation de ce jeu. D'autant plus que le public semble être convaincu de cette solution au vu de l'augmentation soudaine de popularité de l'émulateur et du nombre de mécènes sur la plateforme de financement. Ainsi, les développeurs reçoivent 24 000 $ par mois.

Toutefois, ne sautez pas non plus de joie si vous souhaitez jouer à Zelda. En l'état, le jeu ne peut pas être fini avec l'émulateur.


Votre opinion

Que pensez-vous des émulateurs ? Pensez-vous qu'ils doivent être open source ou fermés ? Est-ce que cela a une importance pour vous ?
Trouvez-vous que cette rémunération est légitime ? Ce travail doit-il être récompensé ?

[Haseo86]

Bien dommage que le public choisisse de privilégier un système fermé.

Perso je pense qu'un émulateur non open source trahit forcément la philosophie de base quelque part.

[RyzenOC]

es ce bien légale tous cela ?

Autant pour l'émulation de vielles consoles style PS2 et < je pense pas que cela pose de probleme, les fabricants comme sony ou crosoft s'en foute un peu (MS n'a jamais levé le petit doigt sur le piratage des vielles version de windows 9.x et 3.x par exemple)

Mais la il s'agit de produit assez récent avec un jeu sortie il y'a 1 mois..., ce qui peu porter atteinte aux benef de l'entreprise, je pense que tous cela vas se finir au tribunal et le projet sera abandonné/interdit, au mieux ils mettrons le code source en libre accès.

Parce que il s'agit aussi de faire la promo du piratage, ceux qui vont jouer à zelda avec l'émulateur n'ont pas acheté le jeu, ils ont téléchargé la rom sur un site tipiak ne nous voilons pas la fasse, je suis le 1er à le faire.

[MikeRowSoft]

Que pensez-vous des émulateurs ? Pensez-vous qu'ils doivent être open source ou fermés ? Est-ce que cela a une importance pour vous ?

Les émulateurs, j'aime bien, surtout les principes de cheats codes et sauvegarde à tous instants.

Trouvez-vous que cette rémunération est légitime ?

Oui, c'est du code source qui est écrit et compilé.

Un jeu récemment sorti émulé, oui, cela n'est pas sur que le kit de développement ai reçu des mises à jour.

Comme pour Webkit/Wi-Fi dans la nouvelle console de Nintendo...
source : http://www.clubic.com/video/actualit...ee-486536.html

[FatAgnus]

Les émulateurs de consoles ou de jeux sont importants, ces émulateurs permettent de préserver les jeux vidéos. C'est intéressant de pouvoir montrer aux nouvelles générations des jeux Commodore 64, NES, ... sortis dans les années 1980 tournant sous un émulateur. Et dans vingt ans nous seront content de pouvoir voir les vieux jeux Wii U et les faire partager à ceux qui ne sont pas nés aujourd'hui.

C'est pour cette raison que les émulateurs doivent être open-source et multiplate-forme. Cemu, un logiciel fermé et fonctionnant que sous Windows, n'aura pas un dollar de ma part. Alors que decaf-emu est diffusé en GPLv2 et fonctionne sous Windows et GNU/Linux, si les développeurs demandent de l'argent, je leur en donnerait sans hésiter.

[TiranusKBX]

@RyzenOC
Les émulateur tant qu'ils n'utilisent pas un dump(copie) du système la console sont totalement légal dus moins en France
Par contre cemu laisse planer un énorme doute de par le fait que les sources sont fermées

[Mat.M]

Bien dommage que le public choisisse de privilégier un système fermé.

avant de critiquer peut-être faudrait-il prendre le temps de comprendre un minimum...le système est fermé certainement pour des questions de royalties versées à des tierces.

[Ryu2000]

Que pensez-vous des émulateurs ? Pensez-vous qu'ils doivent être open source ou fermés ? Est-ce que cela a une importance pour vous ?

Les émulateurs sont extrêmement importants ils permettent de préserver l'histoire du jeux vidéo.
Et c'est cool de pouvoir rejouer à tous les vieux jeux qu'on a connu ou manqué.
Pour l'arcade c'est génial, il faut se procurer un bon stick, et après hop on émule CPS1, CPS2, Neo Geo ou un autre système compris dans MAME. (en plus il y a moyen de jouer en réseau)

Open Source c'est mieux, mais un émulateur fermé peut être bon également.

Trouvez-vous que cette rémunération est légitime ? Ce travail doit-il être récompensé ?

Je ne suis pas fan d'émulation de jeu récent...
Les joueurs peuvent acheter une Wii U + le nouveau Zelda ou une Switch et le nouveau Zelda facilement.

Je préférerai que des développeurs bossent pour que l'émulation Naomi fasse partie de MAME, mais plus de gens sont intéressé par l'émulation Wii U.

[MikeRowSoft]

Pour l'arcade c'est génial, il faut se procurer un bon stick, et après hop on émule CPS1, CPS2, Neo Geo ou un autre système compris dans MAME. (en plus il y a moyen de jouer en réseau)

À la Geek Convention de Clermont-Ferrand il y avait un stand avec des bornes d'arcades que le responsable du stand vendait, vraiment du très beau travail t'en sur la finition que le côté technique (utilisation d'un écran de Minitel pour l'un dès modèle exposé)

[Ryu2000]

À la Geek Convention de Clermont-Ferrand il y avait un stand avec des bornes d'arcades que le responsable du stand vendait

Il y a moyen d'acheter une vraie borne d'arcade rénové sur des sites comme :
http://arcade.am/
Il y a moyen de se procurer une SEGA New Astro City par exemple.

Le guide d’achat d’une borne d’arcade

Et sinon en borne construite il y a ça :
http://www.r-cade.fr/categorie-produit/1-borne/

Ils font des trucs comme ça :

[_FLX_]

Il faut saluer la prouesse technique, mais faire de l'argent dessus c'est pas fair-play.
L'émulation de vieux jeux/consoles devenus trop durs a trouver ok, mais quand le jeu viens de sortir non.
Pour une fois une réaction des ayant-droits et surtout de Nintendo, connue pour ne rien laisser passer, me semble tout a fait normale.

[LittleWhite]

Il faut aussi savoir que le SDK de la WiiU a fuité en 2014. Il est possible (c'est une hypothèse, car il est dur de vérifier une telle chose) que les développeurs de cet émulateur reposent principalement sur le SDK, et non sur un reverse a proprement parler de la console.

Je suis pour la préservation du patrimoine et donc, je trouve que les émulateurs aident à conserver ce patrimoine. Par contre, un émulateur fermé n'aide en rien à la conservation du patrimoine, ni même à comprendre comment la console a été conçue/fonctionne. Dans ce dernier cas, ce n'est que du piratage.

[MikeRowSoft]

Il faut aussi savoir que le SDK de la WiiU a fuité en 2014. [...]
Je suis pour la préservation du patrimoine et donc, je trouve que les émulateurs aident à conserver ce patrimoine. [...] Dans ce dernier cas, ce n'est que du piratage.

Tu as bien raison, Nintendo est une entreprise, tous comme les divers éditeurs sur sa plateforme et non un artiste autodidacte tel un peintre.
Ma sauvegarde et ma créativité de joueur tu en fait quoi ?

Franchement, dans l'histoire de l'informatique et du numérique/analogique, une entreprise à déjà demandé à des pirates les moyens de récupérer le MASTER ou une copie/dump ?

[Kannagi]

Je trouve cemu inintéressant pas de code source + windows only....

Bon pour le reste il faut mettre les choses au clair la pratique n'a rien de nouveau , la fabrication d'émulation se fait souvent pendant la durée de vie de la console (enfin en fin de vie) , sauf que avant y'avait pas internet et personne n'en parlait.
Il ne faut pas se leurrer faut mieux que l'émulation se fait pendant la durée de vie , après ça sera beaucoup plus compliqué , je soupçonne fortement que l'émulation de certaine console ont était fait grâce a des programmeurs qui bossait dans le milieu , après on peut trouver ça nul oui mais vous n'aurez probablement pas une bonne émulation même au bout de 20 ans faut faire ds choix
Je rajouterai qu'il y'a toujours eu des fuites des documentations officiel (qui aide énormément a la fabrication de l'émulateur) ensuite l'explication du fonctionnement du matériel qui a sûrement aidé sur la précision de l'émulateur.

Ou alors on se retrouve avec des genres de M.A.M.E ou y'a plein de 'if' pour que tel jeu marche correctement , cela signifie aussi que ces machines resteront a tout jamais dans l'inconnu (personne ne saura comment elle fonctionne précisément) , moi je trouve ça complètement nul en terme de savoir et de patrimoine (tant technique que artistique).

[LittleWhite]

D'après ce que je sais, le second cas d'émulation durant une durée de vie commerciale de la console est la Nintendo 64. Pour le reste, c'est vrai que c'est plus en fin de vie.
Après, l'émulation repose beaucoup (si ce n'est pas énormément) sur le reverse pur et dur de la console. Si vous ne pouvez pas exécuter vos propres logiciels sur la console (homebrew) alors il sera très très dur de faire la documentation et donc, très dur de faire l'émulateur. De plus, il faudra lancer côte à côte un produit émulé avec sa version originale pour voir les détails et les défaut. C'est ce que font les développeurs de l'émulateur GameCube/Wii (Dolphin). La console à tout de même dix ans et il n'y a que depuis quelques mois qu'ils ont réussi à lancer le dernier jeu qui ne se lançait pas sur l'émulateur. (D'ailleurs, l'émulateur Wii a démarré comme émulateur fermé.) Et même si globalement l'émulateur fait fonctionner les jeux, il y a encore énormément de défaut.
Que le SDK fuite, c'est une chose et cela débloque l'émulation HLE (ré-implémentation des fonctions interfaçant le matériel à la console). Par contre, dans ce cas, rien ne dit que vous fassiez exactement comme le matériel d'origine. Si vous pouvez tester ce que fait le matériel et le reverse, vous pouvez faire du LLE et obtenir un résultat bien plus fidèle.
Par contre, la documentation exacte des puces ne fuitent rarement (je n'ai pas de cas en tête ou cela a fuité). Pire, les puces sont parfois personnalisés pour le constructeur de console et ont des comportements différent de la gamme "classique" d'une même puce.

Je tiens à faire remarquer que la Saturn n'est toujours pas correctement émulée

[Kannagi]

Je serait d'accord mais la plupart des émulateurs sont fait de manière beaucoup plus simple , émulation du CPU + connaissance des I/O (donc de la memory map).
Je doute que le souci se trouve sur le premier (émulation du CPU) , la plupart des émulateur l'émul correctement (je connais en faite pas d'émulateur qui a un souci de ce niveau ) , enfin sauf peut etre la Sega Saturn , faire fonctionné 8 processeurs et savoir comment il communique entre eux avec une certaine précision ne doit pas être facile aie:

L'autre point est plus problématique parce que même par retro ingénierie apparemment ça peut avoir ces limites , je prend un truc sur Taito F3 l'émulateur MAME met : "Unknown 0x4c0000, 0x4c0003 " , et en debuggant certain rom des jeux l'utilisait pendant l'initialisation , le truc c'est qu'on sait pas ce que ça fait
Et c'est cette partie qui coince en général quand on débute un émulateur , le fonctionnement des I/O , les documentations officiel fourni en général une I/O complète (ou presque complète) de leur machine et c'est vraiment non négligeable .
Le dernier souci et comment cela fonctionne -t-il concrètement (avec quel contrainte aussi) et la c'est plus complexe , parce que il faut que les I/O fonctionne avec une certaine fidélité pour que cela marche bien , par exemple de savoir quand se fait exactement l'affichage , trop tôt ou trop tard pourrait causer quelque bug visuel sur certain jeux.
Le second point (les contraintes) tout les émulateur se plante lamentablement n'en possédant par nature pas , elle sont en général plus 'laxiste' que la machine cible.

Pour je que je disais que il y'a certainement d'ancien programmeur qui ont sûrement aidé , je pense principalement a la PS2 et a ces 2 coprocesseurs VU0 et VU1 en retro ingénierie , ça serait quasi impossible de savoir comment elle fonctionne les puces sont intégrée au processeur principal
La lecture des binaires n’aiderait pas , si on ne sait ni leur opcode , ni leur instruction et j'ai pas vu de doc officiel sur le net qui en parlait (mais il y'a des doc non officiel par contre).
Donc la a part un tools officiel qui a fuité ou un ancien qui a bossé dessus , je vois mal comment ils ont su , enfin surtout quand je vois la date de l'explication du VU + exemple de code : 2004 , a peine 3-4 ans après la sortie de la console je trouve cela relativement tot pour la connaître de bout en bout une tel partie

[LittleWhite]

Je serait d'accord mais la plupart des émulateurs sont fait de manière beaucoup plus simple , émulation du CPU + connaissance des I/O (donc de la memory map).

C'est vrai que pour les consoles "simples" ou "anciennes". Celle qui n'ont pas de système d'exploitation (le BIOS n'est pas vraiment un système d'exploitation).

Et c'est cette partie qui coince en général quand on débute un émulateur , le fonctionnement des I/O , les documentations officiel fourni en général une I/O complète (ou presque complète) de leur machine et c'est vraiment non négligeable .

Comme je l'ai dit, c'est dur d'avoir une telle doc, sachant qu'il arrive que certains constructeurs ont des variantes personnalisés de la même puce.

par exemple de savoir quand se fait exactement l'affichage , trop tôt ou trop tard pourrait causer quelque bug visuel sur certain jeux. Le second point (les contraintes) tout les émulateur se plante lamentablement n'en possédant par nature pas , elle sont en général plus 'laxiste' que la machine cible.

Et c'est lorsque l'on reproduit à 100 % la console d'origine (avec les mêmes crash, les mêmes bogues, les mêmes rendus) que l'on peut parler de préservation. L'équipe derrière Dolphin fait actuellement un gros travail de développement pour avoir un comportement toujours plus fidèle (même jusqu'à émuler les particularités de la lecture du DVD, car cela influe sur les timing dans les Metroid, et que sans, alors l'émulateur ne peut pas être utiliser à des fins de speedrunning).
La solution chez les gars de Dolphin, c'est de comparer le résultat d'une console réelle, avec le résultat de l'émulation et ce, de manière automatisée. Il suffit de voir les derniers progress report pour voir que c'est un boulot de fourmis.

Pour la PS2, je ne sais pas vraiment. On m'a dit qu'il y avait une doc disponible, mais que même celle disponible avait des différence avec l'implémentation réelle .

[MikeRowSoft]

Sachant que la plus part des émulateurs ont au moins une rom "légale" en téléchargement, je comprend encore plus ton souhait du open source.

[Kannagi]

C'est vrai que pour les consoles "simples" ou "anciennes". Celle qui n'ont pas de système d'exploitation (le BIOS n'est pas vraiment un système d'exploitation).

Ben OS ou pas , cela n’empêche pas que CPU + I/O (memory map) reste la base , L'OS est juste un 'programme' en plus sur ces machines.

Comme je l'ai dit, c'est dur d'avoir une telle doc, sachant qu'il arrive que certains constructeurs ont des variantes personnalisés de la même puce.

Je crois que en ne se comprend pas ,je parle pas du fonctionnement de la puce interne , je parle que tel I/O = tel action.
Comme je l'ai dit , sans doc on peut se retrouver avec des I/O complètement inconnu.
Et ça toute les doc officiel l'offre (sinon je vois pas comment les programmeur peuvent coder leur jeu un minima , même si les SDK ont évolué pour ne pas se soucier trop du matériel).
Je te le répète cite moi une machine qui aurait ces I/O qui changerait ? en général elle est fixe et la doc officiel donne au moins une description (certes pas forément détaillé) de celui ci.
Un exemple bidon genre 0XF003 affiche un triangle d'un point de vue programmeur faudra juste écrire dessus pour afficher son triangle , d'un point de vue de l'émulateur , comment on affiche le triangle (par rapport au x effet qu'on lui implémente) et a quel moment ? on se rejoint dans le sens ou la doc ne donne pas ce genre d'info (ou vaguement).
Mais la doc donne bien une info sur celui tout de même , et c'est pas une variante.

Et c'est lorsque l'on reproduit à 100 % la console d'origine (avec les mêmes crash, les mêmes bogues, les mêmes rendus) que l'on peut parler de préservation. L'équipe derrière Dolphin fait actuellement un gros travail de développement pour avoir un comportement toujours plus fidèle (même jusqu'à émuler les particularités de la lecture du DVD, car cela influe sur les timing dans les Metroid, et que sans, alors l'émulateur ne peut pas être utiliser à des fins de speedrunning).
La solution chez les gars de Dolphin, c'est de comparer le résultat d'une console réelle, avec le résultat de l'émulation et ce, de manière automatisée. Il suffit de voir les derniers progress report pour voir que c'est un boulot de fourmis.

C'est tres bien pour Dolphin de vouloir reproduire a 100% J'ai jamais étudié Dolphin mais vu que c'est un souci sur tout les émulateurs , le souci ne vient pas du CPU ou des I/O mais juste le comportement exact de celui ci (j'ai donné l'exemple pour l'affichage ou le triangle).
Enfin je dirait plutôt que un émulateur n'est pas un simulateur d'un machine , si tu émul tel CPU , on est d'accord que on reproduit pas le fonctionnement exact de celui ci , en général en faite on transpose son effet (et ça marche très bien dans les grandes lignes).
Le souci de reproduire les crash sur la fabrication des émulateurs doit venir d'une implémentation arbitraire , je prend un exemple admettant que tu lis le joypad au mauvais moment , sur un émulateur a part l'interdire tu ne fera pas grand chose , sur une machine réelle cela peut causer un bug visuel , donc a part coder sciemment un tel crash tu ne l'aura pas sur l'émulateur.

[LittleWhite]

Ben OS ou pas , cela n’empêche pas que CPU + I/O (memory map) reste la base , L'OS est juste un 'programme' en plus sur ces machines.
Je crois que en ne se comprend pas ,je parle pas du fonctionnement de la puce interne , je parle que tel I/O = tel action.
Comme je l'ai dit , sans doc on peut se retrouver avec des I/O complètement inconnu.
Et ça toute les doc officiel l'offre (sinon je vois pas comment les programmeur peuvent coder leur jeu un minima , même si les SDK ont évolué pour ne pas se soucier trop du matériel).
Je te le répète cite moi une machine qui aurait ces I/O qui changerait ? en général elle est fixe et la doc officiel donne au moins une description (certes pas forément détaillé) de celui ci.
Un exemple bidon genre 0XF003 affiche un triangle d'un point de vue programmeur faudra juste écrire dessus pour afficher son triangle , d'un point de vue de l'émulateur , comment on affiche le triangle (par rapport au x effet qu'on lui implémente) et a quel moment ? on se rejoint dans le sens ou la doc ne donne pas ce genre d'info (ou vaguement).
Mais la doc donne bien une info sur celui tout de même , et c'est pas une variante.

Mais, ce fonctionne de l'émulateur n'est plus vrai depuis une certaine époque. C'est bien pour les vieille machine qui demande peu de puissance (disons 8 bits et 16 bits), mais pour la suite, ce n'est pas tangible comme méthodologie. Prenez n'importe quelle machine avec un GPU dédié, il faudra faire du reverse pour savoir comment l'étape de blend a été réalisée, comment il gère les shaders, comment il fait la rasterization et ainsi de suite. Et ce, peut importe que vous appeliez une fonction drawTriangle(), si le GPU fait des trucs un peu farfelu, il faudra reproduire, car le code du jeu sera adapté à la machine et non l'inverse.
Les machines récentes ne dit plus "on met tel état sur telle pin".

Enfin je dirait plutôt que un émulateur n'est pas un simulateur d'un machine , si tu émul tel CPU , on est d'accord que on reproduit pas le fonctionnement exact de celui ci , en général en faite on transpose son effet (et ça marche très bien dans les grandes lignes).

Dans les grandes lignes oui, mais c'est aussi pour ça que si vous faites un accès hors de la zone mémoire habituellement réservée, la console crash, votre émulateur passe (ou inversement) (même si cet accès, ne sert a rien et a été spécialement prévu pour détecter si c'est une émulation ou la console réelle).

Le souci de reproduire les crash sur la fabrication des émulateurs doit venir d'une implémentation arbitraire , je prend un exemple admettant que tu lis le joypad au mauvais moment , sur un émulateur a part l'interdire tu ne fera pas grand chose , sur une machine réelle cela peut causer un bug visuel , donc a part coder sciemment un tel crash tu ne l'aura pas sur l'émulateur.

Sauf que la lecture des contrôles est gérée par le jeu lui même. C'est le jeu qui déterminera quand il aura besoin de la valeur et l'émulateur (ou la machine) ne feront que servir la valeur. Et puis, malheureusement, si cela est autrement, il y aura des soucis dans le jeu, visible. Par exemple, prenez un replay d'une course de Mario Kart provenant d'une machine. Passez dans l'émulateur. Il faut que l'émulation soit assez parfaite, sinon, le replay ne finira jamais la course. (J'avoue, ce fut encore une problématique que j'ai connu en regardant les progress report de Dolphin).